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