27 May
2012
27 May
'12
12:02 a.m.
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)