artificial latency: sample based & negative values about lv2 HOT 9 CLOSED

Sure, happy to include it, just send the pull request.

I'm a bit confused about the latency being in samples though, I don't see why that would let it be more accurate? The UI should allow you to set any number of fractions of ms.

from lv2.

I just can speak for my use case: Ardour displays times with a precision of 1 ms, what is equivalent to … / 48 / 96 / … samples. When precisely compensating microphone distances, 1 ms / 1 ft is quite coarse.

I'd name it offset-swh.lv2 / Artificial offset (sample based) if you think that is adequate.
I go for a slightly different name because it has different ("reverse") semantics in comparison to "Artificial latency". Further "delay" feels a bit to much related to mixing/artistic effects whereas the use case for this plug-in is very technical.

from lv2.

Ah, OK. Agreed that 1ms is too coarse.

Name sounds good.

from lv2.

I agree this would be a very useful addition.
There's balance.lv2, but that doesn't do negative delay, which is indeed very handy when aligning mics.

from lv2.

It is actually very easy - I hope that I find the time to issue a proper pull request soon.

from lv2.

I have a trivial plugin working that acts in analogy to the plugin "Artificial latency": it reports the desired offset as latency to the plugin host.

However, there are two further questions where LV2's docs and the IRC channel was not very enlightening:

1. Is it bad practice or something to report a negative latency to the plugin host?
   (This is the way it is "implemented"). It works fine for Ardour.
2. Is there a way for a plugin to update control value values?
   Because ideally, the offset could be set in milliseconds and samples and when setting either one, the other value would get updated accordingly.

I choose the bounds -24k and 24k since even at 192kHz, that corresponds to ~42 meters / ~140 ft and should be sufficient in almost all cases (if not, it can be chained, of course).

from lv2.

If the LV2 spec doesn't say otherwise, then plugins are free to emit whatever latency values they like. The onus is on the hosts to handle anything, as there's more plugins than hosts.

Of course, how the host interprets it will likely vary... I've no idea if there's consensus behaviour.

from lv2.

Okay I just double-checked and found hints that is is not the favored way of doing it. I'll work on a proper implementation ASAP - probably this comes with the possibility to automate.

from lv2.

fixed by #11

from lv2.