[LAD] Plugin buffer size restrictions

Paul Davis paul at linuxaudiosystems.com
Sat May 26 22:34:48 UTC 2012


On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen <fons at linuxaudio.org>wrote:

> On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:
>
> > as once again another discussion that could be a useful technical
> > discussion turns into a stupid spitting match. sigh.
>
> So far I didn't spit and I have no intention to do such a thing.
>

I think you know precisely what I mean.

> look fons, variable size frame counts were one approach to a genuine
> problem: how to deliver automation data to plugins. but they were not
> added solely for that reason.

 That is probably true. But that doesn't make using that mechanism
> to deliver automation data a good idea.


in the absence of a part of the API designed specifically to deliver
automation data, its one of the few reasonably straightforward choices.


> A well-designed plugin
> should actually impose its own limits on the rate of change or
>

plugins are free to do this with or without a requirement that they handle
0..N frames. certainly, doing so can be a bit more complex with the 0..N
requirement, but its not impossible - there is an entire company's suite of
plugins that all do this across more than 6 plugin APIs all of which have
the 0..N requirement.

I didn't comment *at all* on the desing process of the LADSPA plugin
> standard. Please re-read. I did imply that copying some aspects of it
>

LADSPA and LV2 are not independent here. the requirement that you're
talking about:


> - the requirement for a plugin to accept any value of nframes


is shared across just about every plugin API out there. on the other hand,
its use as an


> easy way to allow 'sample accurate' control - into the 'next generation'
>

is host-specific, and doesn't have much to do with the API.


> Question: do A2 and/or A3 actually subdivide a period in order to
> deliver automation data or not ?
>

depends on the plugin API in use. in some cases yes, in others no.


> If yes, do they also try to deliver 'sample accurate' control values
> in case these are real-time (from GUI widgets, MIDI, OSC) ?
>

data from control surfaces of any kind is quantized to the blocksize, and
when delivered during  non-automation playback, delayed by up to one block.

automation data is recorded by sampling plugin control port values. the
only thing that can generate sub-block size resolution is GUI-based (or
similar) editing of the data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120526/fd4d3cec/attachment.html>


More information about the Linux-audio-dev mailing list