Why musicians need to think like programmers …
… when collaborating online.
If I was collaborating on a software project right now (even during lockdown) the team would be “agile” —a term (and explanation coming shortly) that has been hijacked (mainly incorrectly) in other business areas. Because software projects have failed so spectacularly in the past, smart organisations have adopted an alternative methodology that makes such catastrophes less likely. I will argue a similar approach can be applied to musical collaborations.
In an ideal world, bands would be able to rehearse/record together merely using a Zoom link. In practise the sound delays between the players’ computers make this impossible. Here is a diagram showing three interrelated processes used in software production. Today I am going to concentrate on Agile, but I might explore design thinking and lean startup in future articles.
If you are interested you will find a lot written about the above processes on the internet, but the main takeaway here is that software projects have failed, and often failed big time because a “waterfall” approach was adopted. By this, I mean that the process flowed downwards — requirements, design, implementation. More often than not, this leads to a product that no one was expecting and no one was happy with — assuming anyone could actually make the program work. This was how we worked thirty years ago.
Niagara, not Viagra (hey, it’s a song title) is how I am feeling with the 3 bands I am collaborating with. In each case one person will rough out a song which will then be passed to the other musicians, one by one, to add their bit with the hope that this can be mixed into something that will, um, work. This is very waterfall and not how a song would evolve at a rehearsal where the musicians will play their way through who does what, how and when: from overall layout (verses, choruses and solos) to tempo and dynamics (well possibly not dynamics). And, not forgetting, how a song might mature as it is played live. Yes, this is an iterative process.
One key element of the agile process is communication — regular planned meetings of all the stakeholders. Interesting aside: in a software project, a key stakeholder is a customer who will eventually use (or sell on) the program. Pieces of music do get commissioned but the result is not normally heard (I could be wrong) until the work gets played. The commissioner hopes that the eminence of the composer will attract concert-goers to the performance and thus make their money back through ticket sales. Could there ever be a collaboration between, say, a band and a pub where they work together to provide music that will attract a healthy audience and increase beer sales (leading to an unhealthy audience!).
My current experience of collaboration communication is — one person sends out an email, and a few days later someone replies “er, what’s happening”. Two months down the line — 3 bands, no music (yet). Email is not working. I think regular video calls between the whole band are needed — could be Zoom, could be Skype, my preference is Whereby as it has some cool integrations that would make project management easier — more on this in a bit. Whereby is free to use for a small group of people and has no time limit for meeting length, and no passwords are needed. Instead, the user is assigned their own personal “room” e.g. whereby.com/my-room. Whatever system one uses, the group should plan regular meetings as fixed times, whether this is twice a day, or once a week.
It’s a short meeting — let’s listen to what we have already recorded. What aspect of a song will I work on next? Do I have questions on how to do this? Do you have any thoughts and suggestions? Do we have a light touch way of managing all this? Yes, it’s called Trello, it’s free, and guess what, it is integrated into Whereby. I may discuss Trello and the other apps I mention in further articles, but in short, it is a graphic, card-based system for assigning tasks to team (band) members and maintaining to-do and done lists. I even use it for organising songs into setlists.
As one goes through the software cycle, tools exist to make sure that no one messes up the best (or current working) copy whilst allowing experiments and development. We’re talking version control: we’re talking Git (look it up). A music collaboration needs version control (in fact it does exist in some apps — see Blend.io — but I have not found a single app that does everything I want or does it cheaply, or better still, free.
Talking of different versions of a song, where do we store them? Once again there are music apps that take care of this but once again I have found none that are particularly suitable. I think the overall problem is that some apps handle one part of the process well but ignore others, and, so far, the best tools can be found outside of music circles. Cloud storage is one of them. Dropbox is an obvious choice for sharing files as it can be made to look like the local storage system but, unfortunately, my Dropbox was maxed-out and I wasn’t yet ready to start paying for an upgrade. Doing a search of alternatives, I came across pCloud which seems highly thought of and, like Dropbox, is seamless between local and cloud storage. pCloud is also generous in the amount of free storage (10 GB) with reasonably priced options up to 2TB for lifetime use — more than enough for that album.
Let’s have a folder for each song we are working on with sub-folders for individual recordings (WAV files) that are shared between band members. Let each musician download a local copy to work on and only upload their own tracks to the “working” version. Only the team leader (who may be different for each song) can create the (audio) mixed working version although there is nothing to stop individuals experimenting with local mixes and then sharing the ideas. However, this latter point brings us to something I am surprised I haven’t got round to discussing until now.
And that is — why are we collaborating at all? For me, this is different for each of the 3 projects I am part of. The projects are
- Long-standing band wanting to make videos of some of their (cover) songs but asking other Brighton musicians to participate (a local version of Playing for change — Song around the world). The challenge here is to be able to leave space for other musicians on songs where we are usually full-on. And to do it to our best abilities.
- A new band learning original songs by the guitarist but with the scope of everyone developing the arrangements and improvisations. And with the intention to play live when that becomes possible. Here we are learning new material and, in part, can use the recordings to become fluent with our parts.
- As for 2 but less fully formed — the idea is to put a live set together from a singer-songwriter’s material and then find other musicians to play with. So this will be much more about making interesting arrangements of very original material.
Finally, I have not mentioned DAWs (digital audio workstations). As I started writing this piece I was thinking that all the players should use the same app and was perplexed by the notion that some of the team might have Apple products and some PCs. While most common DAWs for the PC (Ableton, Cubase, Reaper and others) have versions that run on a Mac, the opposite is not true. Garageband, and it’s big brother, Logic Pro, are not PC compatible. If one was looking for a common (and free) way to work across both platforms I would suggest Audacity. Even though I am an Ableton user, I still use Audacity for various bits of work.
The main thing to remember if one is creating tracks for sharing, make them run from the beginning of the song, even if you are only playing from halfway through. This means that others will be able to line your work up exactly with theirs. How you will achieve this will depend on the software but should be doable.
Everything that I have written so far is theoretical — untried and untested — but I plan to write of my successes and failures if and when we adopt any of the above. I am more confident in the methodology than the peopleolgy.
