Paul Davis schrieb: > On Mon, Dec 21, 2009 at 10:43 AM, Niklas Klügel <[email protected]> > wrote: > >> Hello list, >> >> I recently wrote a sequencer for multi-touch/collaborative music >> composition as part of my thesis. I currently set the PPQ to 128 which >> > > "PPQN" (an inadequately defined term if ever there was one) should be > a number with a very large number of factors. Several DAWs, including > Ardour, use 1920, some use 3840. The idea is that you want to be able > to express as many possible subdivisions of "a quarter note" (whatever > that actually means, since its not always "a quarter note") as a whole > integral value. This avoids rounding error. 1920 is a pretty good > choice; 3840 is arguably even better. > > To be more precise, you want to be able to express, at the absolute minimum: > > 1/2 1/3 1/4 1/5 1/6 1/8 1/16 1/32 1/64 1/128 > > divisions of a note as an integer. > > it has absolutely nothing to do with clock/timer resolution and > certainly is not related to choices like 32 bit/64 bit etc. > Then I guess I misunderstood the idea of PPQ. I was not clear about how events are timed. It is stored as a number of ticks absolute (from a starting point in time == sequence start). In this way the PPQ and BPM ~define the length of a tick (in my application), which directly relates to the clock/timer resolution. In the current case an event can take place in 1/512 (4*128). This might be totally different how it is handled in general but this primitive design pays off for this application. So, sorry for the confusion and my question should have been, how is the high resolution timing achieved reliably in current applications? Is there more info on that topic?
Thanks, so long... Niklas _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
