Vienna Symphonic Library Forum
Forum Statistics

183,392 users have contributed to 42,296 threads and 255,064 posts.

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

  • last edited
    last edited

    @MS said:

    I can confirm that DP does not latency compensate properly. 

    Err... okay... and the solution is???

    I mean, since you did not imply it in your post: can we expect a future VEPRO version that addresses this (already now known!) DP/ADC issue?

    TIA

    Arceo


  • We will have to investigate this further, but currently it looks more like a DP issue than a VEP issue.


  • Thanks. I sure HOPE you get this fixed ASAP as it was one of the selling points of VEP5! We were aware of issues with PT, but told DP7 was fine with all the compensation. Thanks again, and please keep us posted.

  • Same issue w/ Logic, I always have to zoom in and push the wav back

  • I can confirm that DP does not delay compensate VEP 5 properly. I would like to roll back to VEP 4. Is there an easy way to do this?


  • last edited
    last edited

    @Another User said:

    I can confirm that DP does not delay compensate VEP 5 properly. I would like to roll back to VEP 4. Is there an easy way to do this?

    Latency compensation also doesn't work with VEP4 in DP. As I wrote earlier, it looks to be a DP issue.


  • I don't recall ever having a problem with VEP4 not latency compensating. Hmm this is a huge issue. I hope this gets resolved soon because right now it looks to me that the software doesn't do what it is advertised to do. 


  • As I wrote earlier, VEP reports latency properly to the sequencer. It does however rely upon the host sequencer being able to adjust the latency compensation of plugins dynamically. It might simply be that DP lacks this feature.


  • Hello Martin. By "dynamically" do you mean prior to, or during playback? Or are you talking about 'per instantiation' ? Perhaps a specific type of example can help us to follow what you are explaining??? I can say that all the rest of our plugs on our 12 rigs DP have compensated fine the past 3+ years or so, excepting for a bug here or there on a specific plug. And we have tons of plugs, VI's etc. :)

  • It needs to react to latency changes during playback, when changing buffer settings in the plugin, or changing latency of your soundcard. Most plugins with latency have a fixed latency, which of course is easier to compensate for, perhaps only during plugin instantiation, or a plugin scan.


  • Does this mean that if we don't touch our DP latency or the VEP latency, then it works?

    I'm wondering becuaes it seems to be working okay here...  and I never really change my buffers..

    Thanks!

    J


  • just to add..

    It's not working 100% here.. but at a low enough buffer, it works decently.. 

    At a higher buffer, it's unusable..

    ~J


  • Hi Martin,

    Thanks for getting involved in this. I understand your explanation of the problem. However, I can't help but feeling that this explanation is the equivalent of saying that the software is incompatible. I wouldn't be so critical if this were a minor inconvenience, however I think most musicians would say that having perfect time is not some added luxury feature, but a requirement. I also wouldn't be so critical if I was forewarned about this issue. 

    Thanks for your attention. I hope this gets resolved with haste.

    As a P.S. to DP users: this issue can be alleviated (albeit painstakingly) by adding a MIDI time shift plugin to each MIDI track, and shifting the timing earlier by the correct number of samples. For those of you with hundreds of tracks... have fun with that!


  • Thank you Martin. We have several plugs that I know of, that change their latency to DP depending upon what buttons are toggled within them. And they work as soon as you stop/start DP. And you can have 3 of the same plug in a session with differing settings. That to me, seems like what VEPro does. So I imagine it is quite possible to fix. BTW . can you have someone start monitoring and participating in this thread over at motunation. I think it would help us all out alot. http://www.motunation.com/forum/viewtopic.php?f=26&t=49430&sid=327c9a59dc218f35c893bec1752c8e4d

  • Are these other plugins instruments or effects?


  • We just did an experiment here with the Vienna Suite Convolution Reverb, which reports latency changes to DP in the exact same way as Vienna Ensemble Pro does. Here, latency compensation is updated and works as it should after a stop/play cycle, just as expected. My suspicion therefore remains, that DP doesn't respond to property change events for kAudioUnitProperty_Latency with AU instruments.


  • Many of us have submitted a tech note to MOTU regarding this. A fellow at MOTU named Lorne said that he will look into it.


  • So then if we leave the VEP server plugin at zero buffers, it should compensate correctly?

    I just did a test where I set the VEP plugin latency to zero buffers, but set the MOTU hardware buffer to 1024. I then recorded the audio output of some snare drum hits coming off my slave-- both dry and running through Altiverb. Everything lined up. Changing the buffer setting to anything other than zero is what causes the problem, as Martin is suggesting.


  • Hey Martin, thank you for taking us updated on your progress.

    FWIW also my tech link at MOTU has been answered by the same guy (Lorne) which will be probably investigating on their part. It would be a blessing if you two could get in touch to share technical upgrades.


  • At Zero buffers, there is no latency to compensate for!

    CPU usage will be a bit higher with 0 latency though, but since the CPU time is yielded back to the scheduler while waiting for data from the VEPro process, the CPU usage is only virtual - adding more plugins in DP should be possible without any noticable increase in total CPU. That being said, processing graph of host of course also comes into play. If plugins and effects are chained after the VEPro plugin, DP has to wait for the VEPro data before continuing with further processing, making this virtual load real :)