Re: [LAD] Plugin buffer size restrictions

On Sat, 2012-05-26 at 19:47 -0400, Tim E. Real wrote:
> I added variable run-length processing to MusE.
> It can break a period into single frame runs if necessary.
[...]
> What about encoder and decoder plugins? Yer switching matrices etc.
> Their precise control rates and timestamps must be preserved right?
> I guess if LV2 allows hi-speed control rates, it would cure the issue with
> some ladspa audio ports being used for hi-speed control, with no way to
> know that fact.

LV2 does have CV ports, which are identical to audio ports but
semantically the values are control values.

For discrete controls, actually you can easily do this with a normal
event port, just as we do MIDI. There's just a lack of convention, or
standard event type to convey control values.

Once you go that far, though, you start questioning why you're using
different port buffers when it's easy to multiplex controls to a single
buffer, which is:

* More space efficient
* Easier to iterate over and process as time progresses (but harder for
some other things)
* Allows for dynamic controls (e.g. n-band EQs and such), a highly
desirable feature
* Faster than multiple run() calls due to decreased
function-call-via-a-pointer overhead

> Whaddya you guys think?
> Or did I actually just provide arguments /against/ vari-runs? Ha ha...

Basically you've provided arguments that the control rate not always
being the Jack buffer size is good. Few would argue that.

It's splitting the cycle on odd numbers that causes problems for certain
kinds of plugins. However it should be mentioned (despite suggestions
to the contrary) that if a solution to this was implemented, it is
trivial to make old plugins adapt to restricted buffer sizes. It's the
other way around that doesn't work.

Cheers,

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun May 27 04:15:02 2012