This draws upon elements of Test Driven Development and Spiral Model but tries to be lighter-weight. Requirements gathering is eschewed in favour of domain expertise. The screencast building and documentation process is used as a springboard for mockups and graphic designs, and to force user interaction think-through prior to coding.

Any thoughts?

Nothing ever seems to work first time. For every piece and every concert we have to painstakingly decipher the work of the original creators in order to unravel some mysterious problem. We untangle cables and untangle code, we restart, rewire and reconfigure until everything works.

But the truth is, when all of the preparation is done, when the problems are solved, when the mixing desk is in place and the speakers are on. When the levels are up and the score is open, when you sit facing the performer and the audience is ready, when the lights are dimmed and the atmosphere is charged; ready for the first note… there’s nothing quite like the ‘buzz’ of live electronics.

“the most revolutionary new musical instrument of the last 60 years […] Designed specifically for live performance, it is simply the most expressive electronic musical instrument ever made.”

Now this claim has got me kind of annoyed. Not because I think the design is bad, or that it isn’t a great product, but because the Eigenharp isn’t a musical instrument at all, it’s just a controller. It’s a device a performer can use to produce a stream of information that could be used to trigger or control the synthesis of sound. However the Eigenharp itself however, doesn’t produce sound, and in fact once eigenlabs open source their software the Eigenharp could be used to control pretty much any electronic device . It is no more a musical instrument than a Wacom graphics tablet, an iPhone or any other device that can emit control data that when mapped correctly can be used to synthesise sound.

This might sound like a pedantic distinction, but it is very, very important in understanding what makes something a musical instrument. The instrument isn’t just about the physical interface, but rather the combination of a number of elements working together:

• the physical body of the instrument
• the human-mechanical interface
• the sound-producing mechanism

Traditionally musical instruments have a range of sound qualities (timbre) and a largely deterministic sound response in relation to human interaction. This makes them interesting and identifiable as being one specific instrument or another. Examples of instruments or devices with instrument-like capabilities include:

• a flute
• an electric guitar played through a Marshall amp (the combination of the guitar and the amplification form the instrument in this case)
• a zero input mixing desk
• a minimoog synth

All of the above have identifying sonic traits and models of interaction. The Eigenharp provides a interface with for the performer to interact with… so what of the sound production? Well, from the eigenlabs website:

“You can load and play your own Soundfonts, Audio Unit Plugins and Midi instruments with the Eigenharp Alpha. In addition, the Alpha comes with its own native instruments (at present a software model of a Cello, Clarinet and a Synth engine). The Alpha also ships with a collection of loop libraries and several acclaimed instruments from our partners:”

So basically, the Eigenharp could sound like anything — it is just a controller, it may be an excellent controller (I’m not sure), but it is only a controller — not a musical instrument.

Which brings me to the main point of this post. We really need to move beyond the controller-centred approach to ‘instrument design’, and start thinking about what it is that we are controlling, and what the complete interaction model is. By this, I mean that we need to design for the complete sensory experience of the performer when they play an instrument, not just physical control. The complete ‘feedback loop’ might include:

• physical input
• physical response (in the form of vibration e.g. through the fingertips)
• sound production
• physical stimulus (in the form of sound from the instrument)
• (adjusted) physical input in response to audio/visual cues

All of these elements interact in complex ways to form the performer-instrument relationship. However, if we focus too heavily on the design of one element (the controller, or the sound), we end up producing not an instrument, but a system that gives the illusion of being an instrument.

Syntax

These are just ideas, not formal syntax rules, but could serve as a starting point.

• Objects are instantiated using <object name> <arguments> e.g. cycle~ 440
• Connections are made using curly braces: <source object>{<target object>}. This makes an implicit connection from the first outlet of the source object to the first inlet of the target object. If inlets other than the first are required then inlet/outlet labels can be referenced using the slash notation: \<source label>{\<target label>}
• Inlets can be given labels using \<inlet number from zero>:<inlet label>
• Outlets can be given labels using \\<outlet number from zero>:<inlet label>
• Sub-patches can created using \pd <subpatch name> \{ <subpatch content> \}
• Messages are indicated with \msg

Curly braces and the backslash character have been chosen here because they are disallowed characters in Pd, thus avoiding ambiguities between the scripting code and the Pd code.

Example

To test the scripting language properly, I’ve constructed an example of medium complexity that illustrates a number of aspects of Pd patching.

In the fledgling pdscript, this would be represented as:

\pd mtodt \{
    inlet
    {
        mtof
        {
            \msg 1000 $1
            {
                /
                {
                    sig~
                    {
                        outlet
                    }
                }
            }
        }
    }
\} \0:midiin \\0:dtout

noise~
{
    *~ 0 \1:noisemul
    {
        delwrite~ buff 256 \0:delayin
    }
}

notein \\1:velocity
{
    {
        spigot \1:noteoff_filter
        {
            t b a \\1:pitch
            {
                {
                    f 1 \1:amplitude
                    {
                        \noisemul
                    }
                } 
                {
                    del 2
                    {
                        \msg 0
                        {
                            \noisemul
                        }
                    }
                }
            }
        } 
    }
}

\velocity
{
    / 127
    {
        \amplitude
    }

}

\pitch
{
    \midiin
}

\dtout
    {
        vd~ buff
        {
            {
                *~ 0.995
                {
                    lop~ 5000
                    {
                        \delayin
                    }
                }
            }
            {
                dac~ \1:rightout
            }
            {
                \rightout
            }
        }
    }
}

Implementation

I’m thinking that this could be implemented by writing a pdscript interpreter, which parses the script and compiles it into a list of FUDI commands to be sent to Pd via a network connection. If the script proves to be popular the interpreter could be built into Pd itself and maybe invoked with a command line flag:

pd -script myscript

Or maybe even run interactively

pd -ishell

Outro

These are just a few ideas as a starting point. Comments welcome!

Update 10/4/09

Thinking about this a bit more, the closing braces are redundant except in the case of branching. This means we can reduce the verbosity of the syntax a bit if we introduce a block delimeter. I therefore propose the comma for this purpose. I’ve also introduced the semicolon as comment identifier and changed the inlet/outlet labelling syntax to use an array-like syntax ‘\in[n]:label’ labels the nth inlet, ‘\out[n]:label’ labels the nth outlet.

;We define a subpatch using '\pd <subpatch name>'

\pd mtodt \in[0]:midiin \out[0]:dtout
    inlet
    {
        mtof
        {
            msg 1000 $1
            {
                /
                {
                    sig~
                    {
                        outlet

;A comma acts as a block delimeter
,

noise~
{
    *~ 0 \in[1]:noisemul
    {
        delwrite~ buff 256 \in[0]:delayin
,

notein \out[1]:velocity
{
    {
        spigot \in[1]:noteoff_filter
        {
            t b a \out[1]:pitch
            {
                {
                    f 1 \in[1]:amplitude
                    {
                        \noisemul
                    }
                }
                {
                    del 2
                    {
                        msg 0
                        {
                            \noisemul
                        }
                    }
                }
,

\velocity
{
    / 127
    {
        \amplitude
,

\pitch
{
    \midiin
,

\dtout
    {
        vd~ buff
        {
            {
                *~ 0.995
                {
                    lop~ 5000
                    {
                        \delayin
                    }
                }
            }
            {
                dac~ \in[1]:rightout
            }
            {
                \rightout
            }
,

This reduces down to the following if we remove the newlines and whitespace:

\pd mtodt \in[0]:midiin \out[0]:dtout 
     inlet{mtof{msg 1000 $1{/{sig~{outlet, 

noise~{*~ 0 \in[1]:noisemul{
    delwrite~ buff 256 \in[0]:delayin,

notein \out[1]:velocity{{spigot \in[1]:noteoff_filter{
     t b a \out[1]:pitch{{f 1 \in[1]:amplitude{
          \noisemul}}{del 2{msg 0{\noisemul}}},

\velocity{/ 127{\amplitude,

\pitch{\midiin,

\dtout{vd~ buff{{*~ 0.995{lop~ 5000{\delayin}}}
     {dac~ \in[1]:rightout}{\rightout},

It’s true of all forms of music that repeat performances increase the benefit, cost ratio. For example, if a composer is paid £5,000 to compose a work for an ensemble of 8 musicians and the piece is rehearsed for 8 hours plus one sixth of a 2 hour concert at a rate per musician of £30/hour with production costs at £1500 and 30 people attend the concert at an average of £10 per ticket that’s a loss of 5000 + 1500 + (30 * 8.3) - 30 * 10 = £6450.

However if the piece is played on a tour with 6 concerts, with 2 hours rehearsal per concert to ‘sound check’ this introduces a per-concert profit of (30 * 10) - (30 * 2.3) = £231. So clearly, the more times an ensemble can successively perform a work, the more the economic gain from each performance balances out the initial cost of commission and rehearsal.

Where L is the total loss, c is the commissioning cost, p is the initial production cost, r_n , a_n and t_n are the rehearsal cost, audience size and ticket price for the nth of N successive productions. With such a small profit margin as that shown above it would take 27 successive performances for the ‘piece’ to break even! This clearly illustrates that when commissioning new works, the cost of the comission and the likely production costs need to be balanced against the significance of the work in terms of the audience size it is likely to generate. This business model is epitomised in musical theatre with productions like Les Misérables seemingly on a constant loop at venues like the Queens Theatre in London.

The graph below shows a representation of total loss on a commissioned work as a function of the number of successive performances. However so far we have only been talking about ‘normal’ concerts that don’t involve live electronics. If we add electronics into the equation, we still get economic benefit from repeat performances, but this is offset by the additional production cost entailed by the electronics, especially if the setup is complex. In the following sections I will suggest possibilities for dealing with this scenario.

Standardisation

The currently exists no standard setup for live electronics performance. In fact, to my knowledge there isn’t even a standard recommendation for basic equipment like loudspeakers, mixing desks, laptops and software. Equipment is often sourced on a work-by-work basis entailing hire cost and hidden costs in terms of producers’ time researching and sourcing equipment. Few small ensembles have in-house systems. In addition composers and live electronics performers tend to use a variety ad-hoc and personalised software. This can be a good thing from a creative perspective, but can make it impractical to program multiple pieces with different live electronics requirements in the same concert.

One possibility for addressing these issues is to standardise. If we had a centralised equipment recommendation for live electronics performance it would enable new music ensembles and producers to start to build up a collection of equipment in-house, safe in the knowledge that they would be able to accommodate a wide range of works. Although this entails a high initial capital expenditure, it is soon outweighed by reduced production costs. Likewise, if composers and performers converge on certain standard protocols or setups they can be assured that their equipment will work ‘out of the box’ with other compliant systems.

The better the standardisation process and the more widely standards are adopted, the easier and more cost-effective repeat performances become. This reciprocal relationship is shown in the diagram below.

Innovation

So far live electronics has been discussed in relation to music for ‘acoustic instruments and live electronics’ where the electronic treatment is something conceptually separate ‘added to’ the instrumental sound. However, as pointed out by Alexander Jensenius in this post, there are a number of other live electronic idioms that allow for a far better benefit/cost ratio than traditional models.

With the growing prevalence and wide, relatively cheap availability of laptops and low cost or free software, technical virtuosi are emerging who can compose, develop live electronics systems and perform their own works without the need for external assistance or hired-in equipment.

Conclusions

In this post I have argued that whilst live electronics composition and performance carries with it a high economic cost, this cost can be greatly reduced by balancing commissioning/production costs against repeat successive performances, developing and adopting standardised equipment and software and through composers and performers adopting new more integrated approaches to electronics.

In the next and final post in this series I will examine some of the software barriers to the wider adoption of live electronics and suggest ways in which these problems might be resolved.

• live electronics requires a technological development process that runs alongside the composition process in order to develop the electronics
• often technician(s) or musical assistant(s) are required, and this costs money
• additional equipment (computers, software, interfaces, amplification, speakers, microphones) are required in both the studio where the music is composed and in the performance venue
• additional rehearsal time is required for the performers to experiment with and master the electronics
• additional training is needed for composers and performers to learn about electronics

Compare this with ‘acousmatic’ or ‘tape’ music:

• The same finished ‘product’ serves as a representation of the piece, a recording of the piece and the playback medium
• No score production is required
• No performer costs for rehearsals
• Diffusion systems are expensive to hire/install/maintain but these are often also required for live electronic music
• Composer has role of composer, performer and technician
• Composers tend to use existing tools, less of a software development element

Or instrumental music:

• No loudspeaker/amplification
• No technicians/musical assistants
• No studio costs other than for recording
• Rehearsal time is reduced because no need to rehearse electronics
• No software development alongside composition process

It can be seen clearly from these ad hoc lists that from a ‘total cost’ perspective, composing and performing live electronic music is significantly more expensive than either acousmatic or instrumental music. In addition, many of these costs are financially ‘hidden’ from the composer, however regardless of whether the composer works in academia, professional music or both, the cumulative ‘cost’ of production could have significant impact on the following benefits:

• The number of minutes-worth of music a composer can produce annually
• The number of works an ensemble can perform
• The quality/substance of the music produced
• The number of repeat performances of a work
• The profile generated for the composer and/or performers
• The academic ‘research value’ generated annually
• The international prestige associated with the work
• The total audience members reached annually
• The willingness of ensembles to record the work

Clearly if live electronic music is more expensive to produce, then fewer works will be composed and performed, negatively impacting on the benefit generated. Taking into account the total cost of production and the above benefits generated for the three types of music considered, I have extrapolated the following graph.

Excluding the rare scenarios of large-scale film music and musical super-stardom, the benefit-cost ratio of all music production is low. However, it could be argued that despite its relatively high cost, live electronic music has a high research value due to its inherently experimental and developmental nature. How this translates to business value for academic institutions is a different matter. To be continued!