[LAD] Plugin buffer size restrictions
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
> - 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...
More information about the Linux-audio-dev