Maybe SC is better, but I'm on a PC running WinDohs so I never used SC.
However, I guess this is really a question of how much jitter occurs - if the jitter was low, and you had reasonably low latency, then you'd still get the benefits of synchronized shreds, right? I just imagined it would be intuitive to have a bunch of functions that dump parameters for graphical objects into PD, and run different calculations on the fly. Some things are definitely much quicker to code, than to figure out in dataflow, and calculating certain things in 3d are good examples.
I mean, if you don't like dataflow patches, I guess you might as well use ANY programming language, but starting and stopping shreds on the fly is key, and that's what ChucK lets you do. Each shred could control a different object or process in PD, and could send loads of data at any desired rate into PD. At least in my mind, it's seems pretty easy. And I think a lot of things in ChucK will become pretty mature, in the next year. Actually, I like ChucK better for audio than PD, I was thinking of doing ChucK + GEM for my more experimental / noise shows.
Also, I believe someday there is an intention that chuck could be used to livecode for video and audio, in the future.
~David
On Thu Jul 06, 2006 at 05:32:47PM -0500, David Powers wrote:
> How about using ChucK to send OSC messages to PDP?
wouldnt most of the benefits of chuck (eg the synchronous sample-accurate execution of multiple shreds) be lost when youre flattening the messages out to something and then sending over the network? i mean its not much of a language, other than something to talk to its v. cool VM. why not just use SClang then? i hear it has a nice OSC lib.
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list