Re: [chuck-users] MAUI for PC/Linux

22 Apr 2008

      Kas,
...
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?
Yes, of course.  So, a while back (and I had promised to send video
and school took over my life instead) I worked on a project building a
trash-sculpture with two bands, who graciously donated audio samples
to the project.  The trash sculpture had things you could turn, twist,
open, close, etc and each of those would trip various sensors
connected to an Arduino microcontroller board, which sent ASCII text
to Python script, which bundled the information as OSC messages and
sent them along to Chuck which would happily scrub away at the poor
bands' audio samples and turn them into an audience-driven remix.
(That's the backstory.)

Between Chuck and the Python script, I tried to create an OSC address
hierarchy not unlike the following:

/control
    /birdnoise
        /gain
        /filterq
    /aliensquawk
        /freq
        /gain
    ...

/router                               (this was for controlling the
Python script)
    /shutdown
    /reset
    ...

Or something like that.  While other OSC implementations allowed for
the parsing of the addresses and assignment of the address hierarchy
to different parts of code.  Now, I'm not positive that my knowledge
of the OSC specification is on target, but here's what I found
frustrating to do in Chuck.

I have a message: "/control/birdnoise/freq" for instance.  So I took a
look at the example OSC receiver code, which is here:

http://chuck.cs.princeton.edu/doc/examples/osc/OSC_recv.ck

Here's the part of the code that i'm talking about:

// create an address in the receiver, store in new variable
recv.event( "/sndbuf/buf/rate, f" ) @=> OscEvent oe;

First, for some reason, chuck didn't care if i specified it like this either:

// create an address in the receiver, store in new variable
recv.event( "/sndbuf/buf/rate", f ) @=> OscEvent oe;        //notice
the difference in where i break the string.  what's the deal with this
method?

And then, also you can listen to two events at once, so if you wanted
to also send "/sndbuf/buf/gain" you'd have to set up a new shred...
but that also necessarily means a new receiver, a new port, and a new
event.  The sender will have to know that to send "/sndbuf/buf/gain,"
they have to send to a different destination.  So, what's the point in
the hierarchy, right?  Everything is flat and everything is it's own
net address.

Unless I'm wrong about OSC, this seems like a serious limitation.  I
feel like I should be able to structure my code such that it can route
"/sndbuf/buf/rate" messages to the part of code dealing with rate and
"/sndbuf/buf/gain" messages to the part of the code dealing with gain
*within a single shred.*  After all, that's where my SndBuf buf =>
dac; patch is.

The other thing is that, OSC events listening for two different
messages on the same port, will respond erroneously if the number and
types of data values match, meaning that the OSC "signature" in Chuck
has nothing to do with the address.  This also seems "wrong" to me.
I'm not sure if anyone else has encountered that.

Anyway, I'm done ranting for now.  I have to admit that I'm a bit
obsessed with OSC in general.

cheers,
mike

On Tue, Apr 22, 2008 at 6:26 AM, Kassen  wrote:
...
On 22/04/2008, mike clemow  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.

...
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.
_______________________________________________
 chuck-users mailing list
 chuck-users@lists.cs.princeton.edu
 https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- 
urls is coming...