In the second part of this article, I will describe some diverse uses of live electronics. These various approaches can all represent noteworthy techniques, potentially to be used either separately or in combination, within a single real-time system.

The works to be covered include Cluster by Enrico Francioni which makes use of the timeline (utilising the timeinsts opcode) and delay-lines, eSpace by Enrico Francioni which is an example of a quadraphonic spatial signal, Accompanist by John ffitch which is based on a reaction to rhythmic impulses, Claire by Matt Ingalls which is based on the pitch and the randomness of signal reaction, Etude 3 which is an experiment by B McKinney based around the pvspitch opcode, and Im Rauschen, Cantabile by Luis Antunes Pena which is based on keyboard commands using the sensekey opcode.
A number of tutorials have been prepared that demonstrate many of the techniques that are described in this article. They can be downloaded as a zip archive here.

I. Description of Examples of Live Electronics Pieces that use Csound

Cluster by Enrico Francioni

My work Cluster[1], for any instrument, live electronics and fixed medium, comprises three constituent elements: the sound of the solo instrument, the reproduction of the sounds of the instrument (processed in a variety of ways), and the part for fixed medium (tape).

Shown below is a page of the score, in this instance for vibraphone, live electronics and prepared electronic sound.

Figure 1. Page 1 from the score for Cluster by Enrico Francioni.

The version with live electronics interests me for several reasons.

One reason is how the soloist can engage in a dialogue with the various complementary sounds through exploiting the ability of the algorithm to capture, reproduce, and delay some of their phrases. I think that within this scenario there are aspects in common with with Solo N.19 by Karlheinz Stockhausen about which I wrote in Part I of this article.

Another reason that this piece’s method interests me is that the signal path within the code is always dominated by a time-line, thereby allowing specific events from the live score to be isolated and processed in specific ways. For this I used the k values of timeinsts. This data allowed me to implement events, as described above, simply by following conditional branches in the code.

In this example (in two channels), the selected signal enters the algorithm at a time and for a duration as defined within the Csound score (action-time and duration). The processed audio is sent to the output in real-time but is simultaneously captured and sent to the output output again with a delay (implemented using the delay opcode). Some things to note about the orchestra:

  1. In the first instrument we hear the original signal output processed in two channels.
  2. With the second instrument we will hear the original signal processed ans with a delay in two channels.

; header
sr          =           44100
ksmps       =           64
nchnls      =           2
0dbfs       =           1

gaRM        init        0
gktinst     init        0

    instr    1    ; signal processing

ktinstr     timeinsts
gktinstr    =           ktinstr
            outvalue    "timer", ktinstr

kin         invalue     "in"

if (kin == 0) then
aSIG        soundin     "demo.wav"
aSIG        inch        1
if (ktinstr >= 0) && (ktinstr < 3) then
           outvalue     "capture", 0
kgaincb    =            0

elseif (ktinstr >= 3) && (ktinstr < 6) then
            outvalue    "capture", 1
aosc        oscili      1, 300, 1
aRM         =           aSIG*(aosc*4)    ; RM
gaRM        =           aRM
kgaincb     =           1

elseif (ktinstr >= 6) && (ktinstr <= 10) then
            outvalue    "capture", 0
kgaincb     =           0


            outs        aRM*kgaincb*.6, aRM*kgaincb*.1


    instr    2    ; signal revived

adelay       delay      gaRM, 4

if (gktinstr >= 0) && (gktinstr < 7) then
            outvalue    "revived", 0
kgaincb     =           0

elseif (gktinstr >= 7) && (gktinstr <= 10) then
            outvalue    "revived", 1
kgaincb     =           1


            outs        adelay*kgaincb*.1, adelay*kgaincb*.6        ; processed signal and delayed output (unbalanced on the right channel)
            clear       gaRM


f1    0    1024    10    1
i1    0    10
i2    0    10


This piece is also interesting in terms of the spatialisation of the sound materials within a quadraphonic system. I am particularly interested in designing sound paths through the acoustic space that have a logical sense.

The creation of the fixed medium/tape part for this piece was not trivial but hearing it, it is clear that it contains material obtained, at least tonally, from what has already been heard.

The sound of the live instrument in this piece is, at various times, treated or left untreated by the software, sometimes it is relayed back in real-time and at other times delayed but it is always subjected to spatialisation.

The prepared part for fixed medium is made up of bands of sounds that form clusters and that serve as the backdrop to the other sonic components. These sounds come from a single pitch from a vibraphone (B3) and are treated, in deferred time, with spectral analysis and resynthesis. A specific example of this kind of processing in Csound is the phase vocoder.

This piece is carried out as a ‘one-man performance’. This is fulfilled with the assistance of the graphical interface which is of fundamental importance. In addition to the interactive GUI controls (shown below), the timer and the time-line tools contribute to the dynamics of the electronics.

Figure 2. GUI for Cluster by Enrico Francioni.

The following diagram illustrates the signal path with its treatment, the tape part and routing of the audio of a metronome.

Figure 3. Flow diagram for Cluster by Enrico Francioni.

eSpace by Enrico Francioni

I will now reflect in my article upon the use of real-time spatial movement, as used in my piece eSpace[6]. Some years ago I had the idea of adding effects to some piano pieces by the composer Henry Cowell. The proposal was to give the pieces additional interest. I was studying spatial aspects for an application in terms of location or spatial movement in a quadraphonic space. It seemed like it would be a good exercise to my teacher and myself.

My contribution would be limited to the design of the patch and to the movement of the spatialised signals during the performance of Cowell’s pieces.

Based on the knowledge I had gained I was intrigued by the subject and I undertook further work to create a control system based around an efficient graphical interface. The system would have to take into account certain aspects of the signal’s movement in space such as:

The code for this system requires the use of different instruments, each with a specific role in the routing of the signal; I would like now to describe some of them. One of the instruments is designed for directing the spatialisation in straight segments, sometimes with recursive movements.



idur_seg    =           36
idur        =           idur_seg * (1/9) 

ir          =           2.25        ; conversion value for the meter in the Widgets Panel
ia          =           -1
ib          =           1

kx          linseg      ia, idur, ib, idur, ib, idur, ia, idur, ia, idur, ib, idur, ib, idur, ia, idur, ib, idur, ia    ; segment x
ky          linseg      ib, idur, ib, idur, ia, idur, ia, idur, ib, idur, ia, idur, ib, idur, ia, idur, ia, idur, ib    ; segment y

timout 0, idur_seg, continue
reinit reset
rireturn                 ; henceforth never goes out

kamp        linen       1, .7, p3, 1
a1, a2, a3, a4  space   gasig * gkbutton3 * kamp, 0, 0, .01, kx, ky
ar1, ar2, ar3, ar4 spsend

kx_2        =           (kx + (ir * .5)) / ir        ; kx conversion values for the meter
ky_2        =           (ky + (ir * .5)) / ir        ; ky conversion values for the meter

            outvalue    "kx2out", kx_2    ; export values in the meter
            outvalue    "ky2out", ky_2    ; export values in the meter
            outvalue    "kxd2out", kx     ; export values in the text-value display
            outvalue    "kyd2out", ky     ; export values in the text-value display

ga1B        =           ga1B    +    ar1
ga2B        =           ga2B    +    ar2
ga3B        =           ga3B    +    ar3
ga4B        =           ga4B    +    ar4

            outq        a1, a2, a3, a4
gasig       =           0


The variables kx and ky are responsible for shaping the motion of the signal within the quadraphonic space. The following example will show the generation of those two values.

; calculation of kx and ky

kv          invalue     "kvers"    ; import values 1/0
kvers       =           (kv * ir) - (ir * .5)

kangolo     init        3.14159         ; the initial position of the signal

inc         =           6.2832
incr        =           inc / p3 / kr * 3    

; with the value 6.2832 around it tends to be complete, with -6.2832 reversing the direction - this calculation determines the values that define each point of the circle and the multiplier kr determines the number of laps around the listener, which may also be less than 1 or fractional - all within the time duration defined by p3

kincr       linseg      incr, 29.5, incr * 100, 1, incr * 100, 29.5, incr * .5    
; variation of the speed of the signal in space

kval        linseg      1, 30, .001, 30, 1

kvel        invalue     "kvel"
kincr1      =           kincr * kvel
kangolo     =           kangolo + (kincr1 * kvers)        
; kvers determines whether the movement is clockwise or counterclockwise

kxx         =           cos(kangolo)
kyy         =           sin(kangolo)    

kx          =           kxx * kval            
ky          =           kyy * kval
; this multiplication is used to activate a spiral movement (the signal goes to the origin and then returns outside)

Shown below is the code for free movement by GUI joystick.

kx_in       invalue     "kx1in"        ; import from the graphical interface of the value of k x
ky_in       invalue     "ky1in"        ; import from the graphical interface of the value of k x

kx          port        kx_in, .2      ; smoothing
ky          port        ky_in, .2      ; smoothing

Below is a fragment of code showing random signal location in additional instruments.

kcpsx       linseg      .1, 30, .7, 30, .1
kcpsy       linseg      .2, 30, .1, 30, .3
kamp_x      oscili      1, kcpsx, 2
kamp_y      oscili      1, kcpsy, 2

kcps_x      line        .1, 60, 1
kcps_y      line        .1, 60, 1
kx          randh       kamp_x, kcps_x
ky          randh       kamp_y, kcps_y

In the code and widgets panel, we have also included the following controls and instruments:

The selection of the various types of spatialization of the signal is carried out through a button exclusive to the Widget. Finally here is the interface of eSpace.

Figure 4. GUI from eSpace by Enrico Francioni.

To conclude this section of Part II of this article, I would briefly like to review some experiments carried out by other composers, who have used Csound in real-time for live electronics.

Accompanist by John Fitch

An notable example of the use of Csound for real-time interaction is the piece Accompanist by John Fitch[5]. Some time ago John sent me the csd of Accompanist; one of the key mechanisms of the algorithm is how it senses and reacts to rhythmic impulses. Here is brief description of the algorithm by Andrew Brothwell and John ffitch: "The development of a computer musical accompanist is presented, that attempts to model some of the characteristics of human musicianship, particularly concentrating on the human sense of rhythm, and the playing 'by ear' skill set. It specifically focuses on blues accompaniment, and works with no previous knowledge of the particular song that is about to be played. The performance of the lead musician is constantly monitored and reacted to throughout the song. The system is written in Csound and runs in real time." [Abstract by Andrew Brothwell and John ffitch taken from the article An Automatic Blues Band.]

In the systems that we have analyzed above, there is often a leveraging of pitch and/or amplitude RMS data to influence the behaviour of the algorithm. This patch uses the pitchamdf opcode which uses the AMDF (average magnitude difference function) method. It outputs both pitch and amplitude tracking signals. The method is quite fast and should run in realtime. This technique generally works best with monophonic signals. Contrastingly, this patch gives us the opportunity to use time, duration, and rhythm, as parameters that can define the triggering of other events. This seems to me a really interesting approach when working with a live signal input.

Inspecting the method taken in this algorithm can become a starting point for designing other interactive systems in pursuit of other musical goals than those for which it was origianlly intended, for example to create an accompaniment that is as ‘human’ as possible for a genre such as the blues. After deciding here that also it must be treated as the input signal and what it needs to be taken of the same:

The code excerpt shown below suggests how a live audio signal can be read into Csound, low pass filtered using the tone opcode to suppress high frequency transients and then scanned using the RMS opcode (root-mean-square method) to provide a measure of changing sound intensity.

ktime  timek                  ; current time
asig   in                     ; mic input
asig   tone    asig, 1000     ; apply a lowpass-filter
krms   rms     asig           ; the rms of current input

Amongst the other original ideas contained within this patch, are the possibility to adapt the speed of the pulses of the algorithm to those of the performer and to impose a pitch that matches the pitch of the pulses. The initial count-in also seems to me noteworthy: this is implemented by simply beating at least four pulses in front of the microphone to activate the algorithm and and to put into action an event that has been prepared. Let us now have a look at the global variables shown in the example below.

; global user configurable variables
gkonsetlev     init     1500      ; set depending on input level
gkoutlatency   init     50        ; allows for latency in pause after count in
gkinlatency    init     13        ; allows for latency in expected beat position for in song tempo

; global variables counting for tempo recognition
gkfirstcount   init     0
gklastcount    init     0
gkcountnumber  init     0
gktempo        init     0
gktempochange  init     0
gkchecktempo   init     0

; global variable for pitch
gkpitch        init     0

;global variables for song position
gkbar          init     1
gkbeat         init     1

;global variable waiting for song end
gksilence      init     0

Shown below is the behavior of the code if the pulses are less than or equal to three.

if (gkcountnumber <= 3) then
; A)
  ; if it's the first note played start counting
  if (krms > gkonsetlev && gkcountnumber == 0) then
     kbeatpitch, krms  pitchamdf  asig, 40, 80
     gkpitch           =          gkpitch + kbeatpitch
     gkfirstcount      =          ktime                  ; ktime photograph of the first beat (gkfirstcount)
     gklastcount       =          ktime
     gkcountnumber     =          gkcountnumber + 1
                       printk     0, gkfirstcount        ; debug, in samples
; B)
  ; if it's the second or third keep counting
  elseif (krms > gkonsetlev && gkcountnumber < 3 && ktime > gklastcount+(kr/2)) then
     kbeatpitch, krms  pitchamdf asig, 40, 80
     gkpitch           =          gkpitch + kbeatpitch
     gklastcount       =          ktime
     gkcountnumber     =          gkcountnumber + 1
                       printk     0, gklastcount        ; debug, in samples
; C)
  ; if the count isn't completed within 10
  elseif (gkcountnumber > 0 && ktime > gklastcount+(kr*2)) then
     gkcountnumber = 0
                       printks    "Restarting the count in",0    ; Press "Restarting the count in"
; D)
  ; if it's the fourth and final count then extract tempo and pitch and generate chords
  elseif (krms > gkonsetlev && gkcountnumber == 3 && ktime > gklastcount+(kr/2)) then
     kbeatpitch, krms  pitchamdf  asig, 40, 80    ; extract pitch and envelope of current input
     gkpitch           =          (gkpitch + kbeatpitch)/4
     gklastcount       =          ktime
     gkcountnumber     =          gkcountnumber + 1
     ; calculate the average time between the intro beats
     gktempo           =          int((gklastcount - gkfirstcount)/3)
     ; difference in samples: directly proportional to the speed of the pulses
                       printk     0, gktempo        ; debug, in samples


Shown below is what is followed if the pulses number more than three.

if (gkcountnumber > 3) then

   ; if the count-in is complete and it's exactly the start of a beat to trigger the backing music

if (ktime == (gklastcount + gktempo - gkoutlatency)) then
     gklastcount       =          ktime + gkoutlatency
     gktempo           =          gktempo + gktempochange
     gktempochange     =          int(gktempochange/2)
     ; increment the silence count
     gksilence         =          gksilence + 1
     ; if a root note is being played fine tune the pitch
     kpitchcheck, krms pitchamdf  asig, 40, 80, 55, 0, 3
   if (kpitchcheck < gkpitch*1.03 && kpitchcheck > gkpitch*.97) then 
      ; take the average of the believed and the new
     gkpitch           =          (kpitchcheck + gkpitch) / 2
event "i", 2, 0, 1/kr    ; call the instrument that generates the backing music


   ; if count is complete and it's close to the start of a beat check we're in pitch and in time
   elseif (ktime>=(gklastcount+gkinlatency-10) && ktime<=(gklastcount+gkinlatency+10)) then

     ; if we're at the start of the window and there's not already a note ringing
     if (ktime==(gklastcount+gkinlatency-10) && krms>gkonsetlev) then
     ; stop any more checking this beat
     gkchecktempo      =          0

     ; once inside window if a note is played adjust tempo accordingly
   elseif (gkchecktempo==1 && krms>gkonsetlev) then
                       printk     0, ktime-(gklastcount+gkinlatency)
      ; adjust tempo
      gktempochange    =          gktempochange + ktime-(gklastcount+gkinlatency)
      ; stop any more checking this beat
      gkchecktempo     =          0

      ; once at the end of the window
   elseif (ktime==(gklastcount+gkinlatency+10) && gkchecktempo==0) then
      ; end of check, reset gkchecktempo so it starts the check again next beat
      gkchecktempo     =          1
      ; there has been sound so reset the silence count
      gksilence        =          0

If the pulses number more than three, the "Accompanist" activates the desired event, using the call shown below to help fulfill the goal of the project.

event "i", 2, 0, 1/kr

Claire by Matt Ingalls

Another very original patch that diverges from normal methods for live electronics involving a performer, microphone and computer is Claire 2.0 by Matt Ingalls.

Matt writes that:

"I should first come clean and say that the last half of the piece is a pure tape part which I really like for its practicality but this also raises some philosophical/aesthetic issues such as: what is the difference between playing a 1 sec sample or a 1 min sample? Or a 10 min tape piece for that matter? But if you are interested in the first part of the piece, I will try to explain it here. My approach comes from George Lewis - you should check out his Voyager if you haven’t already. The basic structure is fairly straight-forward: Multiple, ‘always on’, instruments are created, each one addressing a different task." [2]

For convenience in reporting the comments by Matt, I will extract certain passages of code.

i "Input" 1 999999
i "Analysis" 1 99999
i "PlayMode" 3 999999

Matt writes "Input: a ‘pitch’ opcode and logic to determine note on/offs, write to buffer
(I know I tried all the pitch-tracking opcodes and this one was the best one for
me accuracy & cpu )" [2].

This is shown below after the acquisition of the microphone signal and filtering.

asig                 =      asig   ; signal
iupdte               =      .02    ; length of the period, in seconds, that the outputs are updated
ilo                  =      6      ; range in which the pitch is taken, in octaves in form decimal point
ihi                  =      12     ; range in which the pitch is taken, in octaves in form decimal point
idbthresh            =      20     ; amplitude, expressed in decibels, necessary to ensure that the pitch is active. He once started continues until it is 6 dB down.
ifrqs                =      120    ; number of division of one octave. Default is 12 and is limited to 120.
iconf                =      10     ; the number of structures had need of a jump in eighth. Default is 10. 
istrt                =      8      ; start of the pitch for tracker. The default value is (ilo + l'ihi)/2.
iocts                =      7      ; number of decimation of eighth in the spectrum. Default is 6.

gkCurPitch, gkCurAmp pitch  asig, iupdte, ilo, ihi, idbthresh, ifrqs, iconf, istrt, iocts    ; extraction values (pitch and amp)

Matt explains the function of the instrument input by saying:

"[it] mostly determines if a new ‘note’ has started and/or the current ‘note’ has ended. Since what we hear as one of those can either be a change in pitch or in amplitude, there is some logic needed to determine that. At the same time, I keep track of the duration of notes and the time between the last note starting and the current note starting, which I call ‘density’."

The portion of the code that determines the logic of the note-on and note-offs is very enlightening because it allows for an absolute control of the signal.

The initialization of the k variables is shown below.

kIndex       init   0    ; tables index
kOnPitch     init   0    ; pitch when new note started 
kOnAmp       init   0    ; amp when new note started
kLastPitch   init   0    ; pitch from last k-pass
kAvePitch    init   0    ; low-pass of pitch
kLastAmp     init   0    ; amp from last k-pass    
kNoteDur     init   0    ; duration counter for currently playing note 
kOnCount     init   0    ; time since last note on [density]
kOnOnDur     init   0    ; time since last note on at current note on [density]

; Determine whether we need to turn notes off or on upon every k-pass

kNewOff      =      0    ; default to 0
gkNewOn      =      0    ; default to 0 

This section of the code shows the approach for amplitude.

if (gkCurAmp == 0) then      ; if no signal then...
 if (kOnPitch > 0) then 
  kNewOff      =    1                                           
else                         ; has input: 
                             ; special trick pause
 if (gkGlobalWait > 0) then
  gkGlobalWait =    0
  kOnOnDur     =    0

This section of the code shows the approach for pitch.

if (abs(gkCurPitch - kLastPitch) > 1/24) then
 if (kOnPitch > 0) then
  if (kNoteDur > kr/20) then
   kNewOff     =      1
   gkNewOn     =      1
  gkNewOn      =      1

kNoteDur       =      kNoteDur + 1
kLastPitch     =      gkCurPitch
kAvePitch      port   gkCurPitch, .1
kLastAmp       =      gkCurAmp

Matt explains that "when the note ends, I write its info (pitch, dur, amp, density) to a table used in the ‘analysis’ instrument".[3]

 tablew dbamp(kOnAmp), kIndex, giAmp
 tablew kLastPitch, kIndex, giPit
 tablew kNoteDur/kr, kIndex, giDur
 tablew kOnOnDur, kIndex, giDen

Matt continues to describe "Analysis: averages & limits of input" [2].

Below is the logic of the code to calculate averages and signal limits based on the single amplitude.

kIndex init 0
; initialize
if (kIndex == 0) then        ; kIndex works from 0 to 16 - when it returns to 0 then ...

    kAmpMin  =   99999      ; all parameters are reset on these defaults
    kAmpMax  =   0
    kAmpMea  =   0



; for every kpass, do one item in table
    kAmp table kIndex, giAmp
    if (kAmp < kAmpMin) then
        kAmpMin = kAmp
    if (kAmp > kAmpMax) then
        kAmpMax = kAmp
    kAmpMea = kAmpMea + kAmp


    kIndex = kIndex + 1

The variables that follow are photographed every 16 milliseconds. After the condition of the loop below is satisfied, gk values are then passed to the instrument PlayMode.

if (kIndex == giTableSize) then      ; if kIndex = 16 then ...
    gkAmpMin = kAmpMin         ; minimum value (amp) of the random tool PlayMode
    gkAmpMax = kAmpMax         ; maximum value (amp) of the random tool PlayMode
    gkAmpMea = kAmpMea/giTableSize ; average value in an event in PlayMode (p4 of an event)

    kIndex = 0                    ; ...kIndex reset


Matt concludes writing about Claire 2.0 that:

"+ Play: spawns ‘events’ (for an instrument playing pre-sampled sounds from my own playing) and has different ‘modes’ of playing based on analysis and lots of random numbers. I add more ‘play’ instruments as the piece progresses.
Then there are a couple gimmicks - silence, long tones, and a tape part that is the last half of the piece! One thing that I came away with after doing this piece was that if I wanted to do this sort of thing again, I would strip out all the logic/algorithmic stuff and do it in C – a visual debugger and being able to step through code, set breakpoints, and view current variable values makes life so much easier it is worth the extra hassle of hosting a CsoundLib or a separate application sending MIDI messages to Csound or whatever. (Or just not even use Csound?)." [2]

Etude3 by Bruce McKinney

I will now consider Etude3 by Bruce McKinney[7]. He sent me his .csd file accompanied by explanatory notes on the intentions of the piece. Here is a description of the process from its program note:

"Etude No.3 is one of a set of studies for the trumpet and a computer. The computer program is interactive in that the performance of the trumpeter influences the pitches and rhythms produced by the computer. The language of the computer program is Csound, one of several computer-music languages which have been under develdopment since the 1960s. The sounds which appear in this Etude include altered (processed) versions of the trumpeter’s timbre as well as new synthesized sounds produced by the computer but influenced by the way in which the trumpeter plays his part."

The author wants to leave the interpreter free of sliders, knobs, buttons, MIDI systems and so on and to make the algorithm react only to the sound of a musical instrument, in his case the trumpet. Shown below is a synthesis of the entire algorithm for Etude3 by Bruce McKinney.

The first part shown is where McKinney reads in the signal and performs an analysis on it with code utilizing the pvspitch opcode.

Figure 5. Flow chart from from Etude3.

  1. Clarinet-like instrument 1 and 44 input from mic to computer: A/D conversion. Create a phase vocoder (PV) analysis.
    • pv pitch/volume track the sound at control rate.
    • Put pv analysis into a buffer for use as "trumpet-like" delayed sound. Buffer turns over every 55 seconds.
    • Compare input pv analysis with pv analysis of a square wave (clarinet-like). PV filter the input analysis so that only clarinet-like components are let through. This is the basis of the Clarinet-like instrument.

  2. Controller Instrument
    • controls the turning off of instrument 44 and controls instrument 23.

  3. WAVE-SHAPER INSTRUMENT, instrument 23: NOT SOONER than every 0.7 seconds and ONLY IF the trumpet is playing
    • Sample the trumpet pitch from the pitch tracker.
    • Randomly choose one of 5 sets of pre-determined notes (defined as transpositions of the trumpet pitch) from a table. There are 1-5 notes in a set.
    • Each note of the set is randomly displaced by -2 ...+2 octaves.
    • Send the appropriate intervals to the "wave-shaper" instrument so that the notes play .2-.5 seconds apart.

      Functions of the wave-shaper instrument:
    • selects amount of vibrato
    • type of envelope for each note
    • varies the timbre of each note
    • low-pass filter at 1000 cps NB: Wave-shapers have been around for a long time. This is a very efficient way to synthesize an interesting sounding timbre that is "wind-instrument" like.

  4. Trumpet-like delayed sound, instrument 5 - ONLY AFTER 30 seconds AND ONLY until a key is pressed on the keyboard (near the end of the piece).
    • read a random amount of the buffer containing the input sound (1-5 seconds).
    • randomly transpose the pv stream.
    • randomly speed up/show down the reading (faster/slower note play).
    • randomly change the timbre of the sound by including more/fewer pv bins and/or starting with a higher bin and/or including only every 3rd (4th or 5th) bin.

    Finally, there is A/D conversion, reverb, and output.

Im Rauschen, cantabile by Luís Antunes Pena

The last piece I want to describe, Im Rauschen, cantabile, is for double bass and electronics (2012) and was written by Luís Antunes Pena. The piece does not use the microphone for live electronics, but is controlled directly from the keyboard of the PC via the operator using sensekey or sense and MIDI commands through a musical keyboard interfaced to the system. In the interest of an execution one-man performance, I think that this strategy is a medium that adds to the possibility to the interpreter to handle more events in real-time. Obviously the interpreter might become distracted from the performance by devoting himself to giving commands at the keyboard, and that could also lead to the involvement of an assistant for the live electronics.

Pena states (in German) that:

"Im Rauschen, cantabile ist ein Delirium für Kontrabass und Elektronik basierend auf das Stück Im Rauschen Rot, ein zwanzigminutiges Stück für Kontrabass, Schlagzeugquartett und Elektronik, das 2010 von Edicson Ruiz und das Drumming Ensemble uraufgeführt wurde. Im Rauschen, cantabile beschreibt einen Zustand der ständigen Spannung. Eine organische Spannung in der die Ungewissheit eine Rolle spielt. Und Gleichzeitig ist es eine zweistimmige Komposition von Melodien perkussiver und rauschiger Natur, eine Bewegung zwischen Abstraktion und empirische Wahrnehmung […]." [4]

Below is a part of the patch dedicated to the input keys with the opcode sensekey.

kres, kkeydown sensekey            
; kres     = returns the number of the pressed key (if no key is pressed returns -1)
; kkeydown = returns the values 0/1/0 (every time we press the button)

gkkey      =          kres            ; globalizes the value k of the number of the pressed key

kthreshold =          .1              ; threshold
kmode      =          0               ; operating mode
ktrig      trigger    kkeydown, kthreshold, kmode    ; Informs when a krate signal crosses a threshold - 

           schedkwhen ktrig, 0, 1, 4, 0, 0.1        
; called the instrument 4 which in turn calls the events (commands) based on the number of the pressed key

ktrigtoggle changed   kres            
; changed — k-rate signal change detector. This opcode outputs a trigger signal that informs when any one of its k-rate arguments has changed. Useful with valuator widgets or MIDI controllers.

           schedkwhen ktrigtoggle, 0, 1, 5, 0, 0.1    
; called tool 5 that if you press the + or - in turn activates other instruments for the increase/decrease of some values

Below is the list of the keyboard commands:

r ... record
p ... play original file
s ... stop
1-9 ... select samples
m ... mode forward/backward/for-and-back
+/- ... change loop duration
0 ... reset & print this info

Partial code from instrument 4 shows it will activate events according to the scheme shown below.

ikey = i(gkkey)
if (ikey == 114) then
    schedwhen 1, 99, 0, -1             ; start record
elseif (ikey == 115) then 
    schedwhen 1, 90, 2, .1             ; stop record / play
elseif (ikey == 49) then               ; sample 1
    gifn = 1
    prints "\n\n\n -----------> Selected Sample: "
    Sample strget gifn
    prints Sample
    prints "\n"


elseif ikey == 48 then    
    schedwhen 1, 90, 0, .1               ; 0 info
elseif ((ikey == 112) || (ikey == 32))  then    
    idur filelen gifn
    schedwhen 1, 11, 0, idur             ; p play file



The technical equipment is described as follows in the score of the piece:

Figure 6. Schematic layout for Im Rauschen, cantabile.

The author has pointed out that "Mainly the live-patch of Csound controls the click-track and triggers the audio files". (L.A. Pena, email communication, September 4, 2015)

In some pieces there is a need for a metronome click through headphones (stereo) or through a headset (mono) for the benefit of the performer so we frequently find a greater number of channels that expected (e.g. 3, 5, 6, etc...) are necessary in the .csd. For example in the case of the previously discussed piece Cluster, the first four channels are dedicated to the sound of the piece with two further channels (5 and 6) being used for the metronome.

The main piece of Im Rauschen, cantabile is stereo so the first two channels are reserved for that with a third track being necessary for the click of the metronome.

To conclude this survey of patches dedicated to real-time processing in performance, a brief mention is made of another example Will you fizz electric down the black wire to infinity (2009) by Rory Walsh[8] which utilizes a midi controller UC-33.

Rory states within the comments of the .csd of this piece:

"This composition for piano and computer forms part of a larger work which is still under development. The piece focuses on heavily processed piano sounds which are captured in realtime by the computer. The computer then runs a sequence of different algorithms that manipulate and alter the sounds being output through the speakers. Rather than viewing this piece as a straightforward duet for piano and computer I see it more as a solo piece for computer, with the piano driving the computer’s performance. Special thanks to Orla who let me borrow a line of text from one of her emails and use it as a title for my piece."

II. Conclusion

Upon completeing this extensive survey of the use of live electronics in chamber music using Csound it is clear that the work of programming is challenging; by applying the language to the few ‘historical’ pieces as well as to other recent compositions. Csound when ised in real-time can present some significant challenges, particularly those relating to user-control can be particularly difficult. However, after a careful study of what the potential of code and opcodes available is, it quickly becomes apparent that Csound excels at performing very precise and exacting processing upon a signal. This is not just as an auxiliary element to be modified and modeled, but is a valid resource to exploit in order to dictate within the csd what ‘could be’ the actual path of the algorithm and therefore the fate of the song, that is what the composer, and for him the interpreter, wants to realize in real-time.


I would like to thank John Fitch, Eugenio Giordani, Joachim Heintz, Matt Ingalls, Iain McCurdy, Bruce McKinney, Alessandro Petrolati, Luis Antunes Pena, Vittoria Verdini, Rory Walsh for helping me in various ways on the realization of these articles.


[1]E. Francioni: "Francioni-CLUSTER V (demo-2ch)," (for a percussionist, live electronics and sound support). Internet: https://soundcloud.com/enrico_francioni/cluster-v-demo-2ch, [Accessed October 17, 2016].

[2]Matt Ingalls. (2011, Feb. 20). Nabble. C+C interactive computer music [Online]. Available e-mail: http://csound.1045644.n5.nabble.com/C-C-interactive-computer-music-td3328610.html

[3]Matt Ingalls. (2011, Feb. 23). Nabble. C+C interactive computer music [Online]. Available e-mail: http://csound.1045644.n5.nabble.com/C-C-interactive-computer-music-td3328610i20.html

[4]Luís Antunes Pena, 2012. "Im Rauschen, cantabile." Available: http://luisantunespena.eu/imrauschencantabile.html. [Accessed Nov. 1, 2016].

[5]Andrew Brothwell, John Ffitch, 2008. "An Automatic Blues Band", Proceedings of the 6th International Linux Audio Conference, Kunsthochscule für Medien Köln, pp. 12–17. Available: http://opus.bath.ac.uk/11394/2/13.pdf.

[6]Enrico Francioni, 2007. "eSpace", csd for real-time spatial movement, Pesaro, Italy.

[7]Bruce McKinney, 2007. "Etude3", for trumpet and computer, Cranford, NJ, USA.

[8]Rory Walsh, 2009. "Will you fizz electric down the black wire to infinity", for piano and computer.


J. Heintz, J. Aikin, and I. McCurdy, et. al. FLOSS Manuals, Csound. Amsterdam, Netherlands: Floss Manuals Foundation, [online document]. Available: http://www.flossmanuals.net/csound/ [Accessed May 25, 2013].

Riccardo Bianchini and Alessandro Cipriani, "Il Suono Virtuale," (Italian Edition). Roma, IT: ConTempo s.a.s., 1998.

Richard Boulanger, The Csound Book, The MIT Press-Cambridge, 2000.

Enrico Francioni, Omaggio a Stockhausen, technical set-up digitale per una performance di "Solo für Melodieninstrument mit Rückkopplung, Nr. 19", in AIMI (Associazione Informatica Musicale Italiana), "ATTI dei Colloqui di Informatica Musicale", XVII CIM Proceedings, Venezia, October 15-17, 2008 (it).

Karlheinz Stockhausen, Solo, für Melodieinstrument mit Rückkopplung. Nr. 19, , UE 14789, Universal Edition-Wien, 1969.

Essential Sitography

AIMI (Italian Association of Computer Music). Internet: http://www.aimi-musica.org/, 2015 [Accessed October 16, 2016].

A. Cabrera, et. al. "QuteCsound." Internet: http://qutecsound.sourceforge.net/index.html, [Accessed May 16, 2016].

apeSoft. Internet: www.apesoft.it, 2016 [Accessed October 16, 2016].

Boulanger Labs. cSounds.com. CSOUNDS.COM: The Csound Community, 2016 [Accessed May 16, 2016].

I. McCurdy and J. Hearon, eds. "Csound Journal". Internet: csoundjournal.com [Accessed May 16, 2016].

E. Francioni. "Csound for Cage’s Ryoanji A possible solution for the Sound System," in Csound Journal, Issue 18. Internet: http://www.csoundjournal.com/issue18/francioni.html , August 3, 2013 [Accessed October 17, 2016].

E. Francioni. "Cage-Ryoanji_(stereo_version)_[selection]," (on SoundCloud). Internet: https://soundcloud.com/enrico_francioni/cage-ryoanji-stereo_version, [Accessed October 17, 2016].

E. Francioni. "Stockhausen-SOLO_[Nr.19]_für_Melodieninstrument_mit_Rückkopplung," (Version I). Internet: https://soundcloud.com/enrico_francioni/kstockhausen-solo_nr19_fur_melodieninstrument_mit_ruckkopplung, [Accessed October 17, 2016].

E Francioni. "SOLO_MV_10.1 Solo Multiversion for Stockhausen’s Solo [N.19]," in Csound Journal, Issue 13. Internet: http://www.csoundjournal.com/issue13/solo_mv_10_1.html , May 23, 2010 [Accessed October 17, 2016].

iTunes. "SOLO [Nr.19]," by apeSoft. Internet: https://itunes.apple.com/us/app/solo-nr.19/id884781236?mt=8, [Accessed October 17, 2016].

J. Heintz. "Live Csound, Using Csound as a Real-time Application in Pd and CsoundQt." in Csound Journal, Issue 17. Internet: http://www.csounds.com/journal/issue17/heintz.html , Nov. 10, 2012 [Accessed October 17, 2016].


Enrico Francioni graduated in Electronic Music and double-bass at the Rossini-Pesaro. His works are carried out to Oeuvre-Ouverte, Cinque Giornate per la Nuova Musica, FrammentAzioni, CIM, EMUfest, VoxNovus, ICMC, Bass2010, Acusmatiq, etc.
He performed the world premiere of the Suite I F.Grillo. From author and soloist was awarded in national and international competitions. He has recorded for Dynamic, Agora, Orfeo and others. He is dedicated to teaching and has taught double-bass at the Rossini-Pesaro.

email: francioni61021 AT libero dot it