Hi Ben,

Perhaps you can simplify your thought process by instead using the 
ctrl7 opcode.

The first block could then be

	instr 70 ;midi switchboard

knob1:
kval1	ctrl7	1, 81, 0, 13
gkosc1freq	=	kval1

FLsetVal	81, gkosc1freq, giosc1freqhandle

...
and so on.

A couple of things that I might suggest haven trodden this path before.

1) Try to avoid using FLTK widgets whenever possible. I know it sounds 
counterintuitive, but they always seem to crash Csound when you say, 
for example try to control button widgets with program change messages. 
There are several other things such as that that seem to contribute to 
the instability of FLTK.

2) midiin seems to work most efficiently when encapsulated inside of a 
UDO, see
http://www.csounds.com/udo/displayOpcode.php?opcode_id=71
http://www.csounds.com/udo/displayOpcode.php?opcode_id=69
http://www.csounds.com/udo/displayOpcode.php?opcode_id=68
http://www.csounds.com/udo/displayOpcode.php?opcode_id=65
http://www.csounds.com/udo/displayOpcode.php?opcode_id=74

for more examples. Note that the last one of those UDO's actually takes 
the same formula for scaling as found in the source code for ctrl7, and 
thus can be quite useful when used in combination with raw midiin.

In general I would suggest to start looking towards TclCsound for GUI 
display purposes. It seems much more robust and stable than the current 
FLTK implementation, as I've been having extreme difficulty making 
stable, cross-platform patches using FLTK, but not at all with 
TclCsound.


-David

On Feb 14, 2006, at 1:57 PM, Ben McAllister wrote:

> 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:
>
> 
> 	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...
> 
>
> 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