[PD] Limit bandwith for MIDI output / precise metro

Miller Puckette msp at ucsd.edu
Tue Aug 20 03:00:29 CEST 2013


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 at iem.at mailing list
> >>>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>_______________________________________________
> >>>Pd-list at iem.at mailing list
> >>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>
> >_______________________________________________
> >Pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list