Hey, so how can I upgrade my Mini to the CVS version, with all the file IO capabilities? Or, even 1.2.1.2? I successfully compiled the CVS command line version, but I've never compiled the Mini. I just found myself liking the pretty colored text. Andrew On Wed, Sep 9, 2009 at 1:24 PM, Kassen wrote:

Hey, Kurt.

I think the shell has been close to abandoned, which is a shame as there were some really good ideas planned for it. Right now the shell offers little over a plain commandline; you can enter code but if you make a single typo (and who doesn't?) you need to start all over again as there is no buffer for commands. There were plans for a way to navigate the scope of running code from the shell (to update it) but those never materialised. I'm still a bit sad about that as those plans were amongst the most exciting plans for ChucK ever, IMHO.

I think the Mini mostly replaced it; it does all that the shell does and more though of course it does need to be used with a Gui; that might be a downside to some.

Personally I tried to use the shell for a while but I found it a bit clumsy so I'm curious why and how you use it.

Yours, Kas.

2009/9/9 kurt :

...

Hello all- First of all, I love ChucK shell!!! But I wondered if there are any plans for ChucK shell improvements in the works?  It would be nice to have some normal shell type stuff... Tab-completion, command line history (it would be sweet to 'up-arrow', then 'enter key' to keep adding the same shred), the ability to change directories (or at least the ../../ syntax would be nice, cause, as it stands, one has to use absolute path names for files not in the working directory), and to move the cursor with the arrow keys to edit commands.  Also it might be cool if when querying active shreds (the '^' command)  it would be cool if the child shreds were indented a level from the parent shreds.  It would be nice if you could add and remove shreds by name (eg. all shreds named "foo.ck" could be removed by some command like '-! foo", i dunno?).  I feel kinda lame asking about this stuff, but I figured if some awesome ChucK dev out there was thinking about spiffying up the shell for the next ChucK release they might be stoked to know someone out there was exited about potential improvements. thanks. K. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Andrew;

Um, I didn't actually expect it to be quite that easy. I just copied the 1.2.1.2 CVS v2 source into the miniAudicle directory and recompiled, then ran the "write.ck" example and it worked.

:-) Yeah, i was happy when I first did this. as far as I have been able to find it's as stable as anything ChucK related is ever going to be. CVS may of course have additional bugs. It shines on Spencer that it's so modular and clean in design that this simply works. Long live Open Source and modular design!

Now, let me ask, why isn't there a version of the mini with 1.2.1.2 available for download?

I suggested that; it would just be a simple compile for the commercial OS's and a quick edit for Linux. Anyone could do it in half a hour or so. So far there have been no responses to that.

Or, at least on the wiki or something. This is great, like Christmas when something like this works.

It is, or a birthday. BTW, try highlighting some text in the mini and hitting ctrl+D, I don't think that's documented but it's cool. Kas.

Some of these steps may be optional but this way it works for me.

Right, I decided that looking up the Moog's sweep rate was optional and just skipped straight to the next drink. Anyway, being on OSX, I just compiled it without any external libraries and (after you mentioned the widgets) made sure to test the MAUI, and the gauge and everything works just fine. This inspires me to try (and fail) building my own ugen. I don't believe in D# minor--I wanted the mini to test my expanding/contracting microtonal scales.

BTW, try highlighting some text in the mini and hitting ctrl+D, I don't think that's documented but it's cool.

Oh cool, I made sure to highlight important text to get the full effect. brb pouring another drink. Andrew On Wed, Sep 9, 2009 at 2:07 PM, Kassen wrote:

Andrew;

...

Hey, so how can I upgrade my Mini to the CVS version, with all the file IO capabilities? Or, even 1.2.1.2? I successfully compiled the CVS command line version, but I've never compiled the Mini. I just found myself liking the pretty colored text.

Ok. i only did this on Ubuntu Linux. Other OS's may or may not present hurdles, particularly where newer and more strict versions of GCC are concerned. I did this with 1.2.1.2 but CVS will likely work as well.

Download the source of the ChucK version you want. *optionally edit it to have things like Tom's fix for CNoise and or other things you might like (CVS may have this already). Download the source of the latest Mini.

browse the mini source to find the chuck directory, I think it refers to chuck1.2.1.1. Delete all that's in that directory but leave the dir be. Dump your downloaded ChucK source in there, it should look a lot like it did before.

Compile the mini as per the documented instructions, you'll need some extra libraries over plain ChucK, especially that widgets thingy, but this is documented and none of it very exotic. This process will now compile the ChucK version we cunningly pretended is the one it knows as a part of it's compile. Ignore all other bits of the source. Pour yourself a drink while it compiles.

Start your new Mini and resolve to write a small canon for Wurley and Moog in d#minor to verify that it works. Pour another drink while you look in the manual for the exact name of Moog's sweep rate. (stuff happens) Look up to see the dawn, realising you just wrote another experimental gabber piece that you forgot to record but content with your new mini.

Some of these steps may be optional but this way it works for me. This won't fly for the full Audicle for reasons unknown.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hey Kassen-Thanks for the quick reply ...

I think the shell has been close to abandoned,

That is a bummer. I kinda had a feeling that might be the case. I guess that is why I inquired.

I think the Mini mostly replaced it; it does all that the shell does and more though of course it does need to be used with a Gui; that might be a downside to some.

I like the Mini but I really like Vim. That is really the only reason I use the shell.

Personally I tried to use the shell for a while but I found it a bit clumsy so I'm curious why and how you use it.

I mainly edit .ck files in Vim in one window and then run 'chuck --shell' in another window to add and remove shreds and occasionally call a method from a public class to change tempo or key globally. Nothing that couldn't be done in the Mini. Those abandoned shell plans you mention sound awesome. I hope someday (maybe with more and more people live coding) the shell becomes a priority again. Thanks. Later. K

Kurt & Kas, 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? Clearly, the shell is more customizable (and I used it before I upgraded mini to CVS v2) but the entire process of memorizing the file paths (even with ../../ syntax) seems like a huge waste of energy compared to the time it takes to find a file with cmd+o opening the mini. 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. 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. (mostly just daydreaming instead of working) Andrew On Thu, Sep 10, 2009 at 11:05 AM, Kassen wrote:

Kurt;

...

Those abandoned shell plans you mention sound awesome. I hope someday (maybe with more and more people live coding) the shell becomes a priority again.

I suspect that part of the issue is that many people who now start working/playing with chuck never saw a CLI before. For these people the mini will be a lot more easy to use than shell. If shell were to grow to "be all it could be" we'd have something like a miniture vi or EMACS on our hands. I'd love that, you would, probably a dozen or so other people would and I think many young students starting out with their first code and beeps would hide under the nearest couch.

I strongly suspect (but I have no proof) that most people will want icons, a mouse and so on, and really; the mini does work quite well.

What I would advocate for the future of interacting with running ChucK code would be having all of that controllable straight from the commandline, then make the mini use hooks to that (this is already what is going on and why we can update ChucK, recompile the mini, and expect it to work). From there on people could write extensions to editors like vi and EMACS or even borrow the Fluxus "scratchpad" (simple but it looks good...) and use what they like. I don't think that highlighting a certain block of text in the mini would need to be that different from navigating scope from the shell (as outlined in those rather old plans), the hard but there is making it work at all.

Unless I'm mistaken, the one way to get data into the shell (for example code) is to type it in there yourself. I don't think we can have other programs do this for us. To me that makes it a bit of a dead end. People like us will be so picky about what makes a good editor that even the few who would prefer this scenario wouldn't agree on it. Then again; I would actually like to be able to reconfigure parts of the mini using ChucK code and I do think that would be a nice idea so maybe I have no right to talk about what is and isn't sensible in this :-).

At least we have Spencer; all of Spencer's ideas on editing ChucK so far turned out to be good ones, I feel.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

...

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 database. 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. Andrew On Thu, Sep 10, 2009 at 12:08 PM, Kassen 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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Kurt;

For the most part it comes down to not having to use the mouse.  I can edit in Vim and use ChucK shell and play for hours without touching the mouse.  I am also used to vim commands and can edit much faster with them which makes a Huge difference in live coding.

The odd thing is that the Linux version of the mini does need the mouse. You can't ctrl+tab from buffer to buffer and selecting or creating a new buffer doesn't automatically move keyboard focus to it. On Windows these things do work. If it weren't for those things I don't think I'd need to use the mouse with it; I don't think i do under Windows.

Oh well.  I'm just going to stick with the command line version and hope someone realizes that the shell is where it is at.  If the capability to really live code in the shell (navigating namespaces and stuff beyond just adding/removing shreds etc.) grew, it would be incredible (fingers crossed).

Yes, indeed, but of course that involves more than just the interface. I heard gossip that that might be hard to add to ChucK, or at least harder than previously imagined. Kas.

2009/9/11 Scott Hewitt :

In terms of the mini interface I actually think it is very clean and easy to use which makes learning to use it and ChucK much easier in my opinion.

Well for myself, I just don't grok the mini at all. It seems to me that there really needs to be some kind of incremental (read shell-like command line) interface somewhere, so that I can change parameters on the fly. I'm sure that I just don't understand how y'all do it. But what I really want is a module where I can map my A4-size graphics tablet to different sound controls. I think it would be really cool to print out a sheet of paper describing my parametric layout and be able to use that for dynamic expression in high-level ChucKing. And no, just using the mouse HID isn't quite enough - I want the tablet to be like an instrument independent from what is happening on my monitor (hence the printout overlaid on the tablet). Any takers? david rush -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

David, You could try just making a single file with lots of Machine.add commands. I mean, it won't run automatically but it's way easier than typing in 20 individual files. Don't know about your tablet, and the HID thing isn't especially well-documented. The Mouse HID clearly won't work because it's build entirely on deltas, unlike the HID for SC or something. Just finished digging through the source, and looks like we have joystick, mouse, wiiremote, keyboard, and tiltsensor. I wonder how hard it would be to just make a tablet addition. Andrew On Fri, Sep 11, 2009 at 5:09 AM, David Rush wrote:

I thought I should add a bit of detail here. In order for any of my compositions to work I have a library of 20 ChucK source files which need to be loaded. As far as I can tell, the Mini just doesn't have a good way top do this. What am I missing?

2009/9/11 David Rush :

...

2009/9/11 Scott Hewitt :

...

In terms of the mini interface I actually think it is very clean and easy to use which makes learning to use it and ChucK much easier in my opinion.

Well for myself, I just don't grok the mini at all. It seems to me that there really needs to be some kind of incremental (read shell-like command line) interface somewhere, so that I can change parameters on the fly. I'm sure that I just don't understand how y'all do it.

But what I really want is a module where I can map my A4-size graphics tablet to different sound controls. I think it would be really cool to print out a sheet of paper describing my parametric layout and be able to use that for dynamic expression in high-level ChucKing. And no, just using the mouse HID isn't quite enough - I want the tablet to be like an instrument independent from what is happening on my monitor (hence the printout overlaid on the tablet).

Any takers?

david rush -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

-- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

It seems like changing parameters is possible through the mini rather than through the shell at all--you could use MAUI elements, at least. Another thing to try is using static classes and have some smaller .ck files that take arguments to change the static elements (therefore changing global frequencies, tempos, etc). That could be easily done via the shell or via the mini. I'm not sure why using the shell makes a huge difference, aside from avoiding the mouse. Did that make any sense? Words are tricky this morning. Andrew On Fri, Sep 11, 2009 at 10:56 AM, Kassen wrote:

David;

...

Well for myself, I just don't grok the mini at all. It seems to me that there really needs to be some kind of incremental (read shell-like command line) interface somewhere, so that I can change parameters on the fly. I'm sure that I just don't understand how y'all do it.

I'm not sure i understand the question. As far as i can see the mini does all that --shell does, just in a different way. could you perhaps try to re-word this because I'm quite intruiged by what you mean by "incremental interface" here.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hey, I just found this: http://wiki.cs.princeton.edu/index.php/ChucK/Dev/Shell/doc#Command_Summary I don't know if it had ever been discussed (documented? ha!), but check out "Inline Coding." With a solid pre-made library of static class values that could be shared globally this could make for actual livecoding. It still doesn't help with your want for VIM, but it would be even more badass to just livecode with a huge terminal window and nothing else. The audience doesn't have to know that the classes you're calling are homemade, nor will they care, unless they're total nerds, which most of them and us probably are. It's like when Thurston Moore comes on stage with a power drill to play a guitar solo--we don't think, "Man, he should have built that power drill ON STAGE from scratch," we think, "Rad." Andrew On Fri, Sep 11, 2009 at 11:23 AM, Kassen wrote:

Andrew;

...

I'm not sure why using the shell makes a huge difference, aside from avoiding the mouse.

I'd like to make a distinction here, before the poor mice and touchpads all get put against the wall; I think the ideal editor wouldn't *need* the use of a mouse, this is distinct from offering support for it. Nearly all good code editors these days can make use of the mouse if we'd like but don't need it if we don't want to.

Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users