[LAD] Plugin buffer size restrictions

[Paul Davis]

as once again another discussion that could be a useful technical
discussion turns into a stupid spitting match. sigh.

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.

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.

this is also a characteristic of ASIO and EASI and Rewire and many
other audio-related APIs.

now, we can sit here and listen to you and dave mudslinging about the
sanity of this or that. you can, if you want, insist that everyone who
designed AU and RTAS and VST also don't understand audio programming.
maybe you're even right about that (though it seems less likely). but
that doesn't actually solve anything or move anything forward.

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.



On 5/26/12, Fons Adriaensen <fons at linuxaudio.org> wrote:
> On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
>
>> This is not a problem.  If a plugin exists that requires this
>> functionality, it won't work in hosts that can't provide that
>> functionality.  Compared to the situation of that plugin not existing at
>> all, something has been gained, not lost.  There is literally no
>> downside to this situation.  Feature, not a bug.
>
> Compared to the actual situation (without that extension) something
> is gained indeed. But it's like paying off $5 if you start with a
> debt of $10000.
>
>> If, as you go on to argue, a fixed size solution is so superior,
>> then plugins will require it, and in turn hosts will support it.
>
> I doubt it. That would happen if host and plugin authors
>
> * strive to make high-quality plugins only,
> * take decision on technical grounds rather than
>   opportunistic ones.
>
> The first condition is contradicted by history - I won't
> hesitate to say that 50% of all LADSPA plugins are crap
> (somewhat better for LV2), and that 90% have serious
> flaws that are more often than not related to the way
> that control parameters are handled.
>
> Your own argumentation of why certain things in LV2 are what
> they are (because LADSPA did it that way) is an example of
> the contrary of the second.
>
>> It is, for well-known historical reasons, adopted from LADSPA.
>
> I know.
>
>> It's not "fixed" (You say that because the following argument
>> depends on it, but it is simply not true).
>
> It was part of the 'core spec' last time I looked. All plugins
> are supposed to accept a process call for any number of frames.
>
> Which leads to an interesting observation: you extension
> actually negates part of the core specs. So that is allowed ?
>
>> You criticize LV2 for having control ports, but then say an alternative
>> is impossible because it would be invasive?  This does not make sense.
>
> Not for having control ports. For encouraging (almost mandating -
> there is no alternative in the core spec) a way to provide control
> values at arbitrary points by manipulating the nframes of a process()
> call. There is a world of difference between
>
> 1. telling a plugin that at N frames from the current position the
>    parameter P should have value V, and
> 2. doing the same, while also requiring that the plugin outputs
>    N frames at that time.
>
> My argumentation is that doing (2) is a bad idea, and even more so if
> you consider that (1) is a silly thing to in the first place, at least
> for the usual audio processing tasks such as EQ, dynamics, and most
> effects. The exception is synthesis modules of course, but those should
> have a dedicated mechanism for it anyway, or accept audio rate controls.
>
> The full report included a detailed anaysis of why (1) is a bad
> idea in most cases (with the exception of synthesis modules). It
> is because it makes it almost impossible for the plugin code to
> compute good parameter trajectories. A well-designed EQ, effect,
> compressor, etc. should actually *ignore* attempts to control its
> internals in such a way. So there was never any need to allow
> arbitrary nframes values. The correct thing to do would be to
> remove that from the core spec, and provide an extension for
> finer-grained 'sample accurate' control.
>
>> FUD, or solution.  Your choice.  I'll be over here solving problems if
>> you need me.
>
> Been there before, I get used to it.
>
> 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)
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>