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

David Olofson david at olofson.net
Tue Dec 24 09:20:01 UTC 2002


On Tuesday 24 December 2002 03.57, Tim Hockin wrote:
> > (Speaking of which, I implemented a VVID manager for Audiality
> > the other day. "Finished and tested", although I haven't
> > integrated it yet.)
>
> excellent - and the code is where? :)

Well, I don't know when Audiality 0.1.1 will be ready for release, so 
I just put the files here for now:

	http://olofson.net/download/	(a_vvid.[ch])


Not very sophisticated, but it should work, I think. (Or I'll just 
have to fix it when I get around to actually use it, obviously. :-)


> > > * This is all designed to take away the extra fields that
> > > aren't
> >
> > 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".
>
> not many I realized - how does the below code look?
>
> > There should be no special "MIDI compatible" controls at all,
> > IMHO,
>
> Well, we want MIDI compatible hinted controls to fall withing the
> -1 to 1 or 0-1 range, right?  That is a bit more than a hint..

The actual mapping/translation still has to be done somewhere, 
though, so I don't think there's much point in dictating much in the 
API. There will be some "official" MIDI->event converter, I guess, 
but I think it's more important to worry about what we want for the 
new API, than worrying about MIDI legacy. We have a slightly 
different way of controlling things, and thus, MIDI CC can't map 1:1 
to our Controls. I don't think it's useful to impose MIDI related 
restrictions upon the API, since there's probably no single "correct" 
mapping that will work for everything anyway.

In short, we should have our own set of "standard controls", with 
sensible units. Mapping MIDI to that is more of an implementational 
issue, IMHO.


> > 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.
>
> Well, we're documenting things as MIDI-compatible hints, right? 

I'm not sure. We could *suggest* that they're similar to certain MIDI 
controllers, but I think we're going down the legacy route as soon as 
we start imposing "arbitrary" limitations upon ranges and units to 
make MIDI->control mapping closer to 1:1.


> I.e.: use this hint if you want a host to know it should connect
> MIDI velocity.

I don't think the host should be aware of the existence of MIDI. It's 
a driver/translator thing. The MIDI driver/converter would have 
hinted outputs, and *those* are what the host should look at - if it 
cares to support "Cables" at all. What MIDI events the 
driver/converter maps to which Control outputs is an implementational 
issue, rather than something that should be strictly specified in the 
API. (And in fact, I don't think it should be all that strict either 
way. In my experience, fixed MIDI CC mappings are nothing but a PITA 
if you have controllers that aren't fully programmable.)


> > Well, I still think the cleanest way would be to use the Control
> > metadata stuff, giving the timeline controls datatype IDs of
> > their
>
> How's this look - like what you are thinking?
[...macros...]

Yes, something like that.

Maybe they should just have the ranges and all - or perhaps it's 
better to make them more "opaque" to hosts that don't want to care 
about the details. What I'm thinking is that hosts should be able to 
figure out whether an input is compatible with an output without 
having to understand every aspect of the datatype. (That's the 
problem with hints + range; if range isn't implicit, the host will 
have to check...)


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



More information about the Linux-audio-dev mailing list