I had the same problem with Logic using VSL AU, I have solved it putting Logic on an old 8 core Xeon and putting MIR on my 12 core Xeon

Did you try putting ONLY Cubase on your I7 and all VSL/MIR on your Xeon

I didn't try that solution no, that would complicate my setup...

I'm using my Xeon as master PC, also for normal non-DAW everyday usage (in which I'm enjoying the speed of my one SSD) and video converting. The Xeon's power consumption is half that of the i7 which I notice considerably (costs & temperature), so I'm not planing on using the i7 as my main PC (the i7 was my old PC). I connect to the i7 PC via Remote Desktop, and Remote Desktop being a bit slow would not do well with Cubase on it. And using my i7 as MIR dedicated is a bit throttling.

Thanks for your probable solution, it could work, because then the audio input plugins would be running on the PC that is not hosting Cubase. Good to hear it worked for you, but for my usecase it would complicate matters too much, and I'm not sure it would fix the problem on my setup. But it is mind-boggling, I might have a look if I could somehow optimise my setup for exactly such a case.

Cheers

@Zelorkq said:

I didn't try that solution no, that would complicate my setup...

Not at all, If I have understand your setup.

You will not have the 200 / 300 audio back to Cubase(it could be the reason of your dropouts), only the midi traffic and the signal out from MIR will transit on your Ethernet cable

I forgot to say that now I have all my setup (a full orchestra with all articulations of setup II + Kontakt + 2xQLSC, + omnisphere ) running on my 12 core using IAC

The number of I/O didn't quite register here, forget my remarks about C7 issues. Frankly you should expect to have big latency with 2 and 3 hundred inputs and outputs.

what possible reason is there for this number coming back? you need to learn to use VE Pro as a submixer to some extent; are you going to print a couple, three hundred stems? you can automate all the levels with the automation mapper of VEP. This is serious bloat, buddy. the first thing to do is be realistic. I think you could divide the number coming back to Cubase by ten.

Cyril is right on the point about the data coming back over the ethernet as a bottleneck. I wouldn't want to use that workaround at all, but then again I'm not with Logic.

@Another User said:

what possible reason is there for this number coming back?

I won't be printing 300 stems, nope. My plan was to have one main mixer (the one from Cubase), so I can mix everything in one, so I wanted all of the outputs of all instruments there, giving me a nice view of all my outputs at once. From here I'd be routing some sends to different reverbs etc. So what you're saying is using 3 mixers basically, Cubase mixer, VEP 'sub'mixer on the slave, and the VEP 'sub'mixer on my master. This would for me defeat the "one mixer solution" that I was keen on using...

The next reason was that VEP does not support Cubase insert effects (Cubase not letting others use their inserts) and VEP does not recognize all of my third party insert effects either. So for those instruments that need them, I would have to route those outputs specifically to Cubase, because Cubase supports all of these inserts. In the end I would then have a mixture of some outputs not going to Cubase to mix, and some going to Cubase to mix, thus I opted for 'all' going to Cubase, so I could be as flexible as possible, because I don't always know which instrument will be needing these extra inserts.

The next reason is that I want most of my outputs of my slave VEP to be able to go into MIR of my master VEP, so each instrument sits differently in the room. If I'm not mistaken, the way of doing this is having an output for each instrument and using the audio input plugin on each, linked to the INs of my master VEP. (I will never be playing 200 instruments at the precise same time in MIR, for which I'd need at least double my CPU power, but I want the instruments to be placed individually across MIR, so for their passages they can be moved/mixed/edited each separately)

If I'm not mistaken, my reasons would mean that I cannot build my setup the way you told me I should. Or is my setup a bit too unrealistic? Is my setup not the way it's supposed to be, not very optimal?...

I do have a question: As I pointed out in an earlier post, I can use all of my 300 slave VEP outputs within Cubase without using the audio input inserts. This way I could use MIR within Cubase, and have all of these outputs and the outputs of my master VEP joined here. This seems to work, looking at delay, timing etc. Is there a drawback to using MIR in Cubase, rather than in VEP? MIR seems to run more 'separately', being in its own window and in the system tray.

Thanks a lot for all of your feedback so far!

Well, the sheer number of audio inputs is demanding of resources just having them connected. Then you're doubling that on the same cable, it's no wonder you aren't running that. Also, take very seriously the advice about proper ASIO drivers.

I hadn't imagined such a dependence on Cubase native plugins. Using MIR in VE Pro, you can have all the placement you want but assigned to a few busses since it isn't about stems.

For me, I'm not you, this is a million miles from optimal. If you really have to go with Steinberg's plugins, certainly I would go with MIR in Cubase to get rid of hundreds of channels over the network. NB: the primary real-world reason for outputs from VE Pro is stems. Look at the manual for MIR Pro and note the pictures of everything to the master bus. There are reasons to have more than that and you have indicated some, such as sending to MIR separately. I'll separate things in order to send to the other instance of VE Pro with a lot of reverb, and did with MIR as I'm assigning more threads to the FX type of instance which can use more.

I do little to nothing with the Cubase mixer as far as the VE Pro channels, the Cubase channels sit there at unity. I automate the VEP channels. The instance I'm looking at ATM has 27 channel strips which sends four stereo outputs to Cubase. When I was demoing MIR Pro, a typical setup might have two [output] busses, a room bus [MIR] and a [MIRacle] tail bus at the master output. There is no loss of flexibility, it's just lean and efficient. It can all be  mixed completely individually, just 'grouped' as far as the output. I come from a recording studio paradigm and I rather abhor a hundred outs, it's just nuts to me.

I use [a plugin in] Cubase for when I want to record live tweaking of parameters rather than write them in the lane. For me, with the mapping of parameters VE Pro is the superior mixer, it's all laid out in one place, and because of the control I don't have dozens of instrument channels in Cubase. I have a high number of automation lanes which is more meaningful to me and to me it's less clutter. I think 'more optimal' for you means MIR in Cubase.

@Zelorkq said:

the "one mixer solution" that I was keen on using...

but you're stymied by needing Steinberg's proprietary plugins somewhat.

I seem to have phrased the insert effects priority a bit wrong, sorry about that. I wanted to put emphasis on third part insert effects, Cubase insert effects being secondary. But I have just now found out why my third party plugins did not work in VEP: 32 vs 64bit incompatibility, but I've solved that issue now, so I can use those in VEP. I can live with not being able to use Cubase insert effects, I'll just abandon them I guess. This way I would be able to use my master VEP as my main mixer. Thus I can remove the master VEP outputs that went to Cubase, which will definitely speed things up.

I'll then have to see how to set up the reverbs in VEP with buses. MIRacle versus Vienna Suite's Hybrid Reverb, no idea which would be better. At the moment I was using Hybrid Reverb sections for strings, brass etc. which each only had the early reflections, and the main output channel which only had the tail (so grouping of some sorts).

Back to the routing: However, even if I change the above, I'm still sitting in front of my main problem: the audio input plugins for my slave VEP. I'm not 100% sure I understood your setup. Is there a way other than audio inputs via Cubase to get the individual outputs of my slave VEP to the master VEP? Because as I understood the VEP master/slave principle, the slave VEP outputs go into Cubase, from within Cubase you route these outputs to the master VEP inputs (via audio input plugins, which is killing my asio performance - according to Dietz optimisations of Cubase that interfere with VEP). Once I change the above-mentioned, I wouldn't 'need' any outputs in Cubase anymore, except for one or two from my master VEP.

I don't see how grouping would help here, because I want to have each instrument of my slave VEP separate in my master VEP's MIR for perfect positioning. How do you send your slave outputs to your MIR instance?

Thanks a lot for your assistance in this matter!

It looks like you did not understand why you have drop outs !

You have them because there is too much to do !

You have a bottle neck in your configuration !

Up to you to find it !

My guess is your 200/300 audio tracks !

Start with 20 tracks and see if it is working ok !

What hell are your 300 tracks ?

Use articulation switching and the VST Expression Maps 

I do understand why I have dropouts, I'm asking for too much. The thing that bothers me is that I can receive way more outputs from my slave VEP (over LAN) to Cubase, with no problems whatsoever, than I can re-route with audio input plugins. That's many outputs going through LAN, so for some reason there is no bottleneck here, even though this is the actual network communication of so many audio streams. The only problem is the re-routing of Cubase to master VEP, which is localhost. My guesses are, that the re-routing is kind of 'outside' of Cubase, and every audio input plugin between the two VEPs is continuosly sending data, just to keep its link open, or the optimisations of Cubase, as mentioned by Dietz, are interfering.

I am already using Expression Maps for as many instruments as possible. To roughly some up my 300 outputs, these are 300 Mono outputs, VEP always grouping them in pairs, so it's 150 instruments basically. On that slave VEP I've got all my Berlin Woodwinds (14 instruments), all of my percussions (easily 30 instruments), Piano, Harpsichord, Harp, Organ, Choir and the lot, Guitars, Cinematic Soundscape stuff, Heavyocity patches etc., which sums up to 100-150 instruments. My master VEP basically has Hollywood Strings + Brass, Dimension Strings + Brass, which is also 60 instruments (with place holders for Dimension Strings Violas and Basses). I cannot swap these to the slave VEP, because especially PLAY loading times needs my SSD.

The only solution I can see is grouping my slave VEP instruments in a slightly unflexible way, e.g. grouping all Berlin Woodwinds into one woodwinds output section, grouping the entire Percusion into one output section, etc.. Then I'd have my 20 outputs at max which should work for 'audio input plugin' effects. Disadvantage is that every Oboe, Clarinet, Flute etc. is placed at the same MIR position. But if that's the only way around, then I guess I'll have to do a compromise. (which is what I'm going to try out and post my results) Maybe if I get myself a new soundcard at some stage (with proper drivers), this issue might be resolved, but I wasn't planing on doing that for some time.

Well I've changed my template and grouped all of my outputs of my slave VEP to 20 or so outputs and routed these to Cubase, re-routed via audio-plugin to my master VEP and then MIR. This setup works fine with the asio limits not being reached, its just not as flexible as could be, because for eg. my Woodwinds are all grouped as one instrument in MIR. But that's a compromise I took into consideration. A single PC solution would've been easier, but then I'd need an insane machine.

Why dont you try the solution I have proposed :

1) On the slowest PC :

• Cubase 
• All your orchestral VSL tracks send as midi to 2
• Play send as audio to 2
• Kontakt send as audio to 2
• ...... send as audio to 2

2) On the fastest PC with SSD

• VEPRO with MIR 
• The output of MIR send back to 1

                                            --------------------  OR ----------------------

1) On the slowest PC :

• Cubase 
• All your orchestral VSL tracks send as midi to 2
• All Play, K5  send as midi to 2 

2) On the fastest PC with SSD

• VEPRO + Play + K5 + .... with MIR 
• The output of MIR send back to 1

Reducing the number of outputs was your advice I followed, which is working much better now. The way I grouped it was the only solution that was plausible for me.

Your proposal 1 would be to load all sample libraries on 1), the slower PC (if I understood that correctly). And your second proposal would be to load all sample libraries on 2), the fastest PC. I can see how this would work and better performance (especially proposal 2 which has less network send, being only midi). But for me there are two drawbacks: a) Your proposals are both solutions for loading only one PC with sample libraries, and b) both would have Cubase run on the slower PC, the one I only connect to via Remote Desktop.

a) I thought I had posted this as well, but reading back it might have slipped me. What's important to me is that I can utilise as much RAM as possible, thus using RAM of both PCs to their fullest extent (I'm already purging quite a few instruments). So I have to split my sample libraries, meaning (as far as I know) I will need VEP on both PCs and I will have to use many outputs with audio input plugins.

b) Running Cubase via Remote Desktop is sluggish and I'd have to fix my soundcard, speakers and midi controller to that PC as well.

The way I've currently set things everything's working alright. I 'benchmarked' my MIR yesterday and the grouping doesn't seem to be that bad, because I could never have used so many ungrouped outputs in there, not by a long shot. MIR is amazing, but hungry.

You did not understant at all what mean !

I give more details :

Proposal 2 is the same way as I explained it, which won't help me because one PC is doing almost all the work and loads all the libraries. Seems I only misunderstood proposal 1. However, now that I undestand what you mean, your proposal 1 says that PC2 receives all Play & K5 outputs of PC1. That's the original problem is it not, because there are soo many outputs for Play & K5 to be sent via LAN. I'd still have to configure those outputs with VSL audio input plugins, which would throttle performance, as is the case in my original post.

it's really depends where you put priority,

I am in 5.1 or 7.1 and I give all the priority to VSL instrument so they are well placed  ; Play, K5 and Omnisphere on my configurations just need a few tracks.

I'm only on stereo here. My VSL and PLAY tracks are all positioned completely individually in MIR, it's just my K5s that aren't, which is fine. I'm somewhat happy now with my setup, it also means my MIR isn't as cluttered as before. Thanks for your proposals & help, tho it seems everyone has a different setup, priorities and preferences (and amount of monitors haha).

Cheers

@Zelorkq said:

I wouldn't 'need' any outputs in Cubase anymore, except for one or two from my master VEP.

I don't see how grouping would help here, because I want to have each instrument of my slave VEP separate in my master VEP's MIR for perfect positioning. How do you send your slave outputs to your MIR instance?

Thanks a lot for your assistance in this matter!

Flexibility is not synonymous with more outputs, through the fact of more outputs. You have MIR Pro and all of this placement; this is not diminished by the act of grouping per se. What happens on that stage, what happens with all the pre- or post- fader FX and sends, etc, does not vanish because we, at the end of the day, reduced the number of outs. In terms of your problem, using more resources than you can manage, it absolutely helps and it does not reduce the flexibility in the mixing; it is a matter of embracing another paradigm.

this exceedingly high # of outs is kind of novel to computers and DAWs. When it was physical, no one would want it until it's something you can't manage without.

I'm not conceptualizing this for MIR Pro as a plugin into Cubase, I'm just describing how it worked for me, in VEP. Hence going into the difference of resources management. To be perfectly clear, the MIR instance was the slave. Sometimes I would send from a different instance of VEP to the MIR instance via Cubase, as audio input which seemed to more or less weigh it down the same as a channel in the same instance.

for all intents and purposes, it would be the same procedure for the 'master' or local host instance of MIR Pro in VEP. I don't think MIR Pro as a plugin in Cubase is a great idea, is the upshot, which I have yet to state bluntly. It's competing with other things inside Cubase's process, and you illustrate sending to it is more than your pretty robust system will do. Sorry I was less than clear in these senior moments I have.

@Another User said:

I wouldn't 'need' any outputs in Cubase anymore, except for one or two from my master VEP. I don't see how grouping would help here...

Your bottleneck was largely doing things in Cubase, as all of the things are competing for priority in the process that is Cubase.