[PD] Limit bandwith for MIDI output / precise metro

[Cyrille Henry]

why not using -noaudio?
I did not test, but i think it should be faster.

yes, a -nomidibuffer flag would allow having a fast midi AND audio in the same time.

cheers
c


Le 29/11/2012 13:16, Nicola Pandini a écrit :
> 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
>
>