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

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


On Wednesday 04 December 2002 19.31, Steve Harris wrote:
[...]
> > Good point. In fact, I would say that pitch and velocity are just
> > two arbitrary "instantiation parameters" for notes. For some
> > instruments, they're hardly applicable at all, while for others,
> > they're completely insufficient. That's why I'm leaning more and
> > more towards entirely doing away with on/off events as such, and
> > just using controls. A synth can interpret a "velocity" control
> > like an on/off switch with note on velocity - or as bow speed, or
> > air flow/pressur, or whatever...
>
> Yes, but voice_on/off is a commonly useful abstraction.

Well, yes, but I'm becoming more and more convinced that it only 
makes sense in the internals of some

> Hoever
> making sure htat the API is scale neutral (unlike generic MIDI) is
> important. I'm not sure what the best way to ensure this is.

I use "linear pitch". 1.0 would be your MIDI standard middle C. +1.0 
would give you the next higher semitone, and +12.0 would give you the 
next higher octave.

Being that note IDs have nothing to do with pitch, you can use 
whatever scale you like, as well as starting all notes at the same 
pitch, or whatever.


> Obviously pitch and velicty are optional, not all instruments have
> either. Thats one reason if favour of using well know portt names
> to indicate what voice parameters normally map to what MIDI
> controls.

Yes, indeed. Most poeple will just want to throw a synth in and start 
playing, so hosts must have a way of figuring out some sensible basic 
routing. Musicians in general probably don't want to connect ten 
"cables" on the screen before they can even get the basic data from 
the MIDI controller into the synth. :-)


> > How about the host knowing that this is the name of a file that
> > should go with the project? I would suggest the following file
> > name "flags":
>
> OK, that is a good point, it would make the host able to store the
> session more easily, and package it up my copying the file into
> local space, and changin the path.

Yes, that's the idea. Getting the best of two worlds: Separate 
(possibly human readable) files, as well as useful project management 
capabilities.


> > Right, either you get memory - or you're screwed.
> >
> > That said, it's possibly to implement real time memory managers,
> > and I think the host designer should have the option.
>
> But if the api is like LADSPA you're not allowed to do allocation
> in the RT part anyway, so you may as well stick to malloc and
> friends.

That's not the whole story. When you hit malloc(), we're talking 
*unbounded* latency. That means it may take 10 seconds to instantiate 
a plugin. This may be ok if you never instantiate plugins "live", but 
if you do (for live gigs, or whatever), you should be nervous about 
this.

Maybe it's no big deal; most people can probably just instantiate all 
plugins before starting to play. I just don't like assuming that this 
will never be an issue, when the solution is as simple as two host 
calls that would normally wrap malloc() and free().


> If hte host is desperate to use something else it can
> override them with LD_PRELOAD.

Yeah - on some platforms. And it's a rather messy hack for something 
like that, IMHO.


> > Good point. I still think it's nice if hosts can construct basic
> > GUIs for simple plugins, but I see no point in taking any major
> > design measures with host constructed GUIs in mind.
>
> Sure, but simple instruments dont require file i/o or any of that
> stuff anyway.

Well, then there's no problem. It's just that if we design an API for 
simple instruments, I can quarantee that it won't be too long before 
we're here again, discussing a third API for "advanced instruments". 
(That will probably happen anyway, but we can at least *consider* 
covering what we know already.)

Or we just design an event system and strap that onto JACK as well as 
a stripped version of LADSPA. :-)


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