[chuck-users] how is this "on the fly"?

[Kassen]

On 9/17/07, AlgoMantra <algomantra at gmail.com> wrote:
>
> (Kassen, I'm here - we had a very brief exchange about ChucK with
> toplappers)


Very good, for a moment I feared you had gone up the mountain and started
meditating until GlucK arrived!



usually
> by someone too good to be true like Kassen.


This online communications stuff is really great, nobody is ever confronted
with morning moods or remembers the time one climbed in through the window
while drunk and so on. :¬)



I want to know what people really
>  mean by OTF (on the fly) or by "livecoding" in Chuck.


Yes, very good, let's talk about this because you have a great point and
IMHO it needs more emphasis so that we could perhaps persuade Spencer to set
some time aside and help us because this would be a huge improvement to both
livecoding and rapid prototyping.



If you prepare your files and code in advance and then just chuck the
> shreds in and out of the VM, it really is a a bit like sequencing, rather
> than livecoding. And if I change the code in the file, save it, then the
> effects don't appear live, do they? I really don't see how i'm changing
> the code "while its running" here.


Yes, true. It's still better then sequencing waves because you can have
random or rule-based variations but still. Changing, then saving files won't
make them run, you need to replace them in the VM but to do that they indeed
need to be saved (or be inside of a(mini) Audicle window.)

So, you make a file called "mantra.ck" that does something marvellously
interesting.

>chuck --loop mantra.ck

Now it's running. So; you edit it to something yet better, then save it.
open a new terminal and go

>chuck = 1 mantra.ck

This will replace the first shred (being your original file) with the new
one. Presto.

This is cool and this is what people do when livecoding though in that case
the miniaudicle will make things a lot more convenient.

Now for the bad news; all variables that your file had and all arrays that
might by now be filled with data that determines what music is being
generated will be re-initialised. At least all other running shreds will be
unaffected and you can try to make the replacement at a musically sensible
moment but if your old code had just written a random yet nice melody that
you now wanted to add reverb to that melody will be gone.


A workaround would be to store all such data in static members of public
classes, those will survive until the end of the VM so those are dependable
but doing this leads to significant overhead in code which is one of the
last things you need when livecoding. I've been meaning to experiment with
this more and see how convenient I can make it for myself but it's still
ugly.

Now, ChucK does have a way to edit just parts of running code, it's part of
the functionality of chuck --shell but it's hard to use (meaning I didn't
get it to work) and almost completely un-documented (it was in some corner
of the wiki). The problem was that you had to navigate through the
name-space, like a directory structure, using the terminal, then type
exactly what you wanted to do.

What I would -perhaps naïvely- think would be *the* solution is having the
MiniAudicle provide a graphical front-end to this aspect of chuck --shell
with highlighting and hotkeys used to indicate what element in what scope we
are trying to edit and replace/add.

Last I heard on this was that Spencer (who manages the mini) seemed to find
the idea interesting but I gather Spencer's time is limited (which I stress
I have a lot of respect for) and I have to admit that this idea could fall
squarely in the "likely to explode if you sneeze" category. What's slightly
mysterious to me is that so far nobody else has been particularly vocal
about how useful this would be so I'm quite happy that you bring it up now.



> What a royal mess.


Let's not exaggerate, writing musical algorithms on stage is still exciting
and fun, even if modifications mean re-starting them but there is certainly
room for improvement.... That said; there is a lot of room for growth in a
lot of aspects of ChucK and so there are priorities.


Perhaps Ge, Graham and  Perry who have been livecoding in ChucK more then I
have and at a higher profile could  share some ideas about how they deal
with this? Perhaps I too am missing something fundamental.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070917/9b258fbe/attachment.htm