[chuck-users] chuck vs supercollider?

Stefan Blixt stefan.blixt at gmail.com
Fri Aug 10 05:27:16 EDT 2012


I really like how you can program tight sequencers that never fall out of
sync in an easy an clean way. E.g. you can spork two different shreds that
each contain a loop where they wait once for 100::ms. Even though they
don't necessarily know anything about each other, they will always say
tightly synchronized, beating once every 100 milliseconds.

I'm sure you can accomplish this in other languages as well, but it's so
easy and easily read in ChucK.

/Stefan

On Fri, Aug 10, 2012 at 4:11 AM, David Ogborn <ogbornd at mcmaster.ca> wrote:

> Great answer - I'm going to save it and quote it whenever needed! :)
>
> Yours truly,
> David
>
> On 2012-08-09, at 10:03 PM, Kassen wrote:
>
> Hey Ronni,
>
> Hi, i was wondering, is there any benefit in  chuck approach  having
>
> one sample block size comparing with supercollider ?
>
>
> Yes, there is, we're not totally silly :-)
>
> Not using block processing has two big advantages for us. The biggest
> one is that that way you can use a feedback loop over a series of
> UGens and not have the block-size added as a delay to the loop. This
> becomes quite important in things like feedback in FM modulation for
> noise, physical modelling, tuned delays, etc, etc.
>
> The other is that we can easily modulate UGens with a precision down
> to the sample. Theoretically you could do that with block processing
> as well, but then it becomes a lot more complicated.
>
> are there things that can be done with chuck that cannot be done with sc3?
>
>
> To be honest; not really. All of this can be done in SC as well by
> creating a new UGens plugin for SC. All of the things SC can do we can
> do too... but of course some things will be easier, even much easier
> in one of the two. A good example of what ChucK is good at is this
> kind of thing; doing DSP in the language itself using feedback over
> UGens or by writing a function that does the processing and makes a
> "Step" UGen output those values as a audio stream. Other
> timing-related things ChucK also tends to be strong at, for example
> execution order is  always deterministic and nearly always very
> obviously clear, even with parallel processes. The integration of the
> analysis/resynthesis stuff with the timing thing seems unique to me,
> not sure how SC handles that in the details. I think it is nice how
> ChucK abstracts stuff like HID interfaces in the same way across OS's,
> I don't think SC does that (yet). There are other cases, I'm sure, you
> get the picture.
>
> Generally, unless you really need some specific feature in either, I'd
> say you should pick the one that has a syntax that makes you feel at
> home, everything else is just icing. SC's larger library of UGens or
> ChucK's timing accuracy will be little consolation if you end up not
> happy coding in it. If you're not sure which one I suggest that you
> spend a weekend with both. Expressive code makes for expressive
> music*.
>
> Yours,
> Kas.
>
> *not a actual scientific proven fact (yet?).
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>
>
> --------------------------------------------------------------------------------
> Dr. David Ogborn, <ogbornd at mcmaster.ca>
> Communication Studies & Multimedia, McMaster University
> Director, Cybernetic Orchestra & ESP Studio
>
> http://soundcloud.com/cyberneticorchestra
> http://esp.mcmaster.ca
> http://davidogborn.net
> http://twitter.com/ogbornd
> 1-905-525-9140 ext 27603
>
>
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20120810/dfe18339/attachment.htm>


More information about the chuck-users mailing list