13 Dec
2002
13 Dec
'02
12:27 p.m.
On Friday 13 December 2002 15.08, Steve Harris wrote:
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.)
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.
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.
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 ---
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:
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. ;-)
* 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...) 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. /*
* 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.) #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. 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. ;-)