[chuck-users] ChubbY (ChucK in Ruby)?

[Joe McMahon]

On Wed, Feb 11, 2009 at 12:23 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> Sorry, dropping into the conversation a little late here.
And I'll be even later!

> This is why I tend to treat ChucK as a synthesizer rather than as a
> programming language.  For me, I don't feel like ChucK was created to
> build applications out of it, or read and write data files, or display
> a GUI, etc.  To me, it's for producing sound.  Since it can be
> controlled remotely by OSC, anything else can be used to do the actual
> application logic.  In my usage, ChucK is used in as stupid a way as
> possible, I give it as little information as I can to get the sound
> and timing I require, with _everything_ else being done elsewhere.
Yeah - the application I did to play the Long Now chimes had all of
the logic in Applescript, and the sound production in ChucK. I daresay
that if I was doing it again now, I'd add a shred to listen for a
"please stop now" message.

> Taken this way, I find ChucK to be pretty much adequate for what I
> want.  Sometimes I need to implement data structures that have a
> certain complexity, but I really do try to keep this to the absolute
> minimum.  Definitely sometimes I feel that it could be greatly
> improved by the use of closures or a better dependency system.  But I
> don't really let this hold me back, because most use cases that I have
> don't really need this kind of flexibility, because I design things to
> be as stupid as possible.  (i.e., retain only the information needed
> to play the right sound at the right time.)  Certainly there are cases
> where this approach isn't adequate, but personally I find it just
> fine.

> To me, the real contribution of ChucK is definitely not the language
> design.  It is basically just C after all, with a few extra goodies.
> The real innovation in ChucK, as we all know, is the idea of being
> oriented around "strong timing".  So, on the one hand, there's no
> reason these ideas can't be present in other languages, and on the
> other hand, there's no reason ChucK itself can't be improved to
> provide dynamic features.
>
> One of the biggest difficulties with extending ChucK is dealing with
> the VM.  It's hard enough to port it to 64-bit, let alone implementing
> new features.  Basically, the ChucK VM has a certain proof-of-concept
> feel about it when you look under the hood.  Important for a thesis of
> course, but perhaps it might be time to think about replacing it with
> something where we can really leverage other people's good work in
> I think the right approach from here
> would be to just replace the VM completely, and using a different VM
> to execute ChucK code.  I've been playing around with two ideas, and
> can't seem to decide which one is better.
This is a darn good idea.

I wonder if the current Perl6 runtime (Parrot) would be a good target.
It's already set up to handle stuff for very dynamic languages, and
it's pretty fast as well.

> One thing to check out on this topic however is Vessel, a ChucK~-like
> thingy running on top of Lua:
>
> http://www.mat.ucsb.edu/~wakefield/lua~/lua~.htm
Will definitely go look at that. Thanks for the ideas.

 --- Joe M.