well put!!! On Aug 9, 2012, at 10:03 PM, Kassen wrote:

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*.

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 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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------------------------------------------------------------------------- Dr. David Ogborn, 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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

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

Hey ! and where can i find examples in chuck of this one sample feedback stuff ? I would like to give it a try to these kind of things in chuck and then compare it with supercollider. any idea? cheers! R. 2012/8/10 Kassen :

Michael;

...

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?

Absolutely, I do that too.

I also went through a phase, right after we got support for HID joysticks, that I did basically everything in ChucK. I had other phases like that with other systems. It's perhaps not very practical, but it does help to internalise the way of thinking that works with a system. To me this is comparable to how travelling to a country and speaking the language full-time for a while will teach you the language like no other method will.

Of course that's a way of learning that suits a certain temperament, I'm hesitant to recommend it outright but it's a option.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

thank you, i will experiment and ill let you know. cheers R. 2012/8/11 Kassen :

On 11 August 2012 17:55, ronni montoya wrote:

...

Hey ! and where can i find examples in chuck of this one sample feedback stuff ? I would like to give it a try to these kind of things in chuck and then compare it with supercollider.

I couldn't remember whether we had one so I made you a simple example. Here we have a system that uses feedback over a pitch-shifter and a lowpass filter. Not the best example in the world, I'm sure, but I made it rather quickly. Because of the feedback, porting this to something like SC should sound different as a extra delay is introduced in the loop.

SinOsc s => Envelope e => PitShift p => LPF f => dac; f => Gain feedback => p;

200 => s.freq; .5::second => e.duration;

1.2 => p.shift; 8000 => f.freq; .99 => feedback.gain;

.2 => dac.gain;

while(true) { 1 => e.value; 0 => e.target; second => now; }

As a bonus example, consider this;

Step s => dac;

while (true) { 100 * (now / samp) => Math.sin => s.next; samp => now; }

Here we imagine that we don't have a SinOsc yet would like to hear a sine. Of course we do have a SinOSc and this only gets really interesting if you substitute my boring function with your own, which I suggest you try.

Do mind your ears, speakers and neighbours, because this kind of experiment can and will potentially blow up.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi, Is this way of making sounds very expensive in cpu terms? :O I was wondering if this type of making sounds can be cathegorized as "non standard synthesis"? In sc3 i been experimenting with something similar but instead of defining the sample values each sample, the approach is to generate waveform segments, so you dont need to specify the values for each sample, you just define the length of your segment and the amplitude value. Do you think defining each sample value instead of waveform segments gives more posibilities? or new posibilities in sound construction? Can the brain feel changes in segment less than 64 samples? i been experimenting in the afternoon and i make this code, theres somethings i still dont understand from chuck logic, for example if i uncomment this line in the code " // v * Math.sin(k) => k;" why do i get so dramatic changes? I was not expecting to have any change because that line of code is going to variable " k" and variable "k" is not being used in "v => s.next; " Can anybody explain me whats happening? thanks! R. Step s => dac; // modulator SinOsc m => blackhole; 0.15 => m.freq; SinOsc t => blackhole; 0.015 => t.freq; 6 => float v; 6 => float k; fun void sample_manipulation( ) { 0.1 + k => k; 220 * (now/ samp) => Math.sin => v; if (v > 0.9) { -0.2 * 10 * m.last() => v; } if (v == 0.2) { -0.2 * 10 * t.last() => v; } if (v < 0.2) { v * Math.sin(k) => v; // v * Math.sin(k) => k; } v * ( v * 100 ) + m.last() * Math.sin( m.last() ) => v; } while (true) { sample_manipulation ( ) ; v => s.next; 1::samp => now; } 2012/8/12 Kassen :

On 11 August 2012 21:43, ronni montoya wrote:

...

thank you, i will experiment and ill let you know.

Great!

If you'd have the time I'd also be curious to hear how you came up with the question. Was this simply a matter of seeing that ChucK uses a process with some CPU penalty and being interested in what this cost was buying? I've seen the reverse happen; people trying to use feedback in Max/Msp or SC and noticing that they weren't getting what they expected and wondered why, but you are going the other way around. That's interesting.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 12 August 2012 10:28, Atte André Jensen wrote:

I seem to remember Ge saying something like "first we make it work, *then* we make it fast", however development of chuck stopped before the last part was started :-(

I don't think it "stopped" as such, there has been some activity, for example the "Chugins" that we know are in the pipeline. Because of that I'd place the focus on a lack of communication, but I can see where you are coming from :-/. Making stuff "fast" while keeping all of the benefits we talked about above may not be that simple, even. Particularly not now that "fast" has come to mean "using multi-threading". Then again; that might be good. That makes it a interesting problem to work on (good for programmers) and I'd say there would be a paper or two in a solution (good for researchers). For less structural issues I'd just like to refer back to my notes on a distributed model as a way of taking away some of that dev-time bottleneck. I said enough about that, there's a line between friendly advice at times and non-stop whining :-) Yours, Kas.

On 12 August 2012 16:33, David Ogborn wrote:

A quick and fun way to work with Chuck in a distributed model is to form a laptop orchestra!

Sorry, David, it appears that I was unclear. I was referring to working *on* ChucK. not *with* it. Of course more people will mean more fun and indeed likely less work per CPU. Yours, Kas.