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.