18 Dec
2002
18 Dec
'02
5:14 a.m.
On Wednesday 18 December 2002 03.08, Tim Hockin wrote:
[...]
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.
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! :-)
Would two
floats (32 bit) do?
Just to play devils advocate:
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)
Obviously any of those field widths can be adjusted. I just wanted
to point out that we CAN transport that data in a single 32 bit
field. Especially since the 'float' values we're
talking about
tend towards simple fractions.
Yes, that's a good point. As soon as you say N+1/3 for beats per
measure, you get a rounding error...
So, how about using the magical 1920 unit for both fields? Then you
can express all sorts of weird values and still get exact integer
values. And it fits nicely with the musical time unit as well. :-)
Now is someone going to tell me they have PI beats per
measure?
Probably! ;-)
//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 ---