[chuck-users] MAUI for PC/Linux

[Kassen]

On 22/04/2008, mike clemow <gelfmuse at gmail.com> wrote:
>
> Hi, Kas,


Hey, Mike (and Stephen and Joe),



> This I agree with completely.  It would be sweet, for instance, to
> "plug" a GUI element into a object parameter.
>
> mge => s.gain;   //this might work like "SinOsc s => dac;"


I've been thinking about things like that as well. This would mainly be
shorthand that would save defining a actual shred but I could imagine that
in the (far) future such things (not just interface elements but also Ugens
send to parameters) would be dealt with by the compiler who would try to see
if that parameter were one where we could do something more clever then
using a shred (equivalent). In the case of gain I could imagine assigning
the fader's internal value for it's state to the oscillator's internal value
for gain. This won't work everywhere; some parameters need to do
calculations upon changing but in some places such things might save cpu, I
wonder if that would be worth it.



> 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.


I agree. I'm extremely curious about the syntax GlucK will have because most
3d libraries seem to reason in a way that's not mine. I haven't yet worked
with the MAUI elements myself as I don't have a Mac but based on what
Inventor found and my own tests there sporking a thousand empty shreds
waiting for a event and seeing how much that took of the CPU (quite a lot) I
think we could use some streamlining.

While that may sound very critical of Spencer I think a syntax is a language
and like all languages will have to be formed, changed and developed by the
people that speak it.



> 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.


Yes, this makes a lot of sense to me. I could see a lot of useful
applications for example running such a interface client on a mobile phone
or on a tablet PC with a modest CPU.

I had a idea last night. How about abstracting the interface to a class
called something like "Gui", Gui would have member functions for doing
things like creating faders and buttons and so on but also (like Hid) a
"open" function. This "open" function would be used to either link the gui
to a window like the Mini has or to OSC. If OSC is chosen it would be given
a port for input and for output and send all commands (standardised) over
OSC to be dealt with by Processing or whatever graphical program the user
wants to use. This way the choice of what interface to use could even be
given as a parameter to the shred. OSC-wise it would just be a abstraction
with a convenient naming scheme. Templates for catching these messages could
be build in Processing and IXI and so on to get people started.

This would also enable us to use a entire graphical interface window as a
single event, ChucK that to now and parse that using the same syntax we use
for Hid "if (msg.isButtonDown())......." which would save a LOT of shreds
for large and complex interfaces.

The big weakspot in this plan is that a user may want to define a element
(say a sprite) in one of these packages that has no ChucKian gui equivalent.
Ideally there would be a way of dealing with that, for example simply
passing them on if the gui is linked to OSC and generating a non-fatal error
otherwise (to preserve compatibility where possible and fail gracefully).

I could also imagine this "open" function getting presets to make it speak
the same language as a Lemur or a Monome. That would chiefly be a
convenience thing but I could see that getting quite popular.

<snipping a few of your ideas here, I think those are quite similar to mine>

>
> 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.


Yes, OSC could use some love, I'm not sure I understand what you mean by the
link between shreds and OSC hierarchy though, could you elaborate on that,
please?


I'm just thinking out loud here...


:¬)

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080422/4771f144/attachment.htm