linuxaudio.org

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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> "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

quoted text
> 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)
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev