On Monday 16 December 2002 22.30, Tim Goetze wrote: [...] > >so yes, ticks-per-beat is still necessary, but its a constant > > (1920 in ardour). > > there's no point in limiting this to be a fixed value.
What's wrong with 1.0? I don't see the point in introducing PPQN here. It belongs in sequencer UIs, IMHO. (If you really care, ask for a XAP_time_info.) [...] > you're right, it doesn't matter what reference length you > choose. quarters simply happen to work well, and there's > no need to break with convention here. Doesn't work very well for 5/8, does it...? > >>add seconds-per-beat for plugins that are not limited to > >>audio purposes. > > > >but thats just a straightforward transform of samples-per-beat > > given samples-per-second, so there is no reason to specify both. > > either one seems equally good to me. > > it must be assumed the hosts knows seconds-per-beat better > than the plugin. If that's the case, there is a problem with the host/plugin (or rather sequencer/plugin) interface. > thus, forcing another calculation back > from frame units is illogical. The only relevant relation to "seconds" here is that with the audio sample rate - and you have that in common with the sequencer. [...] > one of the basic properties of rhythmn is that human beings > are able to count it, otherwise they cannot sync (groove) > to it. no musical tradition i know of violates this principle; > rhythmn is integral by its very nature. > > i'd be happy to hear a good example proving this wrong. but > take note that i don't accept 1/2, 1/3 and relatives as > qualifying because they can better be (and usually are) > expressed using integer numbers. Well, it's just that you can't stretch that "trick" indefintitely, since eventually, you run out of standard note values - and then you need float for those anyway. Either way, if you don't care, don't worry. You can still calculate the number of ticks in a beat, or in a bar if you want. What situations are you worried about? > about arithmetic: float operations, as you know, introduce > round-off error. No, only when the result doesn't fit in the mantissa. > integers can be used in accumulators with > much less inconvenience. When are you actually expecting to se *exact* values? The very process of mapping musical time to an audio sample rate is inherently inexact, unless you express tempo as a fixed relation between ticks and samples. (Which is entirely useless.) //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 ---