Hi Tom et al!
On Jul 22, 2004, at 4:50 AM, <tom_at_nullpointer.co.uk> wrote:
> I've just been lookinjg at the docs for chuck, seems like a good idea.
> Seems a bit like sc server?
At a high level, some stuff (like the listener/client setup) is like SC
Server.
the language and programming model is quite different, with the timing
model and the precise support for concurrency (both really work
together)
ChucK, in some sense, is more like a poor-man's Max, where you can
connect ugen's quickly. Where it differs from Max/SC and many other
languages is that the control for the ugen's can be completely separated
from the patching itself, and can be exerted at arbitrary time
granularities.
The concurrency is very useful here to organize everything according
to the needs of the program.
> I'm interested in the system but I'm also intereseted in the
> einvironment,
We totally agree on this. both the language(s) and environment(s) are
crucial pieces to effective live coding.
> In chuck I can see it would be beneficial to have the ability to run
> multiple windows holding code fragments that can be cut/paste
> and 'shredded' etc. allowing a multitasking fluidity to the
> environment.
Definitely. The audicle will strive to do this, but the exact semantics
is still in the air. Currently, the audicle is designed to have a flow
graph of windows denoting parent child shred relationships and
timing. But this is still not well-defined. Hopefully we can all work
on making this aspect fluid, like playing a good video game or even
better, a musical instrument. Good thoughts Tom, let's keep going
on this. And what do others think about this?
> It would be nice to allow users to define chuck files as 3rd
> party generators etc
> (as in max/pd as both compiled code and as language built
> subroutines), and
> have these to
> be easily accessible in the performance environment.
Yeah! I think because ChucK has a well-defined set of
byte-code instructions and sample-synchronous timing, we can
do a compiled "plug-in" (an internal, ha) natively in ChucK. This
feature doesn't exist yet. Currently, it IS possible to import
ugen's and generic libraries from c++ (not documented yet).
> This may well be a case of adding extra shells to the
> system but it could radically effect the usability/performance flow etc
An interesting question with this is how to organize the predefined
stuff both as the performer and also make them available for the
audience,
to perhaps hint and preview the audience for a taste of things to come.
I think we all may be experienced difficulty convey some ideas/algorithm
even the screen is projected. This is really an interesting HCI-esque
research problem - how to effectively convey the process visually to the
audience?
> mmmmmmmmm i think i've just realised that you have a project 'audicle'
> that
> is
> looking at this sort of stuff hmmmmm... ah well i've written this so
> I'm
> still gonna send it ;)
I am very glad you did. In addition to new ideas, it shows that we
have been thinking in similar directions for the things to
try/research next! ChucK is very young (currently implementing
arrays, ha), and it really isn't based on any one language.
we are free to move it in new and better directions (certainly from
its current rather fledgling state). Come and join the
discussion list - currently 70+ souls are subscribed.
general list:
https://lists.cs.princeton.edu/mailman/listinfo/chuck
developer:
https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
Best,
Ge!
Received on Thu Jul 22 2004 - 23:57:22 BST