Hi Guys,
Sorry for the off topic,
but can anyone reccomend a usb/firewire/pcmi audio interface for a PC
laptop?
Ive been using onboard stuff bu in need a better latency for realtime i/o
ta
Tom
http://www.nullpointer.co.uk
http://www.r4nd.org
----- Original Message -----
From: "Ge Wang" <gewang_at_CS.Princeton.EDU>
To: <livecode_at_slab.org>
Sent: Friday, July 23, 2004 12:56 AM
Subject: Re: [livecode] chuck
> 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 Sun Aug 01 2004 - 20:48:22 BST