linuxaudio.org

On Sun, 2012-05-27 at 21:59 +0300, Stefano D'Angelo wrote:

[...]

quoted text
> 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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev