Another realtime performance issue I'm trying to get around:

I'm using an external midi controller to send midi controller change
messages to csound.  My approach has been to have a single instrument
(like an event handler in UI programming) always on, monitoring the
midiin ugen for messages, and handling them conditionally, like this:

<snip>
	instr 70	;midi switchboard
kstatus, kchan, kdata1, kdata2 midiin
;
; cc msgs from b-control
;

knob1:
if	kstatus != 176 kgoto end
if	kdata1 != 81 kgoto knob2
gkosc1freq = (kdata2 * .10236)

FLsetVal  kdata1,gkosc1freq, giosc1freqhandle
knob2:
if	kstatus != 176 kgoto end
if	kdata1 != 82 kgoto knob3
gkosc1shape = (kdata2 * .00787)
FLsetVal  kdata1,gkosc1shape, giosc1shapehandle
knob3:
if	kstatus != 176 kgoto end
if	kdata1 != 83 kgoto knob4
gkosc1lev1 = (kdata2 * .00787)


etc...
</snip>

The docs for midiin state:
"kstatus -- the type of MIDI message. Can be:
      128 (note off)
      144 (note on)
      160 (polyphonic aftertouch)
      176 (control change)
      192 (program change)
      208 (channel aftertouch)
      224 (pitch bend
      0 if no MIDI message are pending in the MIDI IN buffer"

The problem is, the last message sent remains in the MIDI IN buffer,
even after it's read.  I never get '0' back for status.  For example,
I would expect a note-on message to appear once in the buffer.  Once
I've read it via midiin, I should get 0 back until another message is
sent from the midi controller.

This makes it difficult to do many things with control changes - if I
want to call another instrument given a controller change, that
instrument will be called repeatedly, at krate, until another message
turns up in the buffer.

I don't see any ugen I should be using to clear the MIDIIN buffer
proactively, but maybe I'm missing something.  What I'm encountering
may be a portmidi issue, I'm not sure.

Thoughts and feedback appreciated.


b