Cracking the Code

I’ve always been comfortable with computers but very much at the user end of the spectrum. I know how to use the tools that other people have built to make the things that I want, there are great tools out there and most of the ones I use on a daily basis are free and open source.

So far so good, I can make my ideas into things that are useful but I can only make things that the tools are capable of making and increasingly that’s not what I need. I need to make my own tools, and that means I need to be able to write code.

My main collaborative creative outlet, temp0rary, uses a lot of data (mainly MIDI) but, aside from triggering video clips with it, my half of the project doesn’t make as much use of this data as it potentially could, and that’s something I need to change, it’ll also be immensely useful as I start working on my own solo AV(Audiovisual) project(s).

Integrating more use of data in real time will lead to more immersive performances and provide more opportunities for development in as yet unknown directions and that’s really exciting to me. But between here and there is a lot of learning, and so far that’s a lot of time being bored or frustrated with occasional flashes of wonder.

My new best friend, the console…



So it’s a month later and a lot has happened. I should backtrack a bit… Why am I doing this?

It started with finding and falling in love with VCV Rack an open-source virtual modular synthesizer about which I’ll write more in a separate post. So, there’s this thing that I like, and for which I’d like to develop some modules. But to do that I’d need to learn C++, and before I even got started with the programming learn how to get the source code onto my computer and compile it into working software.

It’s been a steep but enjoyable learning curve, full of different IDEs (I’ve settled on Visual Studio Community 2017), and I should also mention the Atom text editor (it’s a lovely piece of software to work with). There have been tutorials on my phone and online, which have made me learn to hate all the ‘foo, bar’ explanations of code (I find them difficult to follow as it’s the same words used in different contexts all the time).

I bought a book (C++ Primer by Stanley B. Lippman) which walks you through learning C++ by building a project that actually does a thing – working towards a concrete result works better for me.

I’m also constantly refering back to a YouTube tutorial series by The Cherno which goes a bit fast for me but is really good nonetheless.

I tend to be a bit scattershot about learning which isn’t all that helpful, jumping from here to there, making a lot of mistakes because I’ve skimmed over something important.

Learning C++ is all well and good but I was a long way from getting to the start of what I actually wanted to do with it, or having anything that I could use. When you’re still at the stage of learning fundamentals any sort of increased knowledge doesn’t really feel like progress towards ‘the something you actually want to do’ and the frustrations magnify.

So I stopped for a minute, had a little think and took a bit of a step sideways…

Taking Stock

Taking Stock

Why am I doing this again? Because I love VCV Rack and I’d like to develop for it – even if in a small way. If I want to make modules that work with audio then I’ll have to learn about DSP after I have enough C++ in my head to make a start.

What do I mainly do creatively? Interactive AudioVisual performances.

So I’m finally doing my own Audio, what about the Visual and the interactivity? Can I do something with programming that can respond to what the audio, or any related MIDI data, is doing in real time?

I’ve had a little play around with Processing over the years and tested out some small sketches for integration in temp0rary projects. But the other option, which always seemed very scary when I looked at it, is openFrameworks, and that is written in C++. Win, especially as learning C++ as part of learning how to make things with oF involves a lot of iteration and feedback, write a bit, compile, see if it works, work out why not if it doesn’t. It’s less abstract than just learning the language on its own and it’s a constant stream of results (good and bad).

And then I had lots of versions of things I was working on – SomeProject_001, 002, 003 – little iterative steps, the latest of which kept breaking but the earlier ones were OK to go back to if I got lost. If you have too many versions what you need is version control. What I needed was GitHub.

So here I am, still a long way from creating VCV Rack modules but a long way towards having new visual elements for temp0rary and my own work. I’ve got a new toolkit to play with that delivers shiny, exciting results that I can use for VJing and in Github a new, and far better, way to manage projects.

I’m still bashing my head against problems that, when I eventually solve them, usually revolve around me not having understood something fundamental, but even the mistakes can look interesting and there’s tangible progress…