marlon brando

I guess text based programming is good for controlling multiple parameter synthesis and sound design, like hundreds of parameters of granular synthesis.

What sound design/synthesis/dsp programming language holds most promise for the future?

Is csound a lot harder to get into for people without programming experience?

chuck-vs-csound

Actually they are two totally different things...

csound is a scripting language that controls a DSP library. It has

a pretty extensive set of control signal generators,

signal modifiers, realtime spectral processing, and much more.

It also has an API that allows it to integrate with VST, Max,

python, Java, C++. csound is more the traditional environment of

Chuck is also a realtime DSP environment, but whose emphasis seems to

be command line interaction with processes that you can control

and interact with in real time. It takes the approach that the laptop

is like an instrument that you perform. As such, you would need ways

to create and control processes that would create gestures. It is an

interesting approach to composing on the computer. But Chuck is relatively

new, and has no where near the DSP functionality that csound does.

I would certainly keep an eye on chuck and see how it develops.

If I had to pick one, I would definitely choose csound. The syntax is

no more harder than any other text based synthesis language. It has a huge

user base and there are tons of resources out there to get you started.

An added benefit to csound is that it integrates with Max. With the

csound~ external, you can load your csound creations in Max and hook

up your favorite interface to it. Check out csounds.com and

csound is a scripting language that controls a DSP library. It has
a pretty extensive set of control signal generators,
signal modifiers, realtime spectral processing, and much more.
It also has an API that allows it to integrate with VST, Max,
python, Java, C++. csound is more the traditional environment of
sound design and synthesis. 

Chuck is also a realtime DSP environment, but whose emphasis seems to
be command line interaction with processes that you can control
and interact with in real time. It takes the approach that the laptop
is like an instrument that you perform. As such, you would need ways
to create and control processes that would create gestures. It is an
interesting approach to composing on the computer. But Chuck is relatively
new, and has no where near the DSP functionality that csound does.
I would certainly keep an eye on chuck and see how it develops.

If I had to pick one, I would definitely choose csound. The syntax is
no more harder than any other text based synthesis language. It has a huge
user base and there are tons of resources out there to get you started.
An added benefit to csound is that it integrates with Max. With the
csound~ external, you can load your csound creations in Max and hook
up your favorite interface to it.  Check out csounds.com and
also look into the csound book.


Without wanting to mess things up, I think that SuperCollider is also worth exploring. I love CSound (and it has the best FFT sound of them all) but SuperCollider is a great platform, very different to Max and therefore allows (forces) you to think in other ways. Learning curve is steep and uncomfortable, but you have a very rich community of friendly users with a dynamic mailing list...

Without wanting to mess things up, I think that SuperCollider is also worth exploring.  I love CSound (and it has the best FFT sound of them all) but SuperCollider is a great platform, very different to Max and therefore allows (forces) you to think in other ways.  Learning curve is steep and uncomfortable, but you have a very rich community of friendly users with a dynamic mailing list...

ChucK and SuperCollider can also be integrated into the Max environment:

* http://music.columbia.edu/~brad/chuck~/
* http://music.columbia.edu/~brad/sc3~/

"ChucK and SuperCollider can also be integrated into the Max environment:"

Actually, if you are on windows, the don't integrate at all.

Actually, if you are on windows, the don't integrate at all.
Which is why I use csound and Max.


I am very interested in Supercollider. Unfortunately the windows

port of SC has never really worked well. I have never been able to

get it to work right, and I am a pretty savvy user. Maybe one

I think a Supercollider v.s. csound would be a more appropriate

discussion. From what I understand one major difference is that

you can dynamically change the signal path in SC, csound does not

I am very interested in Supercollider. Unfortunately the windows
port of SC has never really worked well. I have never been able to
get it to work right, and I am a pretty savvy user. Maybe one
day it will catch up to the Mac version.

I think a Supercollider v.s. csound would be a more appropriate
discussion. From what I understand one major difference is that
you can dynamically change the signal path in SC, csound does not
allow you to make any runtime changes.


I think it depends on what you want to do. Supercollider is extremely powerful and flexible: you can generate huge amounts of instances and create complex DSP chains. If you are interested on 'the fly' type of work you have a 'ProxySpace' that can be used for live performance. Of course the main problem is the learning curve.

Chuck is also quite nice. However, being younger than supercollider, has slightly less UGens(Unit Generators). The community is considerably smaller than that of supercollider.

I think it depends on what you want to do. Supercollider is extremely powerful and flexible: you can generate huge amounts of instances and create complex DSP chains. If you are interested on 'the fly' type of work you have a 'ProxySpace' that can be used for live performance. Of course the main problem is the learning curve.
Chuck is also quite nice. However, being younger than supercollider, has slightly less UGens(Unit Generators). The community is considerably smaller than that of supercollider.


chuck is a tight solution. it has a nice ugen connector (=>) and the learning curve is pretty fast. also available for max msp (mac only).

but like efe says, it depends on what you want to do..

chuck is a tight solution. it has a nice ugen connector (=>) and the learning curve is pretty fast. also available for max msp (mac only).
but like efe says, it depends on what you want to do..


This I want to do: (from Csounds.com) a 22,050 oscillator additive synthesizer with 1024 stage envelope generators on each is merely a copy-and-paste operation. The same goes for a 1 million voice granular texture! Have you ever dreamed of sounds such as these? Well in Csound you can. And in Csound these dreams can come true!

Basically I want to render sounds, not perform, which seems to be Chuck strongest point.

Is Csounds the obvious choice for million voice granular synthesis?

This I want to do: (from Csounds.com)  a 22,050 oscillator additive synthesizer with 1024 stage envelope generators on each is merely a copy-and-paste operation. The same goes for a 1 million voice granular texture! Have you ever dreamed of sounds such as these? Well in Csound you can. And in Csound these dreams can come true!

Basically I want to render sounds, not perform, which seems to be Chuck strongest point.  

Is Csounds the obvious choice for million voice granular synthesis?


SynthDef( "sine", { arg freq=440, amp=0.1;

    sinustoon = SinOsc.ar(freq, 0, amp);

    s.sendMsg(s_new, sine, 1000+counter, 1, 0, freq, 1000.0.rand+140);

    s.sendMsg(s_new, sine, 1000+counter, 1, 0, freq, 1000.0.rand+140,amp,0.8/100);

Give it a shot:
(
SynthDef( "sine", { arg freq=440, amp=0.1;
	var sinustoon;
	sinustoon = SinOsc.ar(freq, 0, amp);
	Out.ar(0, sinustoon);
	}).send(s);
)

(
16.do({ arg counter;
	s.sendMsg(s_new, sine, 1000+counter, 1, 0, freq, 1000.0.rand+140);
	});
)	

(
100.do({ arg counter;
	s.sendMsg(s_new, sine, 1000+counter, 1, 0, freq, 1000.0.rand+140,amp,0.8/100);
	});
)


; Create an amplitude envelope for the vibrato.

; Initialize the global variables.
sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

; Instrument #1.
instr 1
  kamp = 31129.60
  kfreq = 440
  kpres = 3.0
  krat = 0.127236
  kvibf = 6.12723
  ifn = 1

  ; Create an amplitude envelope for the vibrato.
  kv linseg 0, 0.5, 0, 1, 1, p3-0.5, 1
  kvamp = kv * 0.01

  a1 oscili kamp, kfreq, 1
  out a1 * 0.5
endin

; Play Instrument #1 for two seconds.
i 1 0 5
e

Personally, I like RTcmix the best. Works on windows, too.

Personally, I like RTcmix the best.  Works on windows, too.

"Without wanting to mess things up, I think that SuperCollider is also worth exploring. I love CSound (and it has the best FFT sound of them all) but SuperCollider is a great platform, very different to Max and therefore allows (forces) you to think in other ways. Learning curve is steep and uncomfortable, but you have a very rich community of friendly users with a dynamic mailing list..."

Will you also recomend this to someone without any prior experince in object oriented programming, or any programming at all.

Yes, I would recommend that, though the learning curve is harder. But the pain is fruitful, as they say in the gym world ;-)

Yes, I would recommend that, though the learning curve is harder.  But the pain is fruitful, as they say in the gym world ;-)

I'd put in a vote for SuperCollider; I can't program for toffee, but I can hack around and make interesing sounds in sc3, whereas CSound I've always found completely impenetrable. ChucK; I tried it briefly, but came away thinking it would be a better investment in time to learn more about sc3.

>> I guess text based programming is good for controlling multiple parameter

>> synthesis and sound design, like hundreds of parameters of granular synthesis.

I'd like to put in a vote for java under mxj. Using mxj in max with Eclipse is quite convenient when managing hundreds of parameters and oscillators. Of course it is not a "sound" programming language itself like the ones disputed in this topic. But i then send the data to max objects like oscbank~ and resonators~. I now put all my algorithmic and calculation stuff in mxj -damned faster than max- and only use max for UI and audio.

I stopped since a long time with the [zl] nightmare, when you start to deal with lots of real time sensor datas and lists, i feel max is not good anymore for calculations. but as an UI environment max is really great. It have greats UI and audio objects. But one can also do audio in mxj~.

below is an example of algorithmic stuff i'm working on, made in java, which would not be easy/efficient in max.

Now if you use the result data of this example to put into some oscbank~ and resonators~ object, or into some sound oscillators in RTcmix/csound, i wouldn't be astonished that the cpu utilization would be the same. Am i wrong ?

>> I guess text based programming is good for controlling multiple parameter
>> synthesis and sound design, like hundreds of parameters of granular synthesis.

I'd like to put in a vote for java under mxj. Using mxj in max with Eclipse is quite convenient when managing hundreds of parameters and oscillators. Of course it is not a "sound" programming language itself like the ones disputed in this topic. But i then send the data to max objects like oscbank~ and resonators~. I now put all my algorithmic and calculation stuff in mxj -damned faster than max- and only use max for UI and audio. 

I stopped since a long time with the [zl] nightmare, when you start to deal with lots of real time sensor datas and lists, i feel max is not good anymore for calculations. but as an UI environment max is really great. It have greats UI and audio objects.  But one can also do audio in mxj~. 

below is an example of algorithmic stuff i'm working on, made in java, which would not be easy/efficient in max. 

Now if you use the result data of this example to put into some oscbank~ and resonators~ object, or into some sound oscillators in RTcmix/csound, i wouldn't be astonished that the cpu utilization would be the same. Am i wrong ?


One thing that really helps is good tutorials. Whatever about the syntax, you won't learn how to think the way the language needs you to think unless you have some practical exmaples to work through.

I found chuck's syntax and documentation pretty easy to get in to but could not find any substantial set of tutorials [like max comes with] where you're skills are built up gradually over time.

"Using mxj in max with Eclipse is quite convenient when managing hundreds of parameters and oscillators"

> I found chuck's syntax and documentation pretty easy to get in to but could not find any substantial set of tutorials

I recall chuck comes with a large set of examples. Not tutorials really, but good enough to get a grip of the environment.

The documentation of SuperCollider is lacking, and possibly the main reason that it is not more widely used. It is still a great piece of software though.

be careful here : javascript is not java. totally different things:

compiled language, almost as fast as c for calculations. (only the thread crossing bridge between max word(c) and mxj(java) can be sometimes a little bit slow if you forget to pack big list data using "outlet(int idx, float[] values)" optimized MaxObject methods.)

interpreted language, really really slow (almost as slow as max itself). i made some calculations few years ago : the same arithmetic calculation loop is about ONE HUNDRED TIMES SLOWER in a javascript object (or in max world using max objects, nearly the same speed), than in a mxj object using java. javascript. To me the only little advantage of javascript is that you can edit the code easily in max. With java, you have to recompile the code when modifying, but using the great Eclipse editor software, it's half a second. So i don't see the advantage of javascript.

look at the java examples in Max5/Cycling'74/java/help

java:
compiled language, almost as fast as c for calculations. (only the thread crossing bridge between max word(c) and mxj(java) can be sometimes a little bit slow if you forget to pack big list data using "outlet(int idx, float[] values)" optimized MaxObject methods.)

javascript:
interpreted language, really really slow (almost as slow as max itself). i made some calculations few years ago : the same arithmetic calculation loop is about ONE HUNDRED TIMES SLOWER  in a javascript object (or in max world using max objects, nearly the same speed), than in a mxj object using java. javascript. To me the only little advantage of javascript is that you can edit the code easily in max. With java, you have to recompile the code when modifying, but using the great Eclipse editor software, it's half a second. So i don't see the advantage of javascript. 

look at the java examples in Max5/Cycling'74/java/help


chuck vs. csound