[chuck-users] ChubbY (ChucK in Ruby)?
mcmahon at ibiblio.org
Wed Feb 11 17:17:42 EST 2009
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
> 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:
Will definitely go look at that. Thanks for the ideas.
--- Joe M.
More information about the chuck-users