24 Dec
2002
24 Dec
'02
10:19 a.m.
On Tuesday 24 December 2002 03.57, Tim Hockin wrote:
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. :-)
not many I realized - how does the below code look?
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.
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.
[...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 ---
(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? :) * 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". 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.. 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.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?