ChucK-plugin-for-ST3
ChucK-plugin-for-ST3 copied to clipboard
tildebyte
Tracker for Live Coding feature
zeffii says: Finally, I can run Chuck from shell and add + remove shreds. It was a "privileges" problem. Need to have "run as administrator" ticked in the properties of the .exe. What a drag. Anyway. It's time to decide how we want this to work.
- do we want to be able to select something like: (any working code within curly braces will act as a closure)
{
SinOsc s => dac;
3::second => now;
}
and send it as a shred?
- where in the program does one replace / remove a shred? Personally I think adding the REPL to this equation adds more complexity than needed. How about a user defined command-line anywhere in the text area.. For example:
I might have a line , and at the end i could write // %> + moo.ck to add moo.ck from the same directory as the current file. The same would work for:
removing shreds // %> - 1
replacing shreds // %> = foo.ck
The // would only serve to not invalidate the code if you happen to be adding the current file as a shred. The choice to add %> instead of > is arbitrary and could be user definable.
- Starting a shell might be as easy as
// --shellor make that also user definable..
Tildebyte says: Do you have something you can commit, so I can play around with it?
On #1, I think yes, definitely. For one thing, there're very nice key-combos extant in ST to easily select blocks like that.
On #2... Hmm... I like the // %> - 1 type of idea. One issue I see right away (particularly with that command, i.e. remove shred) is that one has to have access to the list of current shreds in order to be able to manage them. There is a "status" command (or something like that) which will list the active shreds, but for short-running shreds, by the time one runs that and gets the results, it may be too late.
I guess what I'm trying to say is that we need to think about what kind of data we want to display from chuck, and where it should go, and in what time frame (I'm thinking of the mA as the example here, with its VM view).
I like the idea of #3 as well.
zeffii says: should be able to see responses in the chuck shell
status
chuck %>
[chuck](VM): status (now == 0h53m42s, 142107136.0 samps) ...
[shred id]: 1
[source]: Mooo2.ck
[spork time]: 35.97s ago
Preliminary code, this takes sublime out of the equation for now... i like to not have to deal with that yet. This way I will get more familiar with starting one thread... letting time pass and send terminal commands to that thread again. Not quite there yet with the threading.
https://gist.github.com/zeffii/7606278
As i see it these are the shell commands that need to be parsed. I'm inclined to pass console comments unfiltered to the shell, (ie minimal sanity check, beyond is the string formatted correctly..) chuck has its own input checking.
// chuck --shell : will start ChucK in --shell mode (server). using a new thread.
// %> -k : will kill ChucK server thread. (no space between -k)
// %> + this: add shred (current open file), "this" will be reserved
// %> =/- this: replace/remove shred (current open file)
// %> = x.ck: replace shred named x
// %> - x.ck : remove shred named x
// %> = number(s) : replace shred(s) by id, separated by spaces
// %> - number(s) : remove shred(s) by id, separated by spaces
// %> -all : remove all shreds. (no space between -all)
// %> status: will print the status to the python console.
A key combo : will add selection as shred (sends everything enclosed in { } as an 'on the fly' shred)
I'll be starting A ChucK.py from scratch, there will be a main comment console parser which will control threading. It doesn't make much sense to me to have that menu there, other than perhaps if we can use it control the verbosity level of the chuck output.
don't think i'm very far off now... // kill does work tho
https://gist.github.com/zeffii/7651707
closer...but troubles communicating with thread: https://gist.github.com/zeffii/7656011