4 Dec
2002
4 Dec
'02
5:40 a.m.
On Wed, Dec 04, 2002 at 03:04:18 +0100, David Olofson wrote:
IMHO, plugins should not worry about whether or not
their outputs are
connected. (In fact, there are reasons why you'd want to always
guarantee that all ports are connected before you let a plugin run.
Open inputs would be connected to a dummy silent output, and open
outputs would be connected to a /dev/null equivalent.)
In modular synth systems there are good reasons why you want to know
whether things are connected (and good reasons why they wouldn't be), but
this spec so far is not useful to a modular synth, so in this case I
agree.
I think there should be as little policy as possible
in an API. As
in; if a plugin can assume that all ins and outs will be connected,
there are no special cases to worry about, and thus, no need for a
policy.
Yes.
Strongest resason *not* to use multichannel ports:
They don't mix
well with how you work in a studio. If something gives you multiple
channels as separate mono signals, you can connect each one wherever
you want, independently, which gives you total control without the
need for the rest of your plugin chain to understand any multichannel
formats.
Strongest reason *for*: When implementing it as interleaved data, it
may server as a performance hack in some situations. It is still
unclear to me, though, whether or not this applies to "your average
plugin" in a real virtual studio, and even if it does, whether the
complexity/performance ration is anywhere near justifiable. (I
suspect not.)
Interleaved data is more trouble that its worth IMNSHO. I think
multichannel outputs are extra complexity with no benefit.
I'm not sure what peoples opinions on numbers of outputs are, obviously the
number needs to be variable per instrument at development time, but I dont
think it should be variable at instantiation time, that doesn't sound
useful, and it would be hell to optimise.
> Can you expound on the well-known labels idea?
I'm
> not sure I fully understand what you're thinking.
...
In a plugin API, you could standardize the way of
"naming" these in
some way, such as always marking things MONO, LEFT, RIGHT, CENTER,
BLEFT, BRIGHT, SUB etc etc. Use a string, or a struct with some
enums, or whatever; just put it in the API, so hosts can make sense
of it.
Yes, thanks, thats exactly what I meant. I also proposed a system like
this for standardising panners (eg. stereo in/5.1 out) in LADSPA. Noones
tried it yet, but it should work :)
On controls:
It seems like you need two sets, per instrument and per voice, they should
share the same interface, and the per voice ones definatly should not be
limited to modulation,chorus,whatever.
My feeling is that just float+"arbitrary opaque binary data" is enough.
The float can be augmented with hints, enumerations, whatever.
- Steve