<span class="gmail_quote"></span>Bruce;<br><div><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I generally use it out of habit and then very occasionally get surprised
<br>when it doesn't work. Fortunately, practically all languages thes days<br>are written by people with C backgrounds, so this is included by<br>default. Octal parsing is more intermittent :)</blockquote><div><br>It's usefull to have but I don't think I saw it in ChucK before. Learned another thing.
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Ah yes, so the underlying functions send an arbitrary length vector, but<br>
the polymorphic functions actually exposed to ChucK take the midi<br>message and stuff all three bytes directly into the message without<br>checking. This is where it would be nice to have something that knew<br>what message was what.
</blockquote><div><br>Yes, I agree.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>My favoured solution [1] would be to have the midi message sending
<br>function know exactly how long the different types of messages should be<br>and automatically send just that number of bytes from the message thing,<br>unless overridden by a specific parameter.</blockquote><div><br>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.
<br><br>I think Ge put this proposal on the list.<br><br>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?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">More interestingly, perhaps, the midi functions have polymorphic<br>versions which take a number of bytes (1,2 or 3) and just send those. That
<br>would provide an immediate solution to make my own midi library work<br>properly.<br><br>So, what do people think about that change to MidiOut::send() in<br>midiio_rtmidi.c ? Unless I hear some loud screaming, I'll write and
<br>submit the patch tonight.</blockquote><div><br>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.<br> </div><br>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?
<br><br>Thinking out loud again...<br><br>Kas.<br></div>