## The Molecular Music Box in SuperCollider

posted by on 2014.08.19, under Supercollider
19:

Via Reaktor tutorials I came across this video. I have already talked about generative systems that create rich patterns (see here, and here), and how simple rules can give rise to emergent complexity.
Watch the video to know what the simple rules are in this case (and to see why it is called “molecular” ), or look at the following SuperCollider code, which, I must say, took me a bit more than I thought

MIDIClient.init;

~mOut = MIDIOut.new(3);

(
var seed = 48;
var degrees, deg;
var length = Pseq([4, 3], inf).asStream;
var dur = length.next();
var bars = 25;
var quant = 16;
var notes = [];
var loop = [];
var pos = [];
var next = 0;

degrees = [];

//Building the MIDI values for the white keys

9.do({|i|
degrees = degrees++([0, 2, 4, 5, 7, 9, 11] + (12*i));
});

//Starting notes from the seed

deg = Pseq(degrees, inf, degrees.indexOf(seed)).asStream;

(bars * quant).do({|i|
var note;

if((i%quant == 0) && (notes != []),
{
notes = [];
});

if((i%quant == next) && (pos.includes(next) == false),{
next = (next + dur)%quant;
});

if ( (i%quant == next) && (pos.includes(next) == true),{
dur = length.next();
next = (next + dur)%quant;
});

});

loop.do({|patt, i|
patt.postln;
patterns = patterns++([i * 4, Pbind(*[\type,\midi,\chan,0,
\midiout,~mOut,
[\midinote, \dur]: Pseq(patt, inf),
\legato: 1,
\amp: rrand(0.1,0.5)])]);
});

Ptpar(patterns, 1).trace.play;
)

Notice that you can very easily change any of the rules (duration length, scale used, etc.) with a few keyboard strokes: the power of a text based programming language!
I have sent the output of this to the Grand Piano instrument in Ableton Live 9.
Here is the result for 4C3

and here is the one for 9C14½

## Objects manipulation in SuperCollider and Synths generation

posted by on 2014.08.18, under Supercollider
18:

In the last post, I wrote about some object oriented techniques in Processing which simplyfied our code, and gave the possibilty to reason more abstractly. Also SuperCollider is an object oriented programming language, and in this little example below I want to explore a situation where we can really take advantage of this: it somehow belongs to the category of “things one (or I?) can’t really do in Max/Msp, Reaktor, etc.”.
Here’s the simple situation: suppose we want to create 100 different percussive sounds with FM synthesis, with random waveforms as carrier, random harmonics for the modulating signal, etc., and play them randomly. We don’t want to change the sounds later, just play them. So, the first strategy we could adopt is the dirty and cheap no-brainer approach, which works along the following lines: well, what I will do is to create a SynthDef, i.e. an audio graph on the server, which is “big” enough to encompass the various possibilities of sounds, store the various randomly created combinations of waveforms, frequencies, etc. in an array, and poll these data when needed. The SynthDef would look like

SynthDef(\perc, { arg out = 0, freq = 0, decay = 0.5, pan = 0, depth = 1, waveform = 0, harm = 0;
var sig = Select.ar(waveform, [SinOsc.ar(freq + (SinOsc.ar(harm * freq) * depth)), Saw.ar(freq + (SinOsc.ar(harm * freq) * depth))]);
var env = EnvGen.kr(Env.perc(0.01, decay), doneAction: 2);
Out.ar(out, Pan2.ar(LPF.ar(sig * env * 0.1, 3000), pan));

Setting the parameter waveform will choose among the waveforms, freq will determine the frequency, etc. A big array (or dictionary, if you prefer) with randomly generated values, and I’m done!
Well, yeah, this approach will work, but it’s quite ugly, and, more importantly, inefficient: indeed, for each Synth created, a copy is kept of the two waveforms, only one of which is heard. So, for each percussion sound, we allocate twice what we need. Remember that there is a difference between not having a sound generator on the audio server, and having one which is muted, since in the second case, the sample rate computations are performed anyways.
Let’s think about this situation from a different angle, which makes more use of the language capabilities of SuperCollider. What we really need are different percussion sounds: they are different enough to be considered not as different instances of the same SynthDefs, but rather as instances of different SynthDefs. Instead of having SuperCollider creating different Synth instances, we can tell it to create different SynthDefs! Indeed, consider the following code (assuming a given choice for the range of the parameters)

100.do({|i|
var name;
name = "perc"++i;
SynthDef(name, { arg out = 0;
var freq = [24, 57, 68, 29, 87, 39, 70].choose.midicps;
var decay =  rrand(0.1, 0.5);
var pan = rrand(-1.0, 1.0);
var sig = [SinOsc, Saw].choose.ar(freq + (SinOsc.ar([0, 1, 2, 3, 4].choose*freq*rrand(1, 30))))*0.1;
var env = EnvGen.kr(Env.perc(0.01, decay), doneAction: 2);
Out.ar(out, Pan2.ar(LPF.ar(sig*env, 3000), pan));
})
});

First, we are defining names with which we can refer to the SynthDef: this is easily done, since a name for a Synth is a string (or a symbol), and we can obtain each of them by concatenating a string (in this case “perc”) with the counter index. Next, we define different SynthDefs: the beautiful thing that makes this work in a nice way is contained in the part

[SinOsc, Saw].choose.ar()

Remember: SuperCollider is object oriented, and in most cases, even if we don’t think about it, we are dealing with objects. Indeed, when we write something like SinOsc.ar(440), we are actually creating an object of type SinOsc, and sending to it the value 440 via the method .ar (which stands for “audio rate”), which provides the necessary computations to produce audio on scsynth, the audio server. Since SinOsc, Saw, etc are an “extension” of the class UGen (more or less), we can make a list (or Collection) with objects of this type, and use the powerful collection manipulation methods provided by SuperCollider (in this case the method .choose). Since both SinOsc and Saw react in the same way to the method .ar (this is an example of “polymorphism”), we can have it follow the method .choose, and pass everything in the round brackets. In this way the SynthDef itself will only have one copy of the choosen waveform per name.
This way of reasoning might look a bit abstract at the beginning, but it’s based on a simple concept: everything that require repetitive actions is best left to a programming language! Moreover, since SuperCollider is heavily object oriented, it gives really serious manipulations possibilities, as we have seen. We used already an incarnation of this concept when we built graphical interfaces.
Finally, the percussive sounds can be played via something like this

fork{
inf.do({
i = rrand(0, 99);
Synth("perc"++i);
rrand(0.1, 0.4).wait;
})
}

Here’s the complete code

s.boot;

(

var reverb, delay;
reverb = Bus.audio(s, 2);
delay = Bus.audio(s, 2);

SynthDef(\reverb, {arg out = 0, in;
var sig = In.ar(in, 2);
sig = FreeVerb.ar(sig);
Out.ar(out, sig);

SynthDef(\delay, {arg out = 0, in;
var sig = In.ar(in, 2) + LocalIn.ar(2);
LocalOut.ar(DelayL.ar(sig, 0.5, 0.1)*0.8);
Out.ar(out, sig);

fork{

100.do({|i|
var name;
name = "perc"++i;
SynthDef(name, { arg out = 0;
var freq = [24, 57, 68, 29, 87, 39, 70].choose.midicps;
var decay =  rrand(0.1, 0.5);
var pan = rrand(-1.0, 1.0);
var sig = [SinOsc, Saw].choose.ar(freq + (SinOsc.ar([0, 1, 2, 3, 4].choose*freq*rrand(1, 30))))*0.1;
var env = EnvGen.kr(Env.perc(0.01, decay), doneAction: 2);
Out.ar(out, Pan2.ar(LPF.ar(sig*env, 3000), pan));
});

s.sync;

Synth(\reverb, [\in: reverb]);
Synth(\delay, [\in: delay]);

inf.do({
i = rrand(0, 99);
Synth("perc"++i, [\out: [reverb, delay].choose]);
rrand(0.1, 0.4).wait;
})
}
)

I have added some reverb and delay to taste.
Notice that this code illustrate only the tip of the iceberg concerning what you can achieve with an object oriented approach to structure your code.
No audio this time, since it is not that interesting.

## Colliding particles and the power of abstraction

posted by on 2014.08.17, under Processing
17:

This code is a nice playground for some advanced aspects of Object Oriented Programming (OOP): it is simple enough to be interesting, and show the power and elegance of a more abstract approach to programming. What does the code do? It generates a number of bouncing particles which disappear when colliding with each other. Pretty simple. Now, in general, when you have to test a condition for an object against the totality of objects present, you may run soon in annoying cycles which can obscure the code itself, making it less readable, and which would be best avoided. To do this, I need to introduce one easy, but extremely important observation on how function in Processing (and Java, and many other languages) work: “Objects to a function are passed by reference“. Remember this, write it somewhere, do whatever but don’t forget it. “Oookay”, you say, “but, what does “passed by reference” even mean? What’s a “reference”?”. In OOP, objects are instantiated as initialized references, which means the following: suppose we have a class Ball (with empty constructor), and the following piece of code

Ball p;
p = new Ball();

In plain English, the code above says: create a label p which labels an object of type Ball, then create an object of type Ball, and attach to it the label p. In other words, p is *not* the object*, but it is just a label “referencing” the actual Ball object. Indeed, if we add the following piece of code

Ball q;
q = p;

we are asking to create a new label q, referencing to the same object p is referencing. Now, as soon as we modify the actual object which is referenced, these modifications will reflect on the behaviour of p and q. For instance, suppose that the class Ball has a field a, of type integer, which is initialized to 10. Then the following code

println(q.a);
p.a = 15;
println(q.a);

will return 10, and then 15. In other words, changing p has changed *also* q, and the reason is that we are really not changing p, but rather the object p references to. A bit confusing, right? Neverthless I bet you have seen this behaviour before, if you have ever used (and who hasn’t) arrays.
Indeed, this piece of code would give the same results;

int[] p = new int[10];
int[] q;
q = p;
q[0] = 10;
p[0] = 15;
println(q[0]);

Okay, we are ready to talk about “passing by reference”**. Suppose you have a function

void f(Ball b){
do something;
}

and suppose we evaluate it on p, as in f(p). What happens is that b becomes a reference to the object referenced by p (as in b = p). So, if you modify b inside the scope of f, then you are really modifying the referenced object, and hence also p. Of course, the same is true for arrays, so be careful with what you do inside the scope of a function, when arrays are involved.
Supposing this is more or less, clear, the question remains: why caring about this for some stupid balls? Well, this simple observation allows to define something like this

class Ball{
int a;
Ball[] balls;

Ball(int _a, Ball[] _balls){
a  = 10;
balls = _balls;
}
}

Wait, what’s going on here? Am I defining a class Ball in which one of its fields is an array of objects of type… Ball?! Like, isn’t there gonna be a nasty recursion type of end of the universe OMG!!
Calm down, nothing’s bad gonna happen. And the reason lies in the simple observations above: objects variable (and arrays) are defined as reference, and they need to be initialized. In the case above, we are asking for a label balls which is a reference to an array of type Ball: at this point we are *not* calling the constructor Ball( ). When it will be called, though, the array balls will reference to the same array referenced by the label (or variable) _balls. Here we are using that objects are passed to functions by reference (the constructor, in this case). Nice, uh?
Notice that, on the other hand, this piece of code

class Ball{
int a;
Ball p;

Ball(int _a){
a  = 10;
p = new Ball();
}
}

will give a nasty recursion, since we are indeed calling the constructor inside itself.
Ok, still, what do we do with this?

Here’s the Processing code

int num = 50;
ArrayList<Particle> partls;

void setup(){
size(600, 600);
background(0);
partls = new ArrayList<Particle>();

for (int i = 0; i < num; i++){
partls.add(new Particle(random(0, width), random(0, height), partls));
}
}

void draw(){
ArrayList<Particle> remove = new ArrayList<Particle>();
background(0);

for (Particle par: partls){
par.update();
par.display();
}

for (Particle par: partls){
}

for (Particle par: remove){
partls.remove(par);
}
}

///Define the class Particle

class Particle{
float x, y, vx, vy, r;
ArrayList<Particle> others;

Particle(float _x, float _y, ArrayList<Particle> _others){
x = _x;
y = _y;
vx = random(-5, 5);
vy = random(-5, 5);
others = _others;
r = 20;
}

void update(){
if ( x <=0 || x >= width) vx = -vx;
if ( y <=0 || y >= height) vy = -vy;

x = (x + vx);
y = (y + vy);
}

void display(){
fill(255, 200);
ellipse(x, y, r, r);
}

boolean collide(){
boolean b = false;
for (Particle p: others){
if (dist(x, y, p.x, p.y) <= r & dist(x, y, p.x, p.y) > 0.0){
b = true;
}
}
return b;
}

}

Let’s look at the Particle class. Among other fields, we have others, an ArrayList of type Particle, which refers to the ArrayList _others passed to the constructor. The variable others is used in the method collide, which tests the distance between the instantiated object and all the particles in the list others, and returns the value true if a collision happens (the condition dist(x, y, p.x, p.y) > 0.0 ensures no self-collision). Also, notice the “enhanced” for loop, which is pretty elegant.
Now, the magic appears in the main code, namely in

partls = new ArrayList();

for (int i = 0; i < num; i++){
partls.add(new Particle(random(0, width), random(0, height), partls));
}

The first line initializes the variable partls as an (empty) ArrayList of type Particle. In the for loop, we add to partls some objects of type Particle by passing to the constructor the required fields: x, y, and others. Since objects are passed by reference to the constructor, this means that, at the end of the for loop, for each object instance of Particle the field others will reference to the same ArrayList referenced by partls, which, by construction, is an ArrayList in which each element is exactly the object Particle created in the for loop. The reference partls gets modified at each iteration of the cycle, and since we are passing it by reference, this modification will reflect also on the variable others. Pretty cool, uh?
This is quite a convenient way to manage collisions. Indeed, in the draw() function we have first the usual (enhanced) for loop which updates, and displays the particles. Then we check for collisions: if the particle collides with any other particle, we add it to a remove list. We need to do this, instead of removing it on the spot, because otherwise only one of the two particles involved in a collision would get removed. Finally, we have another for loop, in order to dispose of the colliding particles.
Everything is pretty elegant and compact, and most importantly, the code is more readable this way!
No video this time, since it’s pretty visually uninteresting.

*Not 100% true, but pretty close.
**There exists also the notion of “passing by value”.

## Polygonal Camera

posted by on 2014.08.13, under Processing
13:

It has been a while since my last update, and in particular since my last Processing code! So, here’s something very simple. Basically, it’s a grid of points connected by lines, which form the edges of polygons. The points move almost periodically: each of them undergoes an oscillatory motion, to which I’ve added a bit of noise, to make things more interesting. The polygons, which during the motion change their shape as the vertices move, are colored. Here comes the nice part: the color of a single polygon is given by taking at its geometric center the color of the pixel of the image obtained by capturing a frame via the webcam. In this way, the colors are “smeared”, but you can still somehow discern the webcam input. Here’s the code.

import processing.video.*;

Capture cam;

int n = 30;
float t = 0;
Point[][] points = new Point[n][n];

void setup(){
size(320, 240);
cam = new Capture(this, 320, 240, 30);
cam.start();
background(0);

/* Setup the grid;
for (int i = 0; i < n; i++)
{
for (int j = 0; j < n; j++)
{
points[i][j] = new Point(i*width/n, j*height/n);
}
}
}

void draw(){
if(cam.available()) {
}
background(0);
for (int i = 0; i < n; i++)
{
for (int j = 0; j < n; j++)
{
points[i][j].move();
points[i][j].display();
}
}
grid(points);
t+= 0.1;
}

void grid(Point[][] gr){
int c_x, c_y;
for (int i = 0 ; i < n; i++){
for (int j = 0; j < n; j++){
if ( j < n -1 && i < n - 1){
stroke(255, 100);
/* Compute the geometric center;

c_x = constrain(int((gr[i][j].pos.x + gr[i][j + 1].pos.x + gr[i + 1][j + 1].pos.x + gr[i + 1][j].pos.x)/4), 0, width);
c_y = constrain(int((gr[i][j].pos.y + gr[i][j + 1].pos.y + gr[i + 1][j + 1].pos.y + gr[i + 1][j].pos.y)/4), 0, height);

/* Create the polygon;
fill(cam.pixels[constrain(c_x + width*c_y, 0, cam.pixels.length - 1)], 250);
beginShape();
vertex(gr[i][j].pos.x, gr[i][j].pos.y);
vertex(gr[i][j + 1].pos.x, gr[i][j + 1].pos.y);
vertex(gr[i + 1][j + 1].pos.x, gr[i + 1][j + 1].pos.y);
vertex(gr[i + 1][j].pos.x, gr[i + 1][j].pos.y);
endShape();
}
}
}
}

/* Define the class Point

class Point{
PVector pos;
float angle;
float depth;
PVector dir;
float phase;
float vel;

Point(float _x, float _y){
pos = new PVector(_x, _y);
angle = random(0.0, 2*PI);
depth = random(0.8, 2.4);
dir = new PVector(cos(angle), sin(angle));
vel = random(0.5, 1.5);
}

void display(){
noStroke();
fill(255, 255);
ellipse(pos.x, pos.y, 4, 4);
}

void move(){
/* Oscillatory motion with noise which depends on the "time" variable t;
pos.x = pos.x + dir.x * cos(vel*t + noise(t*angle)*0.1) * depth;
pos.y = pos.y + dir.y * cos(vel*t + noise(t*angle)*0.1) * depth;
}

}

Warning: Kids, don’t code the way I do! In this case I was particularly lazy: indeed, a more elegant way to do it would have been to create another class, say Grid, and hide there the polygon making, etc. The code would have been more readable and reusable, that way. But as I said, lazyness.

Here’s a little video of what you get

## Drones, drones, drones

posted by on 2014.07.05, under Supercollider
05:

Who doesn’t like ambient drones? Ok, I guess some people might not like them.
Here’s a little code in SuperCollider to generate a kind of feedbacky ambient atmosphere. It does look involved, but it isn’t. The main thing is using Wavetable synthesis : what the method .sine1Msg does is to fill the buffer b with a sinewave (of 512 sample “period”), and its harmonics, whose number and amplitudes are specified in the array parameter of the method. Then we can “play” the wavetable with Osc.ar, which is a wavetable oscillator. Moreover, for added noisyness and ambience, I have added a bitcrusher with randomly varying samplerate and bit depth, and also a sample player playing the buffer c, which is not too loud, and just contributes to textures. You could modify it easily to load multiple samples, and choose between them. The last part involves a nice trick I learned here : basically, you stack a certain number of short time delays, and use a feedback line to simulate a reverberation effect. In particular, if the feedback parameter is 1, you get an “infinite reverb”. Very cool. Be careful not to keep feeding input in this situation, otherwise you will get the usual feedback headache!

s.boot;

(
b = Buffer.alloc(s,512,1,{|z|z.sine1Msg(1.0/[1,3,5,7,9,11,13,15,17])});

fork{
s.sync;
~sound = {
var sig;
var local;
var f = [30,60,15]*Lag.kr(TChoose.kr(Impulse.kr(0.05),[0.75, 0.5, 1]), 8);
sig = Mix(COsc.ar(b.bufnum,f + SinOsc.ar(f*25, 0, LFTri.kr(0.01).range(0, 10)), [0.1, 0.1001, 0.2], 0.2))*0.1;
sig = sig;
sig = LeakDC.ar(Ringz.ar(sig, TChoose.kr(Impulse.kr(0.1),[88, 97, 99, 100].midicps), LFTri.kr([0.05, 0.051]).range(0.2, 0.5)));
sig = sig + Decimator.ar(sig, 48000*LFNoise0.kr(1).range(0.25, 1), TChoose.kr(Impulse.kr(4), [8, 12, 16, 24]), 0.4);
sig = LPF.ar(sig, 3000*LFTri.kr(0.01).range(0.1, 1));
sig = sig + (Splay.ar(Array.fill(4, {PlayBuf.ar(2, c, rrand(-0.8, 0.8), loop: 2)*0.01}), 0.5));
sig = CombC.ar(sig, 1.0, [0.1, 0.2], LFTri.kr(0.05).range(5, 9));

local = sig + LocalIn.ar(2);
15.do({
local = AllpassN.ar(local, 0.06, Rand(0.001, 0.06), 3)
});
LocalOut.ar(local*0.4);

Out.ar(0, Limiter.ar(LPF.ar(local, 4000), 0.8)*EnvGen.kr(Env([0, 1, 1, 0],[3, 100, 10])));
}.play;
}
)

s.quit;

You can listen to the result here

## Tides on the Sea of Tranquillity

posted by on 2014.03.04, under Supercollider
04:

A quick post, since it is a while I’m not updating this.
Here’s a short track, “Tides on the Sea of Tranquillity”, built around one of my favourite UGens in SuperCollider: GrainBuf. GrainBuf is a buffer granulizer which is very flexible.
The idea for the track is quite simple: there are four granulizers, which get activated at a certain point, whose parameters are controlled by the loops in the Task. In particular, the position parameter for each of them is “lagged”, so that at each change it will start from the middle of the buffer, and reach the new value in a given time. Also, the spread, pitch, and pan are jittered, to give a spacey feeling. The other important part is that the rate for the grains are controlled via the .midiratio method, which allows to vary the pitch according to a temperate scale, hence giving some harmonic consistency. To end, everything is passed to a feedback delay line with a simple compressor.
One technical point: make sure you load buffers which are mono in GrainBuf, otherwise it will fail silently! Some times ago it took me ages to figure this out (I know, the documentation says so…).
Enjoy.

s.boot;

(
fork({

//Define SynthDefs for the granulizers and delay

SynthDef(\granular, {arg out = 0, buff, pos = 0, spread = 0.05, dur = 0.40, p = 0.5, t_trig = 0, rate= 1, t = 300, a = 0.1, l = 1, pa = 0, att = 6, f = 100;
var trigger = Impulse.ar(t);
var pan = TRand.ar((-1)*p, p, trigger);
var sig = GrainBuf.ar(1, trigger, dur, buff, rate + LFNoise0.ar(f).range(-0.01, 0.01), Lag.kr(pos, l) + sp, pan:pan);
var env = EnvGen.kr(Env.linen(att, 4, 8), gate: t_trig, doneAction:0);
Out.ar(out, Pan2.ar(sig*env*a, pa));

SynthDef(\del, {arg out = 0, in, feed = 0.93;
var sig = In.ar(in, 2) + LocalIn.ar(2);
var delL = DelayL.ar(sig[0], 2.0, 0.2);
var delR = DelayL.ar(sig[1], 2.0, 0.5);
LocalOut.ar([delL, delR]*feed);
Out.ar(out, Compander.ar(sig, sig, 0.5, 1, 0.5, 0.01, 0.3));

// Load samples in mono buffers and create a audio bus for delay
~path = PathName(thisProcess.nowExecutingPath).pathOnly;

~del = Bus.audio(s, 2);

~buff = Buffer.readChannel(s, ~path ++ "sample/sample1.wav", channels: [0]);
~buff2 = Buffer.readChannel(s, ~path ++ "sample/sample2.wav", channels: [0]);
~buff3 = Buffer.readChannel(s, ~path ++ "sample/sample3.wav", channels: [0]);
~buff4 = Buffer.readChannel(s, ~path ++ "sample/sample4.wav", channels: [0]);
~buff5 = Buffer.readChannel(s, ~path ++ "sample/sample5.wav", channels: [0]);

s.sync; //Wait for the buffers to be loaded;

y = Synth(\del, [\in: ~del]);

// Make an array of synths to be used as voices

~synths = Array.fill(3, {Synth(\granular, [\buff: ~buff, \t_trig:0, \pos: 0.5, \rate: ([0, 4, 5, 7, 9, 12, 16, 17] - 12).choose.midiratio, \spread: 0.05, \out:~del ])});

10.do({
~synths[0].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17] - 12).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

rrand(4, 9).wait;
});

30.do({
~synths[0].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17] - 12).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

~synths[1].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17]).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.01, 0.05), \f, rrand(50, 150));

rrand(0.1, 4).wait;

});

20.do({
~synths[0].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17] - 12).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

~synths[1].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17]).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

~synths[2].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17] + 12).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

rrand(0.1, 3).wait;

});
10.do({
~synths[0].set(\buff, [~buff, ~buff2, ~buff3, ~buff4, ~buff5].wchoose([0.5, 0.3, 0.1, 0.08, 0.02]), \t_trig, 1, \t, rrand(10, 400), \dur, rrand(0.020, 0.40), \pos, rrand(0.0, 0.8), \l, rrand(0.4, 4), \rate, ([0, 4, 5, 7, 9, 12, 16, 17] - 12).choose.midiratio, \spread, rrand(0.005, 0.1), \p, rrand(-0.3, 0.3), \out, ~del, \pa, rrand(-0.5, 0.5), \att, rrand(6, 9), \a, rrand(0.05, 0.1), \f, rrand(50, 150));

rrand(1, 3).wait;

});

}).play(quant: 4);
})
)

## A sequenced fx machine

posted by on 2014.01.19, under Supercollider
19:

Ever wondered how to make a sequenced fx machine, where the effects cut each other out (like dbGlitch, say)? Here’s a very simple example

SynthDef(\fx, {arg out = 0, in, trig = 0, lag = 0.1, grid = 1/2, bit = 7, sample = 5000;
var sig, del;
sig = In.ar(in,2)*0.5 + Select.ar(trig, [In.ar(in, 2)*0.5, LocalIn.ar(2), LPF.ar(Decimator.ar(In.ar(in,2)*0.5, sample, bit), 6000)]);
del = DelayL.ar(sig, 1.0, Lag.kr(grid, lag));
LocalOut.ar(HPF.ar(del*(trig.clip(0, 1)), 2000));
Out.ar(out, Pan2.ar(sig[0], TRand.kr(-0.5, 0.5, trig)*trig));

which uses the Ugen Select.ar, which functions as a “one-to-many” audio switch*. The delay part works as a simple beat repeater, and the other effect is a bit-crusher. After instantiating an audio bus, you can then delegate the sequencing to a Pmono

~rep = Bus.audio(s, 2);

Pmono(\fx, *[\trig : Pwrand([0, 1, 2], [0.4, 0.3, 0.3], inf),
\grid: Prand([1/2, 1/4, 1/8, 1/16], inf),
\bit: Prand([7, 10, 8, 24], inf),
\sample: Pwhite(1000, 10100, inf),
\lag: Pwhite(0, 0.1, inf),
\in: ~rep,
\dur: 1/8]).play(quant: 4);

Whatever you send to ~rep will be processed by the fx SynthDef (be careful with the order of execution, or use Group to be on the safe side). If you have already SynthDefs for the single effects you would like to use, it is more convenient to send the audio to single busses, and then add a SynthDef at the tail of the synth chain containing a Select.ar Ugen which will choose among the different effects. You will have to run additional Pmonos to control the various parameters, though.
Notice that this approach to sequenced fx machines is quite expensive, since the various effects will run constantly on the server.
Anyway, in this simple case it sounds like

*You can use a similar approach in Max/Msp, Reaktor, etc.

## First L!vE K@ding session!

posted by on 2014.01.13, under Supercollider
13:

As promised, here’s my first live coding screencast! The video unfortunately turned out to be not very good: ffmpeg on Linux failed me miserably. I thought it was worth sharing anyways, so, here it is.
Some comments: I have used some SynthDefs that I have already prepared and some samples that I have loaded beforehand. This is achieved by the tabs “initialize” and “synths” that you see in the video. This is not a “blank page” approach to live coding, but it’s what I have realized works for me, since I am more interested in improvising patterns than the actual sound synthesis (which I also did in this session, by the way). In particular, one of the SynthDefs which I am really liking is \looper, a custom made looper which allows me to capture audio from other synths and control its parameters to get nice glitchy patterns. I’m really liking it. On the other end, \pad_fm is a very simple pad with fm modulation. Of course, if anybody is interested in these SynthDefs I will certainly share.
Oh, also almost everything happens in ProxySpace.
Enjoy

## New Year Resolutions

posted by on 2013.12.31, under Uncategorized
31:

Here’s that time of the year when you make those resolutions you’ll never gonna keep. I’ll make mine and I’ll try to stick to it, hopefully. Well, what is it? Very simple: I want to practice more and more regularly live coding in SuperCollider AND record audio sessions, and post them here in a section called “L!vE K@ding”. I’m not sure I will be posting codes about it, though, ’cause when I live code I get very messy. But I’ll be happy to discuss techniques, etc., what I do, and don’t. Let me add I’m not an expert at all, and there’s some great people out there doing excellent things. But you know what? If you never start, you’ll never learn. The session is not perfect? Who cares, that’s how “live” is.
So, watch this space, if you are interested.
Meanwhile, Happy New Coding Year!

## Finite fields and musical phrasings

posted by on 2013.12.20, under Supercollider
20:

In this post I want to talk about musical phrasings in algorithmic composition and algebra over finite fields. Yep, algebra, so brace yourself  :-).
I am pretty sure you have been exposed to clock arithmetic: basically, you consider integer numbers modulo a natural number p. Now, in the case p is a prime, the commutative ring $\mathbb{Z}_{p}$ is actually a field with finite elements. There is a name for that, and it is finite field, or Galois* field.
Now consider a pxp-matrix A with entries in $\mathbb{Z}_{p}\:$: A will give us a map $\varphi_{A}$ from $\mathbb{Z}_{p}$ to itself via

$\varphi_{A}(i):=\sum_{j=0\ldots p-1}(A_{ij}\:j)\:{\rm mod}\:p$

where $A_{ij}$ are the entries of A. Now, consider a function f from $\mathbb{Z}_{p}$ to a finite set S, and consider the subgroup P of the group of permutations of p objects given by elements $\pi$ satifying

$f(\pi(i)) = f(i)$

If the function f is not injective, this subgroup will be not empty. Notice that for any function f of the type above, the matrix A gives us another function $A^{*}f$ defined as**

$A^{*}f(i):=f(\varphi_{A}(i))$

Now we can ask ourselves: given a function f, can we find a matrix A such that

$(A^{*})^{k}f = f$

for some natural number k? What this means is that we want to find a matrix such that applied k-times to the function f returns the function itself. This problem is equivalent to finding a matrix A such that

$A^{k} = \pi,\quad\pi\in{P}$

In the case in which the function f is injective, this coincides with the problem of finding idempotents matrices in a finite field: the fantastic thing is that they are known to exist***, and even better their number is known in many situations!
“Ok, now, what all of this has to do with musical phrasing?! No, seriously, I’m getting annoyed, what really? ”
I hear your concern, but as with almost everything in life, it’s just a matter of perspective. So, consider the set S as a set of pairs (pitch, duration) for a note. A function f above will tell us in which order we play a note and what is the duration of each note: in other words, it is a musical phrasing. By picking a matrix A, we can generate from f a new phrasing, given by the function $A^{*}f$, and we can reiterate the process. If A is such that it satisfies the condition above, after a finite number of steps, the phrasing will repeat. Hence, the following Supercollider code

s.boot;

SynthDef(\mall,{arg out=0,note, amp = 1;
var sig=Array.fill(3,{|n| SinOsc.ar(note.midicps*(n+1),0,0.3)}).sum;
var env=EnvGen.kr(Env.perc(0.01,1.2), doneAction:2);
Out.ar(out, sig*env*amp!2);

(
var matrix, index, ind, notes, times, n, a;

notes = [48, 53, 52, 57, 53, 59, 60] + 12;
times = [1/2, 1/2, 1, 1/2, 1/2, 1, 1]*0.5;
n = 7;
matrix = Array.fill(n,{Array.fill(n, {rrand(0, n-1);})});
index = (0..(n-1));

a = Prout({
inf.do({
ind = [];

matrix.collect({|row|
ind = ind ++ [(row * index).sum % n];
((row * index).sum % n).yield;
});
index = ind;

});
});

Pbind(*[\instrument: \mall, \index: a, \note: Pfunc({|ev| notes[ev[\index]];}), \dur:Pfunc({|ev|
times[ev[\index]];})]).trace.play;
)

s.quit;

represents a “sonification” of the probability distribution of finding a matrix A with the properties above, for p=7. We are assuming that the various matrices have equal probability to be generated in the code above.
So, how does this sound?
Like this