Midi delay compensation

[tulamide]

Short question:
When buffering midi notes in Ruby, how to tell the host about the buffer delay?

There's a prim "delay compensation" for delayed (buffered) audio, and expressed in samples, which is way more accurate than Ruby (and midi in general).

[tulamide]

I just noticed that this could be misread as a tip. It isn't. I really ask for help.

I can't express the midi buffer delay in samples, because it is varying depending on the accuracy of Ruby, and the amount of notes that are buffered. I really don't know how to the host aware of it?

[Spogg]

I just noticed that this could be misread as a tip. It isn't. I really ask for help.

I can't express the midi buffer delay in samples, because it is varying depending on the accuracy of Ruby, and the amount of notes that are buffered. I really don't know how to the host aware of it?

I can't help but I am interested.

What sort of delay times are involved? Does the delay vary in a given project depending on the number of notes played, mod wheel, bend wheel etc.? Is the delay time related to the amount of instructions in Ruby?

I can generally cope with live playing with up to 20mS delay. Beyond that my timing accuracy (never good at the best of times) goes awry. If the MIDI buffering delay is less than 20mS it personally wouldn't worry me too much.

I hope someone will clarify this for you.

Cheers

Spogg

[Nubeat7]

first you have to find out the maximum possible latency, set the vst latency primitive to this value..

then you need to know the different latency times on the different cases - in most cases these times are less then the setted max latency - now you add a delay at the end of the signalflow and compensate the difference to the max latency..

like this you always have the same latency..

this is the way i use to compensate my audiostreams, hope it helps..

[Nubeat7]

maybe this can be helpful too..
viewtopic.php?f=4&t=3504&p=19017&hilit=measure+module+latency#p19017

btw. is it possible to change the latency on the vst latency primitive while it is loaded in a daw or is it fixed at the value at loading (which i always thought it is) ?

[tulamide]

btw. is it possible to change the latency on the vst latency primitive while it is loaded in a daw or is it fixed at the value at loading (which i always thought it is) ?

Dynamic pdc is, as far as I know, not part of the VST SDK, at least not in version < 3. In fact I couldn't find anything about pdc. The only function I found is badly documented in the SDK:

Code: Select all

virtual void setInitialDelay (long delay);

Decription: For algorithms which need input in the first place.

It doesn't say what that long expresses, but I assume samples, and therefore think that the compensation prim is referring to this function. The poor documentation allows to assume it could be used more than once, while the name of the function implies the opposite.

Nubeat, thank you very much for your help. But I still struggle with it. MIDI is not blue/white and therefore of an inaccurate timing. As MyCo explained in the linked thread, as soon as I connect to green, the timing is off. And if I use frame start, I am in sync to the stream, but have no timing information (which would require the exact number of samples passed since the start of buffering midi notes, which could have happened in an earlier frame) EDIT: And also this introduces a larger latency of at least the size of the frame

There would be the way of just guessing. I may delay by, say, 40 milliseconds in Ruby's timing, and just report a fixed delay of 177 samples, hoping it will be close enough. How do other midi effects deal with it?

[RJHollins]

Hi T.

Just a thought ...

I remember reading about C-Labs NOTATOR and the mention of 'Time Stamped' MIDI events.

It set NOTATOR apart from the early competition with its accurate [stable] playback [on a 2 MHz ATARI computer].

[KG_is_back]

OK guys, I've done some tests.

The latency compensation seems to be dynamic. I've created a plugin that consisted only of integer delay in blue line and latency compensation prim (the delay being controllable parameter). In FL studio, the output from the plugin was delayed during live play as expected, but FL studio compensated latency (by delaying other tracks) accordingly, depending on the delay-value set. So yes, at least some DAWs are capable of dynamically changing latency compensation. However, I've heard of DAWs that had problem with this in the past.

As for whether this delay compensation works for midi too, more testing is needed.

[tulamide]

OK guys, I've done some tests.

The latency compensation seems to be dynamic. I've created a plugin that consisted only of integer delay in blue line and latency compensation prim (the delay being controllable parameter). In FL studio, the output from the plugin was delayed during live play as expected, but FL studio compensated latency (by delaying other tracks) accordingly, depending on the delay-value set. So yes, at least some DAWs are capable of dynamically changing latency compensation. However, I've heard of DAWs that had problem with this in the past.

As for whether this delay compensation works for midi too, more testing is needed.

That's good! Dynamic pdc can be very helpful for various applications. There's just one thing I can't understand: Midi timing is based upon ppq resolution, not on sample rate. How can I combine those to get accurate pdc for midi?

[KG_is_back]

That's good! Dynamic pdc can be very helpful for various applications. There's just one thing I can't understand: Midi timing is based upon ppq resolution, not on sample rate. How can I combine those to get accurate pdc for midi?

I have a feeling, that when midi is processed in ruby, it is first converted into ruby events, so internally the pdc is converted to ruby time format.
One interesting thing would be if you could send out events with negative time element, like:

Code: Select all

output 0,midi,time-0.5


It would be really cool if that worked, but it probably will not...