rpm 2012 post-mortem

Before the process of making my RPM 2012 album becomes a distant memory, I wanted to get down some notes on the album as a whole, and on each track. This post is about the album as a whole; I’ll follow up with separate posts about each track shortly.

The whole album was definitely a rush, and there are plenty of things that could be improved, but overall I’m really happy with how it ended up. Even if it hadn’t produced useful results, the project would’ve been worthwhile in itself — I learned to get things down more quickly, and learned more about what does and doesn’t really matter when working on tracks. Perhaps most importantly, though, I feel inspired to start working on more new material.

I’m also pleased that many of the tracks sound more musical than my earlier work; there’s more of an emphasis on melodies and chord progressions rather than just rhythm and sound. Some of the musical styles forced me to use more melodies (the chiptune tracks in particular), but I think the time constraint helped force me down a more musical path, by limiting the time I could spend on sound design and effects.

General production notes, workflow changes

Though it’s still in beta, I used Ardour 3 for all of the tracks; one used samples, but the other nine were entirely MIDI. I expected a few bugs and crashes, but I didn’t hit any major problems, and didn’t lose any work — the worst problems were with some notes not starting/stopping properly at region boundaries. Over the next week or two I’ll update my Ardour build and try to reproduce those issues so I can report them properly.

The time constraints caused a few modifications of my workflow in the name of simplicity and brevity:

  • I relied much more on synth plugins than usual — in fact, several tracks used only plugins. Being able to whip up a quick synth sound in TAL NoiseMaker, and then apply effects without having to route or bounce anything, was a huge time saver. I still used Hydrogen on some tracks, and my Blofeld of course, but much more sparingly than usual.
  • Mixing work was kept to an absolute minimum — for the most part I just set some reasonable levels and left it at that. I did apply level automation to some tracks, but I didn’t add any compression or EQ, apart from the odd plugin used for creative effect.
  • Keeping the mixing simple let me skip an entire part of my usual workflow: bouncing. In the past I’ve always recorded MIDI parts to audio before mixing, and taken effort to ensure that things like drumkits have separate tracks for their various parts, to give me maximum flexibility during mixing. With the minimal mixing on this project, I didn’t see the need to bounce anything.

To my surprise, the result doesn’t sound terribly under-mixed, at least to my ears. It’s easy to get carried away with minor tweaks while mixing, so it was refreshing to hear how effective a simpler approach can be. This will definitely influence my future work — I can imagine getting a few tracks in to this sort of state and then mixing them all at once, or simply skipping mixing entirely if I don’t think a track is good enough.

Track notes

I want to go in to a bit of detail on each track, so I’ll be adding a separate post about each track, outlining the tools I used and the process I followed to create them. I’ll try to get one of these posts out each day, but with the release of Mass Effect 3 tomorrow I may be a little distracted!

rpm 2012 update: day 5

It’s the end of day 5 of the RPM Challenge, and I think I’m making good progress! I may have to pick up the pace a little to finish by the deadline, but I’m still fairly confident that I’ll manage it. The strategy that’s been working for me is to brainstorm and come up with demo ideas of a weeknight after work, and then flesh out those ideas on the weekend when I have more time to work with.

So far, I have one finished track (an ambient experimental piece), one half-finished track (a lo-fi downtempo track a la Texel), and two short demos (a chiptune and a solo piano piece). I’ll try to finish the track I have in progress tomorrow, so with any luck by this time next week I’ll have three or four finished tracks, and four or five demos ready to be expanded upon.

Some random things I’ve learned so far:

  • Plugin soft-synths are super, super handy when you’re in a hurry — just drop them in a MIDI track, load up a preset, and you’re good to go, without worrying about routing signals or configuring external software or hardware.
  • Speaking of soft-synths, the TAL-NoiseMaker native VST synth is my new go-to synth. It’s a standard analog-style synth, but it sounds great and has a straightforward UI and a solid feature set.
  • Ardour 3 is still a bit crashy while working with MIDI, but it’s made some nice improvements recently, like being able to double-click to enter or leave note edit mode, and the addition of a drop-down list of synth plugins in the “new track” dialog, so you can start composing more quickly. I could switch back to Qtractor, but even with the crashes I think I’m more productive in Ardour, just because I’m more familiar with it.
  • Sound design is fun! It’s hard not to have a good time when I fire up the Blofeld and start twiddling knobs. I should do it more often!
  • In fact, I should do this whole music thing more often. I might not come up with something interesting every time I sit in front of the keyboard, but definitely won’t come up with anything if I don’t try.

it’s here! native vst support in ardour 3

Ardour 3.0 is still in alpha, but it gained a substantial new feature last week: support for native Linux VST plugins. It’s a feature that’s been on wishlists for a while, but it’s become more important over the last year or so, as the number of VST synths for Linux has increased. The big drawcards are the commercial synths — Pianoteq, discoDSP Discovery, and the various Loomer plugins, for instance — but more open-source VSTs are appearing now too, such as the TAL synths, ported from Windows by KXStudio developer falkTX in his new DISTRHO project.

The new features use the unofficial Vestige VST headers, which means that Ardour avoids the need for users to download the official Steinberg VST SDK and build Ardour themselves. Having said that, the new VST support is a build-time option that’s disabled by default, but I’m hoping that it will be enabled by default, and available in the official binary builds of Ardour, before the final 3.0 release.

Ardour 3 SVN, running the Loomer Cumulus and TAL-Dub-3 native VSTs

As handy as this is, there has been some discussion about whether or not native VST support is a good thing. VST isn’t a particularly elegant plugin system, and given Steinberg’s licensing restrictions, it’s always going to be harder for the developers of hosts like Ardour to deal VST with than other plugin formats, such as LV2. I would hate to see this VST support discourage developers from working with LV2.

Realistically, though, it’s hard to expect commercial plugin developers to embrace LV2, on top of the effort already required to bring their plugins across to Linux. Indeed, now that Ardour has joined Qtractor and Renoise in supporting VST plugins, the size of their combined user bases might encourage more plugin developers to offer Linux support.

I hope we’ll see more ports of open-source Windows VST plugins too, but for anyone developing a new open-source synth plugin, or working on a plugin version of an existing standalone synth, LV2 makes much more sense. Regardless of how open-source they may be, VSTs that rely on Steinberg’s headers will never be allowed in to distributions. With David Robillard’s new LV2 stack, which is already in use in both Ardour and Qtractor, LV2 is a fast, reliable, and highly capable standard, and its use will only increase, regardless of what happens with native VST support.