On Mon, 2012-05-28 at 22:40 +0000, Fons Adriaensen wrote:
No rush. I am particularly interested in your thoughts on my question
about how L is related to the run buffer size, and what restrictions
there are there (e.g. L of course at least has some minimum value
dependent on the sample rate to make bandlimited interpolation possible
at all, but surely there is more to it in various cases)
> It's not a simple issue. For example you mention that control
Actually I think it's globally significantly *less* complicated to
provide future values.
> So it ends up as an exercise in weighting pros and cons, you
Absolutely true. All of these issues, various scenarios and the
different ways they must be handled, are inherently there no matter
However, everything gets quite ugly and complicated when the values the
plugin has during run() have different time bases, because all those
different scenarios then cross-cut the plugin API, and it's *everyone's*
problem to carefully deal with *every* case that exists. This is
probably literally impossible.
Even if it isn't, as you mentioned - lots of code sucks. If plugins
have to have fancy configurable control latency settings it takes a
mailing list of intelligent people weeks to even figure out - they're
simply going to do it wrong.
However, it seems possible to move all of that stuff out of the plugin
API so those different scenarios become only the host's problem.
Everything then becomes clean and feasible.
In my opinion, having several different interpretations for controls
depending on scenario in the plugin is an impossible solution. It would
never happen. Avoiding this, then, is an overriding requirement. We
need *one* way of describing controls in run() that works in all cases.
I think providing synchronous control events, with 'future' values (at
least some distance L in the future) is the way to get that. Let's
pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this
way, is stable and unmalleable, and all you have to work with to deliver
your product (a plugin).
>From the plugin author perspective: is there anything that is
*impossible* to do correctly?
Linux-audio-dev mailing list