Another
alternative - have a new control type that does not have
default, range, etc fields.
Well, they *are* of different types, so why should they have
defaults, ranges etc at all? Each control type has it's own struct
for this anyway, right?
SYS_CTRL just has hints to the host
about the existence of a 'special' event port, without actually
specifying a full control.
Yes, that could be one way. These "things" have to be strictly
standardized anyway, so there's no real need for dragging any
metadata around. Only the type field is needed, basically.
ok, ideas for comments:
struct XAP_descriptor {
...
int n_sys_controls;
XAP_sys_control *sys_controls;
...
};
enum XAP_sys_controls {
XAP_SYS_TEMPO,
XAP_SYS_TIMEBASE,
XAP_SYS_METER,
XAP_SYS_METERBASE,
XAP_SYS_POSITION,
XAP_SYS_TRANSPORT,
XAP_SYS_CUEPOINT,
XAP_SYS_SPEED,
XAP_SYS_POLYPHONY,
};
host {
/*
* get each control queue, then each sys_control queue for each
* channel in the plugin.
*/
for each Channel in Plugin {
for (i = 0; i < channel->n_controls; i++) {
plug->xap_get_event_port(plug, channel, i);
}
for (i = 0; i < channel->n_sys_ctrls; i++) {
plug->xap_get_event_port(plug, channel,
XAP_SYSCTRL_BASE + i);
}
}
Random thoughts:
* sys_controls could be per-plugin not per-channel - they really ARE
plugin-global: TEMPO, METER, TIMEBASE, TRANSPORT, etc. Making them
per-channel means we can have POLYPHONY, VOICE_ON, and SEEK be sys controls,
too.
* This is all designed to take away the extra fields that aren't needed for
magic controls. Maybe that is a waste of energy. Just define macros for
making them taste like normal controls, and tell plugin writers to deal with
the wasted memory/footprint.
* If they taste like normal controls, we need to flag them as system
controls. They really ARE special to the host/sequencer/timeline.
* MIDI-compatible controls are essentially fixed controls, too. We don't
want to break those out. But they aren't as 'special' as these.
Anyone have ideas on the cleanest representation?
Tim
