21 Dec
2009
21 Dec
'09
12:59 p.m.
Paul Davis schrieb:
On Mon, Dec 21, 2009 at 10:43 AM, Niklas Klügel
<niklas.kluegel(a)mytum.de> wrote:
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
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.