2012/5/27 David Robillard <[email protected]>: > 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
