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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP: magic 'sys controls' vs normal controls
From: David Olofson (david_AT_olofson.net)
Date: Tue Dec 24 2002 - 03:57:15 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 24 2002 - 04:01:23 EET