Re: [LAD] High-res PPQn

From: Niklas Klügel <niklas.kluegel@email-addr-hidden>
Date: Mon Dec 21 2009 - 18:59:33 EET

Paul Davis schrieb:
> On Mon, Dec 21, 2009 at 10:43 AM, Niklas Klügel <niklas.kluegel@email-addr-hiddene> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Dec 21 20:15:03 2009

This archive was generated by hypermail 2.1.8 : Mon Dec 21 2009 - 20:15:04 EET