28:
In this post I’ll not show you any code, but I want to talk about coding, instead, in particular about “live coding”.
All the various codes you have seen on this blog share a common feature: they are “static”.
I’ll try to explain it better.
When you write a code in a programming language, you may have in mind the following situation: you write down some instructions for the machine to execute, you tell the compiler to compile, and wait for the “result”. By result here I don’t mean simply a numerical or any other output which is “time independent”: I mean more generally (and very vaguely) the process the machine was instructed to perform. For instance, an animation in Processing or a musical composition in SuperCollider is for sure not static by any mean, since it requires the existence of time itself to make sense. Neverthless, the code itself, once the process is happening (at “runtime”), it is static: it is immutable, it cannot be modified. Imagine the compiler like an orchestra director, who instructs the musicians with a score written by a composer: the composer cannot intervene in the middle of the execution, and change the next four measures for the violin and the trombone. Or could he?
Equivalentely, could it be possible to change part of a code while it is running? This would have a great impact on the various artistic situations where coding it is used, because it would allow to “improvise” the rules of the game, the instructions the machine was told to blindly follow.
The answer is yeah, it is possible. And more interestingly, people do it.
According to the Holy Grail of Knowledge
”Live coding (sometimes referred to as ‘on-the-fly programming’, ‘just in time programming’) is a programming practice centred upon the use of improvised interactive programming. Live coding is often used to create sound and image based digital media, and is particularly prevalent in computer music, combining algorithmic composition with improvisation.”
So, why doing live coding? Well, if you are into electronic music, maybe of the dancey type, you can get very soon a “press play” feeling, and maybe look for possibilities to improvise (if you are into improvising, anyways).
It may build that performing tension, experienced by live musicans, for instance, which can produce nice creative effects. This doesn’t mean that everything which is live coded is going to be great, in the same way as it is not true that going to a live concert is going to be a great experience. I’m not a live coder expert, but I can assure you it is quite fun, and gives stronger type of performing feelings than just triggering clips with a MIDI controller.
If you are curious about live coding in SuperCollider, words like ProxySpace, Ndef, Pdef, Tdef, etc. will come useful. Also, the chapter on Just In Time Programming from the SuperCollider Book is a must.
I realize I could go on blabbering for a long time about this, but I’ll instead do something useful, and list some links, which should give you an idea on what’s happening in this field.
I guess you can’t rightly talk about live coding without mentioning TOPLAP.
A nice guest post by Alex Mclean about live coding and music.
Here’s Andrew Sorensen live coding a Disklavier in Impromptu.
Benoit and The Mandelbrots, a live coding band.
Algorave: if the name does suggest you that it’s algorithmic dancey music, then you are correct! Watch Norah Lorway perform in London.
The list could go on, and on, and on…
18:
This code came out by playing with particle systems in Processing.
I have talked about particle systems in the post before in the context of generating a still image. In this particle system there is an important and conceptual difference, though: the number of particles is not conserved. Each particle has a life span, after which the particle is removed from the system: this is done by using ArrayList rather than a simple array. In the rendered video below, you will see clearly that particles start to disappear. The disappearing of particles could have been in principle obtained by simply gradually reducing the opacity of a given particle to 0, rather than removing it: in other words, the particle is still there, it’s only invisible. In the particle system I have used, the two approaches make no difference, apart from saving computational resources (which still is a big deal!), since the particles do not interact among each other. If inter particle interactions were present, the situation would be completely different: an invisible particle would still interact with the others, hence it would not be really “dead”.
Believe it or not, to accept the fact that the number of particles in a system might not be conserved required at the beginning of the 20th century a huge paradigm shift in the way physical systems, in particular at the quantum scale, are described, giving a good reason (among others) to develop a new physical framework, called Quantum Field Theory.
import processing.opengl.*;
int N=500*30;
ArrayList<Part> particles= new ArrayList<Part>();
float t=0;
float p=1;
float centx,centy,centz;
float s=0.01;
float alpha=0;
float st=0;
void setup(){
size(500,500,OPENGL);
background(0);
directionalLight(126, 126, 126, 0, 0, -1);
ambientLight(102, 102, 102);
centx=width/2;
centy=height/2;
centz=0;
for (int i=0;i<N;i++){
float r=random(0,500);
float omega=random(0,360);
particles.add(new Part(new PVector(width/2+r*sin(radians(omega)),height/2+r*cos(radians(omega)),0)));
};
for (int i=0;i<particles.size();i++){
Part p=particles.get(i);
p.display();
};
};
void draw(){
if (random(0.0,1.0)<0.01) {
t=0;
st=random(0.002,0.003);
p=random(1.0,1.3);
};
s+=(st-s)*0.01;
background(0);
directionalLight(255, 255, 255, 0, 4, -10);
ambientLight(255, 255, 255);
centx=width/2+400*abs(sin(alpha/200))*sin(radians(alpha));
centz=0;
centy=height/2+400*abs(sin(alpha/200))*cos(radians(alpha));
for (int i=particles.size()-1;i>=0;i--){
Part p=particles.get(i);
p.run();
if (p.isDead()) particles.remove(i);
};
t+=0.01;
alpha+=5;
};
%%%%Define the class Part
class Part{
PVector loc;
PVector vel;
float l;
float lifesp;
Part(PVector _loc){
loc=_loc.get();
vel=new PVector(random(-0.5,0.5),random(-0.5,0.5),0.1*random(-0.1,0.1));
l =random(2.0,5.0);
lifesp=random(255,2000);
};
void applyForce(float t){
PVector f= newPVector(random(-0.1,0.1)*sin(noise(loc.x,loc.y,t/2)),random(-0.1,0.1)*cos(noise(loc.x,loc.y,t/2)),0.01*sin(t/10));
f.mult(0.1*p);
vel.add(f);
PVector rad=PVector.sub(new PVector(centx,centy,centz-50),loc);
rad.mult(s);
rad.mult(0.12*(l/2));
vel.add(rad);
vel.limit(7);
};
void move(){
loc.add(vel);
lifesp-=1;
};
void display(){
noStroke();
fill(255,random(130,220));
pushMatrix();
translate(loc.x,loc.y,loc.z);
ellipse(0,0,l,l);
popMatrix();
};
void run(){
applyForce(t);
move();
display();
};
boolean isDead(){
if (lifesp<0.0){
return true;
} else {
return false;
}
}
};
Here you find a render of the video (which took me quite some time…), which has being aurally decorated with a spacey drone, because… well, I like drones. 😉
11:
Here’s a code which uses the idea of a “particle system”, i.e. a system which consists of a number of objects (which may vary with time) interacting among themselves, and with their environment. In this case, I have just used 3 particles which are subject to a centripetal force, and that repulse each other. Once you set up a basic interaction system, you can think about how to represent at each time the data produced by the system: in this case I have choose to draw for each particle a rotating line, whose properties, like its transparency, depend on some other parameters (distance from the center).
The interesting thing about using particle systems to make visual art is that in principle one is dealing with a “parameter space”, which doesn’t need to be mapped via the intuition which it was built in the first place with: in other words, there’s no need to represent the objects as actual particles (with positions, velocity, etc.), but one can consider the system as a machine that produces data, to be then represented in the way one artistically feels like. The advantage of using a particle system is that all these data will evolve according to some dynamical evolution which is (in general) not totally random, giving rise to patterns in the final artistic outcome.
int d=3;
Agent[] point=new Agent[d];
void setup(){
randomSeed(90);
size(500,500);
background(255);
for (int i=0;i<d;i++)
{
point[i]= new Agent(random(10,width),random(10,height),random(-1.5,1.5),random(-1.5,1.5));
};
};
void draw(){
for (int i=0;i<d;i++)
{
point[i].resetrep();
for (int j=0;j<d;j++)
{
if (i!=j) point[i].interact(point[j]);
};
};
for (int i=0;i<d;i++)
{
point[i].applyForce();
point[i].move();
point[i].paint();
};
};
class Agent{
PVector loc;
PVector vel;
PVector rep;
float alpha;
int tran;
float l;
float mag=0;
Agent(float _locx,float _locy, float _velx,float _vely){
loc=new PVector(_locx,_locy);
vel=new PVector(_velx,_vely);
rep=new PVector(0,0);
alpha=0;
tran=10;
l=random(20,50);
};
void resetrep(){
rep.x=0;
rep.y=0;
}
void interact(Agent other){
PVector reps=PVector.sub(loc,other.loc);
float m=reps.mag();
reps.normalize();
reps.mult(3/(m+0.0001));
rep.add(reps);
};
void applyForce(){
PVector force=new PVector(random(-0.02,0.02),random(-0.02,0.02));
force.limit(1);
PVector radial=new PVector(-loc.x+width/2,-loc.y+height/2);
mag=-radial.mag();
radial.normalize();
radial.mult(0.022);
force.add(radial);
force.add(rep);
vel.add(force);
vel.limit(6);
};
void move(){
loc.add(vel);
alpha+=2;
};
void paint(){
stroke(int(mag/10),int(mag/10),int(mag/10),int(abs(sin(radians(alpha)*0.1))*10));
pushMatrix();
translate(loc.x,loc.y);
rotate(radians(alpha));
line(-20,0,-20+mag/10+l*(1+abs(sin(radians(alpha)*0.1))),0);
popMatrix();
};
};
Here’s a screenshot of the animation after a few seconds.