[LAD] Plugin buffer size restrictions

[Fons Adriaensen]

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)