Hi, Kas,
To me ChucK is mainly a syntax though and I think there are very good reasons to try to incorporate visual elements using this same syntax. This has advantages for ChucK as a educational platform (only one syntax to learn) and it has advantages for artists (less mental switching). This does/would also lead to whole projects being more self-contained which is good for communication.
This I agree with completely. It would be sweet, for instance, to "plug" a GUI element into a object parameter. SinOsc s => dac; //"plug" s into dac myGuiElement mge; mge.range( 0.0, 1.0 ); mge => s.gain; //this might work like "SinOsc s => dac;" as well as having a method to return the value: mge.value() => float myFloat; That's off the top of my head, but there are probably a million "chuckian" things one might change about the normal UI paradigm. To be fair, MAUI elements are not created in code in a very novel way. It's still pretty standard UI code. For a live-coding language, this isn't really ideal.
You mean like a separate program? Right now command-line ChucK doesn't depend on Xserver/Quartz/explorer (that I know of) and I could see reasons for keeping it that way like installations or embedded applications. I wonder if you can have a single application that wouldn't need a graphical shell to run but could still use one when one is available and useful.
I think I actually do mean like a separate program. When I run a UI I made in Processing to control Chuck, Chuck doesn't even have to be running on the same machine, since all the control messages are sent via UPD as OSC messages. This is the same kind of paradigm that the SuperCollider language (client) communicates with their synth server. Technically, you could control scsynth with anything that sent the right OSC messages. I guess what I'm suggesting is a similar Paradigm for setting up responders in Chuck code for UI elements if they are around. Perhaps... SinOsc s => dac; OSCResponder resp; resp.type( "f" ); // f is for "float" - OSC has float, int, and string resp.port( 9001 ) resp.address( "/test" ); // the address in OSC namespace resp => s.gain; // plug it in... (if this sort of thing is possible, since right now this attribute wouldn't accept this object) In my Chuckian fantasy, ;-) if the shred received a /test OSC message on port 9001 with a matching type signature, it would "chuck" the value into s.gain. I mean, I guess we're not that far from this... meaning that we could kind of roll our own here with a clever class that abstracts the OSC functionality of Chuck, but to honest, it's going to be tricky. There are some quirks to its current implementation, and some limitations to the OSC hierarchy due to the way that shreds work. If it were built in functionality, I think that this would certainly pave the way to having a framework upon which one could choose-your-own-UI-platform. After that, I could see a Chuck-syntax 2D/3D drawing kit that would use Chuck to do UI. I'm just thinking out loud here... -Mike
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- urls is coming...