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)

Most composers of live electronic music probably don’t think of their work in business terms. After all, there’s little or no money to be made from the medium even for the most well established artists, and even ‘big’ commissions are barely enough to make a living from. As a result of this, many creative types seek academic positions as lecturers or researchers, with institutions giving individuals a portion of their working hours to practice their art as research.

Whether an artist is funded via commission or through an academic position, it often seems inappropriate to consider the music-making process in business terms. However, in order to maximise the value generated through their creative work, musicians working with live electronic media should consider carefully the benefit/cost ratio of their chosen medium. Put simply: live electronics is very expensive to compose and perform, and brings relatively little financial benefit to the people involved in its production. So why is it so expensive?

• 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!

I’m writing this a month later than I’d planned, but nonetheless, I thought it’d be worthwhile sharing my thoughts on useful and interesting technology from 2008. I don’t think ‘08 was a year of earth-shattering innovation, but rather a time of consolidation and growth in already-established technologies. In this post I’ll give my best picks.

Max 5

For me this was the most significant software release of 2008 — the much anticipated, discussed, hyped and criticised release of ‘Max 5’. If nothing else Max 5 has been controversial amongst the Max/MSP and dataflow programming communities.

This release brought a raft of changes including:

• JSON-based file format
• ‘Presentation’ mode, which separates visual and logical layout
• Re-written GUI based on JUCE
• Patching workflow improvements and shortcuts
• Integrated documentation
• New ‘metrical’ timing system

The impressive thing about the Max 5 upgrade is that Cycling ‘74 have managed to make these changes with minimal impact on existing Max patches and externals, i.e. the majority of users’ patches and externals will work as before, with only very esoteric or gui-based externals requiring a rewrite.

However, you could look at this another way: the changes in Max 5 are largely cosmetic. There is nothing ground-breaking about Max 5, there’s no paradigm shift. Just a large number of usability and user-interface improvements, which should make the software easier to program with. I don’t think Cycling ‘74 will lose or gain large numbers of users as a result of these changes.

However there are two things that stand out as being more important. The first is the JSON file format. This has the advantage of making Max patches a lot easier to convert to other formats (e.g. XML) meaning that they can be read and interpreted by other software. It would be relatively straightforward, for example to write a web app for rendering and even editing Max patches in a web browser.

The other significant change is the choice of JUCE for the UI framework. Using JUCE means that Max/MSP no longer has specific dependance on the OS X or Windows operating systems, and can go wherever JUCE can. The subtext of this is that C’74 could (if they wanted) release a Linux version of Max 5 with relatively little porting work.

To summarise, Max 5 marks a significant improvement in usability and interoperability, but the nature of Max as a programming language hasn’t changed.

Twitter

Twitter is just so simple, yet so useful and versatile. It takes the idea of ‘status updates’ found in Facebook and other social networking sites, limits them to 140 characters, and makes a public feed from them. Updates are displayed on the user’s page and any subscribed users’ pages. Twitter is a big win for the Ruby on Rails framework it’s built with.

2008 has been Twitter’s year, with the site’s monthly unique visits rising from 0.5 million in December 2007 to 4.5 million in December 2008 (source: siteanalytics.compete.com). According to Twitdir the total number of Twitter users rose from just over 600,000 to 1,000,000 in the first quarter.

I predict that Twitter become even more significant in 2009, entering public conscious on national news.

OS X 10.5 ‘Leopard’

Leopard was released on October 26th 2007, but its impact was really felt throughout 2008 as users upgraded. Leopard includes a raft of usability improvements including virtual desktops (Spaces), RSS support in Mail.app, CalDAV support in iCal, pseudo-3d file browsing (coverflow), fantastic backup facilities (Time Machine) Cocoa scripting bridges for Ruby and Python etc etc.

This was the release that finally caused me to move away from GNU/Linux as my main desktop operating system and switch to OS X. Put simply, OS X is now too good to be ignored.

Android

Android is a software development platform and mobile operating system released in the UK on October 30th 2008. Android is significant for the fact that it is based on the open-source Linux kernel and a mostly open source software stack, but has massive commercial backing from Google. It supports application development in the Java programming language, and also in Python using the jythonroid extension. The T-Mobile G1 is the first Android powered mobile phone.

Only time will tell whether Google can make a success of this, and take on the Apple iPhone in the super mobile computing market. Personally, I have my doubts.

Python 2.6

Python 2.6 was released on October 1st 2008, and sees significant improvements and additions both as bug fixes and important language-level changes that bring it in line with Python 3.0. Python 3.0 will be the first Python release to break backwards compatibility with prior versions, and 2.6 is designed partly as a ‘transitional’ release to ease the porting process for developers.

Changes are too numerous to mention here, but can be found in detail at docs.python.org. Some of the highlights for me are:

• The new json module for encoding and decoding Python values to/from JSON
• plistlib, a library for generating and parsing OS X plist files
• Class decorators

I haven’t yet ported any code to 2.6, but I’m looking forward to playing with some of the many new features. I’m particularly intrigued by the with statement that was added in 2.5.

—

That’s all folks! We’re already a month into 2009, and with a ‘Max for live’ product announced by Ableton and an Intel Mac-bootable key-based media arts Linux distro on the cards from pure:dyne it looks to be another exciting year.