On 21/04/2008, <b class="gmail_sendername">mike clemow</b> <<a href="mailto:gelfmuse@gmail.com">gelfmuse@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chiming in a bit late here...<br> <br> Count me as +1 in the "swell." ;-) I *heart* MAUI as well. But I<br> also wanted to ask the crowd here what they think about the idea of<br> utilizing/accepting influence from some of the very-accessible<br>
graphics platforms out there. There's SwingOSC, Processing,<br> OpenFrameworks, the <a href="http://ixi-software.net">ixi-software.net</a> people have Mirra... all of<br> which are cross-platform.</blockquote><div>
<br>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.<br><br>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.<br>
<br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think that an OSC-based communication for GUI elements would be<br> great. OSC, as pervasive as it is, is in my opinion an under-utilized<br> protocol. MAUI is awesome and convenient, because it's still in the<br>
miniAudicle environment, I still usually just use it for debugging. I<br> think that I would rather see a set of GUI-specific OSC objects that<br> can be manipulated with whatever visual front-end you want to use.<br> For anything more complex than the normal slider, knob, led, metaphor,<br>
I find myself rolling my own anyway.</blockquote><div><br>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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If the GUI API could be decoupled from the environment, OSC-based, and<br> graphics-platform agnostic (and miniAudicle could easily have it's own<br>
in-environment 2D implementation), then I think we'd really be onto<br> something.</blockquote><div><br>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. <br>
</div><br>Yours,<br>Kas.<br></div>