[PD] Limit bandwith for MIDI output / precise metro

[Nicola Pandini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pd-midi_latency_test.pd
Type: text/x-puredata
Size: 496 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130808/6f2a9243/attachment.bin>