[chuck-users] chuck shell...

Andrew C. Smith acsmith at willamette.edu
Thu Sep 10 12:27:43 EDT 2009

>> Clearly, the shell is more customizable
> Wait, it is? What can be customised and how?

I just meant that it could be used with a variety of editors, where
the mini provides its own editor. I used to edit in TextEdit (before
mini CVS) and just drag-drop the files from Finder into the command
line to get the complete path. I guess this is sort of like the

I've used SC's jitlib, but I didn't think it had any sort of browser.
You still have to search for and open the files, then highlight the
selected parts and hit enter. I was thinking like Logic's sample
browser or media panel or something. See, this isn't really all that
applicable for livecoding, but for actually constructing a versatile
semi-improvised performance it would speed things up.

Random Fiddlings looks (maybe?) cool, although working from the ground
on a sort of parallel mini project rather than just adding an extra
window dialog to the mini. It's wouldn't be a matter of integrating
with ChucK itself, just a modification to the frontend of the mini.
Autocomplete is too confusing for me--just gets me off-track. I prefer
to keep my syntax/capitalization errors, thank you.

The master clock sounds cool--I'm going to have to get into static
public classes due to the last few discussions.


On Thu, Sep 10, 2009 at 12:08 PM, Kassen<signal.automatique at gmail.com> wrote:
> Andrew;
>> 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.
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

More information about the chuck-users mailing list