for my work together with mark d'inverno i coded a few tools. one of the things that came up was a need for a neutral but nice sounding way to test aspects of our musical agents systems. so we got hold of a grand-piano sample library and i wrote a 'giga sampler' like class for supercollider. this allowed us to use this massive sample library (2.5gig) and let the agents play high quality samples instead of cheap midi or boring synthesised sounds. so for testing melodies, harmonies and such this was a good thing.

the trick with the giga sampler is that it preloads a bit from each soundfile into ram memory and then streams the rest from disk when needed. or at least this is how i understands it. so using this technique, one can get quick access to a lot more samples than normally would fit in the memory of a sampler. a massive library like ours with full 88keys range, sampled in many different velocities, would occupy ~5gig of ram (supercollider uses 32bit internally), nor could it be streamed from disk (the harddrive would be too slow to access and load the headers to play fast chords progressions without staggering etc).

i spent some time to make my class all round useful and it can be downloaded _here. it is called RedDiskInSampler.

and here is some testcode for it...

s.boot;
d= ();						/*for mapping midinote to filename*/
r.free
r= RedDiskInSamplerGiga(s);		/*sampler*/
(
var velocities= #[40, 96];		/*velocities to load*/
var octavesToLoad= #[2, 3];		/*how many octaves to load*/
var scale= #['C', 'C#', 'D', 'D#', 'E', 'F', 'F#', 'G', 'G#', 'A', 'A#', 'B'];
/*so number of samples to load is octavesToLoad.size*12*velocities.size*/
/*lowest note C2= midi 36*/
velocities.do{|x, i|
	var tempDict= ();
	d.put(x, tempDict);
	octavesToLoad.do{|y, j|
		scale.do{|z, k|

another thing mark d'inverno and i did was to try to list all the things our musical method agents possibly could do. this was of course an impossible task but still it gave us an overview and was a pretty fun and crazy project.

version 040511 /fredrik

CHORD:
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
* transpose a note tone up/down
* transpose some notes tone up/down
* transpose all notes tone up/down
* transpose a note octave up/down
* transpose some notes octave up/down
* transpose all notes octave up/down
* making more/less dissonant by transposing notes up/down
* shift by inverting
* inverting parts of the chord
* removing highest/lowest note
* removing middle note
* removing every other note
* removing dissonances
* adding the whole chord octave up/down
* adding higher/lower note
* adding note in the middle
* adding notes in between
* adding dissonant notes
* detune a note up/down from current tuning (eg +10 cents)
* detune some notes up/down from current tuning (eg +10 cents)
* detune all notes up/down from current tuning (eg +10 cents) (ie pitchbend whole chord)

* transpose a note tone up/down in current modus
* transpose some notes tone up/down in current modus
* transpose all notes tone up/down in current modus
* making more/less dissonant by transposing notes up/down in current modus
* shift by inverting in current modus
* inverting parts of the chord in current modus
* removing root of current modus
* removing middle notes in current modus (eg 3rd, 5th)
* removing extension notes in current modus (ie E13#11 -> E9#11 -> E9 -> E7 -> E)
* adding higher/lower note in current modus
* adding note in the middle in current modus
* adding notes in between in current modus
* adding extension notes in current modus (ie E -> E7 -> E9 -> E9#11 -> E13#11)
* adding root from another modus (eg E/A)

so mark d'inverno and i worked on quite a few different systems. they all differed but the main goal remained fix: we wanted a responsive music system built from a multi-agent system approach.

the first ideas circled around a multi-agent band.

We originally consider the idea of a multi-agent band, but this was soon dismissed because of the complexity involved with feedback. How does one agent perceive the output of another agent; in effect how do we give that agent ears? The only possibility is to allow one agent to look at some portion of the code that is being generated but it is not clear how you could do this with any semblance of replicating the real-life improvising group of musicians.

Some questions that arose in considering how to build such a band. How aware should the agents be of its fellow musicians? What interplay do we allow between musicians and how to we facilitate this? Should there be one agent per style/piece/genre or is the agent an all round virtuous that can play in different styles/genres? Does an agent know what notes to play by itself or is it handed a score and told what and when to play? Is the agent itself responsible for different manipulations and effects to the sound it generates, or are there other agents deciding this? Perhaps, there is a project for someone else out there?

we abandoned that and tried to simplify a bit. the design we came up with next is sketched out here...

and our ideas around its design was as follows...

A basic design

In order to address some of the issues and motivations outlined in this document we propose a multi-agent architectures with the following design elements.

nick and i made a pact to do 1hour of live coding practice for each day of august. julian joined in too on a couple of days.

here are rendered mp3s of my practising sessions. music quality varies...

they're all coded from scratch (synthesis, patterns etc) in ~1hour using plain jitlib. the sourcecode is available here... code
(you might need to copy and paste or select all to see it as i accidentally colorised all the documents)
so rather than listening to the static mp3s above, i'd recommend to download supercollider and play [with] the code.

i think i've identified two problems. first the getting-started and then the getting-on-when-you-finally-got-started.
in the beginning there's always the empty document... uhu. so setting up a little task to solve or having an idea of some soundscape i'd like to create seemed to help. it was usually ideas like use fm-synthesis today or make soft drone sounds tonight. still, many times it started out sounding just awful and i got more and more stressed trying fix it. any livecoders recognise this feeling? ;-) but pulling some tricks (usually distortion or delay effects :-) and focusing in on a few details - muting other sounds - i think i managed shape all the code to become somewhat okey sounding in the end. i only reset the clock and started all over from scratch twice.

for a recent application i dug up some old klipp av demos we did in march 2004 at steim - more specific in the kitchen of their guest house.
they're here under 'historical examples'.
nick and i had all forgotten about these :-)

between march 2004 and march 2006 i had the fantastic opportunity to work as a research fellow for prof. mark d'inverno (http://www2.wmin.ac.uk/~dinverm/). it was a part time engagement at the math department at University of Westminster : cavendish school of computer science in london.
mark is a math professor specialising in intelligent agents and also a great pianist. our goal was to combine his (and mine) two big interests by creating musical agents that could improvise, jam and play together.
i learned a lot in the process and had to read up on math, specification languages, agent theories, genetic algorithms etc. i found so much interesting stuff out there to get totally absorbed in. this blog is partly started to document our research.