[chuck-users] UI Idea, Uses, Accessibility, HID and MIDI
ssalazar at CS.Princeton.EDU
Wed Mar 7 12:57:26 EST 2007
On Mar 7, 2007, at 8:18 AM, Veli-Pekka Tätilä wrote:
> V: A funny thing about the organ. I've tried playing very fast in
> and it seems to me As though fast input is auto-quantized to some
> coarse note value. I suppose this is a limitation of the keybord
The quantization in that example is actually enforced by that
specific ChucK program. If you check out the code, you might notice
an 80::ms => now; that is executed right after each key press.
Removing that line will remove the quantization--then it should be
able to keep up with faster input, unquantized.
> V: Lastly, some feedback about MIDI:
> I mentioned MIDI processing as one potential use and find the
> current API a
> bit raw. It would be great if I could transparently handle either
> MIDI data in a file or stuff that's coming in on the wire in real
> Further more, if it is off-line, would be very cool if the data
> could be
> idealized a little: note on/off pairs to note events with length, a
> bunch of
> controller messages to 14-bit NRPN and RPN messages and full sysex
> whose checksum would be auto-calculated basedd on the manufacturer
> ID, you
> get the picture. I think the current API is about as raw as in VSt
> means getting the job done but reinventing wheeels in the process.
> I'd like to work at the musician level without having to know about
> status, handle channels by masking off nibbles in binary data and
> or defining constants for the various event types. A Java-like API
> dedicated event classes for each one would be great. Even a more
> presentation as in MIDI Perl using arrays would be quite all right.
Yes, some expansion/abstraction of ChucK's MIDI implementation has
been discussed before, and would be pretty beneficial.
More information about the chuck-users