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

Steve Harris S.W.Harris at ecs.soton.ac.uk
Wed Dec 4 05:08:00 UTC 2002


On Wed, Dec 04, 2002 at 01:09:57 -0800, Tim Hockin wrote:
> > Well, a guaranteed unique ID is really rather handy when you want to 
> > load up a project on another system and be *sure* that you're using 
> > the right plugins... That's about the only strong motivation I can 
> > think of right now, but it's strong enough for me.
> 
> Ok, I see your motivation for this.  I hate the idea of 'centrally assigned'
> anythings for something as open as this.  I'll think more on it..

The central part can be very open, eg in URIs you're allowed to assign
URIs from any domain you have control over, so I could label somthing
"http://plugin.org.uk/foo#23". This means that anyone with a website can
assign URIs.

[NB I know it starts with http:, but it /not/ a URL, me and some others
    argued it should have a non-resolvable protocol name, but...]

I dont really like using strings for UIDs though. Its too easy to read
semantics into them.

> > IMHO, plugins should not worry about whether or not their outputs are 
> > connected. (In fact, there are reasons why you'd want to always 
> > guarantee that all ports are connected before you let a plugin run. 
> > Open inputs would be connected to a dummy silent output, and open 
> > outputs would be connected to a /dev/null equivalent.)
> 
> I disagree with that - this is a waste of DSP cycles processing to be sent
> nowhere.

No, its a waste of DSP cycles to check whether something's there or not.
 
> 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.
 
> Should I use a different word than 'port'?  is it too overloaded with
> LADSPA?

No, thats exactly a good reason to use the word port (unless youre
describing something thats actually different).
 
> So the host would know that if it connects 1 output, the name is "mono", and
> if it connects 2 ouptuts, the names are "left", "right", etc.  Then it can
> connect "left" to "left" on the next plugin automatically.  And if you want
> to hook it up to a mono output, the user could be asked, or assumptions can
> be made.  This has the advantage(?) of not specifying a range of acceptable
> configs, but a list.  It can have 1, 2, or 6 channels.

I'm not sure I like the idea of varying the behaviour of the system
depending on the number of connections, I have hardware that does this and
it drives me nuts. Especially when patchbays come into it. ITs kind of
forgivable in hardware, as noone wants to buy a sperate mono and stereo
reverb, but in software I dont think theres any such excuse.
 
> I'm back to being in a quandary.  Someone convince me!

Dont bundle up channels! People dont do that in studios for a good reason.
a single channel on a single connections is simple, unambiguous, obvious.
But say you have 2 channels is that L+R, M+S, C+M? how about 8, is it 7.1,
8.1 pre filter, 5.1 in ADAT? What do you do when you have a 5.1 bundle
and you want to send it as 5.1 in ADAT? Does that require a 5.1 rebundler?

I think its much better just to have discrete, mono channels that can be
assigned as needed.
 
> * you can limit polyphony in the host
> 	- when I trigger the 3rd voice on an instrument set for 2-voices, I
> 	can note_off() one of them

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.

> Side note:  is there a mechanism in jack for me to pass (for example) a
> 'START NOW' message or a 'GO BACK 1000 samples' message to a Jack port?

Jack has strinport comtrols that can be use to move the conceptual time of
the jack system, loop, sync etc.
 
> Actually, our focus is slightly different.  I'm FAR less concerned with
> sample-accurate control.  Small enough buffers make tick-accurate control
> viable in my mind.  But I could be convinced.  It sure is SIMPLER. :)

I thought this too unltil recent, but Benno demonstrated to me that sample
accurate is not significantly harder, and is more efficient in general.
 
> I've contemplated an array of params that are configurable per-note.  Not
> everything is.  What if we had something like

If the per-voice params are different to he poer-instrument params then
something has gone seriously wrong.
 
> I think INT, FLOAT, and STRING suffice pretty well.  And I MAY be convinced
> that INT is not needed.  Really, I prefer int (maps well to MIDI).  What
> kinds of knobs need to be floats?

Seen as plugins internally work in float, all knobs need to be float ;)

> 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).
 
> 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?
 
> With this I agree.  One of the reasons I HATE so many APIs is that they are
> grossly over normalized.  I don't need a pad_factory object and a pad object
> and a plugin_factory object and a parameter object and an
> automatable_parameter object and a scope object...  I want there to be as
> FEW structs/objects as possible.

Good, so ditch int and string and replace them with a generic binary type ;)
 
> 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.
 
> > 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.
 
> I don't really want the plugins writing files.  I'd rather see the host
> write a preset file by reading all the control information, or by the host
> calling a new char *oapi_serialize() method to store and a new
> oapi_deserialize(char *data) method to load.

Agreed.

- Steve 



More information about the Linux-audio-dev mailing list