studio slimdown

Last weekend, almost exactly five years after I bought my Blofeld synth, I sold it. With plans to move to the US well underway, I’ve been thinking about the things I use often enough to warrant dragging them along with me, and the Blofeld just didn’t make the cut. At first, the Blofeld was the heart of my studio — in fact, if I hadn’t bought the Blofeld, I may well have given up on trying to make music under Linux — but lately, it’s spent a lot more time powered off than powered up.

Why? Well, the music I’m interested in making has changed somewhat — it’s become more sample driven and less about purely synthetic sounds — but the biggest reason is that the tools available on Linux have improved immensely in the last five years.

Bye bye Blofeld -- I guess I'll have to change my Bandcamp bio photo now

Bye bye Blofeld — I guess I’ll have to change my Bandcamp bio photo now

Back in 2009, sequencers like Qtractor and Rosegarden had no plugin automation support, and even if they had, there were few synths available as plugins that were worth using. Standalone JACK synths were more widespread, and those could at least be automated (in a fashion) via MIDI CCs, but they were often complicated and had limited CC support. With the Blofeld, I could create high-quality sounds using an intuitive interface, and then control every aspect of those sounds via MIDI.

Today, we have full plugin automation in both Ardour 3 and Qtractor, and we also have many more plugin synths to play with. LV2 has come in to its own for native Linux developers, and native VST support has become more widespread, paving the way for ports of open-source and commercial Windows VSTs. My 2012 RPM Challenge album, far side of the mün has the TAL NoiseMaker VST all over it; if you’re recording today, you also have Sorcer, Fabla, Rogue, the greatly-improved amsynth, Rui’s synthv1/samplv1/drumkv1 triumvirate, and more, alongside commercial plugins like Discovery, Aspect, and the not-quite-so-synthy-but-still-great Pianoteq.

I bought the Blofeld specifically to use it with a DAW, but I think that became its undoing. Hardware synths are great when you can fire them up and start making sounds straight away, but the Blofeld is a desktop module, so before I could play anything I had to open a DAW (or QJackCtl, at the very least) and do some MIDI and audio routing. In the end, it was easier to use a plugin synth than to set up the Blofeld.

Mystery box of mystery!

You can probably guess what’s in the box, but if not, all will be revealed soon

So, what else might not make the cut? I only use my CS2X as a keyboard, so I’ll sell that and buy a new controller keyboard after moving, and now that VST plugins are widely supported, I can replace my Behringer VM-1 analog delay with a copy of Loomer Resound. I might also downsize my audio interface — I don’t need all the inputs on my Saffire PRO40, and now that Linux supports a bunch of USB 2.0 audio devices, there are several smaller options that’ll work without needing Firewire.

I’m not getting rid of all of my hardware, though; I’ll definitely keep my KORG nanoKONTROL, which is still a great, small MIDI controller. In fact, I also have two new toys that I’ll be writing about very soon. Both are about as different from one another as you could get, but they do share one thing — they’re both standalone devices that let you make music without going anywhere near a computer.

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.

everything you always wanted to know about linuxsampler

LinuxSampler is an odd beast — it can be tricky to install, and confusing to configure, but it’s undoubtedly the best tool for working with large sampled instruments under Linux. With its next release adding support for the increasingly popular SFZ format, and the fact that it’s one of the few LV2 synth plugins ready for use with Ardour 3, I think it’s about to get a lot more important.

Let’s not get too far ahead of ourselves, though. What exactly is LinuxSampler, what’s it useful for, and perhaps most importantly, how do we use it?

LinuxSampler GUI

LinuxSampler handles large sampled instruments with ease

LinuxSampler basics

LinuxSampler is a sample-based synth that lets you use very large sampled instruments. Rather than loading the entire instrument in to RAM, LinuxSampler loads just the start of each sample, and then reads the rest from disk as it’s needed. Because of this, it can load instruments much larger than your system would be able to handle with other software, such as Hydrogen or Fluidsynth/Qsynth.

Realistic piano sounds are perhaps the classic use for LinuxSampler — a good piano, like the Salamander Grand Piano, can reach 2GB or more in size — but it works just as well for electric pianos, guitars, violins, trumpets, drum kits (a personal favourite), or any other instrument that calls for large samples, or a lot of samples, to provide a realistic result.

LinuxSampler can be run standalone — it supports ALSA and JACK for both MIDI input and audio output, and can handle an arbitrary number of inputs and outputs mapped to different instruments. It can also run as a plugin; the LV2 plugin runs well under both Ardour 3 and Qtractor.

File formats

The inspiration for LinuxSampler was a Windows app called Gigasampler, which was the first sampler to incorporate on-demand streaming of sample data. It’s a standard feature in professional samplers today, and Gigasampler itself has been defunct for some time, but its legacy lives on in the “.gig” file format, which is also LinuxSampler’s primary file format.

You can still find some great commercial sample libraries in .gig format, but it’s definitely falling out of favour today. To address that, the development branch of LinuxSampler has added support for a new format called SFZ. It’s a young format, but it’s growing in popularity thanks to the availability of free SFZ plugins across all platforms. Also, because of its design (the SFZ file itself is a simple text file, separate from the actual sample data), you can download third-party SFZ mappings for some commercial instruments.

Even though .gig is fading away commercially, it’s still useful for bundling your own sounds. The LinuxSampler project includes a .gig editor called “gigedit”, which you can use to create your own instruments.

Hopefully you now have an idea of what LinuxSampler is and what it can do for you. Now all that remains is to learn how to install and configure it!

new track: move along

This track has been a long time coming, but it’s finally done! It’s my first original track with lyrics; it’s about leaving my job after so many years there, though I wouldn’t read too much in to the words. It’s certainly a departure from my usual electronic stuff — this has just piano, bass, drums, and vocals — so I’m keen to hear what people think of it.

You can download or stream it below, or at Bandcamp. Some production notes are under the cut.


mp3 | ogg | flac | 3 minutes 47 seconds

Continue reading

favourite features in ardour 3: stacked regions, connection matrix, aux bussing

Easter is a holiday weekend in Australia, and the extra days off gave me time to get back to the piano-driven song that I’ve been working on for some time. I’ve had the arrangement largely complete for a while, so I quickly finished the lyrics and then recorded the vocals.

Until now, this track was all MIDI in Qtractor, and I tried recording the vocals there, too, but I need a lot of takes to get a good vocal down, and Qtractor didn’t make that easy. I suspected that Ardour 3 might, though, so I started a new session, synced it to Qtractor using the JACK transport, and recorded the vocals there.

Stacked region view

Ardour 3 can stack overlapping regions within the one track vertically, making it much easier to work with multiple takes

Ardour has long allowed you to record multiple takes in to the same track, but switching between them in Ardour 2 was time-consuming. In Ardour 3, you can switch a track to “Stacked” mode (under Layers in the track’s right-click menu), which displays the overlapping regions within the track separately, stacked vertically on top of each other. In Stacked mode, you can see clearly what’s in each region (at least, once you’ve expanded the height of the track enough!), and you can rearrange them by clicking and dragging.

It’s also easy to select multiple stacked regions and run the same edit operation on them, such as splitting them at the playhead. It took very little time to split my takes in to individual phrases, and then rearrange and audition them to find the best takes for each part of the vocal.

Matrix-style connection manager

A more fundamental change in Ardour 3 is the new connection manager interface, which is a massive improvement on the old UI for managing connections to tracks, buses, and inserts/sends. It’s intimidating at first, but it’s really quite simple to use: it’s a matrix, with outputs running top-to-bottom on the left, and inputs running left-to-right on the bottom. For each combination of input and output, there’s a box on the grid, and clicking in those boxes creates or deletes a routing between that input and that output.

In specific parts of the UI, you’ll just see subsets of this; for instance, if you open the connections for a specific track, you’ll see the potential outputs on the left, but just the track’s inputs down the bottom. However, there’s also a master connection manager (well, two really — one for audio, and one for MIDI, both available from the Window menu), which lets you make connections to multiple tracks or buses very quickly.

The connection manager can be intimidating at first, but it's super-quick to use

After I finished recording my vocals, I decided to record audio tracks from my MIDI instruments in to Ardour so I could work with just audio for the final mix. For the drums, I used LinuxSampler (discussed a little here), with five separate copies of Analogue Drums’ RockStock kit loaded (one each for kick, snare, toms, hats, and cymbals), each routed to its own pair of JACK outputs. In Ardour 2, it would’ve taken ages to connect those LinuxSampler outputs to my track inputs, but with the master connection manager in Ardour 3, it took just 10 clicks and about as many seconds.

Aux busses (again)

Aux buses and sends make shared effects even easier to set up

I’ve mentioned it before, but the aux bussing in Ardour 3 is great. Once I’d recorded all my instruments in to Ardour, I set up a reverb bus (a convolution reverb using the excellent IR plugin), and added sends from some of my tracks. Not only are they easier to add, but you can see and adjust the send levels straight from the mixer.

While I ran in to some problems with MIDI in Ardour 3 last week, working with just audio this weekend has been rock-solid. A lot of bug fixes have gone in to Subversion since the last alpha release, so I’m hoping we’ll see a beta release soon.

some early ardour 3 impressions

Ardour 3 is now in alpha, and I’ve been poking at it for a few days now; in fact, you may have noticed some bits of Ardour 3’s GUI in the screenshot from my last post. It’s still quite crashy, as you’d perhaps expect from an alpha, but that seems to improve with each new release. In fact, going back to Ardour 2 already feels uncomfortable, because the Ardour 3 interface just feels nicer to work with, even before you consider all the new features.

The MIDI functionality takes a little getting used to, but once you’ve learned a few keyboard shortcuts you can quickly jump between working with MIDI and audio at the region level, and working with the individual notes within regions. I still think I’d be more comfortable if the piano roll was in a separate window, but once you’ve resized your MIDI track and adjusted the range of notes it displays to match your needs, it’s really quite easy to draw in notes with the mouse.

Being able to manipulate notes easily with the keyboard is great, too; once you’ve learned the appropriate shortcuts, you can move between notes and edit their pitch, duration, and velocity using the keyboard. Editing velocity in general is a bit strange, though, since there’s no velocity ruler — velocities are represented just by note colour, though hovering the mouse over a note will tell you its velocity value.

I did run in to a few problems beyond simple crashes, but I’m still pretty confident that Ardour 3 will be pretty solid by the time of its final release. I’m not sure it’ll eclipse other sequencers, like Qtractor, in that first final release, at least not in some ways (I do like having a velocity ruler, for instance). That’s just fine, though — Ardour 3 works just as well with external sequencers as Ardour 2 ever did, and its features extend far beyond simply adding MIDI.

sketchbook: bouncy game music

Here’s another quick piece done quickly for a purpose: my friend Switchbreak spent the weekend developing a short Flash game for the So Many Rooms game jam, where each developer had 36 hours to produce a game that challenges the player to get from a starting door to an ending door, using whatever obstacles or gameplay mechanics they like. Switchbreak’s game is full of bouncing balls, so when he asked me to produce a quick tune for him, I made sure that it was appropriately bouncy.

This was whipped up on Sunday night mostly in Qtractor, with Hydrogen for the drums, and my Blofeld for all the other sounds. I’d normally record everything in to Ardour and mix it there, but I stayed in Qtractor for this one, and it did a fine job; I had no trouble replicating my usual trick of running the drums on to separate tracks so that I can apply individual effects to each, for instance. The result is a bit trite, but it’s fun, it loops pretty smoothly, and I think it suits the game well.


mp3 | vorbis | flac | 1:18

some daw notes: mixing in qtractor, and testing ardour 3

So far, I’ve been using Qtractor for all of the recording and sequencing on the track I’m working on. As an exercise, I’m going to try to stick with Qtractor throughout the mixing process, too. I’ve used different synths and sequencers on different tracks over the last 18 months, but everything has been recorded in to Ardour at some point, so I think it’ll be good to put it aside for one track to see how the other half live.

I’m certainly happy recording MIDI in Qtractor, but it doesn’t yet feel as robust as Ardour for recording audio. It’s working fine, though, so I might get over that initial feeling once I’ve used it a bit and built some confidence in the fact that it’s not going to keel over at random. One thing I haven’t found a way to do, though, is to use a shared reverb bus, as I do in Ardour (as discussed in my last tutorial). It hasn’t been a problem yet, since I’m not using much ‘verb yet, but it will definitely be a problem if I decide to use a convolution reverb later.

Qtractor's new quantise dialog, with percentage options

One very nice thing that’s landed in Qtractor SVN is percentage quantisation, which lets you bring your MIDI notes just part of the way towards being perfectly quantised; it’s a great way to tighten up the timing of a recorded MIDI part without completely eliminating those nice, human timing variations. I described it to Rui on the LinuxMusicians forum the other day, and to my surprise, he had it written, working, and committed to SVN by the very next day. Now that’s service!

Ardour 3’s non-MIDI improvements

I’ve also been testing Ardour 3 from SVN, and I’m very, very happy with how it’s coming along; both its stability (ie: its ability to run for more than five minutes without crashing) and its reliability (its ability to do what you tell it to do in a consistent, repeatable manner) have increased dramatically over the last few months. My good friend (and guitar/drum extraordinaire) Stuzz gave me a link to a list of Ardour 3’s new features, which is an excellent read — going through the new features, which are all described in great detail, it quickly becomes clear that there’s a lot more to Ardour 3 than just MIDI sequencing.

Internal sends to aux buses make shared reverbs even easier in Ardour 3

One thing I noticed quickly is that it handles reverb buses very well. Setting up the bus is much the same as it is in Ardour 2, but once it’s there, adding sends to your tracks takes just a few clicks, and each send has a tiny gain slider next to it in the track’s effects list, so you can adjust your send gain straight from the mixer. The sends are also given meaningful names, now, so you know which bus they’re sending to at-a-glance.

Another nice change is what’s being called the matrix router, which is used whenver you need to connect Ardour’s inputs and outputs (audio or MIDI) to external apps or devices. The dialog for this in Ardour 2 was a bit cumbersome, and I know more than a few users that used an external tool like Patchage to connect things to Ardour. The matrix router, while initially a bit of a confusing sight, makes it much easier both to see what’s connected to where, and to change those connections.

…and the MIDI stuff, too

MIDI editing is done a little differently than in some other apps, but it’s not totally dissimilar to apps like Qtractor, and it follows Ardour’s audio editing model very closely. MIDI regions work much like audio regions — you can copy and drag them around and trim them to length with ease. By default, copying a region makes a “linked” copy, so editing a region changes every copy of that region; if you do need to edit one specific copy of a region, you can “fork” it to create a duplicate that can be edited independently. Speaking of editing, it happens inline — that is, within the main Ardour timelilne window, rather than in a pop-up — which seems odd at first, but it works well enough once you expand your track vertically.

Editing the contents of a MIDI region in Ardour 3 SVN

You can use instrument plugins, too. When you create a MIDI track, it starts with just a MIDI input and output, but if you add an instrument plugin it spawns a matching set of audio outputs, which can be routed just like the outputs of a standard audio track. It also has the best automation implementation I’ve seen on Linux; Ardour’s traditional plugin automation works on instrument plugins on MIDI tracks, and you can also draw automation curves for MIDI CCs. One catch right now is the lack of DSSI support — Ardour only supports LV2 plugins for now, along with VSTi plugins in VST-enabled builds, and AudioUnits on OS X.

Paul Davis wisely warns in his description of Ardour 3’s MIDI features that since this is Ardour’s first attempt at MIDI sequencing, we shouldn’t expect Ardour to necessarily to everything as good as, or better than, other apps that have been working with MIDI for years, and I think that’s very fair. I don’t expect people to dump Rosegarden and Qtractor en masse just yet, since there are certainly features that Ardour 3 lacks. Overall, though, I think he and his team have done a brilliant job, and I think Ardour 3 will have more than enough MIDI functionality to cover most of my projects.

approximating realism: drumming with linuxsampler

It may be the silly season, but I’ve still had plenty of time to work on a new track. It’s coming along well I think, but it’s been quite a challenge, mainly beacuse it’s a very “back to basics” track, with a minimal, piano-based arrangement. You’d think that would make things easy, but it’s quite the opposite! With just a few instruments in the mix, the quality of the performances and mixing, and the authenticty of the sounds, will be paramount. With Pianoteq taking care of the piano, the drums have been my main focus so far.

My first instinct was to load up Hydrogen, sequenced from Qtractor, with one of the few big Hydrogen kits around. The Big Mono kit from Analogue Drums sat nicely with the feel of the track, but they’re recorded in mono (as the name suggests), and they have a lot of room sound, too. They also push Hydrogen hard — with 210MB of samples loaded, it needs 400-500MB of RAM to run. If I wanted to go with even better sounds, Hydrogen wasn’t going to work.

The answer, then, was LinuxSampler, which laughs heartily at gigabyte-sized sound sets. I took the plunge and spent a whole $25 on another Analogue Drums kit, called RockStock — it has more drums than Big Mono, and they’re all recorded in stereo, with separate close mic and room mic recordings of each. Thanks to some third-party SFZ mappings, it works beautifully in LinuxSampler, and despite having 870MB of samples, it uses just 200-300MB.

One question in using LinuxSampler that I haven’t quite answered yet is how I’m going to mix it, since there’s no way to get separate per-drum JACK outputs from it. You can load the same sound set in to LinuxSampler multiple times, though, with little additional overhead, so there’s nothing stopping me from loading RockStock five or six times for each of the different drums I want to use. Those separate instances can then be routed to separate JACK outputs. I just need to make sure that I split my MIDI drum tracks up in the same way.

I have some basic drum parts written, using just two groups of drums (kick/snare/toms, and hats/cymbals) routed to two instances of RockStock in LinuxSampler, and it’s sounding pretty good — not quite there, but hopefully not too far off. With more attention to detail in the programming (it feels like I’m slowly learning the drums, just without the drums!), and some appropriate treatment in the mixdown (EQ, compression, etc.), I think I’ll be able to produce some solid, convincing drum parts.