[LAD] Plugin buffer size restrictions

[Fons Adriaensen]

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.
 
> 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. A well-designed plugin 
should actually impose its own limits on the rate of change or
the bandwidth of its controls, which means it should ignore some
of the things the host tries to make it do. Which in turn means
it's futile for the host to even try.

> you write as if when we designed LADSPA to "support" this, that no
> other plugin API formed a part of the considerations that went into
> that design process. every other plugin API that had a visible spec
> specifically provided for variable frame counts. even in the AudioUnit
> spec, which additionally provides much more sophisticated, scheduled,
> non-scalar mechanisms to deliver automation data, it is *still*
> mandatory for plugins to be able to accept any frame count from zero
> up to some size specified during the last reset.

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
- the requirement for a plugin to accept any value of nframes as an
easy way to allow 'sample accurate' control - into the 'next generation'
was probably a bad idea. Some others parts of the LADSPA specs were not
retained - for good reasons.

> ardour has no requirement to subdivide blocks for automation data.
> precisely because i wasn't interested in implementing support for AU's
> slightly complex automation API, its entirely possible to have do
> block-accurate automation only. and if someone wanted to a bit of work
> to use an API like AU where you can pre-schedule parameter changes, it
> could revert to sample accurate when necessary. plugins are free to do
> whatever they want with the host's attempt to do this.

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

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


Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)