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.

@civilization 3 said:

if you have decided on 'one or two from your [ VEP', that is precisely what I indicated by mixing down to groups, busses, whatever name one uses.

Yes my outputs from VEP are set up exactly like that now. My slave VEP groups its outputs and sends only selected groups to Cubase. From here only these few are re-routed to my master VEP. And I'm using MIR in VEP, not in Cubase, all working fine.

Thanks for your clarification on the matter!

I have seen far too many reports from people that never heard of VE Pro that their {virtual instrument} performance was buggered by Cubase 7 for me to believe Steinberg's - forum's? - story.

No problem with the test I have done with Logic, but I had less than 10 audio tracks, but 100 VI