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
No. The pathway is: keyboard ->M-Audio Firewire 410 MIDI in (via the FW 410's driver) -> PD in -> Pd out -> Yoke in -> Yoke out -> Cubase in. The Yoke is only in the path once.
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) .
I'm sure because when I use the identical pathway but substitute MIDI-Ox for Pd, the latency goes away.
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.
I haven't tried it yet, but it's irrelevant to me. I don't want to play a simple sine wave. I'll try it just because I'm curious, but even if it's perfect, that won't help me.
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).
Generating a MIDI message within Pd would tell me nothing, because I would have no way of knowing exactly when it was being generated.
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).
This may be a Windows 7 64-bit problem. Or it could be because I'm using Pd Extended. Or it could be something else.
--JA
Its possible to track when the message is generated, the issue is with cubase not being an open system is not possible (in my mind) to check its arrival with precision.
I haven't tried it yet, but it's irrelevant to me. I don't want to play a
simple sine wave. I'll try it just >because I'm curious, but even if it's perfect, that won't help me. It can give you some hint/clue about the problem.
This may be a Windows 7 64-bit problem. Or it could be because I'm using Pd
Extended. Or it could >be something else. That's exactly why I suggested to test the simple patch above, if it is any of those issues you suspect, it should come up just when using pd and midi.
On Sun, Jun 6, 2010 at 12:59 AM, Jim Aikin midiguru23@sbcglobal.net wrote:
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
No. The pathway is: keyboard ->M-Audio Firewire 410 MIDI in (via the FW 410's driver) -> PD in -> Pd out -> Yoke in -> Yoke out -> Cubase in. The Yoke is only in the path once.
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) .
I'm sure because when I use the identical pathway but substitute MIDI-Ox for Pd, the latency goes away.
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.
I haven't tried it yet, but it's irrelevant to me. I don't want to play a simple sine wave. I'll try it just because I'm curious, but even if it's perfect, that won't help me.
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).
Generating a MIDI message within Pd would tell me nothing, because I would have no way of knowing exactly when it was being generated.
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).
This may be a Windows 7 64-bit problem. Or it could be because I'm using Pd Extended. Or it could be something else.
--JA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks for taking the time to help with this, Pedro. I appreciate it. I've observed a couple of new things, which I will share.
Its possible to track when the message is generated, the issue is with cubase not being an open system is not possible (in my mind) to check its arrival with precision.
I seem to detect a bit of Linux snobbery in that comment. I'm a big fan of open-source software, and if you can suggest an open-source DAW for Windows that has all of the features of Cubase (by which I do mean "all," not "some"), I'll be overjoyed to switch to it as my primary platform! But if I have to do without important features ... not gonna switch.
In fact, it's perfectly feasible to check when the message arrives in Cubase. Cubase is a low-latency system that uses the ASIO driver. It responds to MIDI note messages within about 10ms. It is very stable and consistent. Thus, if the output from Cubase is delayed when the MIDI message is being passed through Pd, the cause is certainly a delay introduced by Pd.
I haven't tried it yet, but it's irrelevant to me. I don't want to
play a simple sine wave. I'll try it just >because I'm curious, but even if it's perfect, that won't help me. It can give you some hint/clue about the problem.
I don't have a patch handy that will play a sine wave, and my Pd programming is so horribly rusty it would take me an hour to set one up. Instead, I loaded poly.synth.pd, which comes with the system. Its latency in response to MIDI (the MIDI is arriving directly from the Firewire 410's MIDI driver when I play the keyboard) is about the same -- on the order of 100ms.
When I look in Pd's audio settings box, I find something rather disturbing. It doesn't give me access to the ASIO driver. So the latency with internally generated audio will _inevitably_ be 100ms or more. But: That should not affect the MIDI through routing when no audio is being generated! If it does, Pd is in serious need of optimization. It doesn't take 100ms to route three bytes through a buffer. Or at least, it shouldn't.
But again, I don't want to jump to conclusions. My settings may need to be tweaked somehow. Or perhaps Pd (being free, open-source software, unlike Cubase) simply hasn't been updated to be fully compatible with Windows 7 because nobody has gotten around to doing it yet. I wouldn't know.
--Jim Aikin
Jim Aikin wrote:
When I look in Pd's audio settings box, I find something rather disturbing. It doesn't give me access to the ASIO driver. So the latency with internally generated audio will _inevitably_ be 100ms or more. But: That should not affect the MIDI through routing when no audio is being generated! If it does, Pd is in serious need of optimization. It doesn't take 100ms to route three bytes through a buffer. Or at least, it shouldn't.
There should be an item in the Media menu that says "ASIO (via portaudio)" that should be checked in order to use the ASIO drivers.
For what it's worth, I've had the same problem in OSX routing MIDI through the IAC bus into various DAWs (haven't actually tried it yet on Windows XP). It's pretty frustrating. I get the feeling that the delay time set in the Audio Settings dialog is applied to the MIDI I/O as well, though that's just speculation on my part as I have never tried to verify that.
.mmb
there should be an item in the Media menu that says "ASIO (via portaudio)"
that should be checked >in order to use the ASIO drivers. Yep, there should be. I use ASIO via portaudio in Windows XP with PD. Maybe your ASIO is not well configured.
I seem to detect a bit of Linux snobbery in that comment. I'm a big fan of
open-source software, and if >you can suggest an open-source DAW for Windows that has all of the features of Cubase (by which I >do mean "all," not "some"), I'll be overjoyed to switch to it as my primary platform! But if I have to do >without important features ... not gonna switch. It wasn't meant to be snobbery, just showing possibility and a comparison with my XP and my Ubuntu on the same machine - but definitely I don't want to generate a "windows vs. linux" thread :D As for open DAWs, Ardour is very good. I've used Cubase 5 because in one of my musical projects one of the members uses it to record, and it is very very good - a lot of interesting improvements from the previous versions (I recall using Cubase 3 some years ago). I don't have the time to compare all the features of Cubase v.s Ardour but I know some that Ardour is leading is OSC support - which is a really nice feat (irecall reading this [1])
Best regards and keep posting the results, maybe we can figure out what the issue is, Pedro Lopes
[1] http://createdigitalmusic.com/2010/04/07/want-a-daw-that-supports-osc-try-ar...
Thanks to everyone for their help with the MIDI sluggishness problem. I've got it sorted out now. The deal is, when I tried running with the -noaudio option, I didn't think to _also_ go into the audio settings box and set the audio latency to 1ms. I mean, why should that setting matter, if you're not using audio? But it does matter, apparentlybecause (as someone pointed out up-thread) Pd tries to keep MIDI and audio in sync by running them with the same buffer delay.
When I run with -noaudio and then go into the audio settings box and dial down to a 1ms buffer, Pd is able to pass MIDI through in 1ms. Why the user should have to jump through these hoops, I'm not quite sure. Maybe Miller knows best.
Next question: How do I get Pd to save my preferences -- MIDI ports, audio buffer size, and (if possible) running with -noaudio? And no, I don't mean by launching it with a bunch of command line flags. I mean, double-click on the icon and it launches with my preferences intact. Suggestions?
--Jim Aikin
Le 06/06/2010 17:40, Jim Aikin a écrit :
Thanks to everyone for their help with the MIDI sluggishness problem. I've got it sorted out now. The deal is, when I tried running with the -noaudio option, I didn't think to _also_ go into the audio settings box and set the audio latency to 1ms. I mean, why should that setting matter, if you're not using audio? But it does matter, apparentlybecause (as someone pointed out up-thread) Pd tries to keep MIDI and audio in sync by running them with the same buffer delay.
When I run with -noaudio and then go into the audio settings box and dial down to a 1ms buffer, Pd is able to pass MIDI through in 1ms. Why the user should have to jump through these hoops, I'm not quite sure. Maybe Miller knows best.
Next question: How do I get Pd to save my preferences -- MIDI ports, audio buffer size, and (if possible) running with -noaudio? And no, I don't mean by launching it with a bunch of command line flags. I mean, double-click on the icon and it launches with my preferences intact. Suggestions?
i think the best is to change the property of the icon to start pd with the good flags, so that you can create many icon with differents flags.
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
cyrille
--Jim Aikin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cyrille henry wrote:
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
That's fine but what if you want to trigger sound with the MIDI input? I've been trying some settings and find that if I set the delay less than 100ms the MIDI delay goes up to about 500ms, if it works at all.
I usually only use Pd on WinXp to generate background tracks since the latency is so awful compared to linux.
Martin
Le 06/06/2010 18:12, Martin Peach a écrit :
cyrille henry wrote:
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
That's fine but what if you want to trigger sound with the MIDI input?
in my previus mail on this thread, i recommended to use 2 pd, connected via network, or any other osc2midi converter... i.e : i don't know any solution to have a big audio buffer and a small midi buffer.
but midi is slow only for the OUTPUT. if you just have to receive midi note, then you don't have to change anything : it will work...
cyrille
I've been trying some settings and find that if I set the delay less than 100ms the MIDI delay goes up to about 500ms, if it works at all.
I usually only use Pd on WinXp to generate background tracks since the latency is so awful compared to linux.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 6/6/2010 9:01 AM, cyrille henry wrote:
i think the best is to change the property of the icon to start pd with the good flags, so that you can create many icon with differents flags.
Windows 7 won't let me add flags to the command line for a shortcut on the desktop, so that won't work. And Windows doesn't seem to want to launch pd from a batch file either -- I'm not sure why.
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
I'm confused by this. In Program Files (x86)\pd, there is no folder called startup. I can create one ... but what filename should I use for the file that I create in that folder? "startup flags"? "startup flags.txt"? "startup_flags.pd"???
Also, what do you mean by "save all setting"? I can't find any such menu command in the Pd main window.
--Jim Aikin
probably dumb question but: Are you sure that user is administrator? Does 7 has that "run as administrator" feature when you right click the icon or in the properties?
Don't know if it helps, definitely someone with 7 can serve as a better comparison for troubleshoot.
best of luck, Pedro
On Mon, Jun 7, 2010 at 12:14 AM, Jim Aikin midiguru23@sbcglobal.net wrote:
On 6/6/2010 9:01 AM, cyrille henry wrote:
i think the best is to change the property of the icon to start pd with the good flags, so that you can create many icon with differents flags.
Windows 7 won't let me add flags to the command line for a shortcut on the desktop, so that won't work. And Windows doesn't seem to want to launch pd from a batch file either -- I'm not sure why.
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
I'm confused by this. In Program Files (x86)\pd, there is no folder
called startup. I can create one ... but what filename should I use for the file that I create in that folder? "startup flags"? "startup flags.txt"? "startup_flags.pd"???
Also, what do you mean by "save all setting"? I can't find any such menu command in the Pd main window.
--Jim Aikin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jim Aikin wrote:
On 6/6/2010 9:01 AM, cyrille henry wrote:
i think the best is to change the property of the icon to start pd with the good flags, so that you can create many icon with differents flags.
Windows 7 won't let me add flags to the command line for a shortcut on the desktop, so that won't work. And Windows doesn't seem to want to launch pd from a batch file either -- I'm not sure why.
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
I'm confused by this. In Program Files (x86)\pd, there is no folder called startup. I can create one ... but what filename should I use for
He means the Pd menu item File/Startup...
Martin
Le 07/06/2010 01:14, Jim Aikin a écrit :
On 6/6/2010 9:01 AM, cyrille henry wrote:
i think the best is to change the property of the icon to start pd with the good flags, so that you can create many icon with differents flags.
Windows 7 won't let me add flags to the command line for a shortcut on the desktop, so that won't work. And Windows doesn't seem to want to launch pd from a batch file either -- I'm not sure why.
list time i use a windows computer was long ago, so i can't really help path problem maybe use /program file/pure-data/pd.exe ?
but since you don't like this, you should : in pd / startup add in "startup flags" : -noaudio -audiobuf 0 -mididev 3 than : "save all setting" and it should work for next reboot...
I'm confused by this. In Program Files (x86)\pd, there is no folder called startup. I can create one ... but what filename should I use for the file that I create in that folder? "startup flags"? "startup flags.txt"? "startup_flags.pd"???
sorry i was not clean. start pd. click "file" then "startup". add -noaudio -audiobuf 0 -mididev 3 change the mididev to the one you use. click "save all settings" restart pd.
cyrille
Also, what do you mean by "save all setting"? I can't find any such menu command in the Pd main window.
--Jim Aikin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jun 6, 2010, at 5:40 PM, Jim Aikin wrote:
When I run with -noaudio and then go into the audio settings box and dial down to a 1ms buffer, Pd is able to pass MIDI through in 1ms. Why the user should have to jump through these hoops, I'm not quite sure. Maybe Miller knows best.
Maybe file a feature request to the Pd tracker http://sourceforge.net/tracker/?group_id=55736&atid=478073 on smoothing out this issue?
Dan Wilcox danomatika.com robotcowboy.com
On 6/6/2010 10:48 AM, Dan Wilcox wrote:
Maybe file a feature request to the Pd tracker http://sourceforge.net/tracker/?group_id=55736&atid=478073 http://sourceforge.net/tracker/?group_id=55736&atid=478073 on smoothing out this issue?
Good suggestion. Done.
--JA
it's probably midiyoke which has notoriously had issues with Vista and now i assume 7 try midi maple
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Pedro Lopes [pedro.lopes@ist.utl.pt] Sent: Saturday, June 05, 2010 10:06 PM To: Jim Aikin Cc: pd-list@iem.at Subject: Re: [PD] MIDI In-to-Out Latency
Its possible to track when the message is generated, the issue is with cubase not being an open system is not possible (in my mind) to check its arrival with precision.
I haven't tried it yet, but it's irrelevant to me. I don't want to play a simple sine wave. I'll try it just >because I'm curious, but even if it's perfect, that won't help me.
It can give you some hint/clue about the problem.
This may be a Windows 7 64-bit problem. Or it could be because I'm using Pd Extended. Or it could >be something else.
That's exactly why I suggested to test the simple patch above, if it is any of those issues you suspect, it should come up just when using pd and midi.
On Sun, Jun 6, 2010 at 12:59 AM, Jim Aikin <midiguru23@sbcglobal.netmailto:midiguru23@sbcglobal.net> wrote:
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
No. The pathway is: keyboard ->M-Audio Firewire 410 MIDI in (via the FW 410's driver) -> PD in -> Pd out -> Yoke in -> Yoke out -> Cubase in. The Yoke is only in the path once.
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) .
I'm sure because when I use the identical pathway but substitute MIDI-Ox for Pd, the latency goes away. 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.
I haven't tried it yet, but it's irrelevant to me. I don't want to play a simple sine wave. I'll try it just because I'm curious, but even if it's perfect, that won't help me.
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).
Generating a MIDI message within Pd would tell me nothing, because I would have no way of knowing exactly when it was being generated.
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).
This may be a Windows 7 64-bit problem. Or it could be because I'm using Pd Extended. Or it could be something else.
--JA
Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Pedro Lopes contacto: jazz@radiozero.ptmailto:jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
On 6/5/2010 8:08 PM, Pagano, Patrick wrote:
it's probably midiyoke which has notoriously had issues with Vista and now i assume 7 try midi maple
Thanks for the recommendation, but I've already established that it's definitely NOT a problem with MIDI Yoke. The throughput from the hardware MIDI input, through MIDI-Ox and MIDI Yoke, to Cubase does not exhibit latency.
However, Pd by itself (MIDI in from the Firewire 410, audio back out to the Firewire 410 via Asio4all driver) has _more_ than 100ms of latency. It's completely unplayable as a real-time instrument. And MIDI Yoke is not in the loop.
Soooo ... I'm still hunting for a solution. (Other than "use Max" -- I'd prefer to use free software if possible).
--JA
Jim Aikin wrote:
On 6/5/2010 8:08 PM, Pagano, Patrick wrote:
it's probably midiyoke which has notoriously had issues with Vista and now i assume 7 try midi maple
Thanks for the recommendation, but I've already established that it's definitely NOT a problem with MIDI Yoke. The throughput from the hardware MIDI input, through MIDI-Ox and MIDI Yoke, to Cubase does not exhibit latency.
However, Pd by itself (MIDI in from the Firewire 410, audio back out to the Firewire 410 via Asio4all driver) has _more_ than 100ms of latency. It's completely unplayable as a real-time instrument. And MIDI Yoke is not in the loop.
With the attached patch I get a bit more than 100ms using Pd version 0.42.5-extended-20100524 on WinXP with M-Audio Delta 1010LT interface MIDI cable connecting In to Out. ASIO is checked in the Media menu. Audio delay is also set to 100ms.
Martin
-
cyrille henry -
Dan Wilcox -
Jim Aikin -
Martin Peach -
Mike Moser-Booth -
Pagano, Patrick -
Pedro Lopes