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 do tend to be a bit scattershot about learning which isn’t all that helpful, jumping from here to there.
And then I stopped for a minute, had a little think and took a bit of a step sideways… 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?
So I’m finally doing my own A, what about the V and the interactivity? 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 wtitten 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’m still bashing my head against problems that, when I solve them, usually involve me not understanding something fundamental, but there’s progress.