Re: [chuck-users] chuck vs supercollider?
OK, I'll chime in here. Both languages are Turing complete, so anything logic- wise can be done in either. The ability to compute control, physical simulations, and/or samples at any time resolution, even sub sample, is super powerful from an experimental and philosophical perspective. Single sample computation does allow for feedback, and even parallel patches, that are not possible or indeterminant with vectorized (block), computation. And even delay-free loops (needed for some algorithms, like physical simulations) can be more accurately approximated with sub-sample computation. Efficiency is an issue. A more appropriate Ge quote, which came from Paul Lansky, is "never optimize." Ge set out to make ChucK unlike any other language, and efficiency was not a priority. Roger Dannenberg even was swayed, stating that ChucK isn't that inefficient, especially given the power it gives the programmer. One other really nice ChucK tool is the MiniAudicle. Some don't care for it, or don't see the point, but having a smart editor, monitor, shred manager, etc is reall powerful for development and real-time live coding. I don't know if SC has such a real-time IDE. Prc Sent from my iPad :-) On Aug 10, 2012, at 9:00 AM, chuck-users-request@lists.cs.princeton.edu wrote:
Send chuck-users mailing list submissions to chuck-users@lists.cs.princeton.edu
To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.princeton.edu/mailman/listinfo/chuck-users or, via email, send a message with subject or body 'help' to chuck-users-request@lists.cs.princeton.edu
You can reach the person managing the list at chuck-users-owner@lists.cs.princeton.edu
When replying, please edit your Subject line so it is more specific than "Re: Contents of chuck-users digest..."
Today's Topics:
1. Re: chuck vs supercollider? (Kassen) 2. Re: chuck vs supercollider? (Michael Clemow)
----------------------------------------------------------------------
Message: 1 Date: Fri, 10 Aug 2012 13:33:30 +0200 From: Kassen
To: ChucK Users Mailing List Subject: Re: [chuck-users] chuck vs supercollider? Message-ID: Content-Type: text/plain; charset=UTF-8 On 10 August 2012 04:11, David Ogborn
wrote: Great answer - I'm going to save it and quote it whenever needed! :)
Thanks Dan & David,
Credit where it's due; this was more or less the conclusion of the debates I had with SC expert James 'DewdropWorld' Harkins. We found that the differences we and others with some expertise noted didn't really matter at all for those picking up either language. New users (who adopt either) simply seem to find that one is quite straightforward and the other doesn't make a lot of sense. We didn't notice any obvious structure or pattern in that. It's a interesting phenomenon.
It'd be nice to try to figure out whether things like lessons or online tutorials, examples or more experienced friends influence this. What I can tell though is that passionate online debates don't seem to have any effect on this at all; they can take away misconceptions about what is possible but not change what people find fun or easy.
Yours, Kas.
------------------------------
Message: 2 Date: Fri, 10 Aug 2012 10:19:03 -0400 From: Michael Clemow
To: ChucK Users Mailing List Subject: Re: [chuck-users] chuck vs supercollider? Message-ID: <510685F450A1428CB304BD1B4460CF4F@gmail.com> Content-Type: text/plain; charset="utf-8" Hey All,
FWIW, I often take advantage of both systems in a piece. Sometimes I'll create a bunch of synths in SC that can be triggered by OSC and use Chuck as a score language. If I'm doing a lot of string/data processing, then I'll use Python to trigger them. But that's part of my practice, since many of my pieces involve interesting bits of hardware, I have to utilize OSCulator, SC, Chuck, and Puredata all for one piece of music.
So, for the sake of completeness, I'll back the notion that you don't actually have to make an exclusive choice between environments. ;) The right tool for the job, right?
-Mike
-- Michael Clemow
http://michaelclemow.com http://abattoirprojects.com
On Friday, August 10, 2012 at 7:33 AM, Kassen wrote:
On 10 August 2012 04:11, David Ogborn
wrote: Great answer - I'm going to save it and quote it whenever needed! :)
Thanks Dan & David,
Credit where it's due; this was more or less the conclusion of the debates I had with SC expert James 'DewdropWorld' Harkins. We found that the differences we and others with some expertise noted didn't really matter at all for those picking up either language. New users (who adopt either) simply seem to find that one is quite straightforward and the other doesn't make a lot of sense. We didn't notice any obvious structure or pattern in that. It's a interesting phenomenon.
It'd be nice to try to figure out whether things like lessons or online tutorials, examples or more experienced friends influence this. What I can tell though is that passionate online debates don't seem to have any effect on this at all; they can take away misconceptions about what is possible but not change what people find fun or easy.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu (mailto:chuck-users@lists.cs.princeton.edu) https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Perry;
Roger Dannenberg even was swayed, stating that ChucK isn't that inefficient, especially given the power it gives the programmer.
Yes, true. I found performance is quite comparable to other synths that don't use block-processing. There are some, even in conventional plugin formats. Or you can find it when a program emulates a synth that uses RISC cpu. None of those -that I saw- will let you get as detailed about your own ways of sound generation as ChucK, especially not without loading external pre-prepared objects. Philosophically speaking I'd also say that if you can head towards your goal in a more straightforward way you are likely to need less parts stacked on top of each other. That said, I'm also excited about the idea of conditionally using block processing where we can. That would be a new perspective on it all. I don't think it's been done before and I'd like to see this happen or see where the issues are. Yours, Kas.
On 08/12/2012 11:52 AM, Kassen wrote:
... I'm also excited about the idea of conditionally using block processing where we can. That would be a new perspective on it all. I don't think it's been done before and I'd like to see this happen or see where the issues are.
A killer development I'd love to see would be to be able to transparently use the many cores now available in current processors... Easy, right? :-) -- Fernando
participants (3)
-
Fernando Lopez-Lezcano
-
Kassen
-
Perry Cook