Re: [PD] Limit bandwith for MIDI output / precise metro
Thank you Miller! Il 20/08/2013 03:00, Miller Puckette ha scritto: Seems like this should be an option... I think it's a bit late to add features to 0.45 but I'll stick it on my list for later. cheers Miller On Thu, Aug 08, 2013 at 11:03:58AM +0200, Nicola Pandini wrote: Hi, I resume this old thread because I compiled pd with Miller's advices to disable MIDI buffering. I tested it with a patch (attached) and this configuration: vkeyb-MidiOUT(ch1) -> pd-MidiIN pd-MidiOUT -> pd-MidiIN so, every time I play a note, I see how much time it takes to pass through pd. I made this test because in my configuration I place pd between my MIDI devices and synth, samplers, etc. The first thing I noticed is that the latency no longer depends on JACK buffer(frames/period), even with the "-jack" startup flag, and the results are: - With the "-jack" flag, the latency was always 1.45ms - With the "-noaudio" flag, the latency was 0ms (sometimes 1.45ms) Just to compare with the standard pd, the best result I achieved is 1.45/2.9ms with "-noaudio". Nicola Il 27/11/2012 18:50, Miller Puckette ha scritto: I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list #N canvas 96 143 300 152 10; #X obj 79 68 timer; #X obj 79 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 79 88 nbx 10 30 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 20 -262144 -1 -1 1.45125 256; #X obj 106 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 1 90 noteout 3; #X obj 106 3 notein 3; #X obj 1 2 notein 1; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 3 0 0 1; #X connect 5 0 3 0; #X connect 6 0 1 0; #X connect 6 0 4 0; #X connect 6 1 4 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Seems like this should be an option... I think it's a bit late to add features to 0.45 but I'll stick it on my list for later. cheers Miller On Thu, Aug 08, 2013 at 11:03:58AM +0200, Nicola Pandini wrote: > Hi, I resume this old thread because I compiled pd with Miller's > advices to disable MIDI buffering. > I tested it with a patch (attached) and this configuration: > vkeyb-MidiOUT(ch1) -> pd-MidiIN > pd-MidiOUT -> pd-MidiIN > so, every time I play a note, I see how much time it takes to pass > through pd. I made this test because in my configuration I place pd > between my MIDI devices and synth, samplers, etc. > The first thing I noticed is that the latency no longer depends on > JACK buffer(frames/period), even with the "-jack" startup flag, and > the results are: > - With the "-jack" flag, the latency was always 1.45ms > - With the "-noaudio" flag, the latency was 0ms (sometimes 1.45ms) > Just to compare with the standard pd, the best result I achieved is > 1.45/2.9ms with "-noaudio". > > > Nicola > > > Il 27/11/2012 18:50, Miller Puckette ha scritto: > >I believe if you edit s_midi.c and change: > > > > if (midi_outqueue[midi_outtail].q_time <= midirealtime) > > > >to > > > > if (1) > > > >and > > > > if (midi_inqueue[midi_intail].q_time <= logicaltime) > > > >also to > > > > if (1) > > > >that will make it fast-as-possible. The queueing code should probably > >be surrounded by an ifdef to make this easier (perhaps someday...) > > > >cheers > >M > > > >On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: > >>Is there a way to bypass all of this? > >>my pd usage usually imply sending and receiving as fast as possible. > >>sending delay usually annoy me. > >>cheers > >>c > >> > >> > >>Le 27/11/2012 18:06, Miller Puckette a écrit : > >>>Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output > >>>until the correct time; but Pd's accuracy in doing this is limited by the > >>>fact that it can't input or output MIID while it is either sleeping or > >>>running > >>>(only when the scheduler polls for what-to-do-next after either a task or a > >>>sleep has finished.) > >>> > >>>It would be more accurate for Pd to rely on either software interrupts or > >>>even > >>>better on some underlying OS time-tagging mechanism (for instance by > >>>exploiting > >>>whatever portmidi does). But I have to admit I've never treated this as a > >>>high > >>>priority (which one might take as an implied value judgement about MIDI). > >>> > >>>cheers > >>>Miller > >>> > >>>On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: > > Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : > ... > >with MIDI, Pd doesn't do any buffering and no synchronisation to some > >external clock is done, so messages appear in bursts which you notice > >as a inaccurate timing. > There is 1 strange thing however : pd did some kind of buffering with > midi, in order to synchronise with audio out. > if you configure 100ms audio latency, then a midi loop will be between > 100 and 105ms. > with 10ms audio buffer out, the midi loop is between 10 and 15ms. > but this buffer should not change anything on timing except adding > latency. > cheers > c > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >>>___ > >>>Pd-list@iem.at mailing list > >>>UNSUBSCRIBE and account-management -> > >>>http://lists.puredata.info/listinfo/pd-list > >>> > >___ > >Pd-list@iem.at mailing list > >UNSUBSCRIBE and account-management -> > >http://lists.puredata.info/listinfo/pd-list > #N canvas 96 143 300 152 10; > #X obj 79 68 timer; > #X obj 79 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 > -1; > #X obj 79 88 nbx 10 30 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 20 > -262144 -1 -1 1.45125 256; > #X obj 106 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 > -1; > #X obj 1 90 noteout 3; > #X obj 106 3 notein 3; > #X obj 1 2 notein 1; > #X connect 0 0 2 0; > #X connect 1 0 0 0; > #X connect 3 0 0 1; > #X connect 5 0 3 0; > #X connect 6 0 1 0; > #X connect 6 0 4 0; > #X connect 6 1 4 1; > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Hi, I resume this old thread because I compiled pd with Miller's advices to disable MIDI buffering. I tested it with a patch (attached) and this configuration: vkeyb-MidiOUT(ch1) -> pd-MidiIN pd-MidiOUT -> pd-MidiIN so, every time I play a note, I see how much time it takes to pass through pd. I made this test because in my configuration I place pd between my MIDI devices and synth, samplers, etc. The first thing I noticed is that the latency no longer depends on JACK buffer(frames/period), even with the "-jack" startup flag, and the results are: - With the "-jack" flag, the latency was always 1.45ms - With the "-noaudio" flag, the latency was 0ms (sometimes 1.45ms) Just to compare with the standard pd, the best result I achieved is 1.45/2.9ms with "-noaudio". Nicola Il 27/11/2012 18:50, Miller Puckette ha scritto: I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list #N canvas 96 143 300 152 10; #X obj 79 68 timer; #X obj 79 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 79 88 nbx 10 30 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 20 -262144 -1 -1 1.45125 256; #X obj 106 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 1 90 noteout 3; #X obj 106 3 notein 3; #X obj 1 2 notein 1; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 3 0 0 1; #X connect 5 0 3 0; #X connect 6 0 1 0; #X connect 6 0 4 0; #X connect 6 1 4 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
why not using -noaudio? I did not test, but i think it should be faster. yes, a -nomidibuffer flag would allow having a fast midi AND audio in the same time. cheers c Le 29/11/2012 13:16, Nicola Pandini a écrit : For my midi-only patches, I use the -r flag to reduce the latency. For example, -r 192000 gives me 1.333-1.666ms of latency (using jack with a buffer of 128). However having a startup flag that do the "fast-as-possible" thing, would be even better :-) Nicola Il 27/11/2012 18:55, Cyrille Henry ha scritto: cool, thanks. better than a ifdef, a startup flag! cheers c Le 27/11/2012 18:50, Miller Puckette a écrit : I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
For my midi-only patches, I use the -r flag to reduce the latency. For example, -r 192000 gives me 1.333-1.666ms of latency (using jack with a buffer of 128). However having a startup flag that do the "fast-as-possible" thing, would be even better :-) Nicola Il 27/11/2012 18:55, Cyrille Henry ha scritto: cool, thanks. better than a ifdef, a startup flag! cheers c Le 27/11/2012 18:50, Miller Puckette a écrit : I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-27 18:06, Miller Puckette wrote: > better on some underlying OS time-tagging mechanism (for instance > by exploiting whatever portmidi does). But I have to admit I've > never treated this as a high priority (which one might take as an > implied value judgement about MIDI). > i share any bad sentiments about midi. anyhow, i think jack-midi allows for timestamping as well. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC1BBMACgkQkX2Xpv6ydvS/RQCfYqw/3yD6MvNkl/MPdTYbCnBt OCsAnRPVNnxLLrpU8RghzctkCAscbYxO =21d7 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
cool, thanks. better than a ifdef, a startup flag! cheers c Le 27/11/2012 18:50, Miller Puckette a écrit : I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: > Is there a way to bypass all of this? > my pd usage usually imply sending and receiving as fast as possible. > sending delay usually annoy me. > cheers > c > > > Le 27/11/2012 18:06, Miller Puckette a écrit : > >Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output > >until the correct time; but Pd's accuracy in doing this is limited by the > >fact that it can't input or output MIID while it is either sleeping or > >running > >(only when the scheduler polls for what-to-do-next after either a task or a > >sleep has finished.) > > > >It would be more accurate for Pd to rely on either software interrupts or > >even > >better on some underlying OS time-tagging mechanism (for instance by > >exploiting > >whatever portmidi does). But I have to admit I've never treated this as a > >high > >priority (which one might take as an implied value judgement about MIDI). > > > >cheers > >Miller > > > >On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: > >> > >> > >>Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : > >>... > >>>with MIDI, Pd doesn't do any buffering and no synchronisation to some > >>>external clock is done, so messages appear in bursts which you notice > >>>as a inaccurate timing. > >> > >>There is 1 strange thing however : pd did some kind of buffering with midi, > >>in order to synchronise with audio out. > >>if you configure 100ms audio latency, then a midi loop will be between 100 > >>and 105ms. > >>with 10ms audio buffer out, the midi loop is between 10 and 15ms. > >>but this buffer should not change anything on timing except adding latency. > >>cheers > >>c > >> > >>___ > >>Pd-list@iem.at mailing list > >>UNSUBSCRIBE and account-management -> > >>http://lists.puredata.info/listinfo/pd-list > > > >___ > >Pd-list@iem.at mailing list > >UNSUBSCRIBE and account-management -> > >http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: > > > Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : > ... > >with MIDI, Pd doesn't do any buffering and no synchronisation to some > >external clock is done, so messages appear in bursts which you notice > >as a inaccurate timing. > > There is 1 strange thing however : pd did some kind of buffering with midi, > in order to synchronise with audio out. > if you configure 100ms audio latency, then a midi loop will be between 100 > and 105ms. > with 10ms audio buffer out, the midi loop is between 10 and 15ms. > but this buffer should not change anything on timing except adding latency. > cheers > c > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
thanks, clear indeed ! JM Le 27 nov. 2012 à 10:36, IOhannes m zmoelnig a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2012-11-26 23:29, Cyrille Henry wrote: >> >> >> Le 26/11/2012 22:38, Jean-Marie Adrien a écrit : >>> Thanks Miller ! -nosound -udiobuf 5 -slepgrain 1 >>> Definitely academic :) >>> >>> But I run intense audio on this PD instance, together with midi >>> driving lights in real time. here are the flags : >>> >>> -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 >>> >>> phasor~ would not do it ? >> phasor~ will do provide a better clock than a metro since pd >> internal time is "perfect". your problem come from jitter between >> "pd time" and "real world time". > > just to clarify: > both [phasor~] and [metro] live in an ideal world with perfect timing. > unfortunately this ideal world is not "real" (compared to your wall > clock) and has a slight jitter. > the jitter of [phasor~] is cleared by sending samples in a buffered > way to your soundcard. > with MIDI, Pd doesn't do any buffering and no synchronisation to some > external clock is done, so messages appear in bursts which you notice > as a inaccurate timing. > but the problem is really not Pd's internal timing (which is "ideal") > but the communication to the outside world. > > so to answer that specific question: [phasor~] will help you, but only > if you are able to use the signal that comes out of your soundcard, > which is synced to the wall clock, in order to trigger (or do whatever > you want to do). > if you only want to use audio-objects as an internal clock source, > then you will gain exactly nothing (but lose a lot, since you > complicate things which you normally get for free). > > >>> maybe simply change MIDI interface to without-driver model. >> yes, that sound like a good solution. > > well yes, if your midi driver is broken (that's how i interpret a > "weird stacking process"), you should probably replace that. > > fgmadr > IOhannes > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlC0iYMACgkQkX2Xpv6ydvSnRwCgr46N5LhnlkpNtiBQUFx8BKbE > BMgAn3dpbvGMaDuoGWWH8shQqYZfoCO4 > =IhZR > -END PGP SIGNATURE- > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-26 23:29, Cyrille Henry wrote: > > > Le 26/11/2012 22:38, Jean-Marie Adrien a écrit : >> Thanks Miller ! >>> -nosound -udiobuf 5 -slepgrain 1 >> Definitely academic :) >> >> But I run intense audio on this PD instance, together with midi >> driving lights in real time. here are the flags : >> >> -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 >> >> phasor~ would not do it ? > phasor~ will do provide a better clock than a metro since pd > internal time is "perfect". your problem come from jitter between > "pd time" and "real world time". just to clarify: both [phasor~] and [metro] live in an ideal world with perfect timing. unfortunately this ideal world is not "real" (compared to your wall clock) and has a slight jitter. the jitter of [phasor~] is cleared by sending samples in a buffered way to your soundcard. with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. but the problem is really not Pd's internal timing (which is "ideal") but the communication to the outside world. so to answer that specific question: [phasor~] will help you, but only if you are able to use the signal that comes out of your soundcard, which is synced to the wall clock, in order to trigger (or do whatever you want to do). if you only want to use audio-objects as an internal clock source, then you will gain exactly nothing (but lose a lot, since you complicate things which you normally get for free). >> maybe simply change MIDI interface to without-driver model. > yes, that sound like a good solution. well yes, if your midi driver is broken (that's how i interpret a "weird stacking process"), you should probably replace that. fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC0iYMACgkQkX2Xpv6ydvSnRwCgr46N5LhnlkpNtiBQUFx8BKbE BMgAn3dpbvGMaDuoGWWH8shQqYZfoCO4 =IhZR -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Le 26/11/2012 22:38, Jean-Marie Adrien a écrit : Thanks Miller ! -nosound -udiobuf 5 -slepgrain 1 Definitely academic :) But I run intense audio on this PD instance, together with midi driving lights in real time. here are the flags : -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 phasor~ would not do it ? phasor~ will do provide a better clock than a metro since pd internal time is "perfect". your problem come from jitter between "pd time" and "real world time". reducing audio latency should help to reduce this jitter. or clipped cos~ ? maybe simply change MIDI interface to without-driver model. yes, that sound like a good solution. cheers c JM Le 26 nov. 2012 à 17:19, Miller Puckette a écrit : This isn't a very good answer, but the "real" timing jitter in Pd can often be rediced by reducing audio buffering, In particular if you don't need audio at all you might be able to run Pd -nosound -udiobuf 5 -slepgrain 1 or something like that. cheers Miller On Mon, Nov 26, 2012 at 03:35:41PM +0100, Jean-Marie Adrien wrote: Hi list Im trying to cope with the MOTU Micro lite USB Midi driver under OsX Mountain Lyon. The stacking process of the driver is weird, means data are totally corrupted if they arrive too quickly to the interface, which does not happen with OsX Lyon, although MOTU announces full compatibility with OsX ML, anyway. I'm trying to make my own fifo from within PD, and, in this process, at some point I have to dump values out of the stack at "regular" time intervals. The straightforward implementation uses a metronome object, say with period 10 msec. The problem is that the metronome object is not precise enough, and it bangs erratically with time intervals within 0 to 20 msec, as measured with the (realtime) object, and this screws again the midi interface (everything else normal, dsp 10%). Is there an academic way to get a steady flux of bangs with short period ? Delay ? Hack some audio for control purposes ? (use a phasor~ ? :) Thanks Jm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Thanks Miller ! > -nosound -udiobuf 5 -slepgrain 1 Definitely academic :) But I run intense audio on this PD instance, together with midi driving lights in real time. here are the flags : -rt -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8 phasor~ would not do it ? or clipped cos~ ? maybe simply change MIDI interface to without-driver model. JM Le 26 nov. 2012 à 17:19, Miller Puckette a écrit : > This isn't a very good answer, but the "real" timing jitter in Pd can often > be rediced by reducing audio buffering, In particular if you don't need audio > at all you might be able to run Pd -nosound -udiobuf 5 -slepgrain 1 or > something like that. > > cheers > Miller > > On Mon, Nov 26, 2012 at 03:35:41PM +0100, Jean-Marie Adrien wrote: >> Hi list >> Im trying to cope with the MOTU Micro lite USB Midi driver under OsX >> Mountain Lyon. >> The stacking process of the driver is weird, means data are totally >> corrupted if they arrive too quickly to the interface, which does not happen >> with OsX Lyon, although MOTU announces full compatibility with OsX ML, >> anyway. >> >> I'm trying to make my own fifo from within PD, and, in this process, at some >> point I have to dump values out of the stack at "regular" time intervals. >> The straightforward implementation uses a metronome object, say with period >> 10 msec. >> >> The problem is that the metronome object is not precise enough, and it bangs >> erratically with time intervals within 0 to 20 msec, as measured with the >> (realtime) object, and this screws again the midi interface (everything else >> normal, dsp 10%). >> >> Is there an academic way to get a steady flux of bangs with short period ? >> Delay ? >> Hack some audio for control purposes ? (use a phasor~ ? :) >> Thanks >> Jm >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-26 17:19, Miller Puckette wrote: > at all you might be able to run Pd -nosound -udiobuf 5 -slepgrain 1 > or if that gives you trouble, try the flags "-nosound -audiobuf 5 -sleepgrain 1" :-) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCzoa0ACgkQkX2Xpv6ydvTUagCdGg4kgwYzxIkg7QhjrEaBG5Yz HjoAnA3UhlNbmn79uGng9NGKRSQycVl8 =2j6b -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
This isn't a very good answer, but the "real" timing jitter in Pd can often be rediced by reducing audio buffering, In particular if you don't need audio at all you might be able to run Pd -nosound -udiobuf 5 -slepgrain 1 or something like that. cheers Miller On Mon, Nov 26, 2012 at 03:35:41PM +0100, Jean-Marie Adrien wrote: > Hi list > Im trying to cope with the MOTU Micro lite USB Midi driver under OsX Mountain > Lyon. > The stacking process of the driver is weird, means data are totally corrupted > if they arrive too quickly to the interface, which does not happen with OsX > Lyon, although MOTU announces full compatibility with OsX ML, anyway. > > I'm trying to make my own fifo from within PD, and, in this process, at some > point I have to dump values out of the stack at "regular" time intervals. > The straightforward implementation uses a metronome object, say with period > 10 msec. > > The problem is that the metronome object is not precise enough, and it bangs > erratically with time intervals within 0 to 20 msec, as measured with the > (realtime) object, and this screws again the midi interface (everything else > normal, dsp 10%). > > Is there an academic way to get a steady flux of bangs with short period ? > Delay ? > Hack some audio for control purposes ? (use a phasor~ ? :) > Thanks > Jm > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Limit bandwith for MIDI output / precise metro
Hi list Im trying to cope with the MOTU Micro lite USB Midi driver under OsX Mountain Lyon. The stacking process of the driver is weird, means data are totally corrupted if they arrive too quickly to the interface, which does not happen with OsX Lyon, although MOTU announces full compatibility with OsX ML, anyway. I'm trying to make my own fifo from within PD, and, in this process, at some point I have to dump values out of the stack at "regular" time intervals. The straightforward implementation uses a metronome object, say with period 10 msec. The problem is that the metronome object is not precise enough, and it bangs erratically with time intervals within 0 to 20 msec, as measured with the (realtime) object, and this screws again the midi interface (everything else normal, dsp 10%). Is there an academic way to get a steady flux of bangs with short period ? Delay ? Hack some audio for control purposes ? (use a phasor~ ? :) Thanks Jm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
