On 13/02/12 01:07, Martin Peach wrote:

On 2012-02-12 17:32, Nicola Pandini wrote:

...

Hi, I'd like to use Pd for midi processing, and I'm trying to find the flags to have the best "Pd for midi" possible. For me midi latency is an extremely important factor, so all my efforts were in the way to optimize it. I did some experiments, playing with flags and seeing what happens (I use Pd 0.43.1 on Debian Wheezy, with jack 44.100 - 128 frames):

With -rt -jack -audiobuf 1 -alsamidi I get 2.9 ms of midi latency

Adding -noaudio I get two possible values: 1.45 or 2.9 ms

Adding -r 192000 I get 1.33 ms

Interesting. But how are you actutually measuring this? And is this using external hardware for midi IN/OUT?

...

I don't know why I have to modify the sample rate (-r) to affects the midi latency.

Pd sends non-audio messages in between audio blocks, usually every 64 sample frames. MIDI is sent via a Pd message. You may not get latency so much as jitter on the millisecond level, as all messages are quantized to the audio block period. At 44100Hz, 64 sample frames take up 1.4512 ms, so Pd messages are spaced at multiples of that period. So you get either one or two frames latency depending on when you send the message relative to the audio block. Running at a higher sample rate gives you lower message latency. Add to that the latency of the MIDI driver and hardware, which is probably less than 1ms. As well a full 3-byte MIDI message takes 0.96ms to send at 31250Hz (30 bits * 32us/bit). Probably you could get lower latency by encoding the MIDI directly as an audio waveform but you'd need to make a hardware circuit to convert the audio levels to MIDI levels. Since sound travels about 1 meter in 3ms, it's not all that much latency.

Lorenzo.

Martin

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Il 13/02/2012 01:07, Martin Peach ha scritto:

On 2012-02-12 17:32, Nicola Pandini wrote:

...

Hi, I'd like to use Pd for midi processing, and I'm trying to find the flags to have the best "Pd for midi" possible. For me midi latency is an extremely important factor, so all my efforts were in the way to optimize it. I did some experiments, playing with flags and seeing what happens (I use Pd 0.43.1 on Debian Wheezy, with jack 44.100 - 128 frames):

With -rt -jack -audiobuf 1 -alsamidi I get 2.9 ms of midi latency

Adding -noaudio I get two possible values: 1.45 or 2.9 ms

Adding -r 192000 I get 1.33 ms

I don't know why I have to modify the sample rate (-r) to affects the midi latency.

Pd sends non-audio messages in between audio blocks, usually every 64 sample frames. MIDI is sent via a Pd message. You may not get latency so much as jitter on the millisecond level, as all messages are quantized to the audio block period. At 44100Hz, 64 sample frames take up 1.4512 ms, so Pd messages are spaced at multiples of that period. So you get either one or two frames latency depending on when you send the message relative to the audio block. Running at a higher sample rate gives you lower message latency. Add to that the latency of the MIDI driver and hardware, which is probably less than 1ms. As well a full 3-byte MIDI message takes 0.96ms to send at 31250Hz (30 bits * 32us/bit). Probably you could get lower latency by encoding the MIDI directly as an audio waveform but you'd need to make a hardware circuit to convert the audio levels to MIDI levels. Since sound travels about 1 meter in 3ms, it's not all that much latency.

Martin

Thank you Martin, now it's all more clear.