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