I’ve been through a few linux distros over the years, neatly getting progressively easier to install and configure as I get less willing to spend time recompiling kernels, culminating in ubuntu, enjoying the attention to detail and simplicity of use.  Recently though, I’ve had to give ubuntu up and go back upstream to the rather higher maintenance Debian again.  Linux suffers from creeping featurism in its layers of audio APIs, it started with OSS, a straightforward API based on files, then came ALSA, a wildly complex API with broken documentation in a wiki you can’t edit, and an architecture that somehow means only one OSS application can write sound at a time.  It seems to me that it’s a failing of ALSA that further layers of abstraction are piled on top of it, creating a rather complex landscape for sound hackers to navigate.

Ubuntu has joined in the fun by shipping with PulseAudio, which is probably great for general users but a pain for those needing to work with audio on a low level without using loads of CPU.  Pulse is not straightforward to remove, and when I removed it had problems with volume controls not working, and the likelihood that future system upgrades wouldn’t work so well.  That’s why I switched to debian sidux, but then I couldn’t get laptop hibernation, or my firewire sound card working, and had the stress of maintaining an unstable distribution.

However this week Puredyne carrot and coriander came out, and it’s really great.  The kernel is optimised for realtime sound, and jack audio runs solidly without any drop outs, something I haven’t seen before.  My firewire sound works reliably, better than I managed under ubuntu.  It has a really nice logo and clean look, with no plump penguins in sight.  It comes with all the best a/v software beautifully packaged, including all the live coding languages.  The people behind it are super friendly and helpful.  It’s downstream from ubuntu, so all the software is available.  It’s a dream!

They make a big deal out of it being good for booting off a USB key, and I think have worked out some nice practicalities of working that way.  This makes it great for doing workshops and running linux in a non-linux lab etc.  It installs and works just as nicely on a permanent hard drive though, and that’s what I’ve done.

Anyway, heartily recommended, a dream come true, congratulations to all those involved.

Here’s what it does:

Makes the point nicely that symbols and spaces can intertwine.

Using opencv blob detection, the regularity, direction and area of the shapes map to envelope modulation, resonance and pitch. The drawing is then sequenced into a melody using the minimum spanning tree (from the boost library) of the shape centroids, where distance maps to inter-onset interval.

It also has a mode for projecting the red circles and highlights back on the drawing surface which worked well.

This is only the second thing I’ve made with openframeworks, and while I don’t really get on with the codeblocks editor recommended for linux, I’m impressed with how accessible it makes opencv and all that.

Update: sourcecode

I did something similar last weekend, a remote performance to the Piksel festival in Norway, and I enjoyed it so much I had to repeat it.  Hopefully it’ll become a regular thing, yeeking has already offered to do the next one.

I’m doing the streaming with gstreamer, I don’t know if it’s possible to do live screencasts in this way with anything else and it offers a huge amount of control.  I reached the limits of gst-launch so have written a little gstreamer app to use for this weekend.  I’ll be releasing that soon…

Another thing – it’s the xmas dorkboteastlondon tomorrow (thurs) and one of our best line-ups ever.  Unmissable if you’re in around…

First, dorkcamp is a lovely event in its third year.  The idea is for around 60 of us to go to a campsite an hour out of London, well equipped with showers, toilets, a big kitchen and hall, and do fun dorky stuff like soldering and knitting.  It happens at the end of August, tickets are running low so grab yours now.  More info on the website and wiki.

Second here’s a new demo, this time with two drum simulations, one high and one low:

A .tar.gz file including some windows demo programs and the (Borland) C++ source is here.  I hope to make some time to translate some of it into realtime supercollider unit generators soon…

Thanks, Joel!

*update*

I ported it to GNU C++, a version with my edits is available here.  There’s also a darcs repository — patches very welcome!

[kml_flashembed movie="http://doc.gold.ac.uk/~ma503am/software/space/audio.swf" height="300" width="400" bgcolor="#000000" /]

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.

The demo by the way is coded in haxe and compiled to flash. The source code is here.

Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.

Diagram © lispcast, some rights reserved

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.

This post is distributed under the attribution share-alike cc license.


    *------------------------*
    |           .--------.    \
  .-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.

Abstract:
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.