This entertaining article supporting test-first development has been playing on my mind. The article is beautifully written so it is easy to see the assumed context of working to deadline on well specified problems, most probably in a commercial environment. It saddens me though that we accept this implicit context across all discussion of software development practice all too easily.
Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.
So there is a fairly clear reason not to write any tests for your code — you will take in more of the problem domain without such directive constraints. What you are left with will be the result of many varied transformations, and be richer as a result. You might argue that this is undesirable if you are coding a stock control system to a tight deadline. If you instead take the example of writing some code to generate a piece of music, then you should see my point. The implicit commercial context does not apply when you are representing artistic rather than business processes as code.
In fact this notional straight line is impossible in many creative tasks — there is no definable end goal to head towards. A musician is often compelled to begin composing by the spark of a musical idea, but after many iterations that idea may be absent from the end result. If they are scoring their piece using a programming language, then there would be no use in formalising this inspirational spark in the form of a test, even if it were even possible to do so.
What this boils down to is the difference between programming to a design, and design while programming. Code is a creative medium for me, and the code is where I want my hands to be while I am making the hundreds of creative decisions that go into making something new. That is, I want to define the problem while I am working on it.
While “end user programming” in artistic domains such as video and music becomes more commonplace and widely understood, then perhaps we will see more discussion about non-goal driven development. After all artist-programmers are to some extent forced to reflect upon their creative processes, in order to externalise them as computer programs. Perhaps this gives a rare opportunity for the magic of creative processes to be gazed upon and shared, rather than jealously guarded for fear that it may escape.
A nice video of the livecoding sessions at v2 last month. Florian Cramer starts with an interesting take on livecoding, and it’s an honour to be mentioned in the same breath as Click Nilson. I should admit though that I was far from being the first livecoder as Florian suggests. SuperCollider server and Chuck were existed way ahead of my lowly feedback.pl, and in slub, my collaborator Adrian Ward was livecoding at least a year before me. In fact powerbooks unplugged who present and perform with their beautiful conversational code system later in that video were doing this stuff long before I livecoded my first gabba kick.
I wrote a perl script that allows you to compose puredata patches in a text editor. You define the patch using ASCII art like this:
*------------------------* | .--------. \ .-x--------. | osc~ 5 | * | osc~ 500 | `-x------' | `-x--------' | | | .-x------. | | | *~ 300 | | | `-x------' | *---* | | | *------------* .-x------. | *~ 0.2 | `-x------' | * |\ | * | | .-x-x--. | dac~ | `------'
Then run the Perl script over it to produce a .pd file, that you can then load into puredata to get this:
The ASCII syntax basically allows you to define pd objects and connect them together. Layout is preserved. Much like in ghostbusters, you can’t cross the lines, and there isn’t syntax for different box types (messages and numbers). Fixing this would be short work, but I ran out of train journey :)
There is a particular syntax for drawing the lines. You use – for going left and right, | for going up and down and \ and / for going diagonally. To change direction or fork a wire you have to place a * . Mark inlets and outlets with x .
I think this shows nicely how there is no real difference between patching and coding. Shades of pixels are an alphabet, anything can be a program if you define a suitable interpreter to go with it.
Sadly you can’t do live patching with this, but perhaps this could be a starting point for thinking about more interesting ways of programming with text.
If you are curious you can download the script (and patch) here.
Apologies to those who weren’t getting any sound from vocable, here’s a version with a quick bugfix from Rohan Drape that makes sure control buses are properly initialised. It should work for everyone now. Thanks Rohan!
By the way you might notice that vocable records everything you do under the ‘logs’ directory. I’d be really interested in seeing your log files and the dorky words and funky rhythms you are typing in. Please send me a copy if you don’t mind — don’t be shy now…
My MSc thesis is here. The reader may find many loose ends, which may well get tied up through my PhD research.
In the context of the live coding of music and computational creativity, literature examining perceptual relationships between text, speech and instrumental sounds are surveyed, including the use of vocable words in music. A system for improvising polymetric rhythms with vocable words is introduced, together with a working prototype for producing rhythmic continuations within the system. This is shown to be a promising direction for both text based music improvisation and research into creative agents.
Another screencast, a short one this time, which I’ve been using as a demo in talks.
I’ll be talking about my adventures with vocable synthesis at OpenLab 4 this Sunday. Openlab are a collective of people doing artistic and musical things with (or as) free software, putting on top notch free events such as this.
Full details here:
The haskell source for my vocable synthesis system used in my previous screencasts is now available. I’ve been having fun rewriting this over the last couple of days, and would appreciate any criticism of my code.
I love graphviz. You feed in data in a simple, easy to generate format and it creates the most beautifully laid out visualisations from it.
I didn’t tell it to lay them out in a hexagon, it just did because it was the simplest way of doing so. I then tried manually adding extra connections
As ever, feedback, both positive and negative is very much appreciated!