czaja at chopin.edu.pl
Wed Jan 23 16:55:08 CET 2002
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?
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
More information about the Pd-list