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

 

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. :¬)

 

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.

 

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.

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.