<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hello Gabor,<br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


this request was added to the fluxus task list long time ago. since i'm not a musician, what would be the useful syntax to control midi output?<br><br></blockquote><div><br></div><div>I think that the main thing would be to enable this at all. A simple (midi-out n [n1] [n2]) function that would take one, two or three numbers would do for this. These numbers could be required to be integers in the range of 0 to 127 (with any other number giving a error) or they could be floored and modulo-ed by the function. </div>

<div><br></div><div>I think we need something like that anyway, as MIDI is a fairly extensive protocol, implementing everything would be insanely boring and on top of this individual users could build anything they might need, from simple notes, to a clock, to detailed sys-ex control over whatever hardware they might own.</div>

<div><br></div><div>One other core function we could consider is something like (midi-out-cue) that would return a list of the messages in the current midi cue, or even just the length. I'm not sure RtMidi supports this. The issue is that MIDI is slow and a system like our own could easily clog it. With this command we could verify whether there is space for non-essential messages if it is turning out that our program is clogging the bandwith. I requested this for ChucK a few times, but nobody else seems to find the fact that we are much. much faster than MIDI as a protocol could ever anticipate relevant. The result is a software system that's potentially quite out of touch with the underlying hardware. We could look at this a bit like (delta) which we also use to compensate for hardware variations, except in this case the hardware is static and it's Fluxus's speed that varies. This is non-essential but would be nice.</div>

<div><br></div><div>On top of this nearly everyone will want (midi-out-note ) and (midi-out-ccn) so perhaps those should be supplied, as well as (midi-out-program). I think the current syntax of those in their input variants is perfectly fine. IMHO doing something different there doesn't allow for so many gains that this would offset the loss in convenience brought on by a wildly different syntax. Some people may wish to use Fluxus to dynamically process MIDI and those will be cursing us if midi-in and out work in different ways. For the channel bytes I'd suggest performing a floor and a modulus 16 on the input, as that seems well matched with the way in which we treat the (gh n) calls.</div>
<div><br></div><div>Disclaimer; I have worked with MIDI for a decade or so, but nearly always I was configuring the meaning of messages on both ends because I always wanted to do unusual stuff and ended up using MIDI as a sort of tunnel most of the time. I can't see this proposal breaking "traditional" usage at all but if somebody does I hope (s)he chimes in. I'm sure that unless the library filters things like single byte messages (ie midi clock) like the one in ChucK does this proposal should enable anyone to implement anything supported by the MIDI standard as well as some convenient utility functions. </div>
<div><br></div><div>In recent years there has been a decent amount of releases of controllers that have stuff like light-up buttons and so on. Some of these lights can be controlled through note-on messages while other manufacturers saw fit to make up their own protocol. With low-level (individual bytes) control over the output owners of such devices could write their own interface to such hardware. That might be nice for some types of performance. Fluxus does allow us to see the final result (GL graphics) and the code, but not always the "state" of the running program. Controllers like that might be nice for this.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>