A collection of noisy, fun, cool, geeky, techy, wired or just plain wierd stuff for your consideration!

SuperCollider/Coding

IxiLang percussive SynthDefs

(more…)

Advertisements

‘Prelude to scarier chorals’ (Laptop Musicianship task 1 composition)

After weeks of tinkering with code, writing and re-writing the piece i have finally completed the following composition. It has gone through many transformations and i have had to significantly reduce the piece in length; originally it was about 8 minutes, now it is just over 4. I have named this piece ‘Prelude to scarier chorals’ (anagram of ‘A Supercollider Orchestra’).
It is written for cello, harpsichord, harp, piano, vocals and various percussion. My scale is 0, 3, 7, 12, 15, 20, 22 ; it stretches over two octaves starting at C, then D# and G from the first octave and C, D#, G# and B from the second. However only the introduction is played in this scale, all other parts are transposed (+7, +2, -2 and +5 semitones in sequence) every 4 bars. I feel this scale and transpositions give the piece a bright, airy feel.

What follows is overly verbose waffle – i’d just scroll to the bottom if you are interested in having a listen!

Each instrument has several different sections. In the introduction the cello and vocals play long legato notes, accompanied by two harp staccatos speeding up and slowing down (one transposed up 12 semitones, one transposed down 12 semitones), till the 30th bar. At this point the whole piece doubles in speed starting with cello and two separate harpsichord parts (one part 2 octaves lower than the other) playing different melodies. These are also joined by the percussive elements (Timpani, Gong, kick, snare toms and hi-hats). The percussive elements are randomised, so on each evaluation of the code it will play differently. After 4 bars of each transposition (a reoccurring theme) the cello and harps are replaced with three piano parts, one playing a sequence of chords, the other two mimicking the parts played previously by the harpsichord. In the next section the piano chords remain while the other parts for piano are replaced with a harp and the harpsichord returns, this time playing the same pattern as before but at twice the speed. We then move on and introduce the vocals, one female, one male singing the same sequence one octave apart. At this point all percussion is stopped,the pianos are reintroduced, with one part playing twice the previous speed; the second harpsichord part reappears at double speed and the existing part slows back to it’s original tempo whilst the harp is switched for it’s alternative part and joined once again by the cello. In the next part the double speed piano and harpsichord are brought back to original tempo, piano chords and one part of harpsichord are removed. To bring the piece to and end the following sections consists of piano and female vocals only, finishing with a gong hit. But have a listen for yourself!


Pgeom normalization

When using a Pgeom, it can be rather difficult to tie it in with our time signature. Julio has shown me how to ‘normalize’ the Pgeom so that we can ensure that the pattern it creates will fit in with the structure of our piece. For example, to get our Pgeom pattern to last 4 beats we have to use the normalizeSum function. However we discovered that we cannot simply put this into our Pbind as below because our pattern will return one value at a time, and the normalizeSum needs to know all values before the pattern is played, if it is to perform its function.

Pdef(\synth,
(Pbind(\type,\midi,\midiout,m,\chan,0,
\midinote,Pseq([49,52,59,60,61,62,63,64]-1, inf),
\dur, Pgeom(1/8,0.8,10).normalizeSum*4,
\db,-3
)));

So we have to get the series of values from the Pgeom and create an array from it. This can then be normalized and the new values be used to control our pattern.

Array.geom(10, 1/8, 0.8).normalizeSum*4; // CREATE AN ARRAY OF VALUES USING GEOM PARAMETERS, BUT NORMALIZE THEM TO BE 4 BEATS LONG.

We can create this array as a variable and then enter it into our code. (Pn is a basic pattern class, that repeats the enclosed pattern for a user defined number of repeats, Plazy evaluates a function which returns a pattern, then embeds it in a stream)

Pdef(\synth,
(Pbind(\type,\midi,\midiout,m,\chan,0,
\midinote,Pseq([49,52,59,60,61,62,63,64]-1, inf),

\dur, Pn( Plazy{ \\EVALUATE FOLLOWING FUNCTION, THEN EMBED IN Pn STREAM
var axDur; \\CREATE VARIABLE axDur (ACCELERATING DURATION)
axDur = Array.geom(10, 1/8, 0.8).normalizeSum*4; \\ASSIGN ARRAY TO axDur
Pseq(axDur, 10); \\PLAY SEQUENCE USING VALUES FROM axDur 10 TIMES
},2) \\COMPLETE Pn PATTERN TWICE

\db,-3
)));

Pdef(\synth).play;

The Pgeom creates an effect that, to me, sounds more like a human musician – it can sound more like an improvised solo than a rigidly structured piece of code that is tied into a uniform time structure. By normalizing it is easier to control the length of Pgeom patterns and incorporate these into our work to create a much more interesting piece.


Pbindef!!

I have written the different parts of my track to include a sequence of transpositions, but because of the way i have written the code it seems too repetitive to me. I wrote the parts to be 16 bars long, so that after 4 bars it could transpose and after 4 more bars it would transpose to a different key and so on. This repeats through the whole track, so i felt that it was too formulaic and the key changes lose their impact after hearing the same pattern over and over. I wanted to add \ctranspose into the sequencing section of code, so that all parts in that ‘section’ would transpose :

e.g.
Ppar([Pdef(\cellopreintro)],1)
++
Ppar([Pdef(\glocksolo),Pdef(\glocksolo1),Pdef(\harps4intro),Pdef(\vox4intro),Pdef(\cello4intro),\ctranspose, -1],1)//TRANSPOSED SECTION
++
Ppar([Pdef(\cello),Pdef(\harps),Pdef(\timpani),Pdef(\kit),Pdef(\glock),Pdef(\break),Pdef(\harp2),Pdef(\kit1)],1)
++
etc.

I tried and failed, I have as yet been unable to figure out how to do this. Julio has shown me how to use a Pbindef to add parameters to a Pdef without having to write the code out in full. This will enable me to trigger any transpositions manually, although i would still like to find a way of automating this in the way described above.

Pbindefs work by referencing our original Pdef, and then stating additional parameters to add to it.
e.g.
Pdef(\harps,
(Pbind ( \type, \midi, \midiout, m,\chan, 0,
\scale, [ 0, 3, 7, 12, 15, 20, 22,]-24,
\degree, Pseq([ 2,3,6,5,4,7]-1, 4),
\dur, Prand([Pstutter(2,Pseq([12/8,2/8, 2/8]/2, 4)), Pseq([12/8,2/8, 2/8], 4),],1),
\db, -3,
\mtranspose, Pdef(\transposition)
)
)).play;//ORIGINAL PDEF

Pbindef(\harps, \ctranspose, -5); //THIS WILL USE ALL THE PREVIOUSLY EVALUATED CODE FOR PDEF(\HARPS) BUT ALSO ADD TRANSPOSITION

Note that once the Pbindef has been evaluated it changes the stored Pdef, so to change it back you will have to evaluate a new Pbindef stating the original values.
So it seems the Pbindef is good for live on-the-fly coding, but not so good for use in event stream players. I will, however, continue to look into this dilemma and try to come up with a suitable solution.

(I hope this is clear, but if not then feel free to find me and pick my brains, sometimes these things are easier to explain face to face)


iXiQuarks

I have downloaded iXiQuarks and had a good play around with the various instruments and effects and i really like it…… alot. For improvisations either solo or group work it is ideal. Sol Bateman, Andy Buclaw, James Rogers and I all got together on Wednesday afternoon for a jam. To begin with it was very messy (iXi was new to us all so new to us all so we had a lot of experimenting to do), but within about 1/2 an hour we were getting somewhere. We were starting to get a theme running and sticking with it, whilst trying out new things. I think we’ll need much more practice than we’ll be able to get, before it sounds presentable – we only have two opportunities when we are all free to get together before we have to present our ideas next week, but as we have a month before we have to have a finished piece/concept i’m sure we will be fine. I have done some practicing at home, and come up with some rather ambient, conceptual stuff ( i will upload an example soon), and have really enjoyed the way the instruments work. Once mastered ixi will enable us to confidently and competently perform our ensemble well.


New discoveries!

Having written the main structure for my Laptop Musicianship task 1 i’m now experimenting with various patterns and nesting Pdefs for different effects. Pgoem is a fantastic pattern command, which i have used to introduce a harp solo into the piece, it allows values to be repeated whilst increasing the ouput value geometrically. The first argument is “start”, the second is “grow” (multiplication factor) and the third is “length” (number of values produced) e.g Outputs for Pgeom([1,1.5,3]) would be 1, 1.5,2.25. Used to control duration produces a very nice effect, especially when placing different Pgeoms into a Pseq. I have, as yet, not tried using it in other parts of the code.
I have also been experimenting with Pdefs to control transposition. Instead of writing several identical pieces of code over and over again i wrote it once, but as a Pdef –

e.g Pdef(\transposition, Pstutter(12,Pwrand([10,5,0,-2],[0.1,0.2,0.5,0.2],12)));.

Now every pattern i want to use this code in, can simply have the new Pdef nested within it –

e.g Pdef(\harps,
(Pbind ( \type, \midi, \midiout, m,\chan, 0,
\scale, [ 0, 3, 7, 12, 15, 20, 22,]-24,
\degree, Pseq([ 2,3,6,5,4,7]-1, 4),
\dur, Prand([Pstutter(2,Pseq([12/8,2/8, 2/8]/2, 4)), Pseq([12/8,2/8, 2/8], 4),],1),
\db, -3,
\mtranspose, Pdef(\transposition) //NESTED PDEF
)
)).quant_(4);

This is very handy, when you know you will be repeating sections of code, for reducing the amount of code that need to be written, and unless i’m mistaken, all patterns containing this nested Pdef will return the same value simultaneously. Each piece using Pdef(\transposition) in its code will transpose to the same note, whereas if i had written the code individually to each element they would transpose to different notes at each ‘return’ of the transposition code .
I hope this doesn’t sound too complicated, and that you do actually understand what i’m talking about, but if not then feel free to come and find me at uni and i’ll try and explain it in a better way.


++ sequencing

As shown in Julio’s tutorial downloaded from bitbongo, it is possible to sequence different parts of code in Supercollider. Whereas before i have been triggering Pdefs, or groups of Pdefs manually, by using the ++ code i can program these to be triggered automatically. When triggering manually it does not leave much room for the editing of the Pdefs live, as i have been concentrating on when the next section should be started. Once i have sequenced my different sections i can evaluate the event stream player and leave it to run, happy with the fact that the parts will start and stop as i have specified, and can actually start amending code live to give the piece a much more improvised edge.
The structure of the ++ sequencing is demonstrated below. The code is from my orchestral piece and only includes the first 6 sections of changes. The first part of code (Ppar (Pdef\nameofpdef), indicates which part/parts to be played, the number following indicates how many times the parts should be ‘looped’ and ++ indicates that after the Ppar has been executed the next one should be evaluated.

(
(Ppar([Pdef(\cello)],1)
++
Ppar([Pdef(\cello),Pdef(\harps),Pdef(\timpani),Pdef(\kit)],2)
++
Ppar([Pdef(\cello),Pdef(\harps),Pdef(\timpani),Pdef(\kit),Pdef(\glock)],1)
++
Ppar([Pdef(\harps),Pdef(\timpani),Pdef(\kit),Pdef(\glock),Pdef(\break),Pdef(\harp2),Pdef(\kit1)],2)
++
Ppar([Pdef(\harps),Pdef(\timpani),Pdef(\kit),Pdef(\break),Pdef(\harp2),Pdef(\kit1),Pdef(\vox2)],2)
++
Ppar([Pdef(\vox),Pdef(\harps),Pdef(\glock),Pdef(\cello),Pdef(\harp2),Pdef(\vox2)],2)
).play)