Hi Eric, Krzysztof,
"flush" messages indicate MIDI input queue over-runs. All MIDI queuing originates in s_unix.c (a comment suggests rename the file to s_midi.c). The FLUSH message originates in the function,
void sys_midibytein(int portno, int byte){...}
This function maintains a circular queue of MIDI events. When the queue fills up, the head hits the tail and this triggers the flush message. The queue size is defined by MIDIQSIZE and is only 256 bytes. Therefore if PD does not process the MIDI messages in a reasonable time the queue is flushed as new messages come in.
For example, I get flush messages when using an electric-field sensing controller (Fish) with my laptop running Windows 2000 Pro. The Fish outputs control change messages at a very high rate and thus fills the queue rather quickly, therefore yielding said "flush" messages.
To fix this, I use [metro] to downsample all [ctlin] messages using a [float] buffer for temporary storage between bangs. This way I process control messages at 50ms intervals but the float buffer updates at the rate of MIDI control input. This works because the excess messages are handled efficiently, thus the MIDI-IN event queue drains faster than it fills.
Best regards,
Michael Casey http://www.media.mit.edu/~mkc
hi Michael,
that explains a lot. One thing is still not clear, though. What is reading from midi input buffer is not a [ctlin] object, but an internal queue handler. It keeps sending MIDI controller data to a `#ctlin' target, regardless of what is in a patch -- whether there is one [ctlin], many, or none.
For example on a 800Mhz linux box I get `flush' warnings after banging a [metro 1]->50000->[until] and sending a stream of volume controller data, aftertouch, or any other continuous data out from a MIDI keyboard (with no midi objects in a patch).
The midi input queue itself is maintained in order to minimize jitter, and not as a communication buffer between reading and writing threads (or the like). It works by imposing a dejittering delay, i.e. midi bytes are not dispatched immediately, but only if (midi_inqueue[midi_intail].q_time <= logicaltime). Thus if anything expensive happens during _one_ such delay, there will be no overrun -- there probably need to be a stream of such events, but this is the point I am lost in.
Anyway, all this could be perfectly understandable and working just as expected' for an expert of course, unlessflush' warnings appear
in case of a less computationally intensive patch, or even an empty
patch. Is this your case, Eric?
Krzysztof
Btw. I think my old and very specific problem with Pd/Windows midi input (becoming deaf after working for several minutes) is unrelated.
Michael Casey wrote: ...
"flush" messages indicate MIDI input queue over-runs. All MIDI queuing
...
For example, I get flush messages when using an electric-field sensing controller (Fish) with my laptop running Windows 2000 Pro. The Fish outputs control change messages at a very high rate and thus fills the queue rather quickly, therefore yielding said "flush" messages.
To fix this, I use [metro] to downsample all [ctlin] messages using a [float] buffer for temporary storage between bangs. This way I process control messages at 50ms intervals but the float buffer updates at the rate of MIDI control input. This works because the excess messages are handled efficiently, thus the MIDI-IN event queue drains faster than it fills.
-
Krzysztof Czaja -
Michael Casey