LOGIC's 960 ppqn?
Clint Ward
LOGIC Audio.
I thought some people would enjoy this note from Dr. Gerhard Lengeling.
Any comments?
Live Long
CW
The 960 ppqn Question:
Why do LOGIC and LOGIC Audio support such a high resolution of 960 ppqn?
I've heard that some people are saying that 960 ppqn is not supported by MIDI
and that with MIDI 480 ppqn is the maximum resolution possible, that anything
more is superfluous.
Answer:
This high resolution of 960 ppqn makes perfect sense.
First of all: MIDI is not the universe. For example, the digital audio/NuBus
card aspect and support of Digidesign's Sample Cell card in LOGIC and LOGIC
Audio takes full advantage of the 960 ppqn resolution because neither of them
use MIDI for either the transmission or reception of data. And besides, why
not be prepared for other 'future' enhancements.
Secondly: Even with current MIDI devices you benefit from the high
resolution. Don't mix up the terms "resolution" and "transmission delay". The
MIDI standard does not say anything about sequencer resolution and in fact it
doesn't need to say anything about it.
Let's have a look on the MIDI standard which precisely determines the
transmission delay. The standard defines the physical baud rate of the
transmission and the protocol. As a result, the transmission of a single MIDI
Note On information takes about 1 ms time (in fact it is 0.96 or 0.64 ms,
depending on certain circumstances).
The resolution of LOGIC is 960 ppqn which results in an absolute value of
about 0.5 ms at a tempo of 120 bpm. This is clearly less than than 1 ms.
Notes might be delayed but the relevant musical information is determined by
the relative musical timing distances between notes - not by the delay of
when the music actually arrives to the listener. The transmission delay is
not a natural limit for the resolution.
An example: let's assume a terrible "MIDI" standard would take a one second
delay to transmit one Note On information and let's assume a sequencer would
play a monophonic musical phrase. If in this case a sequencer would support
the same low resolution of one division per second the music would sound
badly quantized. If another sequencer would support a very high resolution
the music would sound one second late but it would still have excellent
timing.
For those who want to dig even deeper in these complicated timing things: The
true interaction between the musical timing, resolution and transmission
speed comes with the note polyphony especially if the polyphony of music
changes. This is more or less true for most kinds of music. With dynamic
polyphony there is an influence of the transmission speed on the resultant
timing. For this reason future enhancements to the MIDI Spec would be
welcomed.
Nevertheless - after such a technical discussion we should consider that it
is the music which we are really speaking about. Hear the difference
yourself. Record a track into a sequencer with 384 of 480 ppq resolution.
Listen to this track without quantization. Record a track with LOGIC at 960
ppq and you most definitely will feel a difference, and most audibly hear a
difference as well.
We make computers groove...
Dr. Gerhard Lengeling, EMAGIC
Peter Castine
> I thought some people would enjoy this note from Dr. Gerhard Lengeling.
>
> Any comments?
Sure...
> This high resolution of 960 ppqn makes perfect sense.
Except that higher resolution would be even better :-)
> First of all: MIDI is not the universe. [schnipp...]
Amen!
> And besides, why
> not be prepared for other 'future' enhancements.
Such as the ZIPI proposal (see David Wessel's paper in the proceedings of
this year's International Computer Music Conference, or his contributions
in the
upcoming Computer Music Journal).
> Secondly: Even with current MIDI devices you benefit from the high
> resolution. Don't mix up the terms "resolution" and "transmission delay". The
> MIDI standard does not say anything about sequencer resolution and in fact it
> doesn't need to say anything about it.
The first point in the previous paragraph strikes me as a little dubious.
The timing of your sequencer and the timing of your Sampler/Synth/whatever
ar two very different things indeed. As Gareth Loy pointed out in his
seminal paper ``Musicians make a standard: The MIDI phenomenon'' (Computer
Music Journal 9:4, 1985), the time a synthesizer needs to translate an
incoming Note On event into audio output can be variable (and even
non-deterministic). Current MIDI gear may have snappier response times
than the equipment Loy (and F. Richard Moore) made their experiments on,
but no two different machines are likely to have the same latency.
> Let's have a look on the MIDI standard which precisely determines the
> transmission delay. The standard defines the physical baud rate of the
> transmission and the protocol. As a result, the transmission of a single MIDI
> Note On information takes about 1 ms time (in fact it is 0.96 or 0.64 ms,
> depending on certain circumstances).
The transmission time can also vary due to the fact that the stop bit may
last longer than the 1/31250 sec implied by the nominal baud rate. Since
this is unlikely between the individual bytes of a Note On message, we'll
let this pass (between sequential MIDI messages this actually will happen,
and there is a certain possibility this may happen even between nominally
simultaneous Note On messages).
> The resolution of LOGIC is 960 ppqn which results in an absolute value of
> about 0.5 ms at a tempo of 120 bpm.
~~~
Apropos tempo, some people I know habitually write music at tempi between
20 and 40 M.M. (bpm to many folks on this newsgroup, but I'm old-fashioned
and it's still ``Maezel Metronome'' in my book). Put 8 or 16 in the
denominator of your time signature, and 960
ticks/parts/clocks/whatever-you-want-to-call-'em per quarter starts
sounding cheesy.
> This is clearly less than than 1 ms.
> Notes might be delayed but the relevant musical information is determined by
> the relative musical timing distances between notes - not by the delay of
> when the music actually arrives to the listener. The transmission delay is
> not a natural limit for the resolution. [schnipp...]
Again, this presumes that the recipient[s] of the Note On messages
has/have a uniform latency for all incoming note ons. There are lots of
reasons for this not to be the case.
Nevertheless, I welcome support for higher timing resolution from
sequencer developers (although the now defunct MidiPaint claimed 960
clicks/quarter back in '86, so it's not as if Logic is the only one to
have ever had this). Personally, I would like to see a guaranteed
resolution of 1 ms (or better), regardless of tempo. Oh, and if we have to
have static subdivisions of the quarter, it would be nice if they had
prime factors greater than 5.
My two bits.
--
Peter Castine | Useful approximations:
pcas...@prz.tu-berlin.de | Pi seconds is a nanocentury.
Process Control Center | Electricity travels a foot per nanosecond.
Technical University Berlin | One ostrich egg will feed 24 people for brunch.
Archer Sully
;
; Yes, this has always bothered me: why isn't time
; represented so that the quantization error is something
; like "1920 pps" (which is the same as 960 ppqn at 120 bpm)
; and is thus independent of the tempo?
There's an advantage to using tempo, in that you play around
with the playback speed arbitrarily, which can be pretty cool.
It gives you a form of "virtual time."
The other reason for using a tempo is that it becomes easier
to convert to some sort of notation.
MIDI files use a "pulse per second" sort of mode for representing
SMPTE time.
;
; In order to get around this, when I am recording MIDI events
; that don't have an implied clock (ie when we are recording
; "live" MIDI performances without a click track) I always set
; Vision's tempo to be 500 so as to get the largest number of
; "parts" per unit time. Reading this thread makes me want
; to set my meter to 2/2 or even 1/1 for the best resolution.
Yep. The other idiotic thing is that tempi are defined in terms
of quarter notes instead of per beat. I've always hated that.
You might want to see if you can time stamp in terms of internally
generated SMPTE.
-- a
--
Stop Casting Porosity
Tom Ritchford
[snip]
>Apropos tempo, some people I know habitually write music at tempi between
>20 and 40 M.M. (bpm to many folks on this newsgroup, but I'm old-fashioned
>and it's still ``Maezel Metronome'' in my book). Put 8 or 16 in the
>denominator of your time signature, and 960
>ticks/parts/clocks/whatever-you-want-to-call-'em per quarter starts
>sounding cheesy.
Yes, this has always bothered me: why isn't time
represented so that the quantization error is something
like "1920 pps" (which is the same as 960 ppqn at 120 bpm)
and is thus independent of the tempo?
In order to get around this, when I am recording MIDI events
that don't have an implied clock (ie when we are recording
"live" MIDI performances without a click track) I always set
Vision's tempo to be 500 so as to get the largest number of
"parts" per unit time. Reading this thread makes me want
to set my meter to 2/2 or even 1/1 for the best resolution.
--
/t
Tom Ritchford t...@mvision.com (212) 306-0414
Market Vision, 40 Rector Street, NY, NY 10006
Vote YES on rec.music.makers.bands! Contact me for more info.