I noticed your post on the Vienna forum and there i could find some info.
So if it is correct your setup looks as follows:
master= cubase + VEP server (only 64 bit) + 1 instance (PLAY/VI Pro) + 1 instance Kontakt + MIR (as vsti or in VEP) + Vienna suite plugins
slave = VEP server (only 64 bit) + multiple kontakt instances
The audio from the slave is routed straightforward via the server to cubase, but then rerouted to the VEP environment in to MIR and SUITE.
Most of the vsti’s you mention are romplers so that is normally not the issue. But you are aware of the fact that kontakt and PLAY are also a Multi-core environments. (look for that topic in the VEP manual on page 15)
I also guess that every instrument that is loaded has its own output to the mixer in cubase.
There is nothing stated on the usage of the multitimbral instruments like play and kontakt. That can be important though. Imho try to use one kontakt vst for each preset of PLAY or KONTAKT and do not use the multitimbral functions of them. Otherwise kontakt and vep can be fighting for priority’s. Let VEP do the core handling.
Next thing i referred to (as were the other posters) is the fact that you have several tools for optimizing the setup.
1/ in the server window under options you can define the amount of threads per instance. Normally this should be as many threads for a single instance as possible, leaving one or two for the OS and cubase.
Less optimum, but imho better for analysis, is to assign a single thread to a single instance and then you can split things up and actually monitor in which thread the problem is caused, with cubase and OS taken into account, you can have up to 6 or 7.
To lower the strain in the problematic threads, you have a “buffer size” in the cubase track where your instance is appointed to. Since you have split up to multiple instances, each instance can be assigned its own buffer size. This gives you possibilities on how to control the strain on the entire system by differing the buffer size (per instance)
You can raise the buffer size for the problematic tracks, and keep the buffer size for live tracks down to 0 or 1. You want to be able to have a playable system.
So setup things this way should give you insight in how your system is and hopefully optimize things.
In my opinion, romplers do not cause any trouble. But you have some possible problems if the core handling is not correctly set up. At least there are kontakt and play in yoursetup that are multitimbral and possible multithreaded vsti’s on their won. Keep them one instrument for one outup in VEP, and let VEP handle the cores.
Do not throw everything in a single instance, since the resources that are assigned are in the above example only one thread per instance. Too much activity in one instance will easily kill the overall performance. Once the analysis is done, it is also advisable to rethink the way you will be working, and what will be loaded in what instance, to spread things over the system, taken into account the “threads per instance” assigned to the instance, and the buffer size that instance is being played.
Next probable issue could be the MIR and SUITE. Since you are close to the minimum specs for MIR, when taken into account that you also do play/kontakt/suite/cubase handling on the same machine, i guess lowering quality settings there (buffersize or other) can be possible todo’s here.
But that is something only you can determine.
A very nice way of trying to work around the issue is indeed to work with the affinity settings and reserving some cores exclusively for MIR/SUITE or by assigning threads for an instance that is only used for MIR/SUITE and raise the buffers for that Vienna ensemble instrument in cubase.
Hope this helps a bit.