A couple of years ago I was involved in starting a software development project that aimed to bring a focus of usability, good user experience and ‘feel good’ graphic design to open source music creation software. We were discussing potential platforms one day, and my boss suddenly said to me “we should use Ruby”! I was a little taken aback by this. I had been aware of Ruby as a scripting frontend for the Gnome desktop environment, but not as a serious desktop application development language. So why did he suggest it? Well, if you look around at software on the web that has great UI and UX, and great look and feel, Ruby is never far away. In short, people who understand and appreciate great design are attracted to Ruby, and these people employ great designers.

The Ruby official site is a case in point. It has a nice succinct paragraph telling you what the language is about, set against a simple code example, easy and prominent links to download and get started and a cuddly look ‘n’ feel that makes you want to dive in and get coding. Following the “Success Stories” link, we see that Ruby is used by ‘A List Apart’ and 37Signals; notable gurus of web design and purveyors of good taste.

The Python home page by comparison looks cluttered, and has a clunky opening paragraph. The look ‘n’ feel is clinical and lifeless with no space for the content to ‘breath’. Python’s ‘Success stories’ section is harder to find and more verbose and poorly presented. In short, from the respective websites alone, Python comes across as a less-appealing, less-sexy language than Ruby.

Compare also Ruby on Rails (arguably Ruby’s flagship success story) to other web development frameworks in terms of their marketing:

• Ruby on Rails (Ruby)
• Django (Python)
• CakePHP (PHP)
• Catalyst (Perl)

For me the Rails site just gets it right: it’s clear, concise, elegant and exciting. In terms of design, the other frameworks don’t come close.

So… I can see why someone who wants to make a piece of software with focus on usability and great design, might choose Ruby: it has a community of like-minded people around it, all pushing out nicely designed web apps. This isn’t about band-wagon jumping or being a ‘victim’ of marketing or hype, it’s about acknowledging that talent converges around great design. Python, Lua et al, might be well designed languages, they may well be more powerful, more readable or more flexible than Ruby, but if they can’t convey this effectively through their web presence, they won’t attract developers who value great design.

We spend a lot of time complaining about live electronic music — the unreliable systems — the complex setups — the unappreciative audiences, performers, composers — the poor documentation — the lack of standards — the lack of a good business model.

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.

Happy New Year! In an attempt to encourage myself to keep them, I thought I’d blog my new year’s resolutions. Here they are:

• Give less, do more

This will be the year I give up my long standing Greenpeace donation as well as donations to NSPCC and Cancer research. I feel kinda bad about this, having been a Greenpeace member for over 10 years. I didn’t take the decision lightly, but I now have three children and am considering starting a business - things will be tight. Equally I’m starting to feel that a lot can be achieved through direct action, and there are many other contributions I can make that are not financial. I therefore intend to do more letter writing and campaigning this year. I might even get my conservation volunteering boots back on.

• Grow my own

Growing your own veg seems to me a complete win. It’s good for the environment, it’s rewarding, it’s good for you and it tastes great. I’ve never had a proper garden, but this year I have no excuse. Considering also buying a greenhouse.

• Work smarter, not harder

There is a lot I want to do with my life, and at the moment I’m nowhere near getting it done. If I try to physically do everything myself, I’ll never get there. This year I’m going to step back and delegate more. I’m going to focus on the areas where my skills can add the most value.

• Read a book per week

This may sound ambitious, but I’m going to try to read an average of one book per week. I have way too many unread books sitting at work and at home. Time to read them or stop buying books.

• Relax and play

2009 was kinda crazy. I submitted my PhD and viva’d in March; my wife gave birth to twins in April, making us a family of five; we bought a house and moved in August. All of this whilst managing a European software development project, coding, writing papers and running a number of side projects. Towards Christmas, I was starting to feel a strong sense of burnout. So… in 2010 I need to set aside specific relaxation times in my weekly routine. These can be used for meditation, reading for pleasure or creative play etc.

My overall theme of the year is ‘flow’. The plan is that by doing less in some areas, I can achieve more in the aspects of my life that are most important to me. Let’s see what happens!

My latest offering on Mixcloud — variations on the jazz standard, Caravan.

The blogosphere is currently alive with talk of the new Eigenharp from eigenlabs, officially released earlier this week. The Eigenharp, which comes in two forms, a large “Eighenharp Alpha” (pictured below) costing from £3,950 and a small “Eigenharp Pico” from £349 is described by eigenlabs as

“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.

I’m kind of obsessed by the Jazz Standard, ‘Round Midnight by Thelonious Monk. I performed it for my first year Piano exam at University, and have kept revisiting it ever since. The harmony and and phrasing is enchanting and lends to many interpretations. This mix on mixcloud includes some of the choicest picks. I think the Wes Montgomery take is my favourite.

'Round Midnight by Outoftune.Tv on Mixcloud

The following Google calendar represents the list of BBC Proms 2009 concerts containing ‘modern’ works. Based on a list originally compiled by Ed Lawes that can be found here.

Click individual concert links to see full programme listings.

An iCal file containing the above calendar can be downloaded here.

Enjoy!

I’ve recently been frustrated the lack of facility for sharing Pd and Max patches in an textual format. They are, after all graphical dataflow languages, which is great most of the time, but what if you want to share a bit of Pd code with someone on Twitter, or via chat? Do you attach the Pd file? A screenshot? … all of these seem too ‘heavyweight’ for the underlying medium. Personally, I’d like to be able to share Pd code in textual snippets as Perl and SuperCollider users do.

This has led me to think of a simple ‘lightweight’ scripting layer that runs on top of Pd’s native ‘FUDI’ interface. I want it to be as close to Pd patching as possible to make it easy for Pd-users to learn and to not introduce any new language-level constructs that aren’t already in Pd. Here’s where I am at so far:

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},

In a recent post I talked about the cost/benefit ratio of live electronic music for composers and performers and concluded that whilst traditional live electronics delivers relatively low economic value, it provides high research value. In this post I will describe ways in which electronics can deliver both economic value and research value.

Repeat, repeat!

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.

This can be generalised to the following equation:

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.

This reduces costs during the composition process by removing the need for musical assistants and expensive studio time and reduces performance costs by removing the need for extra technicians etc. It also brings with it added artistic/research value in the form of new artistic idioms associated with laptop performance and the development of new interfaces/systems for musical expression.

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.

“The human-built world can afford a sense of beauty, sublimity, and resonance, and through our advancements in technology can come advances in society. At the center of these advances are interactions—conversations, connections, collaborations, and relationships—within and across multiple disciplines, with and without technology.”

— Richard Anderson, Jon Kolko (Interactions magazine, January + February 2009)