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 WIndows and it seems to me As though fast input is auto-quantized to some pretty coarse note value. I suppose this is a limitation of the keybord scanning, right?
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.
[MIDI] 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 off_line MIDI data in a file or stuff that's coming in on the wire in real time. 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 messages 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 which means getting the job done but reinventing wheeels in the process. Ideally, I'd like to work at the musician level without having to know about running status, handle channels by masking off nibbles in binary data and recalling or defining constants for the various event types. A Java-like API with dedicated event classes for each one would be great. Even a more primitive 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. spencer