[chuck-users] MAUI for PC/Linux

[mike clemow]

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 at lists.cs.princeton.edu
>  https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
urls is coming...