[chuck-dev] Updating ChucK's MIDI support

Kassen signal.automatique at gmail.com
Tue Aug 18 09:49:05 EDT 2009


I don't need all of that for my app but would be happy to continue
> working on it if it's something that's needed by other ChucK users. But
> if I do that, it would be nice to get some feedback on what method names
> the dev folks would prefer to see used in the ChucK VM. On the other
> hand, if this work is already under way by someone else, I don't want to
> step on any toes or release a patch with conflicting MIDI methods. Any
> thoughts on the best way to proceed?
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.

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20090818/30f1d634/attachment.htm>

More information about the chuck-dev mailing list