[chuck-users] UI Idea, Uses, Accessibility, HID and MIDI

[Spencer Salazar]

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