On Thu, 2012-05-31 at 06:59 +1200, Jeff McClintock wrote:
That's essentially the "variants" I am trying to avoid, with the
combinatorial explosion and all that. Might be worth it for
optimization in some cases, but probably not significant in most.
Probably only when branching can be avoided, and vectorization can only
be achieved in the optimized version.
(I actually think vectorization is a better argument for block size
restrictions than the previously mentioned things. That stuff (e.g.
SSE) is literally designed for audio and makes a massive difference, but
plugins can't make the best use of it without certain guarantees)
You can do all the above things mentioned in a host, especially if the
module API is internal and you can do whatever you want, but if a 'dumb'
plugin only reads a single float, well, it only reads a single float.
I guess you could say I'm trying to drag LV2 out of the "dumb plugin"
That said, I don't know if "CV everywhere" is really the best solution.
For some parameters, the ability to do audio rate modulation is
definitely key, and much more of that in 'standard' plugins would be
great. However, for other things, not so much, and it does make for a
severe increase in memory consumption. In modular environments a more
clever buffer allocation scheme could make that less of an issue. Mine
is currently admittedly quite dumb :)
I am tending towards the conclusion that *both* CV and events (i.e.
sending changes) are needed, but single floats just plain suck.
> > personally my interest in a solution here is very real. More people
Go team! :)
Linux-audio-dev mailing list