[linux-audio-dev] Plugin APIs (again)

David Olofson david at olofson.net
Wed Dec 4 15:22:01 UTC 2002


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 ---



More information about the Linux-audio-dev mailing list