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

David Olofson david at olofson.net
Wed Dec 4 13:04:00 UTC 2002


On Wednesday 04 December 2002 11.02, Steve Harris wrote:
> > Slight change - a plugin only needs to handle connected inouts. 
> > If an inout is not connected, the plugin can skip it or do
> > whatever it likes.
>
> This is still complexity (if we have a timestamp system), if ther
> are no events on the input hte instrument will ingore it anyway.

True. At least in the case of Audiality, a plugin doesn't really have 
to care whether or not it's event port is connected or not - it just 
checks for events.

BTW, yes, that's *port*. One DSP loop - one event port. This is 
because plugins checking multiple event ports and deciding which one 
goes first doesn't sound like a whole lot of fun. I definitely prefer 
having the host merge/sort, or even having senders sort/insert when 
sending events. I'm doing the latter in some cases currently, but I'm 
not sure it'll stay that way. When you know there's only one sender 
to a port, you can just tack events onto the end of the list, but 
that only works for very simple plugin nets. The main problem with 
sender sort/insert is that it more or less requires a function call, 
while "add as last event" is a very simple operation that is 
preferably inlined.


[...]
> > I'd assume a violin modeller would have a BOWSPEED control.  The
> > note_on() would tell it what the eventual pitch would be.  The
> > plugin would use BOWSPEED to model the attack.
>
> voice_on is proably more instrument neutral. Not everything is a
> note (eg. my LADSPA gong).

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


> > I agree - Bool is a flag on INT.  File is a flag on String.
>
> I dont think you can do anything useful with a generic file string,
> what could be host use it for?

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

	FILE_PUBLIC:
		The file should be considered public on the system,
		meaning that the user should be warned that modifying
		it may affect other projects. Preferably, the user
		should be given the option of editing a FILE_PROJECT
		copy of the file.

	FILE_LIBRARY: (is FILE_PUBLIC)
		This file is from a standard library, and can
		be assumed to be available on other systems.
		It should not be included in bundles for backup
		or transfer, unless the user explicitly asks that
		*all* files are included.

	FILE_USER: (is FILE_PUBLIC)
		This is user created data, or other data that may
		not be available to the public, or on other systems.
		It should be included in bundles for backup and
		transfer.

	FILE_PROJECT:
		The file belongs specifically to this project, and
		can be assumed to be part of the project. The user
		will not be warned about changing the file. The
		file should be included in bundles for backup and
		transfer.


[...]
> > That said, one I am considering adding is a struct oapi_host. 
> > This would have callbacks for things like malloc, free, and
> > mem_failure (the HOST should decide how to handle memory
> > allocation failures, not the plugin) as
>
> Memeory allocation failures dont really happen in RT systems, you
> get massive overruns first.

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.


> > > Yeah, I know. It's just that I get nervous when something tries
> > > to do "everything", but leaves out the "custom format" fallback
> > > for cases that cannot be forseen. :-)
> >
> > We're speaking of controls here.  In my mind controls have three
> > characteristics.  1) They have to specify enough information that
> > the host can draw a nice UI automatically.  2) They are
> > automatable (whether it is sane or not is different!).  3) They
> > alone compose a preset.  What would a raw_data_block be?
>
> I dont bvelieve the host can draw a nice UI automatically, the best
> it can do is a usable UI.

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.


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