13 Dec
2002
13 Dec
'02
3:29 p.m.
#include
<stdint.h>
I'm thinking about using that as well - but how portable is it these
days? (No big deal, though. Just get one, or hack a fake if you
platform shouldn't support it for some strange reason.) /*
* The current version of the API: read as "major.minor.micro".
*/
#define XAP_VERSION 0x000010
#define XAP_MKVERSION(maj, min, mic) (((mar)<<16) | ((min)<<8) |
(mic))
I generally prefer 8:8:16 format these days, so the minor version
field can be used as something like the serial field below. (Why have
both?) struct
XAP_descriptor {
[...]
uint32_t xap_id;
Why the xap_ prefix on all the fields in the struct? I think this belongs in version, as the micro field.
Hosts should
Version is a string - it could be "1.0" or "1.0 rc26" or
"foobar". Host can
not interpret a string. Serial is for multiple builds of the same plugin.
It makes life easier - think of it as a build number for binaries, maybe?
const char
*xap_label;
Why is this needed? (There are unique IDs, I mean...) const char
*xap_version;
This sort of doubles the 32 bit version field, so I'm not sure /* master
controls and I/O */
int xap_n_controls;
XAP_control **xap_controls;
Maybe... I was thinking that you might as well require that the first
Control Port supports "maximum buffer size" (very important!) and
that kind of stuff - but where's the "first" Control Port!? If you int
xap_n_ports;
XAP_port **ch_ports;
What are these for? Shortcut to avoid the more complex system below,
when you don't really need it? //FIXME: how
to get the num/info currently instantiated channels?
When and why? I mean, isn't the host supposed to remember what it's
done? [...]
As discussed before - setting the rate is something you ought not do often.
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. //FIXME: how
to enumerate errors from this?
//FIXME: return something better than void *?
If you use the state() thing, you have a *very* simple initialization * 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.) int
(*xap_activate)(void *plugin, int quality);
int (*xap_deactivate)(void *plugin);
This is both hairy and incomplete, IMHO. One state() call or have hosts calling these functions in the wrong order,
and the order
Which is why I want two states. It's easy to get right :)
XAP_event_port *(*xap_event_port)(void *plugin, int channel, int
index);
I don't think it's a good idea to require that the plugin returns a
struct. This would mean that the plugin needs to allocate memory for I think "now" should be in the host
interface struct. Any plugin that
deals with events will have to mess with the host struct, and either
way, "now" changes only once per block and host; never for each
plugin. (It cannot, because plugins would be out of sync with the
host WRT timestamp conversion requests and the like...)
What about buffer splitting? You then force the host to have separate host
structs for plugins?
struct
XAP_host {
//FIXME: some sort of host ID/version ?
uint32_t host_api;
Yes! //FIXME: how
does the host know where an event came from?
XAP_event_queue *host_queue;
It basically doesn't - but it does (hopefully) know which plugin it void
(*host_alloc_failure)(void);
Why? You can just return a suitable error code... #define
XAP_RTFL_MALLOC 0x02 /* allocates/frees memory */
#define XAP_RTFL_HMALLOC 0x04 /* allocates memory through the host
*/
This should not be optional for normal plugins, IMHO. The host struct
*is* your source of resources - you may not use OS resources directly. Speaking of driver plugins, those will also have to
tell the host
driver plugins?
> #define XAP_RTFL_HFREE 0x08 /* frees memory
through the host */
ok, I'll unify with RTFL_HMALLOC
#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. #define
XAP_CTRLHINT_AFTERTOUCH "AFTERTOUCH" //voice
#define XAP_CTRLHINT_CHPRESSURE "CHPRESSURE" //channel
We should not separate these. They're exactly the same thing, only
one is a channel control and the other is a voice control. (Which
indeed *are* incompatible due to differing addressing needs, but
that's a different story.) #define
XAP_CTRLHINT_PITCH "PITCH" //channel,voice
...and the optional "NOTE_PITCH" that no one will ever use, of
course. ;-)
[...]
> #define XAP_CTRLHINT_HOLDPEDAL "HOLDPEDAL" //channel,voice: bool
Why boolean? (That's more annoying than helpful
with MIDI, IMHO...
Real instruments rarely have *truly* boolean pedals and stuff, and
sometimes, you actually want to make use of that. Whether synths
check for anything but "value > 0.5" is another matter.)
ok - changed