Vienna Symphonic Library Forum
Forum Statistics

200,898 users have contributed to 43,216 threads and 259,148 posts.

In the past 24 hours, we have 2 new thread(s), 10 new post(s) and 59 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro (legacy)
  4. Running VE Pro with multiple MIDI banks per instance slows down Cubase 6

  • Running VE Pro with multiple MIDI banks per instance slows down Cubase 6

    J
    J

    Hello,

    At first I thought this was a Cubase issue, but after some messing around I've concluded that it is a VE Pro issue.

    I'm running VE Pro on my host computer (Mac Pro) as well as on a PC slave. Being that I'm using Cubase 6 as my DAW and running VSTs (as oppossed to AUs), as you know, I have the ability to have multiple MIDI banks in a single VE Pro instance. For organization sake, I'd have up to 24 MIDI banks per instance on both computers. The kicker is my Cubase template was taking forever to load. It'd just sit at the "loading mixer" box for about 6-7 minutes. It would become a pain when switching between projects to have to wait that long each time. On top of this, it would take about 5 minutes for the memory intensive VE Pro instances to unload from memory.

    Since I thought it was a Cubase problem, I started building a template in Logic. I noticed that Logic loaded super quick with the same template. So on a whim, I decided to load the same new VE Pro template in Cubase with the number of MIDI banks per instance lower in VE Pro preferences. To my surprise Cubase loaded just as quickly as Logic did.

    My conclusion was, regardless of anything actually loaded in the multiple MIDI banks per instance, just having a high amount of the MIDI banks per instance was slowing down Cubase drastically.

    I'm wondering if anyone else running a VST DAW (PC or Mac) with a high number of MIDI banks per instance in VE Pro preferences is having this same issue? If not, that stinks for me.
  • D
    D

    I think part of the problem is that you are going from one extreme to another. logic will give you 16 MIDI channels per instance. Tha's it. You are trying to use 384 MIDI channels per instance in Cubase. I don't really think that this is a fair comparison. In order to compare, you would need to load 1 instance in Cubase and 24 in Logic. How do the results compare now?

    DG
  • K
    K

    Actually, there is a slowness in initializing the VE Pro VST3 plugin the more MIDI ports it has. This is due to a workaround required to properly support MIDI CC messages, resulting in a rather large amount of dummy automatable plugin parameters, which Cubase seems to need some time for to setup in the project. It's advised to set the MIDI ports setting to just the amount you need and not more for that reason.
  • J
    J

    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.
  • D
    D

     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
  • O
    O
    @jackballed:

    I have the same issue. Two dozen VE Pro plugins, with 16 MIDI ports each. Takes 2-3 minutes to load a session. Very annoying.

    I am tempted now to do some experimentation with load times by changing the number of MIDI ports as you and Karel have deduced it does make a difference.

    Although I REALLY wish there was some way for Steinberg or Vienna to do away with the excess processing which makes it so slow in the first place. There's some serious inefficiencies somewhere in there.
  • T
    T

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

    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.
  • B
    B

    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
  • T
    T
    last edited
    last edited

    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...
  • T
    T

    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?
  • D
    D

    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
  • T
    T

    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.