DP/VEPRO - VSL confirms ADC doesn't work properly! :(

[Marc7777]

Vienna has told us that they tested it, and confirmed that it doesnt work at all on their rigs either.

I believe you that it doesn't work.

I'm trying to figure out why it's "Semi" working on my rig...

With technically a 512 buffer (256 x 2) I'm only getting 5-10, sometimes max 20 samples off. Yes it's not as tight as with the Kontakt inside of DP, but it isn't 512 samples off..

If I do the Time shift plug, I only need to set it to around 10-15 samples earlier to get the desired tightness...

Did I just get lucky?? *knock on wood*

Regardless though, I really, really hope this gets solved. And not in a DP 8 form.. hopefully a DP 7.25. I really don't want to jump ship to DP8 and get involved in a whole other mess of bugs...


Although to add, If I change my buffer higher than 256 in DP.. yes, all goes out the window. I never change it when scoring with MIDI. I write and mix at the same time.. I only change it when mixing audio.. and in that case I don't use VEP... maybe that has something to do with it..

~Marc

[labman]

Although to add, If I change my buffer higher than 256 in DP.. yes, all goes out the window. I never change it when scoring with MIDI. I write and mix at the same time.. I only change it when mixing audio.. and in that case I don't use VEP... maybe that has something to do with it..

~Marc

I hear 'ya Marc!

And why you only need 10-15 samples on your rig, thats a head scratcher.

I find the big problem for us is that we never print stems or mixes with our DP buffer low. So... when you kick it up to 1024, VEP timing compared to all your audio trks is now gone out the window. (Of course, it will still be perfectly fine if you dont do any audio, or do ALL the MIDI trks in VEP, cause they are all offset the same.)

[Kubi]

Didn't Vienna say what stumps DP is that the latency is dynamic? This would explain why Marc7777 has far less latency than the expected 512 samples.

If I understand the situation correctly, there is *some* compensation going on, it's just not reliable because VE Pro's latency changes dynamically while DP's compensation is fixed, correct??

This would of course mean that the average latency not compensated for would have to generally be A) smaller than the expected amount (=good), but also B) impossible to predict (=bad.)

[labman]

Didn't Vienna say what stumps DP is that the latency is dynamic? This would explain why Marc7777 has far less latency than the expected 512 samples. If I understand the situation correctly, there is *some* compensation going on, it's just not reliable because VE Pro's latency changes dynamically while DP's compensation is fixed, correct?

Hiya Kubi

That is indeed the term Martin at VSL used - "dynamic". Hopefully he will clarify exactly what that means for us.

[Marc7777]

I find the big problem for us is that we never print stems or mixes with our DP buffer low. So... when you kick it up to 1024, VEP timing compared to all your audio trks is now gone out the window. (Of course, it will still be perfectly fine if you dont do any audio, or do ALL the MIDI trks in VEP, cause they are all offset the same.)

HOLY SH*T! This is scary! I see what you're saying now! Man, sorry in the previous post, I wasn't trying to debunk your situation.. I just didn't see it like that..

For me right now, I'm working on a show that only needs a little, MIDI-only template. I have 3 Mac Pros ready to roll, and with a small template, it's a breeze for them to use a 128-256 buffer..

But i, just now, did a test with an audio track loop, set the buffer to 1024, and holy bajeezus it's OFF!!!

I never noticed it, since I just haven't used VEP, or my rig, to its full potential in about a year! and when the time comes for me to bust out the big guns.. I'm screwed.. so it seems, b/c i'm not going to put a time shift plug on 300+ MIDI channels!

Eye opener for sure!!

I hope the flood of Tech Notes to DP gets through.. personally I've sent in about 5 over the last few years and not one was answered..


Please let us know on the forum what MOTU says regarding this!!

Thanks!!

[Killahurts]

That is indeed the term Martin at VSL used - "dynamic". Hopefully he will clarify exactly what that means for us.

Indeed.

If it's all over the place, that's worse than having no latency compensation at all.

[doodles]

labman wrote:
That is indeed the term Martin at VSL used - "dynamic". Hopefully he will clarify exactly what that means for us.


Indeed.

If it's all over the place, that's worse than having no latency compensation at all.

Yep, we've just printed hundreds of stems for a mix of a soundtrack, and they were indeed all over the place. I never really had time to think about why. Now this all makes sense. eek.

[mhurwitz]

I think we haven't noticed it because with settings like 128 or 256 samples it's not way off.

It's funny how we trust computers. I was much quicker to blame the bad time on my own playing than on the computer. After all how could a computer be anything less than perfect?

This is indeed disturbing and it needs to be addressed. What irritates me is how Martin in the VSL forum says something to the effect of "it's a DP problem"... as if they had no hand in the QA, and then the subsequent advertising of it as "compatible with DP". Sure, the plugin is reporting its latency correctly to DP, it's just that DP doesn't know what to do with it. I interpret this as the equivalent of saying that the software is incompatible. Sure, it does a lot of other things correctly, but I'm going to stand by the statement that for serious musicians, anything that works with less than perfect timing is not going to cut it.

[mhurwitz]

By the way... I have been trying this MIDI time shift plugin fix and I can't get it to work. I've tried all configurations and all multiples of my hardware buffer. I can't find any correlation between the number that "works" and something like 64, 128, 512 etc.

Any ideas?

[Killahurts]

Yeah, try this:

http://www.expert-sleepers.co.uk/latencyfixer.html" onclick="window.open(this.href);return false;

It fixed a lot of problems I had with outboard FX processors. Of course, it's only for recorded audio. I think it's still free.

[mhurwitz]

I just ran the same quantized snare drum test, but this time I did everything on my master computer, in the box, without using VEP.

The waveform still does not line up perfectly with the MIDI note-- it's off by about 60 samples.

OK, so what's up with that? I thought that the ADC was at least supposed to be able to take care of this.

[mhurwitz]

PS This was using EZ Drummer. I just tried it with MOTU's Proton synth and it worked perfectly. Maybe I should start being wary that my VIs are correctly reporting their latencies.

[labman]

If it's all over the place, that's worse than having no latency compensation at all.

Yeah. That is what is my concern.

[labman]

Here is the post from VSL today about the 'dynamic' question...

"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.
--
Martin Saleteg
Software Developer
Vienna Symphonic Library GmbH

[cbergm7210]

Reply from MOTU today:


Hi Chris,
Thank you for the report. We have received numerous reports of this, and as such we will of course be looking into this quite seriously. I will keep this tech link open and let you know when we have updates.

Cheers,
Lorne

At least they acknowledge.