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.