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

[Stephen Sinclair]

Sorry, dropping into the conversation a little late here.

On Tue, Feb 10, 2009 at 4:18 PM, mike clemow <gelfmuse at gmail.com> wrote:

> lacking.  To be precise, the first 5 minutes of Chuck are pure joy,
> but it becomes an uphill battle from there to do anything of
> significant complexity.

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.

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.

Generally I've been doing the "other side" of my applications in
Python, but any other language would do just fine as well.

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
this highly-researched area.  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.

1) Port the VM to LLVM.  Since ChucK is statically typed like C, it
would basically allow us to use ChucK to write code that executes as
fast as C.  This would truly allow writing UGens straight in ChucK
code for example, with little to no drawback as compared to
implementing UGens in C++.  Drawback is that adding new language
features would require implementing them basically from scratch.

2) Port the VM to JavaScript.  Several JS engines are now available
that provide exceptionally amazing JIT-based optimization.  The
browser wars are providing a great incentive for research here, and
there's no reason we can't piggy-back on it.  Using V8 or TraceMonkey,
you'd get pretty good speed, while at the same time opening up the
possibilities of adding dynamic features to the language.  You get
things like closures and memory management for free.  Big downside:
possibly lose real-time safety.

Ideas of using Ruby and Python are good too, but I think both of these
don't have the raw speed advantages of JS or the JVM for example, and
aren't likely to see it soon.

Here's a blog post I wrote a while ago about JS-ChucK:

http://www.music.mcgill.ca/~sinclair/content/blog/ideas_on_transforming_chuck_to_javascript

Of course, on the topic of this thread, there's the whole point of
whether it is really worth it to extend ChucK at all, or simply
implement its strong timing features in another language.  An
interesting question, but it would be a separate project after all, so
to me it's not something that is really on-topic for the ChucK
community.

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


Steve