[chuck-users] chuck shell...

Kassen signal.automatique at gmail.com
Thu Sep 10 12:08:07 EDT 2009


> What exactly is the issue with the shell vs. the mini? I see that
> using Vim could make a difference, but what advantages does Vim have
> that the mini doesn't provide?

Well, vim is a mature editor while the mini is still rather
rudimentary. I never used vi myself but I imagine it at least has
things like search&replace, auto completion, custom highlighting,
probably macros, "move this line/block up/down" etc, etc, etc. Those
are big advantages. I can see why you would want to use that. Of
course another big thing is that somebody might simply be used to a
certain editor and prefer it because of that.

> Clearly, the shell is more customizable

Wait, it is? What can be customised and how?

> I, at least, can get along with cmd + to add shreds--the one thing
> that would seem to just decimate this (in terms to maximum usability
> livecoding grandeur) would be a file browser/code library for the mini
> (possibly stored in XML format, like iTunes Library). This way, it
> would be just a matter of tagging your code files (with tags relevant
> to style/interface/content/public classes) and sporking them from a
> browser.

That sounds close to this; http://randomfiddlings.blogspot.com/
Sadly that one is Windows only and won't work on my XP install for
reasons unknown. I send a comment documenting the error to this blog
but it seems to have gotten lost.

> Um, probably lots of work, and I can't code without =>, but
> for anyone wanting a fun activity a code library would be one more
> unique aspect to livecoding with ChucK that couldn't be found in SC.

Well, SC does have jitlib; http://swiki.hfbk-hamburg.de:8888/MusicTechnology/566
The main advantage to ChucK over SC is that we can have DSP integrated
with the musical structures in the same syntax and file; this can be
interesting in livecoding as well but for convenience in updating
running code SC is -right now- quite far ahead of us, I think.

I have been working on a set of livecoding tools for ChucK.
Particularly a internal clock that all shreds can be synced to. This
is distinct from using "now % T" in that a change to the clock's bpm
will make all synced shreds change tempo without a need to update
them. I'm still refining that. I also want to review my "busses" idea
and see how that works out in practice and I'm thinking about a bank
of static, public LiSa's. LiSa is a fairly unique case here because as
a UGen she can do quite a bit of stuff on her own without the need for
constant commands from code but updating the code containing the LiSa
will flush the memory, memory that might contain interesting sounds
that might will in themselves be the inspiration for a update in the
way we want them played back.

As I see it the big issue with livecoding in ChucK is losing things
like those recordings and the counter of the clock when we update code
so that's what I'm trying to get around.

Aside from these extensions to ChucK's functionality at the start of
the set I don't actually really load any code during livecoding. The
only files I load tend to be drum hits in wave format. I just spend
some time re-naming quite a few classic drum computer samples and
storing them in a convenient place for quicker access.


More information about the chuck-users mailing list