#wulfcode

So Wulfcode is written in Java. I know, I know: for one reason or another (out-of-touch academia; previous jobs; obscure requirements; Symbian's brief reign of mobile app terror), I've ended up with a working knowledge of it and I can knock up desktop applications pretty quickly. Wulfcode takes advantage of a few modernish Java features like decent OS look-and-feel support across different platforms, window transparency, split-window panels, and a variety of useful methods from which I was able to stitch together a decent text input/parser interface customised exactly the way I wanted it.

The main problem with Java is the Java Sound API. It's horrible at keeping time as the virtual machine's garbage collection runs in the background on mercurial gusts of its own capricious wind, so you often get a few beats of solid BPM-locked output followed by a few beats of rhythmic car-crash before it finds its place again. Wulfcode by default takes its clock from an external source - e.g. a DAW or a hardware sequencer - but even then it's a bit wobbly.

The other big problem with Java (or at least the only other one that I have time to deal with here) is OS manufacturers' increasing unwillingness to implement it properly. MacOS is now my weapon of choice, but Apple's current implementation of Java MIDI is a horrible shambles: it drops a lot of messages, flat-out ignores MIDI status bytes greater than 0xf0 so can't handle sysex/clock/timecode, ignores timestamps, and only lists devices in an oblique and unhelpful way. So really, nobody should be using MIDI for Java, and the fact that Wulfcode works fairly well bears testament to how much of my life I've carelessly wasted on it.

My alternatives are limited (otherwise I'd never have used Java), but a recent mobile app dev job I did for a client made me aware of Electron, the Chrome/Node app wrapper that GitHub use for their text editor Atom. Essentially it's a bit like hybrid mobile app development in that you write most of your app in HTML/CSS/JS, but while hybrid mobile development eventually involves compiling against target platform APIs (iOS, Android, etc.) Electron just bundles your resources in with a prebuilt shell executable that reads your config and essentially runs a sandboxed version of Chromium that contains your UI and logic.

Which means: WEB AUDIO API AND WEB MIDI API! Hooray! I've been looking at these on and off for other projects, and I've used them in a few handy utilities for controlling my hardware synths or managing their patch banks. They're pretty great, and would even give Wulfcode scope for generating its own sound without my having to reinvent too many wheels. More importantly, as far as I can tell, they run their timing against the computer's native, bare-metal clock signal rather than the horribly inaccurate (even worse than Java) Javascript timer - also a victim of garbage collection.

Lots of advantages of Wulfcode Java could be retained in Wulfcode 'Electron' - window transparency, secondary output windows, a vast range of handy node.js libraries that would replicate lots of Java helper classes I've used - but it would still be portable across OS X, Linux and Windows. Actually, it would be even more portable - once given security permissions, Web MIDI and Audio work happily in the browser with local hardware; if Wulfcode wasn't dependent on server-side JS, it could be used by anyone in the browser. Show up for a gig, laptop's broken, just borrow one and hit up the Wulfcode page!

(Note: running stuff in the browser is a weird fetish of mine that's never actually solved a real-life problem in the past. My chiptune DJ software Chipdisco - dual-deck Amiga MOD/PC XM playback - ran in the browser until the Java web applet browser plugin was banned by the entire civilised world for being full of security holes. I'd also like to redo that in Web Audio/MIDI some day.)

Another great Algorave last night in Newcastle inspired me to rethink Wulfcode a bit. Documenting progress and thought processes is probably better done on a blog than in the GitHub project's README, not least because a new Wulfcode version might deviate from the current one entirely.

A few things occurred to me last night:

Live coding is still really fucking cool

I still don't have a very good idea of how it's being done by most other practitioners, in terms of coding languages/dialects, IDEs and overarching principles

I tune out for too many months at a time while dealing with life, working flat-out to pay bills and getting distracted by other projects - I should be keeping on top of what's going on in the live coding world

If I had, I'd know more about Tidal - a project by Algorave founder Alex McLean (@yaxu) which looks very slick and accessible, and almost certainly does everything Wulfcode does but better and more flexibly!

If Wulfcode is going to be worth pursuing any further, I need to make it:

Achieve its original goals better (be a better, more flexible performance tool for me to use, that doesn't encourage me to be lazy and play it safe or rely on prepared audio material that can't be changed much on the fly)

Be more reliable (probably by not using Java - more on this later)

Do a few things that nothing else does, but which might be fun (more on this soon)

Another thing that occurred to me, while chatting to Newcastle-based live coder Sean Cotterill (@asunproject), is that I too easily fall into a methodological trap that inevitably arises when a new musical subculture, or mode of performative expression, comes along: that of feeling like the established paradigms are dogmatic and that any deviation from those is somehow illegitimate, or "cheating". This is one of my own perverse neuroses, though it features quite a lot in other scenes - particularly chipmusic/chiptune, for example. Newcomers assume they won't be taken seriously unless they do things "properly" - use authentic retro hardware, learn arcane techniques even though more accessible alternatives are available which ultimately produce the same end result, and so on. One reason this is so bizarre is that, beyond some very general parameters, these scenes and subcultures arise from experimentation and innovation. I've had success with chipmusic because I worked with techniques and limitations I'd used for most of my life, but then experimented and innovated so that I'd be able to create some new and exciting stuff and perform it live in what I'm told was an engaging way! Also, by no means is there any snobbery in the live coding world about "the right way to do things" (there's lots in the chipmusic world, but only amongst people who troll messageboards and produce little or no actual music); it's all in my mind, and going to another Algorave was a great reminder that everyone's cool, everyone's experimenting and furthering the art, and the only real principle underpinning this scene is that interesting music is being made LIVE using CODE. Hence the name, funnily enough!

So it's weird that when asked to do an Algorave set two years back, via a recommendation to Alex by a friend on the basis of my demoscene/chipmusic background, I panicked about not knowing SuperCollider and ended up writing Wulfcode before the gig - THEN panicked about Wulfcode being "not proper live coding", and so on. This was mostly in the privacy of my own tortured head, though, and chatting to Sean about the various ways he juggles boilerplate code and prepares a certain amount of stuff in order that he can dive right into a set and make great music straight away, reminded me that, yeah, I need to stop worrying and get back to exploiting Wulfcode (or SuperCollider, or Tidal) in order to MAKE MUSIC. I'm a professional musician and performer, but also an Olympic-class procrastinator and tweaker of things that really don't need tweaking, so it's worth having a cathartic flush-out of my neuroses before taking another objective look at Wulfcode, and at how I'm approaching live coding in general.