Steve;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don't need all of that for my app but would be happy to continue<br>
working on it if it's something that's needed by other ChucK users. But<br>
if I do that, it would be nice to get some feedback on what method names<br>
the dev folks would prefer to see used in the ChucK VM. On the other<br>
hand, if this work is already under way by someone else, I don't want to<br>
step on any toes or release a patch with conflicting MIDI methods. Any<br>
thoughts on the best way to proceed?<br>
<br>
</blockquote><div><br>I have long advocated that MIDI should (at least optionally) look a lot like the named HID functions and stand by that. As far as I can see right now this would consist mainly of some additional code and methods for the MIDI message, not so much for the actual abstraction of the port, aside from the issues with message length for messages of one or two bytes. <br>
</div></div><br>The one thing I'm a bit torn about is the clock. If we'd have a big shred dedicated to parsing incoming MIDI running through that every time a clock message comes in might translate to a bit of a CPU hit. Another factor is the initiative to have a clock to sync ChucK to other instances of ChucK and to SC, PD (etc). I could imagine that MIDI clock could be made a part of that as well so that in one swoop we could sync laptops, grooveboxes and whatever else comes up. I actually imagine this clock to be a bit like the DAC and ADC in being a VM-wide object that could also sync multiple internal shreds and files using events. Perhaps such a clock, like the DAC, would need channels so I could sync to you over OSC while my groovebox in turn syncs to me over MIDI at 2/3 of the rate by me having one of my clock channels slaved to another.<br>
<br>I'm working from the idea that all clocks are conceptually similar here and that how we'd like to work with them will be more or less constant and independant of the actual protocol and cables, though I suppose I'm also making a lot of assumptions here and it could be argued it's moving in the direction of "dumbing stuff down".<br>
<br>Yours,<br>Kas.<br>