Bruce; I generally use it out of habit and then very occasionally get surprised
when it doesn't work. Fortunately, practically all languages thes days are written by people with C backgrounds, so this is included by default. Octal parsing is more intermittent :)
It's usefull to have but I don't think I saw it in ChucK before. Learned another thing.
Ah yes, so the underlying functions send an arbitrary length vector, but the polymorphic functions actually exposed to ChucK take the midi message and stuff all three bytes directly into the message without checking. This is where it would be nice to have something that knew what message was what.
Yes, I agree.
My favoured solution [1] would be to have the midi message sending function know exactly how long the different types of messages should be and automatically send just that number of bytes from the message thing, unless overridden by a specific parameter.
A while ago I proposed to Ge to turn the MIDI implementation in ChucK into something like was done with the HID and adress them like functions. On the HID side isButtonDown() and so on make everything much easier to deal with then the old way of refering to each type of incoming data by a number. The exact same could be done quite easily with MIDI and at the same time message-length could be dealt with. Dealing with the numbers is very educational and it works but it's no fun at all and I don't think anybody feels like remembering 192 means a program change. I think Ge put this proposal on the list. In the meantime; I noticed that your own code that solves most of the numbers game isn't linked to on the Wiki. I think it would be quite valuable. Should I link to it there? Would you like to do this yourself? More interestingly, perhaps, the midi functions have polymorphic
versions which take a number of bytes (1,2 or 3) and just send those. That would provide an immediate solution to make my own midi library work properly.
So, what do people think about that change to MidiOut::send() in midiio_rtmidi.c ? Unless I hear some loud screaming, I'll write and submit the patch tonight.
I think it would be great but it might be best to check with Ge to avoid paralel efforts, considdering something similar is on the todo list. Another question, if we are talking about this anyway, is the MidiIn. I think the MidiIn might have some sort of filter that only makes it react to three byte messages, at least I think I got some quite odd result when feeding it other stuff. This isn't bad as such; we probably want to be able to avoid having every clock tick trigger some potentially complicated parsing sequence but maybe those filter settings should be configurable as a property of the MidiIn object? Thinking out loud again... Kas.