Difference between revisions of "ChucK/2011 PRC"
From CSWiki
(Created page with "== 1) Buildable/Runnable ChucK with MAUI included == (Mac OSX, Snow Leopard, Lion required, Windoze desired but optional). chuck-Mini would in a way take care of my file-p...") |
(No difference)
|
Revision as of 03:00, 18 October 2011
Contents
1) Buildable/Runnable ChucK with MAUI included
(Mac OSX, Snow Leopard, Lion required, Windoze desired but optional).
chuck-Mini would in a way take care of my file-path problems, as running chuck from the command line or from a clickable script (which could do a cd if necessary) would automagically put things in the directory from where chuck was evoked, and I can ensure all necessary files are there.
Buildable means getting makefiles in a state where I can build stuff.
I have lots of things I'd like to fold into/expose that I could try out and give you for future releases, or just use in my own private chuck builds, but only if I can compile. Some of these include making sure every UG that makes sense obeys some standard messages (like NoteOn, ADSR for example doesn't know what NoteOn means, only KeyOn), more innards of UGs are exposed for power users, etc.
2) extended MAUI widgets (vertical slider, bitmap buttons, other?)
3) SetPath("path"); for chuck
Maybe support for an environment CHUCK_PATH variable, maybe support for ./ ../ etc. while you're at it, maybe support for environment variables in general?
4) something else I think of that I need for levitin's study
5) Some HID additions:
Absolute trackpad finger position. I think I've seen code for this in various forums, and we can get absolute cursor position, but just delta track pad. Possible multi-touch support as well. Fuller (native) support for graphics tablets
6) GreyHole
(BlackHole that ticks at decimated rate, anything chucked to it only runs each N samples). This would be hugely helpful for smoothing functions, doing lower rate signal processing, etc. It could also really ease up processor use, as long as the underlying tree-traversal is efficient. I've implemented it native by chucking for one sample and unchucking for N-1. But it would be nice for a UG to take care of this automatically, and efficiently.
7) Chug-in (runtime) UG loading.
I understand you've worked on this some already.