Vienna Symphonic Library Forum
Forum Statistics

196,182 users have contributed to 43,014 threads and 258,396 posts.

In the past 24 hours, we have 0 new thread(s), 8 new post(s) and 168 new user(s).

  • Hi, 

    Thanks for reporting, we will look into it!

    Best, 
    Paul


    Paul Kopf Product Manager VSL
  • last edited
    last edited

    Great...hopefully you can figure this out quickly.  After some more testing it seems like certain Kontakt libraries may also cause the problem.  The Spitfire EVO GRID libraries seem a bit suspect as well.

     

    Thanks

    @Paul said:

    Hi, 

    Thanks for reporting, we will look into it!

    Best, 
    Paul


  • Hi, 

    My suspicion is that the number of MIDI Ports will be related, it is a CRAZY amount of automation data that needs to be saved for each plug-in in Cubase. 

    You could try saving a project in Cubase, containing nothing but unconnected plugins with lots of midi ports. Is the saving time high?

    Best, 
    Paul


    Paul Kopf Product Manager VSL
  • last edited
    last edited

    @Paul said:

    Hi, My suspicion is that the number of MIDI Ports will be related, it is a CRAZY amount of automation data that needs to be saved for each plug-in in Cubase. You could try saving a project in Cubase, containing nothing but unconnected plugins with lots of midi ports. Is the saving time high? Best,Paul
    If I disconnect all instances then the Cubase save time gets much quicker. Danny

  • Hi dlpmusic, 

    Can you tell me more numbers? How many instances connected, how many MIDI Ports assigned to each plug-in, and what is the difference in loading time?

    Thanks, 
    Paul


    Paul Kopf Product Manager VSL
  • last edited
    last edited

    @Paul said:

    Hi dlpmusic, 

    Can you tell me more numbers? How many instances connected, how many MIDI Ports assigned to each plug-in, and what is the difference in loading time?

    Thanks, 
    Paul

     

    Hi Paul,

     

    Tough to do a lot of tests as my template is huge and takes a lot of time to test certain scenarios.

     

    It looks like I have about 140+ instances in Cubase with 2 midi ports enabled.  Probably the majority of them are only connected via one midi port as I was interested in using Cubase's disable tracks function occassionally.

    Many of these instances are disconnected unless I am using them and the majority of instances are decoupled.  

    However....I do have a fair amount coupled, i.e, 6 or 7 fully loaded Omnispheres, 6 fully loaded Halion 6, many instances of UVI Falcon all with just 1 sound, 16 PADSHOPS, etc...  So obviously with all that coupled my save time is about 16-18 seconds.  Decoupling all that made no difference in save time but DISABLING all of that plus disconnecting about a dozen more fully loaded Kontakt's brought my save time down to about 8.5 seconds.

     

    If VE PRO decouple function worked correctly should there be almost the same decrease in save time as disconnecting?  I realize Cubase still needs to keep track of the connection to the plug but doesn't Cubase only see the in/out connection and nothing else with it decoupled?  Doesn't VE PRO "decouple" block the transfer of data/info to Cubase so ithere should be no difference in save time whether I have 16 Kontakt's inside or nothing at all?

     

    You mentioned automation data....again except for the automation data of the actual VE PRO plug/mixer section all other automation data of a loaded instrument such as Kontakt is blocked by VE PRO unless you map that automation so I am not sure how different plug ins inside VE PRO should make any difference.

     

    Am I right in my understanding that in DECOUPLE mode very little info except for the connection info should be passed on to Cubase?

     

    Thanks,

    Danny


  • Bump for this one! It's indeed quite a pain in ass even with quite simple setup where autosave of DAW make the DAW hangs for 10s or so waiting for VEP to save everything. I'm on DP but I assume it's the same issue here...

    It rly needs some sort out!


  • Hey Paul,

     

    Any progress on looking into this issue?


  • Hi, 

    I talked to our developers about this, there are a few checks that have to be made for stability reasons, which result in ms of delay for each instance, which adds up for these huge templates. 

     E.g., there is a thread which checks connection activity and kills a synchronization semaphore if a broken “zombie” connection is detected, it does this once every 100ms.

    This will be sleeping for 100ms at a time, so on average those threads (200) will have a sleep time of 50ms, giving 10 seconds of waiting time.

    There are some MIR related thread delays as well, that will be 200x40ms => another 8s

    Best, 
    Paul


    Paul Kopf Product Manager VSL
  • last edited
    last edited

    @Paul said:

    Hi, 

    I talked to our developers about this, there are a few checks that have to be made for stability reasons, which result in ms of delay for each instance, which adds up for these huge templates. 

     E.g., there is a thread which checks connection activity and kills a synchronization semaphore if a broken “zombie” connection is detected, it does this once every 100ms.

    This will be sleeping for 100ms at a time, so on average those threads (200) will have a sleep time of 50ms, giving 10 seconds of waiting time.

    There are some MIR related thread delays as well, that will be 200x40ms => another 8s

    Best, 
    Paul

     

    Hey Paul,

     

    I am trying to understand exactly what you are saying.

     

    Are you basically saying if I have one "instance" with 32 midi ports and it is loaded with 32 various instruments that the added decoupled save time should only be an additional 50 ms?  If I took those 32 instruments and put them into 32 separate instances the added decoupled save time would now be 50 ms x 32?

     

    It also sounds like you are not addressing that I am seeing different decoupled save times with different instruments.  In your example it sounds like the developers are not taking that observation into account.

     

    Let me know your thoughts.

     

    Thanks


  • Good news sort of........

     

    With 6.0.15567 it seems to work properly.  The save time using decoupled works as expected.  Definitely newer versions are not working correctly.


  • I was sent here by NI support as I havwe this problem as well but ONLY when running Scarbee Funk Guitarist inside VEP. I even create a seperate instance just for Scarbee and I still have the problem. 

    So we're at the point of them blaming you, so please don't blame them.


  • Hi, 

    The simple solution would be to run the Funk Guitarist in your sequencer. 

    I hope we can improve connection times with upcoming versions, please stay tuned. 

    Best,
    Paul


    Paul Kopf Product Manager VSL
  • Bumping this in 2024!

    I'm jealous of the save times here. I wish I only had to wait 10 to 16 seconds.

    I'm at at random 10 TO 15 MINUTE save time!! Random as in sometimes its seconds and other times is colossal saving times! And there's times it just freezes, so I have to force exit.

    I'm at a point to dump VEPRO 7!

    I have a single powerful PC running Cubase 13, with VEPRO 7 on it to spread the load.

    Cubase is set to autosave every 20 minutes. VEPRO is decoupled from cubase. Auto save in VEPRO is also set to off. And because its random save times on various projects, I can't nail down which vst "may" be causing it. Plus I don't have the time.

    And I know VEPRO is the culprit, as there's times I've let it run for 20 to 30 minutes to save. But when I realise its never going to stop, I force exit VEPRO and Cubase becomes accessible again. So at least I can save it then!

    Any advice??

    Thanks