Vienna Symphonic Library Forum
Forum Statistics

196,028 users have contributed to 43,014 threads and 258,388 posts.

In the past 24 hours, we have 3 new thread(s), 20 new post(s) and 132 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. Nuendo 7 - Tempo ramps cause VEP5 processing overloads

  • Nuendo 7 - Tempo ramps cause VEP5 processing overloads

    D
    D

    Similar issues were reported a few years ago, and in recent years as well, but usually associated with Kontakt 5.

    However, this is not a Kontakt 5 issue.  It seems to be the host DAW overloading VEP5 with tempo change messages. 

    In Nuendo 7, even a single note sent to a local instance of VEP5, with EW Play loaded, will cause VEP5's loading to peg at 99% for the duration of the tempo ramp.  This is what causes distorted playback of those samples.  With Digital Performer 9, I can see VEP5's processing load jump up intermittently during tempo changes, but only to around 60-70% (from a normal 20-30% in my test case), so it never "overloads" VEP5.  Perhaps even with curved/parabolic tempo changes, DP is using a lower resolution set of data points to "paint" a tempo curve (hence it acts more like a succession of jump points in Nuendo, where Nuendo apparently uses many more data points for it's ramp function).

    The workaround currently is to set Cubase/Nuendo's Tempo track and editor to "Jump" mode, and draw tempo any ritards/accel with the pencil tool in the Tempo Editor.  I can only assume Cubase/Nuendo is sending too many tempo change messages to VEPro when using it's "Ramp" mode, overloading it's tempo processing.

    To me, the simplest solution would be to provide a way to turn off receiving of tempo change data within VEPro completely.  I don't even need it with my current template.  I see no reason for tempo change messages to go to VEPro if you aren't using tempo sync'd libraries (such as orchestral libraries - VSL, etc).  And given this bug, tempo sync'd libraries often won't work with tempo changes without this distortion problem, or at least artifacts. 

    Even some tempo sync'd effects and VIs loaded internally in Cubase/Nuendo won't respond reliably to tempo changes, so tempo sync, for now, really only works with fixed tempo material - hence, there is no need to globally, perpetually send or receive tempo change data with externally hosted VIs.  Is there a way to filter or turn off tempo change receiving in VEP5, or can such a parameter be added? 

    I have reported this to Steinberg several times, but so far no word on a fix, and it may have to occur on the receiving end anyway (as some users may want tempo change data to be sent to some external devices, but not VEPro, or vice versa).
  • civilization 3C
    civilization 3C

    I don't have tempo rule over MIDI tracks, I set all to linear time, but I extensively use the tempo map so things line up for arranging. Typically I don't need Kontakt to sync. However I did reproduce a couple of problems in the prev. thread and turns out later I needed to forego tempo changes (jump, NB) for a couple of bars where there were pops which certainly correlated with tempo change in tempo map.  Kontakt, Broken Wurli, delay. Since then, I relied on tempo to tell NI Replika how to do its job... I did not experience the issue that I did with Kontakt. The reproduce scenario in the prev. thread was Scarbee Clav with sync'd delay, sync'd something at any rate. That went batguano crazy here as it did for others. The thing I had to attend to was almost unnoticeable, to compare. So there are mainly correlations to talk about and I don't think any of the vendors can be singled out per se, but that it is a combination of interactions, which may well have to do with too much data to VE Pro. However I'm doing really extensive definition of tempo in Cubase and before the Clav sync repro I didnt know anything about this. And the Clav sync deal was more or less the same with a jump tempo change. For their part, NI acknowledged the issue belonging to Kontakt to the extent of claming a fix.
  • D
    D

    This definitely isn't isolated to Kontakt.  It happens with Play (StormDrum2 is particularly bad), as well as Damage in K5.  I think the problem is that tempo changes sent to VEPro cause a processing spike.  With ramps, those changes are sent much more frequently, and the processing load builds to an overload point at which audio can't be streamed successfully - hence the distortion of playback.

    With Digital Performer, the ramps are likely lower resolution - fewer changes sent per second.  So the additional load is lower - low enough that VEP never quite hits the processing limit.  With Cubase/Nuedno the ramps are sending more tempo change messages, so it happens very frequenlty with some VI libraries.

    The additional tempo change loading happens whether there is any midi note data being sent or not.  This also likely scales up with more VEPro instance connections in the host. 

    The other factor is scripting and cpu resource requirements for each VI. Some have very little scripting (Kontakt or Play), and don't add signficantly to VEP's load.  However, some do - such as Damage, HW Brass, etc - and that sends the processing load over the limit.  This could also be tied to how each player and library time-stretches/adjusts sample playback, and perhaps is tied to tempo changes (though it shouldn't unless it is a tempo-sync'd audio loop).  That's why we hear distorted playback in some cases but not others - the higher loading is there, but it isn't enough to affect playback in every case. 
  • civilization 3C
    civilization 3C

    Yeah, that all makes sense to me. In which case the workaround could be to turn it off at the VE Pro side, I don't know how much a PITA that is to implement. I consider myself fortunate, I have very little problem with it and I don't typically write ramp tempo. I noticed that in Kontakt 5 'sync' was enabled, that's the default, here. The thing that gave this slight pop in a couple of spots is pretty heavily scripted. The Scarbee Clav freaked out to the point I had to restart the computer.