[LAD] High-res PPQn

Niklas Klügel niklas.kluegel at mytum.de
Mon Dec 21 16:59:33 UTC 2009


Paul Davis schrieb:
> On Mon, Dec 21, 2009 at 10:43 AM, Niklas Klügel <niklas.kluegel at mytum.de> 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





More information about the Linux-audio-dev mailing list