On Wed, 2007-05-09 at 15:41 +0200, Fons Adriaensen wrote:
3. Plugins may want to delegate some of the processing
to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
Can be done as a HostFeature.
So a plugin writer can't count on it.
4. There
are 'audio rate' and 'control rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
Can be done as a HostFeature.
Again, of no use it you can't count on it being present.
5. If a
plugin is instantiated multiple times to operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
Can be done as a HostFeature.
Same remark as the two above
This is intentional. LV2 is not intended to include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
If something you require is not present, the plugin simply won't work in
that host. You (the plugin) can also make things optional so the
functionality will only be used if supported by the host.
This is a Good Thing(TM), not a bad thing. Bloating the spec requires a
real reason why a thing /must/ be in the core specification, i.e. why it
will not work at all as an extension. Plugins can "count on" anything
they want, if it's not provided things will simply fail gracefully (a
lot of thought has been put into being sure of this).
The simple reason for this is that we cannot be building every single
thing into the spec, because the spec would never exist. We'd be having
the same old LADSPA GUI rant fest on l-a-d all day, and nothing would
get finished. The line needs to be drawn somewhere, so it was drawn as
"equivalent to ladspa, with whatever additions necessary to be fully
extensible".
That said, I like most of your ideas, particularly control ports - I
hate them, lots. Hopefully someone comes up with a better solution and
they disappear entirely one day. Being a modular guy, I want CVs, but
others want timestamped events. It would be nice if we could have some
kind of polymorphic control port that supports all these uses, though
personally I think timestamped controls might as well just be more fully
featured messages.
Optional support for fundament things is not a
solution.
None of the things you have mentioned have any /actual/ reason to go in
LV2 itself, except the sample rate issue which does need to be figured
out. I'm for making it a rational number or double; locking it as an
int for no reason when there's any reason for something better at all is
short-sighted.
I do think I vaguely remember some reason why floating point sample
rates aren't good though.... ?
-DR-