I'm running 0.41.4 Extended on a 64-bit Windows 7 system. I've installed MIDI Yoke to route incoming MIDI from my keyboard through Pd and thence to Cubase 5.1.
What I'm finding is that with the simplest possible notein-to-noteout patch, Pd's MIDI throughput latency is very consistently on the order of 100ms -- plainly unacceptable for real-time performance. Needless to say, Cubase is using ASIO, and has no problem producing low-latency MIDI response when I use a direct MIDI input. The sluggish response is clearly due to Pd. Also, it's consistent whether Pd's patch window is in or out of edit mode.
To test whether MIDI Yoke might be the culprit, I opened MIDI-Ox and routed the physical MIDI input to a MIDI Yoke channel. The latency was maybe a tiny bit greater than via a direct routing into Cubase (maybe), but it was much, much less than with Pd.
The section in the Pd manual on scheduling doesn't mention MIDI latency at all; it's strictly about audio DSP load. I can't find anything else in the manual that seems even faintly relevant. I did find (somewhere ... on the wiki?) a mention that the timing of metro would be improved if I ran with the command line pd -noaudio, so I opened a Command Prompt and tried that. It didn't change anything.
It seems very odd to me that Pd can handle audio streams without glitching, yet it can't process three bytes of MIDI data in less than 100ms. Is this user error on my part? Can anyone suggest how I can reduce or eliminate the delay? Thanks for any tips!
--Jim Aikin
Just to see if I got that right, the rip is:
keyboard -> YOKE in -> YOKE OUT -> PD IN -> PD OUT -> YOKE IN -> YOKE OUT -> CUBASE IN
The sluggish response is clearly due to Pd. Also, it's consistent whether
Pd's patch window is in or >out of edit mode. How can you be sure? You are making two trips using that patching software (I confess I had no clue what MIDI-OX was previous to your thread), there's latency in all of the above hops (MIDI message passing through softwares) .
Do you tried to see how is Pd's latency in a "simple play sine wave with MIDI note" patch? that will give you the response time of keyboard -> PD. Then test the oposite, sending PD to your soundcard MIDI and playing some device or other solution, allowing you to test the output (by generating a MIDI message within PD and route it out od PD).
Maybe those measures could be helpful for now, Best regards and good luck, Pedro Lopes p.s. just for comparison I use MIDI in PD in WinXP without any noticeable latency, although only in Linux I do fancy patching in-out and have no noticeable latency (using everything in realtime).
On Sun, Jun 6, 2010 at 12:26 AM, Jim Aikin midiguru23@sbcglobal.net wrote:
I'm running 0.41.4 Extended on a 64-bit Windows 7 system. I've installed MIDI Yoke to route incoming MIDI from my keyboard through Pd and thence to Cubase 5.1.
What I'm finding is that with the simplest possible notein-to-noteout patch, Pd's MIDI throughput latency is very consistently on the order of 100ms -- plainly unacceptable for real-time performance. Needless to say, Cubase is using ASIO, and has no problem producing low-latency MIDI response when I use a direct MIDI input. The sluggish response is clearly due to Pd. Also, it's consistent whether Pd's patch window is in or out of edit mode.
To test whether MIDI Yoke might be the culprit, I opened MIDI-Ox and routed the physical MIDI input to a MIDI Yoke channel. The latency was maybe a tiny bit greater than via a direct routing into Cubase (maybe), but it was much, much less than with Pd.
The section in the Pd manual on scheduling doesn't mention MIDI latency at all; it's strictly about audio DSP load. I can't find anything else in the manual that seems even faintly relevant. I did find (somewhere ... on the wiki?) a mention that the timing of metro would be improved if I ran with the command line pd -noaudio, so I opened a Command Prompt and tried that. It didn't change anything.
It seems very odd to me that Pd can handle audio streams without glitching, yet it can't process three bytes of MIDI data in less than 100ms. Is this user error on my part? Can anyone suggest how I can reduce or eliminate the delay? Thanks for any tips!
--Jim Aikin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello,
i had almost the same problem : my setup use a usb->midi device, i plugged a cable between the midi in and midi out : i tried to minimized the loop. i'm on linux, and i realized few things :
-midi in is very fast -midi out have the same latency than audio. pd is the only software i know doing this, but it make sense in order to keep sync between audio and midi, whatever you audio buffer is. so, if you reduce the audio buffer, the midi latency will be reduce! -using pd -audiobuf 5 result in a 10ms loop with a lot of jitter. -using pd -rt -noaudio the midi loop is about 3ms and it does have very few jitter. (rt reduce jitter, noaudio reduce latency)
since you did try pd -noaudio, i don't understand why it did not improve things for you. are you sure that this argument was recognise by pd (so that you really don't have audio)?
so, if you don't have to compute audio with pd, then you can have good midi performances. if you need to have a big audio buffer, and a small midi latency, then it's easier to use 2 pd with different configuration, and connect them with netsend/ netreceive.
i used to have a script (maybe you can find one on the internet) that convert OSC message to midi. it's a (bad) solution, but allow to have good midi performance whatever pd configuration used.
hope that help, Cyrille
Le 06/06/2010 01:26, Jim Aikin a écrit :
I'm running 0.41.4 Extended on a 64-bit Windows 7 system. I've installed MIDI Yoke to route incoming MIDI from my keyboard through Pd and thence to Cubase 5.1.
What I'm finding is that with the simplest possible notein-to-noteout patch, Pd's MIDI throughput latency is very consistently on the order of 100ms -- plainly unacceptable for real-time performance. Needless to say, Cubase is using ASIO, and has no problem producing low-latency MIDI response when I use a direct MIDI input. The sluggish response is clearly due to Pd. Also, it's consistent whether Pd's patch window is in or out of edit mode.
To test whether MIDI Yoke might be the culprit, I opened MIDI-Ox and routed the physical MIDI input to a MIDI Yoke channel. The latency was maybe a tiny bit greater than via a direct routing into Cubase (maybe), but it was much, much less than with Pd.
The section in the Pd manual on scheduling doesn't mention MIDI latency at all; it's strictly about audio DSP load. I can't find anything else in the manual that seems even faintly relevant. I did find (somewhere ... on the wiki?) a mention that the timing of metro would be improved if I ran with the command line pd -noaudio, so I opened a Command Prompt and tried that. It didn't change anything.
It seems very odd to me that Pd can handle audio streams without glitching, yet it can't process three bytes of MIDI data in less than 100ms. Is this user error on my part? Can anyone suggest how I can reduce or eliminate the delay? Thanks for any tips!
--Jim Aikin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
Jim Aikin -
Pedro Lopes