[Fluxus] MIDI-out?

[Kassen]

>
> Hello Gabor,
>


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

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.

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.

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.

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.

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.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20100930/4786328e/attachment-0001.html>