21 Dec
2009
21 Dec
'09
11:43 a.m.
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
ought be enough for demonstration purposes and early testing. Now, I am
wondering how to support higher PPQN efficiently. Some of you guys might
have an experience in doing that; I've seen that renoise supports up to
4096 PPQN and DigitalPerformer uses some kind of variable clocking. Have
you heard or implemented of techniques that are smarter than just
cranking up the _fixed_ clock resolution? As timestamps I currently use
64bit ints, I guess I could encode the timing as (tick, +subdivisions)
and poll the timing for the next event(s) and set the clock accordingly.
Would that be worth it? Any general opinions about the max PPQN?
thanks,
so long...
Niklas
21 Dec
21 Dec
12:24 p.m.
On Mon, Dec 21, 2009 at 10:43 AM, Niklas Klügel <niklas.kluegel(a)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.
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.
5401
days inactive
5401
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Niklas Klügel -
Paul Davis