electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
Live streaming at radio.electro-music.com

  host / artist show at your time
<on air> Jez Adventures in Sound
Please visit the chat
 Forum index » DIY Hardware and Software » ChucK programming language
ChucK, SC, thinking styles?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [23 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Wed Jan 30, 2008 8:20 pm    Post subject: ChucK, SC, thinking styles?
Subject description: Academic question for curiosity (hope it won't kill the cat)
Reply with quote  Mark this post and the followings unread

At the risk of starting a religious war (and who needs another one of those in this world?)... this comment in the SuperCollider section intrigued me.

djdaphalgan wrote:
(I'm currently playing with Chuck, but Chuck has no GUI elements on Windows. That's why I also want to test Supercollider, but Supercollider seams not so intuitive as Chuck for me)


... which struck me funny because SuperCollider, especially sc3, is (to me) really intuitive to work with while I find ChucK (personally) a bit confusing.

Now, I don't want to get into a "which is better" flame war. I think the more tools that exist, supporting different thinking styles and different application territories, the better. I'm just interested in the ways different people think about audio programming, which makes one environment really attractive to one person but less appealing to another.

(We could even bring Max/MSP into the discussion, but I suspect its popularity has less to do with its innate strengths and more to do with the fact that people can convince themselves that they're "not really programming" as long as they're dragging pretty things around in a graphic window... when in fact it really is programming!)

For me, it's not just ChucK... sc3 fits me like a glove. sc2 is (was) more like ChucK in that the virtual machine and audio rendering run together in the same app and are closely intertwined... which in sc2 made me wonder how to handle adding new elements on the fly, without stopping the global Synth object. There were ways to do it in sc2, but fortunately I moved to sc3 within a couple of months after starting with sc and found that the whole architecture of sc3 makes it dirt-simple to add things and take them away at will. (Which ChucK handles by sporking, but I don't have a gut feeling of how lightweight a shred is. In sc, a coroutine scheduled on a clock is fairly light, and a new synth node on the audio server is featherweight -- you can create and destroy thousands of them per minute with no ill effects.)

So I'm curious - how do you work practically with ChucK? What kinds of thought processes are helpful? How does ChucK think like you do (or you think like ChucK)? Because, in a real way, sc3 thinks like I do (or at least, I recognized in sc3 immediately that it was more conducive to what I wanted to do than sc2).

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Jan 30, 2008 10:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ooh! Challenging topic. I like it.

As a gesture of good-will against the inevitable differences in taste; I have a big poster above my bed with SC code on it (it advertises a live-coding gathering), I don't dislike SC in the slightest, in fact I recommend it to people at times.

I think you point out some very good and very true issues; SC is indeed very lean and it's way of dealing with code replacement seems excellent (for what I understand of it), in fact those aspects have at times made me wonder whether I should learn SC next to ChucK, especially updating of running code, trying that in Fluxus was like a "free first hit" of a addictive drug, I'm not sure how like or unlike this facility in SC is to Fluxus.

However, I think djdaphalgan was talking purely about the syntax, not the more technical sides to the languages. Those are very important and interesting, arguably more so then something like syntax but syntax makes up the "first impression" and first impressions are important.

Before I starting "going steady" with ChucK I "met up" with SC a few times, trying SC was a big incentive to install Linux, I think, and I wasn't aware of ChucK yet. here the syntax was a big issue to me. No matter how many times people tell me it's very simple; I simply don't get it. Let me quote a semi random bit of SC code from mr.Cottle's e-book;

Code:
(
a = Array.fill(100, {0}); //fill an array with 0s
1000.do( //do 1000 iterations
   {
       b = (100.rand + 100.rand)/2.div(1);
       a.put(b, a.at(b) + 1);
   }
);
a.plot; //plot the results.
)


I'm sorry but I just don't get it. To me this looks like "do" is a property of "1000" instead of the thousand being a parameter of "do", then we open two different kinds of brackets (and close them together as well??) etc. It looks almost as alien to me as Perl and most Perl to me is indistinguishable from purely random characters.

Another issue I had was with the way SinOsc (as well as other Ugens but I started at the beginning) is controlled where all of the parameters go between some brackets and their order determines what number affects what parameter. I'm very bad at that stuff (I always disliked this about Csound as well), it may be short and efficient but I tend to forget these orders and the meaning of the numbers. This introductory example is a good example of this phenomenon;
Code:

\\ spawning time
\\ try changing the envelope durations to be a lot longer than spawning!
(
var freq, amp = 0.25, e;
 e = Env.new([0.001,1,0.3,0.8,0.001],[0.2,0.01,0.5,0.02],'exponential');
{ Spawn.ar({ SinOsc.ar(800.rand, 0, EnvGen.ar(e) ) }, 1, 2, 15) }.scope;

)


Maybe it's my dyslexia acting up again but I can't deal with structures like that, it's all just trains of numbers without context or unit or meaning to me, I'd have to count them out to figure out their meaning,

Likely these matters are just a phase one has to go through, you probably hear the sound mentally as soon as you see trivial examples like that.

What happened for me in the meantime though was that this phase for ChucK was very, very brief for me. Back then there was no manual to get confused by, just the examples so I started editing and remixing the examples and I was having fun right away. Ok, that's not true. I started remixing, ran my new code and it made a terrible noise as it crashed (this was when Dracula was new). I first had to realise that it was quite likely that my own ideas about ChucK syntax were often better then ChucK's, there was soon a fix and *then* I was having my fun :¬).

That's no real answer to your question, I realise. I can say the learning curve was very smooth and often unnoticeable for me but I couldn't tell you *why*. I suppose this is a question like *why* one gets along so well with one's best friend.... *why* is a joke funny?

I don't know... I think others had the same experience I had with ChucK except with SC. At times when I look at the code-replacement and some of the great Ugens I envy those people though I don't like block-processing at all and I never understood why separating the "language"and "server" would be a good idea. If I understand correctly what those do I think I'd always want them as close to each other as I could get them.

Maybe I should just spend two weeks of full work-days on learning SC once some of my current deadlines are gone to get a deeper insight into this matter. How much would two weeks of full-time SC learning get me?

About some of your other questions; how lightweight a shred is is a question like how lightweight a object is. A shred may not take any cpu time at all or it may make you put projects in the closet until TeraHz CPU's become affordable. You can start hundreds of thousands of them but typically that's unwise and the total lack of garbage collection at the moment can really make you feel you are dealing with something young and experimental though in most cases I found I was able to code around the issue and simply not generate any garbage. ChucK is much, much heavier on the CPU then SC for most task, but I do wonder how large that difference would still be if you'd run SC with a block-size of one sample (I really passionately dislike what block-processing does to feedback loops).

With ChucK I tend to either build my own instruments as more serious, long term projects or I play around with algorithmic processes for fun and kicks and occasional surprises. I hardly ever save those.

With regard to the timing stuff I had to adjust my thinking a bit but now I tend to think about timing and parallel processes like ChucK does. I still find reasoning in ChucK a bit harder then reasoning in English for most topics.but I've been speaking, reading and writing English for much longer then ChucK so that's normal, I suppose.

Oh, one thing I don't entirely like is the way ChucK's method of being object oriented works. Here I tend to think very differently from how ChucK works and I tend to want things that are more typical of Prolog, I tend to want do things to all objects in the whole VM or file, sort them and base rules on their type and property... For example open the cut-off on every LPF that takes a wave buffer as a input unless this wave buffer is past half it's buffer, then mark this LPF with some property. Or maybe double the size of every array who's length got defined by a certain parameter and copy the contents of the original one to the new one twice. Of course I *could* write code that does this but then I'd have to structure the whole program around it, I want to do such things on the fly without preparation. I don't think I'm allowed arrays of type "object" anyway, nor can I poll objects for their type. Basically I want "sets" as a data type, I want sets much more badly then I want proper lists but I don't think I'll ever get those.

I realise ChucK's OO implementation is based on sensible languages like C++ and Java which are generally considered to be Good Ideas and Prolog is all but discarded but I think borrowing more from Prolog would be a good idea for livecoding, for one thing Prolog is meant to have a dialogue with....

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Wed Jan 30, 2008 11:42 pm    Post subject: Reply with quote  Mark this post and the followings unread

when I'm working with ChucK with simple/example patches,
i feel that the code looks straightforwardly modular, nice for musicians starting to design modules with programming.
SuperCollider, for me the coding and reading the code are a little harder to understand at first,
but after practicing, i'll get more used to it.

that's why I have to start SC sometimes -_-"
i'm too lazy these days heheheh..

oh.. and I feel quite lazy when coding in ChucK comparing to another languages hahah
ahhh lazy hmm maybe i mean too comfortable.
-_-"
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Thu Jan 31, 2008 10:36 am    Post subject: Reply with quote  Mark this post and the followings unread

Only time for a couple of quick comments now... more substantial remarks might have to wait until the weekend.

Kassen wrote:
Before I starting "going steady" with ChucK I "met up" with SC a few times, trying SC was a big incentive to install Linux, I think, and I wasn't aware of ChucK yet. here the syntax was a big issue to me. No matter how many times people tell me it's very simple; I simply don't get it. Let me quote a semi random bit of SC code from mr.Cottle's e-book;

Code:
(
a = Array.fill(100, {0}); //fill an array with 0s
1000.do( //do 1000 iterations
   {
       b = (100.rand + 100.rand)/2.div(1);
       a.put(b, a.at(b) + 1);
   }
);
a.plot; //plot the results.
)


I'm sorry but I just don't get it. To me this looks like "do" is a property of "1000" instead of the thousand being a parameter of "do", then we open two different kinds of brackets (and close them together as well??) etc. It looks almost as alien to me as Perl and most Perl to me is indistinguishable from purely random characters.


"." doesn't mean "property" in sc - it means "I'm sending you this message" - which may access a property and return its value, or it might do something.

There are several ways to write a do loop - let me simplify by just counting from 0 to (n-1):

10.do({ |i| i.postln }); // traditional, sc2 syntax
do(10, { |i| i.postln }); // function-call notation
10 do: { |i| i.postln }; // infix notation

And the winner in reading ease, new as of maybe a year ago:

do(10) { |i| i.postln };

... which also applies to while, if, loop, case and switch structures.

if(0.5.coin) { "heads".postln } { "tails".postln };
x = 0; while { x < 10 } { x.postln; x = x + 1 };

So let me rewrite the example:

Code:
(
a = Array.fill(100, 0);  // or, 0 ! 100
do(1000) {
       b = (100.rand + 100.rand) div: 2;  // div: means integer division
       a[b] = a[b] + 1;
};
a.plot;
)


Quote:
Another issue I had was with the way SinOsc (as well as other Ugens but I started at the beginning) is controlled where all of the parameters go between some brackets and their order determines what number affects what parameter.


I find this challenging also -- so, a couple of years ago, I wrote an auto completion utility (MacOSX for mine, although Marije tells me that the scel front end in Linux has its own auto completion). So I type

SinOsc.

... and a window pops up with class methods to which SinOsc responds. If I hit return on ar(), then I get this in my document window:

SinOsc.ar(freq, phase, mul, add)

... and I can just fill in what I need.

Keyword argument addressing also helps with readability (and I use it fairly frequently, especially with UGens):

EnvGen.kr(env: Env(levels: [0, 1, 1, 0], times: [0.1, 5, 0.1]), timeScale: 0.1, doneAction: 2)

Quote:
I realise ChucK's OO implementation is based on sensible languages like C++ and Java which are generally considered to be Good Ideas....


Ugh. Don't get me started. The real power of OOP is in polymorphism, but strict typing turns polymorphism into a weak shadow of what it can really do. (But then SC has made me all smalltalk-y and mushy-headed I guess.)

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Thu Jan 31, 2008 12:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:
Only time for a couple of quick comments now... more substantial remarks might have to wait until the weekend.


Cool. I'm finding this quite educational. I wish somebody who's fluent in both SC and CK would write a comparison but I wonder if such a person even exists.

Quote:

"." doesn't mean "property" in sc - it means "I'm sending you this message" - which may access a property and return its value, or it might do something.

There are several ways to write a do loop - let me simplify by just counting from 0 to (n-1):

10.do({ |i| i.postln }); // traditional, sc2 syntax
do(10, { |i| i.postln }); // function-call notation
10 do: { |i| i.postln }; // infix notation

And the winner in reading ease, new as of maybe a year ago:

do(10) { |i| i.postln };

... which also applies to while, if, loop, case and switch structures.


Yes! Much more readable to me. I find the function-call notation defendable as well because you get the power of using data as code but the "traditional" one is just pure confusion to me.

you do get the data-code thing, right? Say I have a string named foo, formatted to be legal SC syntax this would be legal?
Code:
do(10,  foo );


And "foo" would still be editable as a string?

Quote:

I find this challenging also -- so, a couple of years ago, I wrote an auto completion utility (MacOSX for mine, although Marije tells me that the scel front end in Linux has its own auto completion).


Ok, but doesn't that syntax cause issues? For example, say I have a SinOsc and I don't know it's current pitch (for example because that's randomly set some time ago) and now I want to change it's volume without affecting it's pitch? I was/am under the impression that I need to supply a argument for pitch if I want to affect the volume?

Quote:

Keyword argument addressing also helps with readability (and I use it fairly frequently, especially with UGens):

EnvGen.kr(env: Env(levels: [0, 1, 1, 0], times: [0.1, 5, 0.1]), timeScale: 0.1, doneAction: 2)


Much better though they still lack units for the time but that's a issue that would disapear with getting used to the convention.

Quote:

Ugh. Don't get me started. The real power of OOP is in polymorphism, but strict typing turns polymorphism into a weak shadow of what it can really do. (But then SC has made me all smalltalk-y and mushy-headed I guess.)


I see what you mean. I do think though that many of the issues ChucK has there are caused by it's youth more then by real design choices. For example, being unable to extent "Ugen" in new classes is quite inconvenient as is being unable to overload operators. I don't think strong typing needs to be a big problem as long as you have enough power to control your (new) objects.... and it does have advantages. Anything that compiles in ChucK shouldn't be able to crash the VM, I don't think you can (try to) make that guarantee like that with weak typing but I'm not sure? Of course you can still crash the VM but it's becoming harder all the time. A while ago I had some issues with implicit casting between "time" and "duration" types, I still think that situation is less then ideal but at least I it turned out I could write two functions that would do this explicitly so there is no practical problem for me anymore. That said; I really don't understand why in ChucK functions aren't objects.

Still, does SC have the ability to do stuff like what I mentioned? For example, could you take a certain scope that was already defined and have SC put references to every object, regardless of type within that scope in a array automatically? (maybe excepting that array itself....).

My one only real issue with ChucK, BTW, is that so far hardly any real usage is made of this idea of having the compiler and VM share namespace so we could update running code. That's the one thing I really lust after at this moment, for the rest I'm quite content and most issues I can write around. I don't like that attitude but I have to admit that on current computers you can survive for quite a while without garbage collection of memory.

Thanks for your comments so far. I'm out of my depth but quite enjoyably so :¬).

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
djdaphalgan



Joined: Jul 19, 2007
Posts: 20
Location: Belgium

PostPosted: Fri Feb 01, 2008 12:16 am    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
However, I think djdaphalgan was talking purely about the syntax, not the more technical sides to the languages.


Yes, it was about the syntax. Chuck looks like Java/C++, and that's why I find it easy to read.

I started with Chuck, and after a while a gave SC a try, but had difficulties with the SC syntax. Maybe I should give SC3 an other try.

I would be cewl if someone could make a list of the pros and cons of both languages (espessialy about the way they handle time, how they syncronise threads, how they handle midi, ...).
Back to top
View user's profile Send private message
Dr. Spankenstein



Joined: Mar 03, 2007
Posts: 136
Location: Cambridge
Audio files: 1

PostPosted: Fri Feb 01, 2008 3:22 am    Post subject: Reply with quote  Mark this post and the followings unread

Quote:


It would be cewl if someone could make a list of the pros and cons of both languages (espessialy about the way they handle time, how they syncronise threads, how they handle midi, ...).



I second that idea! The use of time in SC3 is what really put me off it. I've coded GUI's and control stuff in there, but timing is just way out of my league of thinking.
Back to top
View user's profile Send private message
Inventor
Stream Operator


Joined: Oct 13, 2007
Posts: 5978
Location: San Antonio, Tx, USA
Audio files: 258

PostPosted: Fri Feb 01, 2008 12:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

For me, I was completely unaware of software like these great packages until i saw an entry at apple.com's downloads section about the mini-audicle. It sounded like a whole new adventure for me and sure enough I'm locked into ChucK. I don't know about SuperCollider so I can't comment on it.
Back to top
View user's profile Send private message Send e-mail
Antimon



Joined: Jan 18, 2005
Posts: 3720
Location: Sweden
Audio files: 273
G2 patch files: 96

PostPosted: Sun Feb 03, 2008 3:10 pm    Post subject: Reply with quote  Mark this post and the followings unread

I haven't used the oscillators in ChucK much yet, I've mostly been sending sequences to MIDI or playing small samples. So what I like about ChucK is the stable clock and how the shreds aren't preemptively multithreaded, but rather block the VM until they enter a wait state. (Correct me if I'm wrong on all this). So I can start one shred that waits 10 milliseconds 100 times and antother that wait a second and if I start them at the same time, they will finish at exactly the same time - you can count with time as reliable variable, which is different from the way threads work in, say, Java. This brings a sense of security which is nice when sequencing. And, being pragmatic, when I've found something I like, there's no reason to look for something else.

Having said that, I've had some problems with sound generation. I'm not versatile with filter basics, and have a hard time getting the filters to sound like I want them. I don't really know what a pole does and Q obviously isn't the same as resonance since the sound explodes horribly every time I try to touch it. When i tried making a simple collection of detuned saws I got poor quality - it sounded like I had a really low carrier frequency. These things can probably be easily fixed, but I'm a bit intimidated when I encounter strange problems in very simple things that I thought I had learned to understand.

/Stefan

_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music
Back to top
View user's profile Send private message Visit poster's website
Frostburn



Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9

PostPosted: Sun Feb 03, 2008 3:30 pm    Post subject: Reply with quote  Mark this post and the followings unread

ChucK's timing is definately a strong asset.
Being able to trust that shreds are sample precise is nice.
But what I really like about ChucK is the ability to use different control rates for different things and generally thinking in terms of time.

Antimon wrote:
Having said that, I've had some problems with sound generation. I'm not versatile with filter basics, and have a hard time getting the filters to sound like I want them. I don't really know what a pole does and Q obviously isn't the same as resonance since the sound explodes horribly every time I try to touch it. When i tried making a simple collection of detuned saws I got poor quality - it sounded like I had a really low carrier frequency. These things can probably be easily fixed, but I'm a bit intimidated when I encounter strange problems in very simple things that I thought I had learned to understand.

Can you post an example of a broken filter. I could have a look at it.
Or you can just tell us what you'd like and we'll see what we can make of it.
make a new thread or something...

_________________
To boldly go where no man has bothered to go before.
Back to top
View user's profile Send private message
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Sun Feb 03, 2008 9:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

Sample-accuracy is a problem in SC, but it isn't necessary for all, perhaps even most, musical applications. I haven't missed it one bit in my compositional work.

I'd like to shift the questions about sc's capabilities into another thread in the SuperCollider section -- good questions that I hoped to address this weekend, but I'm under a deadline for an article for publication which took precedence.

So I'll come back to this during the week...
James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Mon Feb 04, 2008 6:48 am    Post subject: Reply with quote  Mark this post and the followings unread

Quote:
The use of time in SC3 is what really put me off it.


I'll get to that after I start the thread on the SuperCollider board. For now, I will just say that there's nothing complicated about the handling of time in something like this, which covers the majority of use cases:

Code:
r = fork {
   loop {
      "abcde".scramble.postln;
      0.5.wait;
   }
};

r.stop;   // when done


Quote:
So what I like about ChucK is the stable clock and how the shreds aren't preemptively multithreaded, but rather block the VM until they enter a wait state. (Correct me if I'm wrong on all this). So I can start one shred that waits 10 milliseconds 100 times and antother that wait a second and if I start them at the same time, they will finish at exactly the same time - you can count with time as reliable variable, which is different from the way threads work in, say, Java.


The realtime clocks in SuperCollider also count exactly, and threads are non-preemptive. In the above example, when you "wait," it adds 0.5 to the time when the thread woke up, not the time of the "wait" call. If you schedule the thread to start at 100.0 beats, the second event will occur at exactly 100.5. Even if you do something more complicated in the loop that takes, say, 0.02 beats instead of a fraction of a millisecond, it will still be exactly 100.5 for the next event. (Note "beats" instead of "seconds" -- most musical sequencing takes place on TempoClock, which can run faster or slower as needed.)

Chuck timing advantages are sample accuracy and rolling your own control rates. I think that very, very few sequencing applications demand absolute sample accuracy -- no one has demonstrated the contrary to me -- although of course synthesis algorithms call for higher precision. Custom control rates are interesting, but to be honest, when I'm sequencing, I don't want to think about control rates at all. I want each note to take care of itself, without constant babysitting.

"Generally thinking in terms of time" -- this is actually the crux of the initial question I asked.
  • In what specific ways do you do think in terms of time when ChucKing?
  • What creative possibilities does this open up for you?
  • Is there anything that's harder because of "strong timing"?

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Dr. Spankenstein



Joined: Mar 03, 2007
Posts: 136
Location: Cambridge
Audio files: 1

PostPosted: Mon Feb 04, 2008 11:45 am    Post subject: Reply with quote  Mark this post and the followings unread

Quote:


I'll get to that after I start the thread on the SuperCollider board. For now, I will just say that there's nothing complicated about the handling of time in something like this, which covers the majority of use cases:



Looking forward to it. I've yet to have anyone explain SC3 timing to me in a clear way that I understand. It's probably the one thing that put me off delving any deeper into the world of SuperCollider.

Rhys
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Feb 04, 2008 12:11 pm    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:

I'd like to shift the questions about sc's capabilities into another thread in the SuperCollider section -- good questions that I hoped to address this weekend, but I'm under a deadline for an article for publication which took precedence.


What we can do, if you'd like is *move* this topic to the SC side yet leave a "shadow" thingy of it here. That will make the same topics accessible from both fora?

It's just a idea, we could also do what you sugest and place a link to it in this topic.

I'm looking forward to hearing more but please don't stress about it for me, I'm not going anywhere Smile

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Mon Feb 04, 2008 12:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

I'm thinking, I have some questions about how ChucK works that make sense to keep here. And there have been some questions about how SC works that make sense to move there. So I'd just as soon start another thread over there for the SC questions.

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Frostburn



Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9

PostPosted: Mon Feb 04, 2008 2:26 pm    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:

The realtime clocks in SuperCollider also count exactly, and threads are non-preemptive. In the above example, when you "wait," it adds 0.5 to the time when the thread woke up, not the time of the "wait" call. If you schedule the thread to start at 100.0 beats, the second event will occur at exactly 100.5. Even if you do something more complicated in the loop that takes, say, 0.02 beats instead of a fraction of a millisecond, it will still be exactly 100.5 for the next event. (Note "beats" instead of "seconds" -- most musical sequencing takes place on TempoClock, which can run faster or slower as needed.)

Chuck timing advantages are sample accuracy and rolling your own control rates. I think that very, very few sequencing applications demand absolute sample accuracy -- no one has demonstrated the contrary to me -- although of course synthesis algorithms call for higher precision. Custom control rates are interesting, but to be honest, when I'm sequencing, I don't want to think about control rates at all. I want each note to take care of itself, without constant babysitting.

"Generally thinking in terms of time" -- this is actually the crux of the initial question I asked.
  • In what specific ways do you do think in terms of time when ChucKing?
  • What creative possibilities does this open up for you?
  • Is there anything that's harder because of "strong timing"?

James


As far as sequencing goes. Sequencing in ChucK is only as strong as you can come up with yourself. It doesn't have any score or pattern handling classes of it's own as far as I know. That's propably the hard part of ChucK that you enquired about.
To me this isn't a problem because I'm more in to synthesizing strange sounds or modeling real instruments ,which usually leads to more strange sounds.... This calls for sample accuracy. And even though doing something on a sample basis is computationally expensive it's still a creative possibility that I feel ChucK really opens up for me.
What makes it different from say coding a C program that outputs wav files is that once I come up with a design I can quickly turn it in to a midi controlled instrument and hear it out in action while applying different filters on it as I go along. After I've finetuned the CPU eating monster I can simply render it to a wav sample to get my resources back.

If you're more in to composing then ChucK may not be the best way to go. But synthesizing and realtime experimentation with different controlling methods (keyboard, mouse, gamepads) fits well with the ChucK syntax.

I can't really say how I spesificially think when chucking because it's all about experimentation. There are no rules I could write down for playing with ideas.

_________________
To boldly go where no man has bothered to go before.
Back to top
View user's profile Send private message
renderful



Joined: Apr 18, 2007
Posts: 29
Location: Boulder, Co

PostPosted: Mon Feb 04, 2008 6:44 pm    Post subject: Reply with quote  Mark this post and the followings unread

Frostburn wrote:
dewdrop_world wrote:

The realtime clocks in SuperCollider also count exactly, and threads are non-preemptive. In the above example, when you "wait," it adds 0.5 to the time when the thread woke up, not the time of the "wait" call. If you schedule the thread to start at 100.0 beats, the second event will occur at exactly 100.5. Even if you do something more complicated in the loop that takes, say, 0.02 beats instead of a fraction of a millisecond, it will still be exactly 100.5 for the next event. (Note "beats" instead of "seconds" -- most musical sequencing takes place on TempoClock, which can run faster or slower as needed.)

Chuck timing advantages are sample accuracy and rolling your own control rates. I think that very, very few sequencing applications demand absolute sample accuracy -- no one has demonstrated the contrary to me -- although of course synthesis algorithms call for higher precision. Custom control rates are interesting, but to be honest, when I'm sequencing, I don't want to think about control rates at all. I want each note to take care of itself, without constant babysitting.

"Generally thinking in terms of time" -- this is actually the crux of the initial question I asked.
  • In what specific ways do you do think in terms of time when ChucKing?
  • What creative possibilities does this open up for you?
  • Is there anything that's harder because of "strong timing"?

James


As far as sequencing goes. Sequencing in ChucK is only as strong as you can come up with yourself. It doesn't have any score or pattern handling classes of it's own as far as I know. That's propably the hard part of ChucK that you enquired about.
To me this isn't a problem because I'm more in to synthesizing strange sounds or modeling real instruments ,which usually leads to more strange sounds.... This calls for sample accuracy. And even though doing something on a sample basis is computationally expensive it's still a creative possibility that I feel ChucK really opens up for me.
What makes it different from say coding a C program that outputs wav files is that once I come up with a design I can quickly turn it in to a midi controlled instrument and hear it out in action while applying different filters on it as I go along. After I've finetuned the CPU eating monster I can simply render it to a wav sample to get my resources back.

If you're more in to composing then ChucK may not be the best way to go. But synthesizing and realtime experimentation with different controlling methods (keyboard, mouse, gamepads) fits well with the ChucK syntax.

I can't really say how I spesificially think when chucking because it's all about experimentation. There are no rules I could write down for playing with ideas.


You've just explained things that I feel and think, but had no idea. I agree with everything you've said here. I play with sounds in ChucK, then control it with external devices/software(OSC).
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Tue Feb 05, 2008 1:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:

Chuck timing advantages are sample accuracy and rolling your own control rates. I think that very, very few sequencing applications demand absolute sample accuracy -- no one has demonstrated the contrary to me -- although of course synthesis algorithms call for higher precision. Custom control rates are interesting, but to be honest, when I'm sequencing, I don't want to think about control rates at all. I want each note to take care of itself, without constant babysitting.


Yeah, I see where you are coming from. I can see how you don't feel the need for sample accurate sequencing but in ChucK there need not be a difference between how you sequence and how you synthesise. Typically the synthesis is done by Ugens but sometimes those don't quite cover all you need. So; sequencing becomes sample accurate because synthesis needs to be.

Custom control rates may be somewhat boring when they concern -say- the modulation of a filter's cutoff but they become exciting where the control-rate is some musical amount of time. The controll-rate of a sequencer may be a quarter-note, the control rate of a granular synth may be based on a frequency...


Quote:
"Generally thinking in terms of time" -- this is actually the crux of the initial question I asked.
[*]In what specific ways do you do think in terms of time when ChucKing?


This is a hard question because I feel nearly everything in music is time-based. Both rhythm and pitch are phenomena that couldn't exist without time.... Actually, in ChucK you can express the pitch of a oscillator in the type "duration", if you like, which makes a lot of sense for LFO's. Since I started ChucKing I got a much stronger grip on sub-division in both pitch and rhythm and the link between a sound's pitch and the sample-rate.

Of course those things are important anywhere, not just in ChucK, but in more traditional contexts the dimension that was made explicit was always pitch and not time so ChucK partially turns that around and where it doesn't you are still free to pick the one you find most appropriate.

As I said it's hard to explain :¬) To put it in more simple terms; this huge diagram about "scales of time" in Road's Microsound looks positively sensible to me now while I thought mr. Roads had started experimenting with chemicals when I first saw it.

Quote:
[*]What creative possibilities does this open up for you?


I'm not sure ChucK opened more possibilities for me per-sé.... at least not more then I would've had if I would've picked up SC or maybe MAX/PD... I had to pick something anyway when I outgrew traditional modular synths and started looking elsewhere. What I can say though is that I suspect it makes some things a lot easier. Things like automatic quantisation or chopping up beats I could do in a modular as well but when you have time and duration as ready made data-types expressing the kind of quantisation or the type of cut you want becomes very intuitive, almost "stating the obvious", which is of course always nice, convenient and looks good.

Maybe this leads to me doing things I otherwise wouldn't otherwise have done but it's hard to think about alternate scenarios like that. I'm hesitant to make claims about ChucK in that direction.

Quote:
[*]Is there anything that's harder because of "strong timing"?


I don't think so... Well, not beyond getting into it. I have to say that for a short while ChucK's syntax and insistence on timing took some getting used to and looked "upside down". I could also say that at times ChucK may be deterministic in it's timing but that need not mean you or me can predict it easily where multiple processes are "shreduled" to do something on the exact same moment which also lines up with some event (like a envelope reaching it's end) in the Ugens. In situations like that *something* will have to happen "first" because the CPU can only do one thing at one time but figuring out which one this will be is not always trivial, at least not for me. That's a fairly rare situation though and likely something that would be worse in many other environments.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Wed Feb 06, 2008 7:06 am    Post subject: Reply with quote  Mark this post and the followings unread

Very helpful, cogent responses all -- just the kind of thing I was looking for when I started the thread. I think SuperCollider suits me as naturally as ChucK suits many of you -- so when I look at the very different ways that chuck handles things (different from what I'm used to, that is), likely I tend to see difficulties more readily and overlook chuck's strengths. It's much more clear to me now.

Frostburn hit it on the head -- I'm definitely more of a composer than an audio experimenter, and it suits me better to define how the synthesis should take place in one part of the code, and use it elsewhere (in some senses, "hiding" synthesis from the compositional logic). That comment makes it clear to me that somebody who wants to dig in to the nuts and bolts of synthesis (without c++) would very likely be better served by ChucK, especially if you're doing things where block calculation gets in the way. And it gives me a good reason to look into ChucK in the future -- not as a replacement for SuperCollider, but as a complement.

(Incidentally, Julian Rohrhuber posted on the sc mailing list the other day about a way to do single sample feedback in sc, despite block calculation. Still working out some bugs, but it's a promising development.)

More to come... I've collected interesting snippets from this conversation into a file, to go through them one by one as I have time.

Thanks for all the replies. Really good stuff!
James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Feb 06, 2008 8:31 am    Post subject: Reply with quote  Mark this post and the followings unread

Quote:
(Incidentally, Julian Rohrhuber posted on the sc mailing list the other day about a way to do single sample feedback in sc, despite block calculation. Still working out some bugs, but it's a promising development.)


That's great news! Reaktor and that modular that Reaktor's core stuff was based on do it as well so it should be possible. I couldn't find Julian's post but I'm sure I'll hear more about this.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Wed Feb 06, 2008 1:20 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
That's great news! Reaktor and that modular that Reaktor's core stuff was based on do it as well so it should be possible. I couldn't find Julian's post but I'm sure I'll hear more about this.


For a quick teaser...

http://www.nabble.com/single-sample-feedback-td15256266.html#a15256266

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Feb 06, 2008 7:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

Looks like some deep stuff but I think I understand the strategy.

Am I correct in understanding that this is one of those things that's quite trivial once you see how it's done? Of course all good things in computing are like that... :¬)

Thanks.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Sun Feb 10, 2008 8:45 pm    Post subject: Reply with quote  Mark this post and the followings unread

I've started the thread on the SuperCollider board, starting with the question about timing in SC.

http://electro-music.com/forum/post-168158.html#168158

Feel free to post followups over there --
James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [23 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use