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

David Olofson david at olofson.net
Wed Dec 4 16:11:01 UTC 2002


On Wednesday 04 December 2002 20.46, Steve Harris wrote:
> On Wed, Dec 04, 2002 at 11:05:21AM -0800, Tim Hockin wrote:
[...]
> > can we meet in the middle and say that for some cases it is
> > easier to assume silence, and in others it is easier to check for
> > presence?
>
> OK, maybe. But (as discussed elsewhere) in an event system theres
> no need to check, there wont ever be any events on unconnected
> inputs.

It's different with audio ports, though. (Unless they were in fact 
abstract objects, controlled by the host only through events sent to 
the plugin. I were thinking along those lines in MAIA.)

An audio input or output either needs to have a valid buffer (which 
may be a fake silence buffer, or a trash "/dev/null" buffer), or you 
must ensure that the plugin checks the pointer.

I would prefer that plugins get to handle this themselves in any way 
they like.

	Dead simple:
		Just say you don't support disconnected ports.
		The host will have to give you fake buffers if
		it wants to leave ports "open".

	Nice but simple:
		Accept disconnected ports, and just check the
		pointers, or whatever. (Note that passing NULL
		buffers might have other users. In Audiality,
		it's legal for inputs, and means "silence for
		one frame". IIRC, you can turn the feature off,
		if you like, forcing the host to always pass
		valid buffers.)

	Elegant (implementation dependent):
		Accept disconnected ports. If the plugin is
		a complex beast, chances are it has an internal
		list, tree or network of things to do. All you
		do is deal with disconnected ports when
		contructing that list, tree or network.


> > > I'm not sure about the other arguments, but polyphony control
> > > is complex and probably only the instrument can do it usefully.
> > > If you want this you might have to do it by telling the
> > > instrument what its max poly should be.
> >
> > Perhaps this, with some way of the instrument telling the host
> > about numbers of voices.
>
> If you think its neccesary, it is meaningless in some cases though
> and I'm not clear on what it would be useful for. Every instrument
> feature adds to the barrier to entry and needs to be justified.

Agreed. I think you either use a monophonic patch/instrument, or you 
just let the synth make the best use of it's voice reserve.

Note that per-note/voice controls have nothing to do with this - 
unless you make the same mistake I did in Audiality; use voice 
numbers as note IDs... A voice is one thing, and a note is another. A 
note may not have a voice at all times.


> > > I dont think you can do anything useful with a generic file
> > > string, what could be host use it for?
> >
> > The host could provide a standard file-open dialog for filenames.
> >  The host could provide a text-box for speech-synthesis.
>
> OK, I'm starting to come round on this one.

Well, the file dialog would need some extra info, but it does make 
sense to use the same file selector (provided by the host) for 
everything it could handle, within reasonable limits. (If you want 
the preview button to work for Audiality AGW scripts, you need to 
wait for me to hack a custom file selector. ;-)


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