4 Dec
2002
4 Dec
'02
4:21 p.m.
On Wednesday 04 December 2002 19.24, Steve Harris wrote:
[...]
Right, but do mixer plugins belong in an instrument API? Be good at
one thing...
Yes - but if you remove the features needed to support things like
mixers, you also remove features that instruments may need. Not
everyone wants to build instruments out of lots of little plugins.
Besides, mixers need automation...
We have another terminology clash, I think... I thought this was
about per-voice control vs per-channel (MIDI style) control - but now
that you mention it, there's a third kind of controls; per-plugin
instance - or per-instrument controls. I would agree that the these
should have a list of their own, as they may in fact have no relation
whatsoever to per-channel or per-voice controls. (I would assume
they're meant for controlling voice allocation parameters, routing,
internal master effects and things like that.)
The binary data comes from "GUIs", I still dont see how a generic
UI can usefully deal with filenames, it can pop up a file selector
dialgoue, but the user doesnt know what thier looking for.
Another good point. Maybe not even file names are a sensible
candidated for a standard control type. But I still think it may make
some sense if the host knows what to do with the *files*, even if it
doesn't understand anything about their formats or naming conventions.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
In a modular system, each oscilator etc, is monophonic
and you
clone whole blocks of the system to make it polyphonic. Also, pitch
is controlled via CV control and gate, which doesnt map well to
midi style note events.
Another reason why having those events at all is a bad idea...
Note that with an event based system (or a callback based system -
but not a shared variable based system, such as LADSPA), you still
actually have *events* for everything. It's just a matter of
interprettation. If you feel like a MIDI synth, just interpret the
first velocity change to a non-zero value as NoteOn with a velocity
of the argument value. Then wait for a velocity change to 0, and
treat that as NoteOff. (Or rather, NoteOn with vel == 0, which is
what most controllers and sequencers send, unfortunately. :-/ )
Sure, you could coerce the described system into a
modular
voewpoint but there would be a lot of overhead and neadless
complexity.
Well, all I have to say on that is that I think it's a bad idea to
draw a strict line between the two kinds of systems. I think one API
that handles both would be a lot more like real analog stuff, where
you don't really have to worry about protocols and APIs - it's all
just analog signals. I'd like to be able to use virtual studio style
plugins inside my modular synth networks, and vice versa, as far as
practically possible.
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.
I'd agree with this, but for a few exceptions:
* Mixer plugin. I really do want it to have a variable number of
inputs. I don't want to say 48-channels or 128-channels. If you can give me an example of an instrument that
benefits from
variable numbers of i/o and doesn't deserve to be a standalone jack
client then I'l agree with you.
Good point - if we were talking about a plugin API strictly designed
for synths. From what I've seen on the VST list, assuming that an
instrument is one thing and an effect is another is just plain wrong
- and that's still within a single API.
Anyway, a stand-alone JACK synth would still need a way to get
control events from a sequencer - just like synth plugins, or effect
plugins. Should we use ten different ways of controlling synths, or
does it perhaps make some sense to have a common protocol for that?
That said, the way Audiality is designed currently, the event system
is a totally independent subsystem. All you need to take part is an
event port and a process() callback. If JACK clients could
communicate events of this type, there would be no problem; we could
"just" decide on a common protocol and hack away.
Can we assume
that all voices have a standard control mapped to
velocity? Or should the per-voice controls actually be another
set of controls, and each instrument needs to specify
velocity,pitchbend (and others)?
Here you could make use of well known labels again,
note-on-velocity, note-off-velocity, pitchbend etc. The host can
map these to the normal MIDI controls of it likes.
It probably makes sense to list the per-voice controls speratly
from the per-instrument. Its just important that they are the same
at a fundamental level (otherwise you end up with very confused
developers and code). My feeling is that just float+"arbitrary opaque
binary data" is
enough. The float can be augmented with hints, enumerations,
whatever.
String is needed if we want to deal with filenames without a
custom GUI. Opaque binary data has no meaning to the host, and
the host is what manipulates controls. Where does it get that
data?