Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 04 2002 - 19:59:12 EET
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 ---
This archive was generated by hypermail 2b28 : Wed Dec 04 2002 - 20:02:06 EET