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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
