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

[mike clemow]

>> ... 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 <mcmahon at ibiblio.org> wrote:
> 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.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



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