Blog

I believe that the next step in my research should be to categorise the different elements of a project according to the characteristics of the technology they represent. Because if I do that, I can start to understand the types of characteristic that exist, and therefore the range of impacts that an element can be expected to have if it can be accurately said in advance to have a certain technological characteristic.

Example 1: I acquire an iPad, and suddenly I can get through my emails 50% more quickly than before. That is an ‘accelerator’, because it has sped up an existing process.

Example 2: I acquire a new set of strings for my violin. Let’s say they have a unique set of qualities that allow me to produce sounds that I could never create before, without doing anything differently in the way I play. The (sound production) process isn’t altered, but the output is. Let’s call that an ‘alternator’.

I’m making up words as I go along here: if you don’t like them, please feel free to suggest an alternative!

**

Here’s where I’ve got to so far …

Accelerator: speeds something up
Alternator: changes the output of a process without changing the process itself

More to follow…

I’ve noticed a flaw with the ‘mapping’ of projects that I’m doing, but I don’t think it ultimately matters that much.

With a map, there are standardised levels of detail. At a certain zoom level, you’ll see area names, motorways, main roads, rivers and major areas of specific terrain (like national parks). Zoom in, and you’ll start to see a consistent enhancement of the detail – small roads, stations, road names. You’ll get this consistency of detail level regardless of where you zoom in on the map. A road in America is depicted to the same granularity as a road in England.

(Royal Academy of Music, from different levels of zoom on Google Maps!)

My ‘mapping’ of the elements of a project is a bit more messy, because there’s no standard categorisation of types. A musical instrument is such a complex thing that you could focus in on any part of it – for a violin, a new technology could be a new set of strings, a new type of rosin (both technologies external to the violin itself), a different-shaped part of the violin design, or indeed an entirely new design of violin altogether. Hook that together with many other different types of thing (people, instruments, venues, tools) and it’s hard to find any consistent way of making like-by-like comparisions. More to the point, it’s different to pinpoint any consistent zoom levels.

That’s why my spaghetti-maps look a complete mess!

However, I don’t see any logical necessity for developing a way of mapping these elements in a manner that is inherently consistent. This is because I am only using the output of these maps for a very specific purpose;  i.e. to see what the effect of technologies is within a map of elements (and thence understand flows of influence within those relationships). It would be unnecessarily time-consuming to endeavour to develop a more consistent mapping language, just for the sake of accuracy or more detailed examples, when I can get enough of a useful output from these messy (and somewhat inconsistent) maps to prove beyond doubt the general principles.

I just need to be able to determine technological influences, and their nature.

Hang on. Is that right? Isn’t there anything else that these maps are useful for? Maybe this is naive and there are subtleties I would miss by not categorising types at multiple levels.

Actually, perhaps it will be after technicological characteristics are categorised that this kind of organised granularity would become useful. Because then I can apply the known characteristics back at a micro-level to see how they work.

I think I’ve just changed my mind – perhaps this is something I must investigate to find out whether it is useful or not. But I’ll do that after categorising the main technological characteristics.

OK, so here’s a version of the map of interactions with the Earpiece reduced to its simplest form:

And here’s one with a couple more elements added in:

So the CDR Soundtrack goes to the Sound Technicians who feed it into a Computer to create a Metronome Click which gets fed into the Transmitter which broadcasts it to the receiver of the Earpiece which plays it into the ear of the Conductor.

I think there are two next steps:

1) Generate several more maps like this charting the path of the music through all the different elements of each project.

2) Begin to categorise the types of technological something that’s happening here. Then trends will start to become apparent.

The problem with a map is that there are so many different levels of detail that it is possible to use.

In the last post, I tried to create a ‘moderately comprehensive’ map of the elements of the project. The next step, I thought, would be to take an ultra-detailed snapshot, focused on one small element.

I’ve chosen the earpiece worn by the conductor during the performance.

Immediately at this level, I’ve been forced to insert a couple of extra bits of detail – just as you’d see more road names if you zoomed in on Google Maps. What’s happening here?

The CD-R Soundtrack is being given to the Sound Technicians who are using it to set the speed of a Click Track which is relayed to the Earpiece (how? Already I see I’ve failed to include the computer handling this, and the transmitter that relays it!), which plays the click (and possibly the backing track) directly into the ear of the conductor.

I’m fairly sure I don’t need the rest of the information on the map, so to make it look less confusing, I’m going to create a version that doesn’t have any of the excess information on it, i.e. I’m going to delete all the other elements listed that don’t form a direct part of the particular process I’m isolating.

I’m using my own projects as case studies during this first year of research, and hope to use them to create a set of theses that I can then test out on other peoples’ work.

One of these case studies that I’m tracking (concurrently, whilst doing everything else!) is my learning curve for the Beethoven Concerto. I’ll be playing it in June with the Ramallah Orchestra at the Palestinian National Theatre in Jerusalem.

I’ve started a page here to track my work on this incredible piece. I can sense already that the kind of interactions I’m able to have as a result of all the different online and offline resources which are available, are definitely very different to the resources I had access to when I was an undergraduate student. It will be fascinating to map out and eventually start to understand exactly what those differences are.

Before I create another map, I want to first try ‘tracing’ the path of the music through the project using my first map.

What am I actually tracing?

I annotated the map (by adding the coloured arrows) before writing the commentary below. Consequently, I am only now thinking through what I have drawn using the arrows, and trying to define it. I knew intuitively what I wanted to trace when I initially drew the arrows, but it is hard to describe. The best way I can think of putting it is that I’m illustrating ‘the ownership of the development process’ of the actual piece of music involved. The custodianship of the music, if you like, between the point of conception and the point of delivery.

GREEN = Client/Agents (Commissioners/Facilitators?*)
BLUE = Composer
RED = Performers

*Problem: Levels of detail I didn’t see

Immediately, I realise that ‘Agents’ (as I am identifying the Royal Academy of Music and the Brand Promotion Company) and ‘Clients’ (who I would assume to be the manufacturer, in this case Samsung), are in fact – for the purposes of this map – needing to be grouped together. This is exactly the problem I identified before… knowing how to deliniate ‘levels of detail’.

For now, I’ll just bunch them together as ‘Client/Agents’. But it immediately shows that it is possible to zoom out to a higher level of detail than I’d previously been aware of.

General Commentary

Here’s a brief commentary to accompany the map above, that attempts to outline ‘the ownership of the development process’ of the music.

In the first instance, the piece of music exists only in the mind of the client. Then, the client talks to the ‘brand experience agency’ (agent) and together they develop the idea of what that piece of music should be. Once the idea has taken root, they contact the Royal Academy of Music (agent), who in turn contact the composition department (agent). The RAM composition department contact a composer who they think can take on the job, and the composer agrees to it.

At this point, the piece of music is purely hypothetical; it doesn’t exist. But is it possible that the key characteristics, or the parameters of the piece are already falling into place? Between the idea that the client (and now the brand experience agency) have in their imagination, and the abilities of the composer (which are high – a composer selected for a job like this has the ability to ‘pastiche’ in a number of different styles), is the final scope of the musical work beginning to be limited and defined by the logistical choices that are being made, even though no-one’s started to create a practical outline of it yet?

The composer starts the process of composition. (When does he actually start it? When he first hears about the commission? When he begins to scribble notes to himself for the first time? When he actually sits down at his desk to write for the first time?). I have notated this as a process, indeed an invisible process, but I’m not sure how accurate a categorisation that is.

The tools I have listed include a sequencer (for creating the backing track) and music notation software (for the sheet music parts that the performers will play off), but immediately I realise I may well have missed out manuscript paper or indeed any other tools that the composer could have used in the compositional process. Back to my original concern – it’s very hard to decide what level of detail is adequate.

If the input into the music notation software and the sequencer during the compositional process can be said to be the ideas of the composer, then I would define the output as, respectively, printable sheet music and a recorded MIDI track. I become aware that my elements on the map are one element further along in the production process from that: the level of detail I have used assumes the availability of a printer and a CD-R recorder. These would elevate those two outputs into an existence as tangible items: printed sheet music and CD-Rs of the backing track.

The sheet music and the CD-Rs are given to the performers to take away and practice on their musical instruments.

Now I remember why I have used separate colours – the change in colour represents a shift in custodianship. Just as the client handed over overall responsibility to the composer, so the composer then hands over responsibility for the music to the performer.

Interestingly, the custodianship is not actually so clear cut, and this is not reflected in the map above. I remember from conversations with the composer, that because of the demands of the client, the piece continued to change even in the final days leading up to the project (some sheet music, for example, had to be reprinted and redistributed to the performers after a change).

Also, earlier in the process, the client had been very closely focused on the compositional process, even though they didn’t actually understand how it worked, because they wanted to be sure that the composer was reflecting their imagined ideas as closely as possible. So the handover of custodianship was in no way complete.

Similarly, the composer worked with the performers during initial rehearsals, in order to convey the ideas that he had about the piece. The composer was also later confirmed as the conductor of the piece, which meant that the custodianship of the piece actually continued, in this instance, to be the ultimate responsibilty of the same person.

I theorized that: by breaking down everything I knew about the project into small component parts (which I shall refer to as ‘elements’), I could start to track how the flow of information and ideas moved throughout the project.  By mapping out the process in relation to the elements involved, I can start to see the role that each of those elements plays.

And I do definitely mean see, rather than understand. At this stage, I’m not worried about looking for any conclusions. I just want to ‘slice and dice’ the flow of information in as many ways as possible. This is because there are likely going to be many layers to this process – the more I look into a particular aspect of the project, the more information will reveal itself. 

Here was my first stab at creating a set of elements, and loosely categorising them (click to enlarge):

Immediately, I am faced with a problem: level of detail. I could magnify almost any of these elements and uncover a whole deeper level of information, and of course there’s nothing stopping me from drilling down to almost any level I like. That makes it impossible to create any kind of ‘comprehensive’ map. Everything presents an incomplete picture.

I don’t see any ‘easy solution’ to this. It’s essentially an arbitrary process. But what I can do, is draw several maps like this, each exploring a different route or a different level of detail through a particular part of the project. Then I’ll compare, contrast, learn, and move forward.