Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 04 2002 - 22:16:57 EET
On Wednesday 04 December 2002 19.24, Steve Harris wrote:
[...]
> 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.
>
> 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...
> 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).
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.)
> > > 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?
>
> 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 ---
This archive was generated by hypermail 2b28 : Wed Dec 04 2002 - 22:19:54 EET