Re: [LAD] Plugin buffer size restrictions

On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen <fons@email-addr-hiddenwrote:

> 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.

_______________________________________________
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:01 2012