DG: I mentioned in my original post that Cubase was just as quick as Logic when I took each MIDI bank (of Kontakt, which I didn't mention) and made it into a single instance. This isn't a Logic vs. Cubase thing -- I switched from Logic to Cubase earlier this year and it has been blissful. So don't get me wrong. Sorry to repeat myself, but what I meant was, the 24 MIDI banks in a single instance I had in Cubase, I separated into 24 intances of one MIDI bank each when setting up my template in Logic. Then I took that same 24-instance template and opened it in Cubase. Everything was just as snappy as it was in Logic. That's how I came to my conclusion about the multiple MIDI banks causing Cubase to load slowly.

-

Karel: Thanks for the info. However, I am using 24 Kontakts, so I had had the correct number of MIDI banks/ports in VE Pro preferences with no excess. Like I mentioned above to DG, the solution was to separate out each Kontakt into individual instances.

 Sorry, I must have misunderstood the post then.

FWIW I use 2 MIDI ports per instance, because housekeeping is easier that way. However, I noticed no slowing down when I used up to 8, when I originally tested it on my system. If you have the energy, it might be worth seeing at what point things get screwy for you.

DG

Any news on this issue, or differences with VEP 5?

It's a problem on the Steinberg side really. I will send them an e-mail describing the problem in detail for their developers. I recommend contacting their support as well with the issue.

Hi

The answer of how best to distribute all the instruments we need across multiple instances is still eluding me. Here is the dilemma as I understand it:

On the one hand, I am hearing that TOO MANY instances of VE PRo (on slaves and plug-in interfaces) can slow things down.

On the other hand, I am hearing that too many MIDI ports (VST 3) can also slow things down, especially loading with Cubendo.

Ok. What is the best approach?

My current setup (which I realize may be a little weak on the slave side of things) is as follows:

Mac ONE 10.6.8 on Brand New hexacore (Main DAW running Nuendo 5 via RME PCIe MADI)

Mac TWO 10.6.8 on 2008 Dual Quad Core 2.8 GHz (24 GB Ram) Slave

Mac THREE 10.6.8 on 2008 Dual Quad Core 3.0 GHz (12 GB Ram) Slave

Networking via independent Ethernet network separate from internet/screen-sharing.

I am definitely realizing that I should have pushed my money onto a 12 core slave, rather than the hexacore (which I recently slotted in as my main DAW) but the main point is, to get the best from THIS SETUP, should I:

A: have approximately 8-16 instances of VE PRo with a minimal number of MIDI ports (say 1 or 2) per instance

or

B: have just two instances of VE PRo (one for each slave) with about 4-6 ports available in each instance.

The maths is:

1 port/instance multiplied by say 10 instances = 10x16=160 MIDI channels.

OR

5 ports/instance multiplies by 2 = 2x5x16=160 MIDI channels.

The mileage will obviously vary (I do not tend to create massive templates, rather they build up as a project evolves, leaving me creatively free of baggage) but my general experience is that I need around 10 sets of 16 channels to be covered.

Creatively, and workflow wise, I prefer lots of modular, smaller instances. But I am hesitating to do this because of "what I heard" about having too many instances.

Added to this mix of tips and balances, is the number of audio channels to "permit" on the system. This really relates to the number of MIDI channels, kind of, from a milage point of view again. But, is this also a key player in performance? At present I allow 32 stereo pairs per instance, but rarely go beyond about 24 pairs in actual use.

Going for the "granular" approach (ie more instances with less ports/instance) I could pull that down to probably 16 stereo pairs or even 8 pairs per instance.  mean, how much mixing do we really want to be burdened with? 

Knowledgeable readers please advise. From experience if possible!

Thanks for reading

Ben

I've posted a small test concerning the number of threads per instance on this thread (I'm going as far as 96 audio outputs per instance), but it seems that no one can really tell how CPU/instances/threads should be managed. Someone with a lot of time on their hands should do a thorough "sweetspot" test, someday...

I am noticing similar issues with PT10HD, VE Pro and Kontakt 4/5 - 9 instances of Kontakt 4/5 using 16GB or RAM.  Same sort of issues as the original post, however PT is set to AUTOSAVE every 5 minutes (now 10).  PT on its own is blazing fast (24GB RAM, 2 SSDs - 1 for system, 1 for VIs including VEP, 3GB PT 10 Disk Cache).  On the save, PT 10 takes about a minute to SSD ... on magnetic media this is quite a bit longer.

The long save times are attributable to VEP (when discusonnected, the save is again instant).  So - what does VEP save when instructed by PT? It should not be saving the samples, the mframe and viframe files are small and saved onto an SSD ... what is the issue?  Is this a bug?

When the DAW saves, it saves the state of every plug in the project. If you have many instruments loaded in VEP, that is a lot of information to save, hence the time taken. Try loading PT itself as full as you can, and you will find that the saves are not instant.

DG

This is an old friend of an mframe loaded into VE Pro 5 (previously loaded in VE Pro 4).  The save times are exhaustingly longer with VE Pro 5 - and this is with an update to SSDs - making all other saves instant in comparison. What I'm doing is not unusual, and has been used without notice in previous versions.

I would respectfully call this - if not a bug - an extreme oversight in VE Pro 5. 

Either way - I believe that the wizards at VSL can address and fix this issue and I'm happy to provide files if needed.