Absolutely breathtaking!

The instrument switching is such a huge time saver and workflow enhancer. Just great. This is a major upgrade to the way we will work with VSL. Can't wait. TH

Really really cool! ...and just in my price range! Thanks herb!

Hi I was wondering, if you have your DAW on one machine and then put VE on another and connect by ethernet, do you still need midioverLan to connect to the VE? Also do I still need a audio card out of the VE machine and then and audio in on the DAW? Or will it be able to send the audio back and forth like the Muse receptor? Thanks, Simon

Yeah, it uses a protocol called uniwire. I was hoping VE had maybe written something like that. Any vienna people like to shed some light on the subject?

Well, the old VSL Performance Tool already used virtual MIDI ports, so I'd imagine it will be simple for VSL to pipe MIDI into the VE from other Windows apps (OS X has virtual MIDI built-in). But even with a 3rd party virtual MIDI app, it wouldn't have to be 32-bit. It's only the memory-intensive VE itself that needs to be 64-bit - even your sequencer could be 32-bit, since 32 and 64-bit process coexist happily on XP x64. At least that's how I understand it working...

@DG said:

Actually nothing has to be 64bit (apart from drivers), providing that you can run multiple copies. Of course this doesn't work with all audio cards.

 

DG

I have a feeling this won't work, DG, as it sounds as though the VE uses a client-server model, like the VI on OS X. So multiple standalones of the VE would not launch multiple servers... I'm not sure about this, of course, but from what I understand, they've made the new VI (2.0) VST/AU use host-based memory (as it already did on Windows), and the VE use "vsl-server"-based memory. The idea being that you can access double the RAM on 32-bit systems (well, OS X anyway, since xp standard can only ever access 3GB) by maxing out the hosts memory with VI instances, and maxing out the VE server as well. On 32-bit OS X, that would give you 3.x GB in the host and 3.x GB in the vsl-server (or whatever they call it). And what's cool about the new model (again, if I'm understanding it correctly), is that you could load VE instances **as VSTs** and still be loading up memory external to your host. This way, with a mix of VI and VE instances (all VSTs), you'd get your 7-ish GB of RAM loaded, and still be running all the audio from within your host app! But what I really don't understand is where the VE Standalone loads its memory. Is it another separate process, like the old VI Standalone, or does it also load to the vsl-server??? Of course, the real point is to just go 64-bit asap, and solve the problem in one go.... But we OS X folks are going to have to wait on that. Thanks, Apple... --- J.

I thought that leopard was supposed to be out at the start of october? But there is no mention anywhere of a release date! For people using Logic 8, if vienna works on Leopard then hopefully the transistion should be smooth enough? I just hope Altiverb works!

@Simsy said:

I thought that leopard was supposed to be out at the start of october?

Well, out some time in October. Probably *very* near the end of the month. But they're not making any noises about more delays, so I do think we'll see it in October. However, the problem with Apple and 64-bit is that they apparently got rid of a framework that VSL was using for their 64-bit support. From what I understand, frameworks are small, dynamically loaded files, so I'm not quite sure why Apple wouldn't just let VSL install the framework as part of their VE installer... (??) Dunno. But the point is that VSL now has to adapt their 64-bit support for Leopard to some new Apple framework. This won't mean a complete re-write, I don't think, but it could be a nightmare of refactoring, and then, of course, testing... And speaking of testing... 😉 ---J.