[linux-audio-dev] XAP: magic 'sys controls' vs normal controls

Tim Hockin thockin at hockin.org
Mon Dec 23 18:35:01 UTC 2002


> > 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



More information about the Linux-audio-dev mailing list