Hello again list,<br><br>Today I hacked a little in the fluxus-midi module. I "needed" to get the MIDI controller change 'as it happened' so to speak.. As usual, various ways to accomplish this... I looked down upon maintaining a local vector of controller values in the (fluxus)
program, and checking out which have changed (every channel, all controllers = most probably very slow to do every-frame). I also looked at (midi-peek), but that returns a string value, and as the function description includes "for debugging purposes", I'm not too sure if that would be most optimal, as it's a single string returning only the last of a sequence of events, so I could loose values there.<br>
<br>The quickest way to get me results, I thought would be to solve my problem in the fluxus-midi module itself. My version will also 'queue' the event like the MIDINotes are queued. I kept this list only 16 items large, as there could be a lot of controller values being sent and for my purpose of animation only the most recent are interesting...<br>
<br>So I went on to implement (midi-cc-event) which returns #f is there was no event and otherwise controller information: number and value, similar to (midi-note).<br><br>Now my question is, was implementing that a wise thing to do? Or did I re-invent the wheel there because I am unaware of something? Or there is a slight possibility that change may be useful upstream? <br>
<br><br>Also, when going through that code (specifically, that enum in MIDIListener), I get the impression that "Program Change" and "Pitch Bend" are planned features?<br><br>If so, perhaps interesting to know that I have already done "Program Change"; implementing (midi-program ch), to get the current program value for the requested channel. <br>
<br><br>I have attached the patch that implements the (midi-program) and (midi-cc-event), might anyone be interested... <br><br>Cheers,<br>Hugo<br>