A brand new website:
The idea is that every month some instructions appear and passersby add
their implementations in code.
Please let me know of bugs / omissions / ideas!
I’m working with Jamie Forth on ideas around spaces of rhythm. Here’s a demo (which might not work in feed readers):
The space has two quality dimensions, “intensity” (X) and “disorder” (Y). Drum patterns are arranged along these dimensions, so more intense ones are towards the left and more ordered ones towards the top.
Draw a line from a high hat to a kick drum. If you draw a short line the rhythms will be more homogenous. Certain angles have certain feels to them. Maybe. It seems a nice way of playing with polymetric rhythms as vectors anyway.
Very early stuff but a rendering of the vocable word sebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobesebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobe is here.
(any website layout breakage is intentional)
The percussive beat you hear in the background is the excitation of the mesh, bursts of pink noise from the ‘b’s and white noise from the ‘s’s. The vowels control the ‘tension’ of the mesh.
The waveguide mesh ugen mentioned in my previous post and used here is now in sc3-plugins.
After quite a bit of fiddling, I got a waveguide mesh working. It’s a physical model of a drum head, basically lots of bidirectional, single sample delays connected in a triangular mesh to form a hexagon. [update: now a second extern is in there that tessellates a circle instead].
It sounds pretty good already, next plan is to play with different ways of exciting it.
The supercollider plugin, together with some haskell (hsc) code for testing it, is downloadable here.
[update: native sclang code and classes included now too]
[another update: new version with patch from Dan Stowell, it uses less CPU now]
Here’s an interesting response to my earlier post about how test driven development does not necessarily apply to all problem domains. Ocean has some insightful things to say about creativity, but mischaracterises me as seeing constraints as undesirable.
In fact I agree that constraints are essential to creativity. Constraints form the walls of the creative space that a creative agent (here, the programmer) searches within and pushes against. My complaint was not against constraints in general, but in the assumption that when we’re talking about development, we’re talking in the context of writing quality assured business software.
Lets take livecoding as a example. A programmer stands on stage, and has to write some software to generate some music so that the people waiting in front of them has something to dance to. Imagine looking up from your code editor to see the expectant faces above. This particular problem domain is one I have found myself in as a member of slub, and already has plenty of constraints to guide my creativity without adding the extra artificial constraints of starting with some unit tests.
[edit: see comments for fine counter-example from dave (a fellow slub member)]
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.