On Sat, 2012-05-26 at 20:05 +0000, Fons Adriaensen wrote:
Sure it is. In this case, it's not even weird, if we do this now it
will look EXACTLY the same as if we did it from day one. It's a
textbook case of what the feature mechanism was designed to do, and not
weird or unnatural at all.
In LV2, stuff like this is done via "features". A feature is either
optionally supported, or required, by a plugin. In code, the host
passes a struct to instantiate for each supported feature which may
contain whatever (in this case, probably a get_buffer_size() function
and so on).
The host may not instantiate a plugin if it *requires* a feature it can
not provide. So, in this case, if the plugin requires e.g. a power of 2
buffer size, and the host can't provide that, well.. it can't provide
that and the plugin can't be used. This isn't crazy decentralized
metadata pipe-dream stuff, it's the way the API would be made from day
one anyway; extremely straightforward basic C stuff.
Because of what "required" means, you can do pretty much literally
anything with a required feature. You could define a feature where the
host must fetch the fifteenth byte from http://linuxaudio.org and pass
that to instantiate if you wanted to. It's crazy, and *requiring* that
feature surely means your plugin isn't going to work almost anywhere,
but that's fine.
In this case, however, it's not crazy at all. It's the most natural
thing in the world.
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.
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.
Different host authors have different opinions about conservatism and
compatibility and such. This is fine and good and expected and natural.
It will all work out eventually. You've been around here long enough to
know everything ain't happening tomorrow regardless :)
tl;dr: If buffer size restrictions are the way to go, then let's go that
way. It's just that simple.
> > You criticize LV2 for having control ports, but then say an alternative
This is a bit difficult to decipher. You are saying you think
block-accurate controls at a given fixed minimum size are good enough?
That's just LADSPA with a simple restriction on sample_count parameter.
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.
> The full report included a detailed anaysis of why (1) is a bad
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.
If you're content with LADSPA style controls with just a restriction on
block size, that's trivial. I don't really see why you've made such a
big deal about it. There's plenty of questions raised by a sample
accurate control port (mainly whether to MUX the controls to a single
event buffer or not), but no questions about that. From a spec POV,
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...
Linux-audio-dev mailing list