On Wednesday 18 December 2002 10.29, Tim Hockin wrote:
METER: uint32_t
meter & 0xffc00000 = beats-per-measure whole (0-1024)
meter & 0x003ff000 = beats-per-measure decimal (1/1000
increments) meter & 0x00000fff = beat-note denominator
(0-4096)
Yeah, but that's not much point in itself. We have at least 12
bytes if we use a non-standard event, so this isn't a major
problem.
why use a non-standard event?
Two standard float controls would work fine. Better, in fact, as you
can handle defaults and presets without any special-casing at all.
Using a
special format inside an integer would be a non-standard
control type anyway, since you cannot assume that the value is a
valid float. Unless it's explicitly encoded that way... Don't
want to go there! :-)
Use an int type. who said to transform it to a float?
Do we have int controls?
Well, I do in my version, and my motivation is that you have 9 extra
bits, compared to float32. This might matter a great deal when you
actuall want an int.
BTW, how about making integer controls 64 bit? (*41* extra bits! :-)
It's no big deal in any way, because they can't be ramped (no event
size issues), and you can just throw the top 32 bits away if you
don't want them in you internal control arrays. The point is that
events are (at least) 32 bytes anyway, so why not make use of the
otherwise dead space?
Now is someone going to tell me they have PI beats per
measure?
Probably! ;-)
and I'm going to ask to hear it before I agree to support it in the
code. :)
*hehe*
//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 ---