Translating CSound pieces to ChucK

Stochastic · Joined: Feb 25, 2008 Posts: 45 Location: Vancouver

So I'm in a detailed computer synthesis class this semester and the language we're supposed to use is CSound.

ugh.

I know, it's robust, it's stable, yada, yada... I don't like the logical flow of it (can you even write to an array in that language?).

I've presented my critiques of CSound to my prof (Barry Truax) and he's allowed me to use ChucK for the assignments instead if I want. The thing is that he's still teaching the course in CSound, so I'm sitting through the tutorials on GEN routines and foscili stuff anyways. So to keep myself on the same learning curve with ChucK I've decided that I'll go along with the tutorials but translate them into ChucK code instead. This will also help teach Barry chuck so that he's not lost when I hand in my (//well commented) chuck assignments.

As I pondered the first steps to doing this, I'm immediately met with some issues that I'm sure wouldn't be such big issues if I wasn't starting from CSound code/logic flow. So here are my questions to the community:

- Is there any table-lookup means in chuck (I know an array would work for simple functions, but what about the more complex GEN routines such as Chebyshev polynomials)?

- I've started by designing the csound instrument declarations into chuck functions and the csound score file into function calls. Should I be declaring variables outside the functions or inside? If they're declared in the function input parameters will I see garbage buildup after multiple function calls?

- Is there anywhere that I can find a pdf copy of the language specification? (I've got me an e-book reader from sony and Ge's thesis has been my bus fodder, but it regularly points back to the language spec for more info and the thing handles pdf files best)

- Are there any danger flags that I should be weary of when translating csound into chuckian? any potential missing features in the language that I'll run head first into half-way through the semester?

P.S. I know the poll is a silly question with no real answer, but isn't that true of most internet polls?

Kassen · Posted: Fri Sep 12, 2008 4:55 am Post subject:

Wow, this a interesting matter.

As for power; no. Any (valid) wave file that could be created by any process could also be created by either CSound or ChucK. All hail Turing completeness (admittedly Turing completeness means you can sleep soundly knowing it's possible yet will lie awake thinking of *how* it's possible for a infinite number of cases).

*Table lookup; Arrays are your friend if you really need tables. The Gen(n) UGens are functions, as far as I know. I'm not sure why this matters. CSound deals with tables mostly because of CPU constraints in the computers it was originally designed for.

*Garbage; Yes, defining variables in function will lead to garbage. For a few floats and integers this is no big issue; a integer is 32 bits, let's say you can spare a half gig of RAM for ChucK... do the math; that's quite a few garbage variables. There will of course be issues if your garbage consists of large arrays and you are pumping out a few thousand notes per second. What I'd do would be making instruments into classes and have the variables outside of the function yet inside of the class. I'd make a array for every type of instrument and outfit the classes with a variable that keeps track of whether they are in use. If a note is needed I'd loop over the array of voices, taking the fist instance that's "free", if none is to be found I'd grow the array by one.

my_voices_array << new my_instrument;
//don't use .size() here! there is a bug in instantiating the new members currently
//use a explicit "new"

You could also consider using sporked functions and signalled Events, signalling of events pritty much gives you voice cycling for free, though no easy detection for running out of voices. This depends on your design and preferences, I'd go with the classes.

This will mean you won't use any more memory then you need to (at least no more then you need in a system without garbage collection). You'll end up using n voices for every instrument where n is the largest amount of voices ever used at the same time for that instrument. Remember to unchuck unused UGens.

*The manual and Ge's thesis won't do? I think those are the only PDF files, if you need a PDF of the online reference I fear you'll need to make it yourself.

*I'm no CSound expert (I do understand the basics) but I don't think there is anything that will be impossible. CSound's score macro's might be a issue but we have functions, arrays and time as a data type so if push comes to shove you can just emulate all of that. Another issue may be the UGens that Csound has and that we don't.

My bet is that you will end up thinking more and typing less then your fellow students.

Great project, either way your (and Barry Truax's) findings will be interesting, do shout if you get stuck; there are rules about doing anybody else's homework but we're quite good at getting people un-stuck :¬).

Keep on ChucKing!

Underwaterbob · Posted: Fri Sep 12, 2008 6:56 am Post subject:

I think ChucK will only handle your coursework until it grows more complex.

I'm completely biased in this since I've been using ChucK for less than a hundredth of the time I've been using CSound, but there are quite a few more complex tasks relatively easily implemented in CSound that could become a nightmare in ChucK. While ChucK is much more akin to a typical computer programming language, utilizing arrays and robust err.. math, CSound is very focused on functional methods of generating sound. This initially makes CSound seem to be far more verbose than ChucK , but in the long run, more complex, conventional sound synthesis methods will be easier to produce in CSound than ChucK.

By all means give a go. I took a sound synthesis course and instead of using all the different and very specific synthesis apps (7 years old now) I vowed to reproduce every assignment in CSound, was pretty successful and learned more than I can remember about computer generated sound in the meantime.

I think an amalgamation of the two languages would be awesome. I would love to be able to use some of ChucK's math and timing functions in an instrument in CSound. Sounds like a project for someone who knows a lot more about computers than I.

chuckles · Posted: Fri Sep 12, 2008 12:58 pm Post subject:

(Re the polls): Yes, perhaps, but is Csound more FUN to use than Chuck? (That's a big NO.)

As an early experiments I took a simple Csound instrument to try to convert it to ChucK.

I wrote about it in a blog entry in csound.wordpress.com, "ChucK meets Csound"

Kassen · Posted: Fri Sep 12, 2008 8:19 pm Post subject:

Inventor · Posted: Fri Sep 12, 2008 10:05 pm Post subject:

I do not recommend taking a class and also burdening yourself with the translation of all the classwork from one language to another. I've paid my dues, I've done my time (BS EE, MS EE), and college is just way too burdensome without throwing obstacles like that in front of yourself. If the prof is teaching CSound, be a good little student and play along, that's what I'd do. Just my two cents.

kijjaz · Posted: Fri Sep 12, 2008 10:39 pm Post subject:

i'm always amazed at how they combine many tools and generators in Csound..
but i'm still too lazy to dig a lot into csound heheh..
i hope ChucK will be extended much more that i can get that Csound feeling with the power of ChucK soon!

Stochastic · Joined: Feb 25, 2008 Posts: 45 Location: Vancouver

Kassen · Posted: Sat Sep 13, 2008 4:46 am Post subject:

Underwaterbob · Posted: Sat Sep 13, 2008 7:50 am Post subject:

Things that might be more difficult to do in ChucK... an example:

GEN19 in CSound allows me to create a wave function with any number of harmonics and non-harmonic partials and control their strength, relative phase and DC offset in one line of code. To do the same in ChucK would require defining a lot of different sinusoids; their phase, amplitude and gain; and some mathematical manipulation to get the DC offset. Suppose you want an instrument with four different functions like this each with 20 harmonics. CSound could define the four functions with four (fairly long) lines of code. In Chuck you would have to define 80 different oscillators

As far as I know, is there a UGen in ChucK that lets you define the waveform according to it's harmonic series?

CSound has physical modeling opcodes (wgpluck, marimba), formant generators, audio analysis and manipulation (vocoding, harmon opcode), extensive granular synthesis opcodes, Butterworth filters and some other things I think would require quite a bit more code in ChucK (though not impossible) to reproduce.

I think both languages could benefit immensely from each other. CSound code syntax is severely dated and the amalgamation of the orc and sco files with CSound 5 if anything, made it worse (IMO). Learning ChucK has made me a better CSound programmer. I have always been coming at sound synthesis from a CSound approach, but ChucK has shown me there are other ways to do things.

radarsat1 · Joined: Mar 14, 2008 Posts: 85 Location: Montreal

dewdrop_world · Posted: Sat Sep 13, 2008 12:53 pm Post subject:

Well, I know this is a chuck thread, but a bit of supercollider-ism might be entertaining.

Kassen · Posted: Sat Sep 13, 2008 5:12 pm Post subject:

Kassen · Posted: Sat Sep 13, 2008 5:34 pm Post subject:

Stochastic · Joined: Feb 25, 2008 Posts: 45 Location: Vancouver

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

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

The above revised with Array.cap(), SawOsc and timing changed:

Antimon · Posted: Mon Sep 15, 2008 2:14 am Post subject:

Er...

Kassen · Posted: Mon Sep 15, 2008 5:38 am Post subject:

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

Kassen · Posted: Mon Sep 15, 2008 9:55 am Post subject:

Yes. Over (or "double") chucking is once again relevant. It results in two connections, meaning twice the volume. This is useful in chucking to a Gain set to multiply where it will square the signal (as it gets multiplied by itself).

There is a bug in this though as double connections to the dac aren't properly cleaned up right now.

Please do note that this feature was once again added with the latest version of ChucK (1.2.1.2) and that the canonical version of the Mini doesn't use the latest version of the VM yet so if you're chucking in the Mini then right now double-chucking doesn't do anything after the first connection.

Confused yet? ;¬)

radarsat1 · Joined: Mar 14, 2008 Posts: 85 Location: Montreal

Kassen · Posted: Mon Sep 15, 2008 1:03 pm Post subject:

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

rogan · Posted: Mon Sep 15, 2008 7:37 pm Post subject:

As a grad student, I'm going to second what Inventor said, for probably the same reasons Smile

. If you're going to take this class, do the homework in the language that the class is using. It'll save you a lot of time, plus you'll actually be able to talk to others in the class about your work. You have plenty of time to use Chuck after you've learned the basic theory from this class.

I actually still use the big CSound book, and port various things to Chuck. The only difference for me seems to be doing math, for example: