[PD] FLUSH

[Krzysztof Czaja]

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, unless `flush' 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.