[LAD] Plugin buffer size restrictions

[Fons Adriaensen]

On Sat, May 26, 2012 at 05:08:47PM -0400, David Robillard wrote:
 
> Here, notice a plugin not working in the host is *inherent*.  This is
> why LV2 folks generally don't consider this a "problem" - it isn't one.
> If the host literally *can't* provide a given feature (e.g. fixed buffer
> size) and the plugin *requires* it to function at all, well, clearly the
> plugin can't work in that host.  LV2 merely provides a mechanism to
> express such things.  The decision of whether to do them is inherent.

Understood, and not for the first time. But it leads to chicken/egg
situations. I'm not going to write an LV2 requiring N features if 
there isn't a host providing them. And probably vice versa for host
authors. And that is why I'd prefer a more demanding core spec.

Dave, if there is anything I find contradictory in your argumentation
(and that is often why I react to it) it is that you seem to sweep
this point under the carpet, while in other cases you can be very
pragmatic. 

> It is not my job, or your job, to tell plugin and host authors what they
> can and can not do.  Ad hoc extensions are where innovation happens,
> where solutions get sorted out *before* they become part of the main
> spec.  You can't sort them out without actually implementing them.
> Software simply does not work that way.  Ever.

Mmm, I'd like to disagree. Most open source software may be developed
in such conditions - but that is both a strength and a curse. Having
worked some ten years developing software for space and aviation I 
can tell you things are different there. And that has some advantages.

> It will all work out eventually.  You've been around here long enough to
> know everything ain't happening tomorrow regardless :)

Yes. But that's no reason to not learn from the past. Which is what
LV2 started out to do...
 
> This is a bit difficult to decipher.  You are saying you think
> block-accurate controls at a given fixed minimum size are good enough?

For anything except synthesis, yes. Not only good enough, but actually
much easier to implement correctly. 
 
> However, making "synthesis modules" an exception is kind of pointless
> over-classification.  Either a sample accurate control mechanism is
> required, or it isn't.  There is no hard distinction between "synthesis
> modules" and other things anyway, it is not a useful (false) dichotomy.

If 'sample accurate' control would be the only difference between
'general purpose' and 'synthesis' modules I'd agree with you.

But it isn't. 'Polyphonic' is not the same as 'multichannel' for one.
And synthesis modules may require real-time instantiation - no need
for that in case of an effect in a DAW. My conclusion is that the
two are fundamentally different. Which doesn't mean that a plugin
standard couldn't provide both. But probably not by ignoring the
differences.

> It's odd to speak of this like there has been some active decision to
> "allow" arbitrary nframes values.  It's more accurate to say that
> basically nothing has been said about this thus far.  It is simply an
> absence of well-defined restriction because nobody has defined them yet.

AFAIK, the 'core spec' requires plugins to accept a non-constant nframes:
 
 "Thus the "control rate" is determined by the block size, which is
  controlled by the host (and not necessarily constant)."

> It'd have been solved and implemented long long ago if it was brought up
> in useful channels and not weird cloak and dagger reports...
 
Nothing cloak and dagger about it. If someone is prepared to pay me for
writing a report on something I do have strong opinions about (and very
probably because of that), should I refuse that ? It's a consultancy
job just like any other. And at least one other well-known developer  
got the same.

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)