linuxaudio.org

2012/5/27 David Robillard :

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

Sure, it's all sound and nice. I was only wondering whether there is a

smarter way to do things.
Stefano

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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