[linux-audio-dev] XAP status : incomplete draft

David Olofson david at olofson.net
Fri Dec 13 11:28:00 UTC 2002


On Friday 13 December 2002 15.08, Steve Harris wrote:
> Generally I agree with David, but there are a few things wher I
> dont:
>
> On Fri, Dec 13, 2002 at 02:30:32 +0100, David Olofson wrote:
> > > 	 * The label is a file-unique, non-whitespace, string
> > > identifier for * the plugin.  Hosts can use the filename and
> > > label to identify a * plugin uniquely.  The label is all upper
> > > case, by convention. */
> > > 	const char *xap_label;
> >
> > Why is this needed? (There are unique IDs, I mean...)
>
> LADSPA has them and its useful sometime, eg. for selecting plugins
> in command line apps, and for developers.

I see. (Easier to remember than the IDs. ;-)


> > > 	void *(*xap_create)(XAP_descriptor *descriptor, XAP_host
> > > *host, int rate);
> >
> > Why only "rate" here - or rather, why "rate" at all? I think
> > there are more things that a Plugin might want to know, so it
> > might be better to pass this kind of info some other way.
>
> Well, you might want to refuse to instantiate, based on the sample
> rate.

Or, in the state based design, you give the host an error event if 
the sample rate is set to an unsuitable value, and refuse to switch 
to a higher state, should the host be stupid enough to try it. 
(Actually, you shouldn't have to check that. A host must *never* 
ignore an error, be it a return value or an event.)


> > > 	/*
> > > 	 * set_rate: set the sample rate
> > > 	 *
> > > 	 * This method may only be called on plugins that are not
> > > active.
> >
> > (Same thing as controls that may only be changed in certain
> > states.)
>
> This should not be allowed, if you want to run the instrument at a
> different rate, reinstantiate it.

Well, that's basically what changing to state CLOSED and back is. The 
difference is that you *can* write and use plugins that say "fine, 
you may change the sample rate at any time".

Not that I think that particular feature is very useful, but this 
applies to things like delay time and similar (memory related) 
parameters of some plugins as well. The mechanism is needed anyway, 
that is.


> > > #define XAP_RTFL_SLOW		0x20	/* is 'slow' in general */
> >
> > Well, everything is relative...
> >
> > I think it would be much more interesting to have a warning hint
> > for plugins that are significantly nondeterministic in their CPU
> > usage.
>
> Agreed. I think tis less confusing to have to indicate that a
> plugin /is/ deterministic though.

Yes... Many coders may not be willing to delve into real time theory, 
or they may not have the time and/or knowledge to make a correct 
decision. So, it's better if the default is to say the plugin is 
potentially nondeterministic, unless it explicitly says that it's 
deterministic.


> Don't do what ladspa did though and mix together RT safe-ness and

Right - those are two entirely different things. (Especially if the 
host is in kernel space, running under RTL or RTAI... *heh*)


> determinicity (is that a real word?).

How would *I* know? ;-)


> > > #define XAP_CTRLHINT_PITCH		"PITCH"		//channel,voice
> >
> > ...and the optional "NOTE_PITCH" that no one will ever use, of
> > course. ;-)
>
> And many of us still think doesn't belong in the API... :)

Well, my remaining point is basically this: Should we have that kind 
of argument about *every* control type hint? :-)

I don't think NOTE_PITCH is much more than that; another control type 
hint. Indeed, if you have a sequencer that only outputs NOTE_PITCH, 
you'll need conversion (explicit or automatic) - but then don't use a 
note/scale based sequencer, or use one that's hardcoded for 12tET, if 
you don't like this. All you'll miss (or not) is a bunch of event 
processor plugins based on traditional music theory.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- 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