[PD] Limit bandwith for MIDI output / precise metro

Nicola Pandini nicola.pandini at gmail.com
Thu Nov 29 13:16:29 CET 2012


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 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


-- 
Nicola




More information about the Pd-list mailing list