[chuck-users] MAUI for PC/Linux

[Kassen]

On 21/04/2008, mike clemow <gelfmuse at gmail.com> wrote:
>
> Chiming in a bit late here...
>
> Count me as +1 in the "swell."  ;-)  I *heart* MAUI as well.  But I
> also wanted to ask the crowd here what they think about the idea of
> utilizing/accepting influence from some of the very-accessible
> graphics platforms out there.  There's SwingOSC, Processing,
> OpenFrameworks, the ixi-software.net people have Mirra...  all of
> which are cross-platform.


I think they are great. I feel there are a lot of very interesting options
there, we'd be silly to ignore those, there's a lot there to learn/borrow
from idea-wise as well.

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 is not to say I disagree with you in the slightest as the Maui are
clearly no alternative for Processing or the like at all. Maybe GlucK would
eventually be but GlucK isn't even released yet.

I think that an OSC-based communication for GUI elements would be
> great.  OSC, as pervasive as it is, is in my opinion an under-utilized
> protocol.  MAUI is awesome and convenient, because it's still in the
> miniAudicle environment, I still usually just use it for debugging.  I
> think that I would rather see a set of GUI-specific OSC objects that
> can be manipulated with whatever visual front-end you want to use.
> For anything more complex than the normal slider, knob, led, metaphor,
> I find myself rolling my own anyway.


Yes, this makes perfect sense. As Inventor ran into on the forum; there are
definite questions about the MAUI at the moment because a array (non-
CS-sense) of buttons will result in a array of shreds listening for them
which in turn results in a array of overhead. Besides that there are no MAOI
on two out of three platforms right now. Regardless of what we do I think it
would be a good idea to have a round-table of ideas on how to deal with
interface elements. I could imagine -for example- a way of abstracting them
that could be tied to either MAUI or OSC depending on mood/platform/needs to
mention but one idea.


If the GUI API could be decoupled from the environment, OSC-based, and
> graphics-platform agnostic (and miniAudicle could easily have it's own
> in-environment 2D implementation), then I think we'd really be onto
> something.


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.

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