Strategies for Algorithmic Composition
-- Any machinery from mathematics/computer science/artificial intelligence is potentially applicable
-- Critical issues of musical representation; how to model music on a computer?
-- Building the model led by musicological analysis and intuition, or by more automated statistical analysis of a corpus
For discussion of different motivations and methodologies for the modeling of composition by computer, recommended you read:
Pearce, M., Meredith, D. and Wiggins, G. A. (2002) Motivations and Methodologies for Automation of the Compositional Process. Musicae Scientiae 6(2): 119-147
//for examples
(
SynthDef(\acsound,{|freq=440,amp=0.1,dur= 0.2,cutoff=2000|
var sound, filter;
sound= Saw.ar(freq, amp)*EnvGen.kr(Env([0,1,1,0],[0.01,0.05,(dur.max(0.07))-0.06]),doneAction:2);
filter= LPF.ar(sound,Line.kr(cutoff,300,dur));
Out.ar(0,filter.dup(2))
}).add;
)
Practical probability
See the accompanying 'Probability distributions' tutorial later for a more mathematical approach from first principles (skip it if it worries you). We'll use helper functions herein for now.
Probability is one of the great tools for algorithmic composition work. Rather than deterministic works, fixed given a starting state, we can create probabilistic works, different with every run.
(Actually, in truth, the random number generation we'll use depends on deterministic 'pseudo-random' functions in the background, cued from some factor like the current system time, but for our intents and purposes, they give the statistically legitimatised variation we seek).
A host of probabilistic functions are available in SuperCollider. We'll try some practically useful ones for algorithmic composition now, and also see the [Randomness] help file for some more hints, both language functions and UGens.
Probability theory allows selection from a space of options. Different options can have different chances of being chosen on any given 'roll of the dice'.
In the simplest form, choices amongst objects might be equally likely (equiprobable, uniform distribution):
//try these:
2.rand //generates an integer, either 0 or 1
2.0.rand //from 0.0 up to 2.0
2.rand2 // -2 to 2
2.0.rand2 //-2.0 to 2.0
rrand(2,4) //range from 2 to 4, so one of 2,3,4
rrand(2.0,4.0) //floating point range
[3,6,8,19].choose //choose one option from the Array
All these functions are making selections where the numbers in the range or options in the Array have an equal chance of turning up.
But the choices can also be weighted differently.
We might weight lower numbers as more likely than high:
1.0.linrand //linear distribution; not the same as uniform! Linearly decreasing weighting, so low numbers have more chance of turning up
Array.fill(1000,{linrand(1.0)}).sort.plot //see this visually by creating 1000 numbers using this generator, sorting them in order, then plotting the results
1.0.bilinrand //similar, goes between positive and negative 1.0, more weight towards 0 in all cases
Array.fill(1000,{bilinrand(1.0)}).sort.plot //see this visually
1.0.sum3rand //sum of 3 uniform random numbers between plus and minus 1.0 (will come out with more chance of numbers nearer 0, since values can cancel between positive and negative; in general, a sum of distributions tends to a centre-weighted normal distribution)
Array.fill(1000,{sum3rand(1.0)}).sort.plot //see this visually
//show similarity
Array.fill(1000,{({1.0.rand2}!3).sum * 0.33}).sort.plot //see this visually by creating 1000 numbers using this generator, sorting them in order, then
exprand(1.0,10.0) //uniform choice, but over an exponentially mapped range, more likely to choose low
gauss(0.0,1.0) //famous bell-shaped Gaussian, normal distribution; has two parameters, mean and standard deviation. Most output values are within three standard deviations each side of the mean
Array.fill(1000,{gauss(0.0,1.0)}).sort.plot //see this visually
gauss(1.0,0.1) //mean 1.0, most output values within 0.3 (3*0.1) either side, so 0.7 to 1.3
Most often, you use arbitrary weights amongst a discrete set of options. Think of choosing amongst a set of possible MIDI notes, or dynamic levels, or durations.
[60,62,64,67].wchoose([0.5, 0.25, 0.2, 0.05]) //the first array is the array of options; the second is the array of weights
Array.fill(1000,{ [60,62,64,67].wchoose([0.5, 0.25, 0.2, 0.05]) }).sort.plot(minval:50, maxval:72) //see this visually
When you use wchoose, the array of weights has to add up to 1.0 (a standard feature of a probability distribution). There is a helper function for this:
[14, 3.7, 5.6, 8, 11].normalizeSum //make array add up to 1.0 by dividing by the sum of the entries
Finally, for rolls of the dice in decision making, the coin function is very useful:
0.5.coin //fair coin, equal chance of heads or tails: true or false as output
0.2.coin //unfair coin, 20% chance true
0.95.coin //unfair coin, 95% chance true
You can achieve a lot just with controlled use of probability distributions in this way.
You may also want to explore using different probability distributions at different points in time during a piece, perhaps by varying parameters in gauss, changing the weights for wchoose, or moving between entirely different functions. You can remap the values to different ranges at different points in time, or restrict which parts of a distribution you select from. We've seen similar ideas before in terms of time varying availability; e.g. 'tendency masks' in granular synthesis for allowed parameter ranges at different points in time.
Use of conditionals
Algorithmic music exploits the fundamental building blocks of computer algorithms. Conditional execution empowers computerised decision making; based on the current state, you can choose the next action in either a rigid deterministic way, or with (psuedo-)probabilistic choice.
//examples:
//deterministic
(
var pitch=60, amp=1.0;
if(pitch==60,{amp= 0.2});
amp
)
//probabilistic
(
var pitch=60, amp=1.0;
if(pitch==60 and: 0.5.coin,{amp= 0.2}); //amp gets set to 0.5 on average half the time
amp
)
In music, different states might correspond to:
-- different parameter settings for musical attributes (as above)
-- different playing modes ('mellow', 'aggressive', etc.)
-- different models of harmony, tonality, melody...
-- etc
One interesting analogy is the idea of a finite state machine as a model of computation: the computer has a set of program states it can be in, and at each step can transition to a variety of other states (including staying where it is).
It is for you to build the model of music; there are as many music theories as you want to explore. Of course, not all correspond well to existing 'styles' or 'genres', and there is much scope for experiment.
Conditional probability
If some event is known to have happened, this gives information about the situation which restricts what else may happen alongside it. Such reductions from a full choice within probability space to a more restricted area is the domain of conditional probability.
P (B | A) = P (A and B) / P (A)
where P (B | A) means the probability of B given that A is known to have happened.
If A is observed, to find P (B | A), look at the probability that both A and B can happen (the intersection of the areas of the probability space represented by A and B) relative to the probability of A happening in the first place.
(sidenote: Bayes theorem follows from the above, as P(B | A)= P(A | B) P(B)/P(A). Bayes theorem is useful for calculating one conditional probability in terms of another, ie A might be some observations and B a world state; Bayes theorem lets us calculate the most likely world state, by looking at how each potential world state explains the observations)
We can also think about this in terms of an event observed a moment ago further constraining what could happen next:
P (B occurs at time n | A occurs at time n-1) = P (A at time n-1 and B at time n) / P (A occurs at time n-1)
In general, decisions can take account of not only the current situation, but the history of past states. We move away from '0th-order' systems where each choice is entirely independent of anything else that has happened.
Markovian systems
The idea of the current choice being dependent on past choices is encapsulated in a Markov system of order n, where n is the number of previous choices at stake. Simple Markov processes need to keep track of a larger and larger number of possibilities in a combinatorial explosion. Say there are 3 options at a given time, say, three notes to choose from:
[\a, \b, \c].choose //0th order system, uniform selection
Now say that the choice depends on the choice just made, a 1st order system:
[\a, \b, \c].wchoose([0.7,0.2,0.1]) //if previously choose \a
[\a, \b, \c].wchoose([0.0,0.5,0.5]) //if previously choose \b
[\a, \b, \c].wchoose([0.1,0.4,0.5]) //if previously choose \c
Then in general there are 3*3= 9 probabilities to specify. For each increase in order, we'd gain another multiple of 3, so a second order Markov system requires 3*3*3 probabilities to be set up, and an Nth order needs 3**(N+1)
Higher order Markovian systems require exponentially bigger multi-dimensional matrices of probabilities.
//1st order Markov system example
(
var markovmatrix;
var currentstate=3.rand; //start in one of three states
markovmatrix= [
[0.7,0.2,0.1],
[0.0,0.5,0.5],
[0.3,0.4,0.3]
];
{
20.do{
Synth(\acsound,[\freq, [48,60,64].at(currentstate).midicps]);
//which probability distribution to use depends on what state we're in right now
currentstate = [0,1,2].wchoose(markovmatrix[currentstate]);
0.25.wait;
};
}.fork;
)
For fixed and variable order Markovian modeling see also the MathLib and ContextSnake Quarks.
Search
Search is a fundamental operation in computer algorithms. Musical parameterisations lead to combinatorially explosive search spaces, and issues of computational tractability. Heuristics are rules of thumb to cut down the amount of brute search by pruning the search tree.
Charles Ames differentiates:
comparative search: an exhaustive search through all options. Can find an optimal solution, but usually too computationally intensive
constrained search: finds a `good' solution by approximate methods, i.e., heuristics.
An early strategy (used back in 1955 by Hiller and Isaacson's) was generate and test. Random numbers are generated until they pass a test. The passed number becomes the latest choice, and a new selection is then made. Alternatively, we might restrict generations to only acceptable options in the first place (by heuristics).
More complicated strategies include back tracking (jumping back to an earlier decision point when a path has led to an impasse) and dynamic programming (greedy selection of the best option according to a cost function at any point, to comparison of multiple paths taking into account all steps but keeping down the proliferation of possible paths by only following best scoring paths to any given branching point).
You should see that any machinery from AI (whether GOFAI symbolic or connectionist) may be imported to problems of musical search.
//generate and test
(
var currentvalue= rrand(60,72);
var generateandtest;
generateandtest= {|previous=60|
var number=rrand(24,127);
var keeplooking;
//keep searching until a number passes the tests
while({
keeplooking= false; //can only fail
//note we could replace this test with just generating number in the allowable range to start with
if (abs(number-previous)>12) {
keeplooking= true;
};
//avoid certain intervals
if (#[-5,-3,4,7,11].includes(number-previous)) {
keeplooking= true;
};
((number.asString)++(if(keeplooking," rejected","accepted"))).postln;
keeplooking
},{
//no need to do anything here, all done in while test function
number=rrand(24,127);
});
number
};
{
20.do{
currentvalue = generateandtest.(currentvalue);
Synth(\acsound,[\freq, currentvalue.midicps]);
0.25.wait;
};
}.fork;
)
Sonification of mathematics
Given the wonderful resources of mathematics, it's very tempting to translate mathematical structures into musical output. But be warned that the transformation does not often make perceptual sense, and can be very contrived. On the other hand, it may lead you to stimulating output you wouldn't otherwise have conceived.
//logistic map function used to generate pitch values
(
var currentvalue= 1.0.rand;
var logisticmap, r;
r=3.74;
logisticmap= {|previous=60|
((1.0-previous)*previous*r).postln;
};
{
50.do{
currentvalue = logisticmap.(currentvalue);
//must convert from the value in the range 0.0 to 1.0 to a musically useful pitch value
//quartertones here
Synth(\acsound,[\freq, (60+((currentvalue*12).round(0.5))).midicps]);
0.125.wait;
};
}.fork;
)
The example here demonstrates how the logistic map acts as a generator of values at the required rate for musical events set required, much as a UGen is a (usually much faster running) generator of sample values at audio rate. Analogous networks of number generation and modification (synthesis and processing) can be formed in algorithmic composition to determine musical parameter values for event streams.
We'll continue this next year in advanced computer music by discussing mappings and musical modeling in general. For example, we haven't touched here on data-driven modeling where a corpus is automatically analyzed to create a generative model. You may still approach such things intuitively, by formulating rules via your own personal analyses of musical style.