[chuck-users] MAUI for PC/Linux

[mike clemow]

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 <signal.automatique at gmail.com> wrote:
> 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.
>
>
> _______________________________________________
>  chuck-users mailing list
>  chuck-users at lists.cs.princeton.edu
>  https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
urls is coming...