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

Reply via email to