Does anyone know what is Live's MIDI resolution?

[dinaiz]

Wait wait wait, if 1/16384 is the smallest grid, and everyone knows you can turn the grid off and get even smaller, then the PPQ is surely even greater than 4096?

16384/4 = 4096. Highest GRID PPQ. Higher PPQ without grid no?

Not necessarily. The display is one thing, the audio engine is another thing. The pixels don't have to match the ticks !

[aioffermann]

Wait wait wait, if 1/16384 is the smallest grid, and everyone knows you can turn the grid off and get even smaller, then the PPQ is surely even greater than 4096?

16384/4 = 4096. Highest GRID PPQ. Higher PPQ without grid no?

Not necessarily. The display is one thing, the audio engine is another thing. The pixels don't have to match the ticks ![/quote

Hm. Well 960, the PPQ you suggested, multiplied by 4 comes out to 3840. 16384 is a much bigger number than 3840, so are you suggesting that after note resolutions of 3840, the finer resolutions are all lies?

Just confused is all, and would love an explanation. Been interested in this stuff for awhile

[dinaiz]

No problem.

This number is called PPQN which stands for "pulses per quarter note".
The "pulse, or tick, is the smalest time unit (in MIDI).

With 960 PPQN, it means you can divide equally the space between two quarter notes in 960 intervals. That's 3840 ticks in a bar, which is a lot already. Imagine that you have 30 intervals between two 1/32th notes !

I know some sequencers have more PPQN, some have less. Normally 960 is more than enough to cover
everyone's needs.

And you might wonder why on earth one needs 30 intervals between two 1/32th notes. That's because when you record and/or playback a musician, he doesn't plays in a "quantized" way. There's always some kind of swing, groove, feeling...

Not sure I was very clear but I hope so !

[aioffermann]

No problem.

This number is called PPQN which stands for "pulses per quarter note".
The "pulse, or tick, is the smalest time unit (in MIDI).

With 960 PPQN, it means you can divide equally the space between two quarter notes in 960 intervals. That's 3840 ticks in a bar, which is a lot already. Imagine that you have 30 intervals between two 1/32th notes !

I know some sequencers have more PPQN, some have less. Normally 960 is more than enough to cover
everyone's needs.

And you might wonder why on earth one needs 30 intervals between two 1/32th notes. That's because when you record and/or playback a musician, he doesn't plays in a "quantized" way. There's always some kind of swing, groove, feeling...

Not sure I was very clear but I hope so !

No thats all very clear to me. I'm just curious as to how Ableton's ppq could be 960 if a grid resolution of 1/16384 allows for 4096 ppq. I mean unless Ableton is lying and 1/16384 actually means 1/3840, I don't see how the ppq isn't atleast 4096.

[dinaiz]

But where did you see the grid resolution is 1/16384 ?
Maybe I'm wrong and the PPQN value is 4096 but in my plugin I clearly had 960 reported.

[aioffermann]

But where did you see the grid resolution is 1/16384 ?
Maybe I'm wrong and the PPQN value is 4096 but in my plugin I clearly had 960 reported.

If you make a midi clip in session view, make sure it's on fixed grid and keep pressing command+2 (i think.. whatever gets you smaller resolutions.. can't check right now..). The highest resolution you can get to is 1/16384. After that it goes to "none". The number 16384 is cited throughout the thread as well

[dinaiz]

But where did you see the grid resolution is 1/16384 ?
Maybe I'm wrong and the PPQN value is 4096 but in my plugin I clearly had 960 reported.

If you make a midi clip in session view, make sure it's on fixed grid and keep pressing command+2 (i think.. whatever gets you smaller resolutions.. can't check right now..). The highest resolution you can get to is 1/16384. After that it goes to "none". The number 16384 is cited throughout the thread as well

Interesting, you're completely right. I don't know then. I think the difference between a couple of ticks at 1/16384 might be difficult to hear though. I'd be interested in an official "ableton" reply !

[aioffermann]

But where did you see the grid resolution is 1/16384 ?
Maybe I'm wrong and the PPQN value is 4096 but in my plugin I clearly had 960 reported.

If you make a midi clip in session view, make sure it's on fixed grid and keep pressing command+2 (i think.. whatever gets you smaller resolutions.. can't check right now..). The highest resolution you can get to is 1/16384. After that it goes to "none". The number 16384 is cited throughout the thread as well

Interesting, you're completely right. I don't know then. I think the difference between a couple of ticks at 1/16384 might be difficult to hear though. I'd be interested in an official "ableton" reply !

Oh yea I totally can't hear the difference once we're moving notes at a 1/512 scale. After 512 I really can't tell.

[pencilrocket]

it seems to be 960 pulses per quarter note. At least, that's what live reports ...

wow that is quite accurate

[crumhorn]

I think that 960 figure is just the unit of time used to comunicate time info to the plugin. so if the vst has some beat synched LFO then 960 PPQ would be the best acuracy of that LFO. When the plugin asks Live for the current time in ticks it gets an answer like "27365.3 ticks at a tick rate of 960 ppqn"

It's quite possible for live to send note data to the vst inbetween clock pulses and to use a finer clock resolution internally.

If you use any external gear the clock rate is 24 PPQ as defined my midi. This is just the rate at which the external gear synchronises it's clock. It has nothing to do with the timeing accuracy of individual notes coming out of Live.

The editing grid in live is just your way of saying when the note on event should occur in tempo related time units. It's no guarantee that Live will actually be able to send the message at exactly that time - It's just that after that time it joins a queue of things to be done next time Live has chance to deal with it. The actual timing accuracy will depend on how busy the program is at that time.

(P.S this last paragraph is a guess. I know nothing about the coding of Live, but this is a very common way to do any type of scheduling)

[theophilus]

you're probably asking the wrong question... afaik, live is sample-oriented, not ppq oriented, and afaik a single sample is probably the smallest time unit internally. of course how that translates to ppq will vary depending on the sampling rate and the current bpm, which may be why they can't really tell you - it may not be fixed.

at 120 bpm, 1 quarter = 125 ms. at 960 ppq, that's ~0.13 ms per tick - pretty damn small. at 44.1KHz, 1 sample = ~0.02ms/sample, or 6 samples/tick (!), so the highest ppq you could have would be around 6*960 = 5760 ppq. higher than that, and you are in sub-sample territory (at 44.1KHz).

[crumhorn]

...at 120 bpm, 1 quarter = 125 ms. at 960 ppq, that's ~0.13 ms per tick - pretty damn small. at 44.1KHz, 1 sample = ~0.02ms/sample, or 6 samples/tick (!), so the highest ppq you could have would be around 6*960 = 5760 ppq. higher than that, and you are in sub-sample territory (at 44.1KHz).

you need to multiply these numbers by 4 - at 120 bpm 1 quarter note = 500ms - unless by bpm you meant bars per minute.

[broc]

you're probably asking the wrong question... afaik, live is sample-oriented, not ppq oriented, and afaik a single sample is probably the smallest time unit internally. of course how that translates to ppq will vary depending on the sampling rate and the current bpm, which may be why they can't really tell you - it may not be fixed.

Good point. For example, in M4L there is a 'plugsync' object that provides timing information from Live. It sends a sample counter and a beat counter (as float number) which is updated every 64 samples and can be used for midi timing. So in this case the midi resolution at samplerate 44.1 is about 1.5ms.

[theophilus]

...at 120 bpm, 1 quarter = 125 ms. at 960 ppq, that's ~0.13 ms per tick - pretty damn small. at 44.1KHz, 1 sample = ~0.02ms/sample, or 6 samples/tick (!), so the highest ppq you could have would be around 6*960 = 5760 ppq. higher than that, and you are in sub-sample territory (at 44.1KHz).

you need to multiply these numbers by 4 - at 120 bpm 1 quarter note = 500ms - unless by bpm you meant bars per minute.

ah yeah, you are right... so that should be ~.5ms/tick at 960ppq.

[hoffman2k]

Actually I developped a small test pluggin using Juce (http://www.rawmaterialsoftware.com/) and it seems to be 960 pulses per quarter note. At least, that's what live reports ...

Ah, cool
Well.. It took only 6 years to get this conversation going.
480 is the default resolution for MFL Transport output. That is where I got my number.