27 May
2012
27 May
'12
10:01 p.m.
On Sun, 2012-05-27 at 21:59 +0300, Stefano D'Angelo wrote:
[...]
In practical terms, especially w.r.t. LV2, there may
be a third way:
let the host pass a limited number of future parameter samples at each
run() (could be negotiated at instantiation time), so that the plugin
doesn't have to add latency to the audio streams in any case. Would be
only supported by "offline hosts". If the block sizes are variable,
future block sizes should be passed as well (argh?). But I don't know
if this really makes sense or has downsides... ideas, folks?
Or just send time-stamped ramped controls (value now is 1.2, value at
some point in the future past this block is 3.9, and so on). This could
be done even online in the case of automated parameters, though of
course not things being actively twiddled by the user live.
I suppose the host could just indicate whether it can send future
control values, so plugins that interpolate can avoid adding control
latency when they don't need to. This maps nicely to a feature, though
it'd be a questionable decision to require it and make a plugin that
doesn't work at all without receiving parameters from the future, since
it'd be impossible to use live. One could argue the host always has to
do the latency part if necessary, I guess.
In terms of API, these can thankfully be tacked completely independently
(even though they impact each other in terms of what plugins actually do
with them). Block size restriction stuff is one thing, a way of getting
more expressive control values into a plugin is another. The former is
easier and more pressing.
-dr