One thing that Steinberg could do would be to allow us to activate more than one project at once… Then they could synchronise when playing. I’d have thought this concept would be a small leap while giving us a great way to compose between and across different tempo maps. Then extend that idea so projects can be referenced in other projects to play like Arranger parts.
Mike.
Hi GargoyleStudio,
I don’t think that activating more than one project at once would ever be possible since one of those projects need to be a master and the rest seen as slaves. Cubase can only be a Master, there is no way to use it as a slave (not like Ableton for ex.) This is just the way Cubase was programmed and having such “limitations” built in makes the whole system very stable.
Too bad VST System Link is a neat concept but it looks like it will stay as such since nobody at Steinberg really cares about anymore. Soon we will see what Cubase 8 will have to offer 
Cheers!
Well, without digressing too much from the title… I’d say the transport would be the ‘master’. In fact I reckon that when you locate in a non-active project then it locates in the active project right now. So, if the projects could just share the transport and the inputs and outputs then we’d pretty much be there.
Mike.
Yes Mike you are right but, sharing just the transport and jumping with the playhead to the same spots on both sessions (where still, only one is active) is the easiest part (all is based on timecode/timestamp/ticks) but “just sharing” the audio part of it, all the Ins and Outs, Groups, Mixer, Inserts and Sends s definitely another pair of shoes.
It would be great though!
One of the reasons I haven’t moved to 64 bit boxes is the problem I’ve heard oft repeated that some 32 bit plugins don’t behave well in a 64 bit environment. My stuff isn’t currently heavy enough to need a master / slave setup (although that is certainly an appealing option), so if I went this route I’d be on a single 64 bit box.
Does VE Pro solve the “32 bit plugin in a 64 bit world” problem comprehensively, or is it money spent on a new box & VE Pro only to find that there are still 32 / 64 issues?
I’d really love to have more than 3 gigs of available memory if I could trust a 64 bit box to be hassle free.
One other thing - my entire network at present is 100 megabit, not gigabit. Does master / slave work on 10/100 connections, just slower, or does it simply not work unless there’s a gigabit path between the two?
gigabit is required.
I can’t think of a reason to stay in 32 bit environment in 2014. Are there any plugins you have that have not been ported to 64bit by now?
+1 for VEPro. It is the best VI hosting platform hands down. This goes for single or multiple computer setups.
When you stop, the slave is always going to take a fraction of a second to stop and thus will be slightly behind the master after you hit stop when using mtc. During scrubbing and actual playback, they should be totally locked however. I wouldn’t sweat it.
I’m primarily using Waves, GPO and occasionally Antares. They get the job done and I don’t have any need to upgrade just to get a 64 bit version of them.
There’s obviously a benefit to have a 64 bit environment, however, for the additional memory if no other reason. If VE Pro will protect my 32 bit plugin investments until I have a reason to spend upgrade dollars, it would be worthwhile.
Well, get the demo and check it out.
5 or 6 years ago when it was still hit or miss with whether vendors had 32 or 64 bit plugs, I used it for all my 32 bit VI’s. Works great. You’re still locked to only 3GB of RAM for the 32 bit ones only, but you can use all your 64 bit stuff at full RAM capacity.
Excellent.
I forgot about the drum plugins (BFD, EZ Drummer), the latter of which at least may be 64. One of the things that’s a bit of a hassle is the fact that I can’t currently run either with the Halion synth at the same time because they’re all memory pigs. I assume 64 bit Cubase would run a 64 bit Halion, thus getting it out of the way. If the drums have 64 bit versions as well, then that gets the biggest offenders out of th e32 bit arena.
both BFD and EZDrummer are 64bit plugs now. So you should be good 
VEP software is server based hosting of vsti’s. You have seperate servers for 32 and 64 bit plugs, so no bridges need to be build. You use this on your main device. What it does is that you take the vsti handling completely out of cubase and deliver audio to the DAW. On top of that you can assign cores to instances on both serversso core handling is manageable. So it gives you a substantial upgrade to your possibilities on a single computer. You also get,and that is the main goal of VEP, 3 licenses in total to connect 2 extra computers to the same environment of the main DAW, but they go trough the network. So network speed is essential. Gigabit is systemRQ.
I tried VEP on 100 megabit and yes it works, but i am on the point to change to gigabit, since 100 mbit works, but will quickly deliver pops and drops because of SysRQ when using multiple channels. the pipe is just not big enough to transfer the data.
But this is the scenario of multiple computers. On a single computer VEP indeed does give you a lot more vsti power, both on 32 and 64 bit. Vienna is a partner of SB, so i guess they are aware of this, and it is offered as a specific alternative for specific conditions, even on their own site.
kind regards,
R.
Thanks, man. Very useful info.
I’ve been using GPO for years, which offers full symphony instrumtation, e.g. pianos, brass, percussion, strings. Is the library that comes with VEP a full orchestra or just a few strings and things?
VEP comes with a basic teaser in the package
for me this was some symphonic instruments.
You get some variations and it is at a very high level.
VEP and VIENNA are products of the same brand
the full deal is 10.000 dollars/euro stuff
vep is standalone
kind regards
R.
Yeah, that’s what I recalled, that VS was wicked expensive.
For my modest needs GPO does just fine. If Hollywood ever kicks my door in and forces me to accept millions of dollars to score for their blockbuster movies, I will of course give another look at the bang for the buck that VS offers. In the meantime, GPO has a very high factor in that regard.
i agree
i have garritan to compensate the same thing (and some other specific things with other brands)
but VEP is worth the package
it is about ASIO and core handling and that is just not something to be unimportant
kind regards,
R.
While I don’t have a need for a $10k orchestral library, it sounds like VEP is a must have as a VST host, and it’s only a few hundred bucks.
I knew you guys could help me spend my money.
I don’t really see the point of VEPro to be honest. My orchestral template is massive, and working directly inside of Cubase has proven to be the most hassle-free. All of my template tracks have a cc1/cc11 reset message at the beginning of them, and each are frozen. So I can load a template with 200+ tracks instantly. If I need a track, I just unfreeze it, which takes 2 seconds. VEPro supposedly makes large templates easier because you can decouple the sample save/recall from your host, but you still have to load that massive amount of samples at some point. But, a Cubase template with frozen tracks means you will only load the samples you need when you actually need them. Zero waiting time for anything.
I own VEPro, and the biggest problem with it is the bussing. I use Instrument Tracks - I do this because I constantly need to EQ, effect, and tweak the audio associated with each track. It’s easy to assign a hotkey to open the Channel Settings window for the selected track. I want the EQ for 1st Violin, I select that track and press my Channel Settings hotkey. When using VEPro however, the general workflow is to create a server and connect to it via multiple MIDI tracks – so if you need to find the audio output associated with a given MIDI track in a large template…good luck to you. And when you select that audio track, guess what happens - your MIDI track is unselected, so you can’t play a note on your keyboard and hear the change you made to the audio output…you have to go back and find that MIDI track again. Infuriating. Separate MIDI and audio tracks is so 1997.
The other problem is automation. Automation parameters for plugins hosted in Cubase show up by name. I have track Quick Control assignments tied to each instrument in my template, and they can be intuitively automated. When using VEPro however, you get destination names like Parameter 1, Parameter 2, etc. Seriously, what the heck is that. Who knows what “Parameter 1” is controlling. I sure don’t.
VEPro is like most other hosts-within-a-host – it inserts this additional layer between you, your plugins, and your workflow. Everything you do is one extra step, even if it supposedly does better with x64 core handling blah blah blah. I sure didn’t notice any improvement. It’s one of those products I just don’t get. I think it’s mostly useful for people who need to wrap VSTs somehow (ProTools or x86 Win users).
Lol, sorry to be so negative - your mileage may vary
I read nothing negative but only see a well motivated statement.
And ok, naming tracks is clearly not your strongest point, but your critics on VEP are.
As i speak for myself, i have never thought about freezing empty tracks. And thus using the freeze function as a way to store presets in to a template. though I like the idea and i will be testing that very soon.
The blahblah is though a very noticable performance difference on my system. But as being said, i haven’t tried the freezing thing, so i have no idea how cubase will respond on that kind of configuration.
The extra layer critic is understandable as are those on the controller side. For me, i use vep mostly as a container for presets i do not want to tweak, but in stead want to use them most of the times. The fact that those instances can be uploaded is though a strong feature, not a weak point, of the software.
Try the freeze method, it’s fun You can even re-freeze tracks that now have MIDI data on them in order to make them audio-only. It’s great for large film templates.
I had an idea that might solve the VEP bussing issue for large projects – and that would be to create one VEP instance per instrument, then have them all aggregated into one metaframe. But, not sure if this would be an inefficient way of working CPU-wise. I mostly use Kontakt, and there is now no penalty for multiple instances of Kontakt vs. multiple instruments in one instance - I wonder if VEP works the same way. Only one way to find out I guess