The following is a Google calendar giving the key dates (including paper deadlines) for a selection of 2011 conferences relevant to live electronic music, computer music and music technology research. An iCal file for the calendar can be found here. Enjoy!
Following my ambitious 2010 New Year’s resolution to read a book-per-week, I started perhaps inappropriately with Carl Honoré In Praise of Slow. ‘Slow’ has the potential to be a life-changing read. It describes a way of life that calls into question the ‘productivity culture’ in modern society, suggesting an alternative based on living (eating, working, loving) more slowly in order to achieve a happier, more fulfilling life. A lot of the ideas presented by Honoré, come out of The Slow Movement and its predecessor Slow Food, the antithesis of ‘fast food’ and ‘ready meals’. All good stuff.
So, inspired the book, I set out to slow down my life. I started growing my own vegetables, making bread, thinking, relaxing, taking time to ‘savour each moment’ etc. For a moment it worked, but for all my good intentions my journey into the world of ‘slow’ was shortlived — quickly the demands of daily life took over as the initial inspiration from In Praise of Slow melted away.
Now at the end of 2010, I find myself reading Do More Faster edited by David Cohen & Brad Feld, an entrepreneur-to-entrepreneur advice book, born out of the TechStars startup accelerator. Do More Faster is an excellent collection of short articles by successful founders, investors and CEO’s sharing their experiences of creating startups. It’s mainly quickfire, practical advice with a common theme of speed — make decisions quickly, fail fast, get feedback early, throw things away etc. The book is written in short easily digestable chunks (1-3 pages) that can be read quickly. It’s not only about speed, but that’s the key advantage of small companies over big ones, writes Cohen.
So what happened? How did I go from “In Praise of Slow” to “Do More Faster”? The truth is, like most people, I live a very busy life: I have 3 small children, a full-time job, a house and garden to maintain and ongoing side projects etc. So, whilst I like the idea of ‘going slow’, it’s not really practical.
One of the key points Honoré makes is that the Slow Philosophy isn’t about doing everything slowly, it’s about achieving ‘tempo giusto’ (the right speed). This means it’s best to do some things quickly and others slowly, as appropriate. The problem is that In Praise of Slow is an exposition on an idea not a practical handbook. It doesn’t really tell you how to achieve slowness, it just says what it is. But here’s the idea: if I do some things quicker, I can do others slower. It’s about balance — simple!
So in 2011, I’ll try to put this into practice and search again for tempo giusto.
I lost interest in developments in the Pd community for a while, and stopped following the list. The same problems kept coming up, with no solutions; key external libraries were buggy difficult to get working. I also found I didn’t have time to support my own externals (I like to contribute to communities I’m involved with).
Recently things seem to be changing, and Pd is really getting me excited again. A few things seem to be catalysing this, with specific individuals moving things forward. The RJDJ project has played a big part in this, along with Peter Brinkmann and Peter Kirn pushing libpd to release. This allows Pd to be ‘embedded’ inside a larger program, and importantly, is supported on a number of mobile platforms.
Then there are recent (2010) developments in Matju Bouchard’s Gridflow (similar to Cycling 74’s Jitter), which now has nice installers for multiple platforms, and is a breeze to setup and get productive with.
I’m also interested in Chris Mccormick’s (also of RjDj fame) PyPd project, which enables easy interfacing of Python with Pd.
Also fairly recent (2009) is William Brent’s timbreID project, which provides various audio feature extraction and timbre recognition functions. The resulting system is impressive:
Additionally Pd’s GUI has been rewritten this year, bringing a number of subtle but important usability enhancements, and paving the way for future work. Changes will be available in version 0.43.
Finally, there are numerous changes to the Pd core, including improvements to data structures and bonk~.
Exciting times… just need to make some time to play with all this stuff!
Many times in reading job adverts or person specifications for jobs, I read the phrase “…or equivalent experience”. The context is usually something like “the candidate must have a degree in computer science or equivalent experience” or “the role requires a PhD or equivalent experience”. Now having taught at two schools, worked for four years at an FE college, studied at three universities to PhD level and worked as university lecturer and tutor, I can say with some authority that the notion of ‘equivalent experience’ is a myth. It’s a concept which trivialises the true value of university education.
The word ‘equivalent’ literally means ‘equal value’, and can also mean ‘of equal significance’, or ‘having the same effect or meaning’. So when we say ‘equivalent experience’, we are implying that it is possible to measure the value added by university education, and that it is in some way possible to gain experience of equal value in the ‘real world’.
I disagree with this on almost every level. I don’t believe it is possible to measure the value of university education (although it may be possible to perceive it); I don’t think there is any process that can provide the same benefits as university education, and I think the polarisation of ‘academia’ and ‘the real world’ as complimentary opposites is a myth — I view the relationship as continuous and reciprocal.
Continuing this line of thinking, I think that ‘…or equivalent qualifications’ is also an inappropriate expression (although I’ve rarely seen it). University study and work experience are simply two different activities offering a different range of skills and knowledge. Both have value, but they don’t have the same kind of value and they are in no way interchangeable.
So how does this relate to the current debate on university funding? Well, I’m inclined to agree at least in part with what Stewart Lee has to say on the matter.
However, whilst Stewart is talking primarily about the arts, I’d go further by adding that we should try to shift the debate towards the value of the pursuit of knowledge for it’s own sake in general. What I would love to see is for universities to become more academic, not more vocational. For some careers (e.g. science, medicine) the two are very closely linked, but for many professions (business, engineering, nursing, teaching!), an academic qualification has little to offer in direct terms — practical, hands-on experience is in these cases a much better qualification.
That’s not to say the fruits a university education have no value in business (for example), they just aren’t equivalent to experience. What university can (and should) produce is individuals with the ability to ask meaningful questions about the world around them, to form a reasoned argument, to value knowledge and the pursuit of knowledge for it’s own sake, to understand the networks and interconnections of people and things…
So, I hope that as universities start to compete for student fees, they sell themselves to their true strengths and don’t simply become factories for the capitalist workplace. If universities do play to their strengths as centres for the pursuit of knowledge, the sector will surely shrink as more potential students enter work instead of study. But as it shrinks over time and clearly defines its role as ‘more than equivalent’, perhaps the university sector will once again become publicly fundable.
I found Steve Job’s rant about Google Android yesterday very interesting, because it highlights something fundamental about Apple: Steve Jobs believes that closed platforms are the price you pay for integration. I’ll call this the Steve Jobs line of compromise:
Apple believes that it can defend its position as essentially a closed-source shop, because there is a deep-seated belief in the company that this is the only way to achieve great user experience. If you build on open source as Google have done with Android, the platform risks fragmentation.
QUESTION: is it possible to build highly integrated platforms on open source models?
Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
Never use a long word where a short one will do.
If it is possible to cut a word out, always cut it out.
Never use the passive where you can use the active.
Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
Break any of these rules sooner than say anything outright barbarous.
I love the concise writing style implied by these rules, but I particularly like rule 6. One problem I find with my own writing is that it can tend to be over-concise; too many words cut out, not enough explanation. Rule 6 asks writers to use the other rules as guidelines and always to use their own judgement. The full essay is well worth a read.
For my next project, I’m going to try the following software development method:
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.
Let’s start by making one thing clear: I’ve never been a huge fan of Adobe’s Flash. It always seemed to me, a necessary evil — necessary because it allows publishing on the web that can’t be done with the browser alone, and evil because it requires the installation extra software to access content.
But in the light of recent criticism from Apple, I find myself becoming concerned about the misleading way arguments are being presented. The main reason for this is that Apple’s criticism of Flash, and promotion of HTML5 seems primarily a piece of market positioning: Apple, the champions of open standards, Adobe, the peddlers of all that is closed and proprietary.
Why would Apple do this?
Well, what the Flash vs HTML5 debate does is to hide the real reason for Apple’s anti-Adobe position: Apple wants to control the web publishing abstraction layer. Specifcally, this isn’t really about Adobe at all, this is about any non-Apple software for developing content and applications on the web. Apple isn’t just anti-Flash, they’re anti-Java and anti- anyone else who wants to provide abstraction from the browser and alternative browser-based development platforms. In short, Apple wants WebKit to be your one-stop shop for web publishing on any device.
In theory this seems like a good thing, developers and designers could have one publishing platform, and one set of standards (HTML5 + CSS + JavaScript) all running under a cleanly designed layout engine developed by one of the best software shops in the world and it would look and feel the same wherever they deployed it. To top this, WebKit is even open source. This is why it is gaining traction and now used not just in Apple’s Safari browser, but also in Google’s Chrome, Gnome’s Epiphany and on a large number of mobile devices .
So what are the implications of this? Well, currently if you want your content or app to look and feel exactly the same regardless of browser, you develop in Flash. Flash provides an abstraction layer that isolates the your code from cross-browser differences and incompatibilities. Apple want’s to kill Flash and for WebKit to become the abstraction layer; it wants WebKit not Flash to isolate your code from cross-browser differences. In Apple’s world, Webkit will become the layout engine.
The problem with all of this is that by controlling the publishing abstraction layer, Apple is effectively controlling the type and nature of the content you can publish online. This is the opposite philosophy to the early evolution of the web and browser technology. Instead of being de-centralised and community driven, it looks like the future of the web will be centralised and driven by a few big companies, like Apple and Google.
I leave the reader to decide if all of this is a good thing, but end with the closing thought that the primary aim of big companies it to make money for their shareholders. Apple are not the champions of open standards Steve Jobbs makes them out to be, neither are Adobe evil purveyors of everything closed-source and proprietary. Both companies are open so far as it suits them and only where it means greater control in the marketplace and gain in market advantage.
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.
Python comes across as a less-appealing, less-sexy language than Ruby
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:
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.