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

[David Olofson]

On Tuesday 24 December 2002 00.28, Tim Hockin wrote:
[...]
> Random thoughts:
>
> * sys_controls could be per-plugin not per-channel - they really
> ARE plugin-global:  TEMPO, METER, TIMEBASE, TRANSPORT, etc.

Yes, if we assume that a plugin can only be aware of one timeline at 
a time. Probably not a major restriction.


> Making
> them per-channel means we can have POLYPHONY, VOICE_ON, and SEEK be
> sys controls, too.

No, the latter two are *per-voice* - although that basically just 
means they take a VVID argument as well.

(Speaking of which, I implemented a VVID manager for Audiality the 
other day. "Finished and tested", although I haven't integrated it 
yet.)


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

How many fields can actually be eliminated? Can't be many bytes, and 
there aren't all that many of these controls. I can't see that it's 
worth any special casing to save a few fields per "magic control".


> * If they taste like normal controls, we need to flag them as
> system controls.

Why? It should be enough to give them datatype codes of their own, so 
no one will get the idea that they're compatible with anything else.


> They really ARE special to the
> host/sequencer/timeline.

In what way? Indeed, the relation between TEMPO and POSITION is a bit 
"odd", but other than that, they're basically just controls used by 
the timeline to express musical time.


> * MIDI-compatible controls are essentially fixed controls, too.  We
> don't want to break those out.  But they aren't as 'special' as
> these.

There should be no special "MIDI compatible" controls at all, IMHO, 
but rather just a standard set of hints. The motivation for those is 
really just this "Cable" idea of hosts connecting ranges of controls 
automatically. PITCH->PITCH, VELOCITY->VELOCITY etc.

MIDI drivers/converters would just map MIDI CCs to suitable Controls 
in the way suggested by the Control hint names. We could have an 
official MIDI CC -> Control mapping, if desired, but no actual 
references to MIDI in the API.


> Anyone have ideas on the cleanest representation?

Well, I still think the cleanest way would be to use the Control 
metadata stuff, giving the timeline controls datatype IDs of their 
own. No hints needed, I think, as ranges, semantics etc would be 
strictly specified in the API anyway.


//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 -'
   --- http://olofson.net --- http://www.reologica.se ---