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

...

... 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.

This is exactly the conclusion I came to as well. The only problem is that I can't get over the strong timing thing. There isn't anything else like it. I'm using ChucK in places in my thesis project that are little scary. I tend to feel that if you're writing ChucK code that doesn't make sound, you're probably barking up the wrong tree, generally speaking.

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

This is fascinating, but I'm disappointed that so many of these things get developed for Max/MSP and not PD--especially since the code bases are so similar. One of the PD developers teaches at my school. I hope to pick his brain about porting these things over to PD someday. The chuck~ object that Brad Garton has written is another one that I'd love to have in PD. Re: V8, Parrot, etc., I think that these are great ideas. Makes me wish I was a better programmer... Hackishly yours, Mike On Wed, Feb 11, 2009 at 5:17 PM, Joe McMahon wrote:

On Wed, Feb 11, 2009 at 12:23 PM, Stephen Sinclair 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. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org