Week 1

Super Collider blog- week 1

This week we were introduced to SuperCollider. According to course notes SuperCollider is a 'interpreted programming language for audio synthesis’. On opening up SuperCollider I was presented with a post window that already had some code in. There were also 2 GUIs one representing the local host server and one representing the internal server. In starting a new edit window I was presented with a blank slate. This could be considered as being slightly intimidating as you are not able to automatically move sliders or interact with graphics on the screen straight away to make sound. This is because the user needs to use a programming language that tells the machine to create and shape sounds. We were told that although it would take practice and perseverance SuperCollider is a very powerful tool for creating sound and it is nice to have a lot of control over the sounds you create.

In our first session our aim was simply to make the computer go "beep" by creating a sine tone and running it. We learnt that to run a line we needed the cursor to be on the line of code we wanted to run. Shift and enter held down together runs the line of code on a mac (which I was using) and cmd + period stopped the line running. Before we could run any sounds we needed to turn on the local host server by clicking 'boot’. We then made the computers talk by running: "I am SuperCollider 3".speak and then changing the words inside the speech marks. We then ran example code:

{Pan2.ar(SinOsc.ar(440,0,0.1),0.0)}.play

which plays a concert A tone. We had a go at changing the 440 (hz) to different frequencies. Each person in the group played their tone at the same time and we discussed how this was an example of additive synthesis which we will be learning more about in coming weeks.

We also played around with this example code:

{Pan2.ar(SinOsc.ar(MouseX.kr(440,880),0,0.1),0.0)}.play

This causes the tone to change when the mouse is moved which gives an initial demonstration of human interaction with Super Collider and how this can be used to change the sounds.

In our second session we started by running the code:

{SinOsc.ar(440)*0.5}.play

This runs a concert A tone. We noticed that the sound only plays through the left ear and is therefore monophonic. We then wrapped it in a Pan UGen (I’ll write more about UGens later) using:

{Pan2.ar(SinOsc.ar(440)*0.5)}.play

This caused the concert A tone to be in stereo and in the centre.

We then used:

{SinOsc.ar(MouseX.kr(440, 880))*0.1}.play

This meant that the mouse could be used to change the frequency of the note from between 440 hz and 880 hz.

I then changed the capital X in MouseX to a Y. This changed so that the mouse then used the Y axis to control the frequency of the tone. This meant that instead of moving the mouse left to right to change the tone (X axis) the tone was changed by moving the mouse up and down.

The *0.1 part of the code represents the volume of the tone. We then worked on adapting the code so that when using the mouse as the controller the Y axis changes the frequency of the tone and the X axis changes the volume:

{SinOsc.ar(MouseY.kr(10,10000))*MouseX.kr(0.0,1.0)}.play

We then talked about what .ar and .kr actually mean. Our tutor Nick got us to see how many times we could tap the table with our hand in a second. This was to give us an indication of haptic rate, of how fast we as a humans can do actions. If a machine was to track human actions it would be wasteful to have too much of a high sample rate.

Kr stands for Kontrol rate (spelt with a K because of Max Matthews music systems which used Kr). Ar stands for Audio rate.

The standard sample rate is 44100 hz. Kr is 1/64 of 44100 which equals 689 hz. The correct sample rate for your situation needs to be twice the highest frequency that can be represented. 689 represents up to 350 hz. When tapping the table we found it was only possible to do a certain amount of tapping (about 50hz) so it is therefore better to use the lower sample rate (Kr). As this is more efficient for the machine many different kontrol rates could be run on the machine at the same time.

We had a look at multi line programs; this is an example we were given:

(

{var n;

n=34;

Resonz.ar(

Mix.arFill(n,{

var freq, numcps;

freq= rrand(50,560.3);

numcps= rrand(2,20);

Pan2.ar(Gendy1.ar(6.rand,6.rand,1.0.rand,1.0.rand,freq ,freq, 1.0.rand, 1.0.rand, numcps, SinOsc.kr(exprand(0.02,0.2), 0, numcps/2, numcps/2), 0.5/(n.sqrt)), 1.0.rand2)

})

,MouseX.kr(100,2000), MouseY.kr(0.01,1.0))

;

}.play

)

We found that if you try running code with just the cursor on the line then SC will post an error message. This is because the computer thinks you are just running that one line of code, which without the other lines would be incomplete. Everything inside the main brackets needs to be highlighted in order for it to run, this can be done buy clicking just inside the first bracket, this highlights the block of code for you. This also makes it easier to see how the code is nested together.

We then started learning more about UGens. On the localhost server GUI it shows you the number of UGens that are being used in a synth. UGens are sound synthesis building blocks that are ‘plugged’ or ‘patched’ in together. SinOsc, Pan2, MouseX and MouseY are all examples of UGens. They all start with capital letters. There are 100s of Ugens in the SuperCollider system.

The paradigm of patching lots of building blocks together comes up in lots of software such as Audiomulch, MaxMSP and PD extended to name a few. In SuperCollider they are nested into one another.

In our example earlier:

{SinOsc.ar(MouseY.kr(10,10000))*MouseX.kr(0.0,1.0)}.play

UGens act as arguments to SinOsc.ar. To view the available arguments of a UGen, double click on the name of the UGen and press cmd+D.

We discussed why SC uses 2 servers. When you write code such as instructions for a synthesizer the local host server is on the same machine as the one you are running SC from and can be viewed in the activities monitor as SCsynth. If you used the internal server you would be running the synth inside the text editor so it wouldn’t be a separate application. We don’t often use the internal server because if we crashed the synth then we would also crash the text editor. This is quite hard to do but it is generally safer to use the local host. If you are using the local host server then it is also possible to run code from the local host server on other machines in the room or even a machine on the other side of the world. One machine could be used to control all the other synths in the room.

In order to get more familiar with SC I then looked at some example Super Collider code and tried adjusting the code and looked at the UGens used and how the code was nested together. I started by looking at an example called ‘babbling brook’ by James McCartney:

(

{

({RHPF.ar(OnePole.ar(BrownNoise.ar, 0.99), LPF.ar(BrownNoise.ar, 14)

* 400 + 500, 0.03, 0.003)}!2)

+ ({RHPF.ar(OnePole.ar(BrownNoise.ar, 0.99), LPF.ar(BrownNoise.ar, 20)

* 800 + 1000, 0.03, 0.005)}!2)

* 4

}.play

)

I used cmd+D to see what arguments the RHPF UGen had. I saw that these are (in,freq,q,mul,add). I asked my tutor about the nesting of the expressions and he said that it was maybe not the best example at the moment for nested expressions. This is because there are a lot of things nested into each other so not obvious straight away though part of what makes the code interesting is trying to find out how he plugged different Ugens together and structured the code.

I played around with tweaking some of the numbers such as changing the volume of the BrownNoise UGen (BrownNoise.ar, 0.99) by changing 0.99 to 0.10. This caused the babbling brook sound to get louder and much more distorted.

I then tried to get familiar with which part of the code controlled different aspects of the sound for example I found that when I changed the 400 and 500 values from:

* 400 + 500, 0.03, 0.003)}!2) part of the code to 800 + 900 the sound got higher and when I changed it to 100 + 200 the sound got much lower. These numbers must therefore have affected the frequency of the sound.