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.

I actually attempted it back in 2008, but that was before I’d really started making music again, and it was a bit of a disaster — I didn’t manage to record anything. I fully expect to have more done by the end of my first day than I managed in that attempt.

What are my goals? I’d like to try a few different tracks — some downtempo stuff, some more melodic chiptune-ish stuff, and likely some droney ambient stuff — and while I expect it all to be quite rough, I hope there are some ideas in there that I can polish in to complete tracks after the challenge.

More importantly, though, I’d like to learn to be more spontaneous and to get my ideas recorded more quickly. I spend a lot of time working on each track, and if I can learn ways to reduce that workload, and hence increase my output, I’ll be very happy.

I’ll try to post some updates here throughout the month, but if you want to track my progress more closely, I’ll be posting to Twitter, too. Wish me luck!

I very nearly neglected to post yesterday’s sketch, since the timing was rough and the whole thing was musically very simple. Needless to say, I’m glad I did post it now — chalk this up as a win for online collaboration and Creative Commons!

SooperLooper is great for capturing new track ideas, especially for the kind of music I make, which is often driven by repeating patterns. In the past I’ve started with a drum beat and recorded loops on top of that, but this time I went freestyle. The nanoKONTROL is great for controlling it — I was able to add a bunch of empty loops, and map a separate fader and record button to each of them, making it easy to both record your loops and control their playback afterward. Once I had some appropriate loops I just played them all at the same time, using the faders to control their relative volumes while recording the output straight in to JACK Timemachine.

I don’t know if this sketch will go any further than this, but with some glitchy drums, some additional synth parts, and a bit more complexity (like, more than two chords), I think it could work as a track.

So far this year, I definitely have been slack; I spent half of December in the US on a working holiday, and combined with the usual holiday season shenanigans on my return, I’ve been spending more of my downtime gaming (Jamestown and Gratuitous Space Battles have been particular favourites) rather than making music (or blogging, for that matter!). Now that things are calmer, I’m looking forward to getting some music happening.

The plan is still to work on some more tracks in the same lo-fi downtempo vein as Texel and push out an EP of tracks that’ll hopefully sound like they belong together. Realistically, that might take all year, but if the tools continue to improve at their current rate, there’s a good chance I’ll be done sooner. Either way, I plan to stick with it!

It pays special attention to one of the most common cases — using a USB microphone — so it’s well worth a read.

The standard rocket parts include all the things you’d expect: liquid fuel tanks and rocket engines, strap-on solid boosters, stage separators, tail fins, support struts, and of course the command module, with add-on parachute, which houses your Kerbal astronauts. Like their real-life counterparts, solid boosters have a lot of thrust but they burn out quickly and can’t be shut down once started, while liquid engines are less powerful but burn longer, and can be shut down or throttled mid-flight.

The Vehicle Assembly Building, where you design your rockets

Simple rockets are quite easy to put together, but more complex rockets require a lot more thought, since you can (and really have to) customise the staging sequence for your rocket, determining when each engine lights and when each stage separator fires. Larger rockets also need control systems, like RCS thrusters and the ASAS flight control computer, to keep them from veering off course.

Once you’ve built your rocket, it’s time to launch it, and if you’ve built it properly, it might even get off the ground! Again, with simple rockets, it’s not hard to get something off the ground and flying upward in a straight line, but as your rockets get larger and more complex, the challenge of building a working rocket increases dramatically.

This one may not be going in the right direction...

Failure can be frustrating, but it’s also hilarious. Rockets can veer off-course wildly, encounter control oscillations so bad that they tear themselves apart, suffer from disastrous separation mishaps, or just sit on the pad due to a shortfall of thrust until they topple over or explode. You might feel bad about dooming so many Kerbal astronauts, but watching a failure play out entirely beyond your control in KSP is just as entertaining as it is in games like Lemmings or World of Goo.

With two liquid-fuelled stages and six strap-on solid boosters, this rocket has plenty of power to reach orbit

One of the great things about KSP is the way it demonstrates the principles of real spaceflight. People may wonder why NASA spends billions sending astronauts in to space while companies like Virgin can do it for hundreds of thousands of dollars, but KSP makes the differences very clear. A small rocket will get your Kerbal astronauts straight up to the boundary of space, around 35,000m up, and a slightly larger one will get them out beyond the atmosphere, at about 70,000m.

Getting Your Kerbals in to orbit, though, requires a lot more power — you need to get them up there, and then get them travelling straight across at about 2300m/s, which means getting an entire rocket stage up to orbital height with a lot of fuel left. Perhaps the coolest thing, though, is that getting back down doesn’t require much power at all: you only need a tiny amount of reverse thrust (50m/s is usually plenty) to slow down enough to dip in to the atmosphere, and from there, the atmosphere will slow you all the way down without needing any extra fuel.

Flying in a high orbit above Kerbin, with Mun in the distance

Earlier versions of KSP required maths skills, or just dumb luck, to get in to orbit: the only way you knew for sure that you’d made it was by waiting until you’d completed an orbit. Current versions include an orbital map, which plots out your current orbit (or your current course back in to the planet) based on your speed and heading.

The orbital map plots your current orbit -- or your current course back to terra firma

When I started playing KSP, it took me a lot of work just to get in to orbit, but in KSP 0.12 there’s now a much grander target: a moon, called Mun. Getting to Mun requires even more power — you need to get to orbit and then accelerate to about 3000m/s in the right direction — and then slowing in to Munar orbit requires even more thrust. Spaceflight is all about weight, and every bit of extra fuel you need at the end of your flight means a lot more fuel (and often more engines, which adds more weight and requires even more fuel) at launch.

The ultimate challenge is a Mun landing. There’s no landing gear as such, but you can cobble one together with tail fins, though the challenge, as always, comes down to weight: you need fuel to get to Mun, slow to a halt above the surface, make a controlled hover over the surface until you find a suitable landing spot, and then very carefully drop down to the surface. Once you’re there, you still need enough fuel in your spacecraft to take off again, break away from Mun’s gravity, and then head back to Kerbin.

My massive moonshot rocket, sitting on the pad before launch

Touchdown! This is all that's left of my giant rocket after reaching the Munar surface

For now, KSP is available only for Windows and Mac OS X; it uses the Unity game engine, which runs on just about every platform other than Linux. The Unity developers apparently plan to add Linux support, but for now, the Windows version runs quite well under Wine. The current version is free, but the developers are going to start charging soon, so now is as good a time as any to check it out!

The music is my most recent track, Texel, which seemed like a good match for the video. It was all shot with a hand-held Canon 550D and a 50mm f/1.8 lens, hence the shakiness — it took some time to go through all of the video and find the usable bits, where the camera was both steady and in focus.

I used Kdenlive to edit it all together, and I’m glad to say that it was much more solid than it was during my last video editing project. In particular, it automatically cropped the extra lines out of the 550D’s 1920×1088 files, so I didn’t need to transcode anything. I didn’t apply much processing this time, which may have helped — there’s just a few simple transitions and some colour correction work.

Kdenlive’s ability to use proxy clips — small, low-resolution copies of your original high-res clips that are used during editing — helped keep the preview playback smooth while editing. The original clips are used while rendering the video, though, so the proxy clips don’t affect the final output quality.

I think Unity2D is not just a terrible idea, but also another example of the new direction that Ubuntu is taking that makes me wonder if it’ll be my distribution of choice for much longer.

Not so unified

Unity2D removes the reliance on OpenGL by avoiding it entirely: it’s a rewrite of Unity from the ground up, based on the Qt toolkit and using the Metacity window manager instead of Compiz. While it looks and feels much like standard Unity, it’s an entirely separate codebase, and keeping the two in sync as features are added will require a substantial amount of extra work. Perhaps the Ubuntu developers have the resources needed to keep up, but it seems like a very shortsighted approach to me.

GNOME 3′s current fallback desktop is definitely a hack, too — it cobbles together a UI that looks a bit like GNOME Shell using the panel and related components that have been ported from GNOME 2. It has neither the flexibility of GNOME 2 nor the elegance of GNOME 3, so it’s not a particularly compelling experience, but the Fedora developers plan to make the full GNOME Shell experience available for nearly everyone in Fedora 17, using some very cool technology.

Software OpenGL with llvmpipe

OpenGL isn’t inherently limited to systems with hardware acceleration; Xorg actually provides a software implementation of OpenGL by default whenever hardware support is unavailable, but its performance is far low to handle desktop effects. However, a new software renderer, called llvmpipe, aims to change that. By using LLVM, a generic virtual machine that produces optimised x86 or AMD64 code on-the-fly, and utilising multiple CPU cores, llvmpipe performs far better than the standard Xorg renderer.

The gains are impressive: running Quake III Arena at 800×600 on my dual-core laptop, Xorg’s renderer managed 3.9 FPS, while llvmpipe managed a fairly playable 34.9 FPS. While that only makes llvmpipe about as fast as my old Matrox G400, that’s okay — it just has to be fast enough, and for GNOME Shell, and even the odd game, it definitely seems to be. llvmpipe has actually been used as the default software render in Fedora since Fedora 15, but it’s only in Fedora 17 that it supports all of the OpenGL features required to run a compositing window manager.

GNOME Shell running without hardware acceleration on Fedora 17, using llvmpipe

I tested the Fedora 17 development packages (aka “Rawhide”) in a KVM virtual machine, and it worked fairly well; logging in revealed a complete GNOME Shell desktop, and while it was a little choppy, it was definitely usable. I’d definitely expect it to be faster on an actual PC, especially with a mutli-core CPU. The Fedora developers have plans to improve performance, too, by optimising llvmpipe and disabling some minor effects.

So, on the one hand, we have Fedora working on key infrastructure that will improve the Linux desktop experience for all users without hardware OpenGL acceleration, and on the other, we have Ubuntu developers throwing effort away on a developmental dead end. Ubuntu has copped flak before for not contributing to Linux development, but I don’t generally buy in to that argument — “contribution” isn’t something you can measure just by analysing commit logs or counting lines of code. Canonical can pay its developers to do whatever it wants them to do, but increasingly, it seems that the effort they’re expending is pushing Ubuntu in a direction I’m not sure I want to follow.

It’s hard to elaborate on exactly why I feel that way — I think it’s really down to little things, like insisting on forging its own path with Unity, the increasing number of built-in monetised services, and their sleazy dealings with Banshee (be sure to read the comments on that one!). Maybe the result is a great OS for a lot of users, but for me, Ubuntu is slowly drifting away from being the OS I want it to be.

I talked a little about the production in an earlier post, but I have included some further details after the jump.

This is one of my shortest tracks, and that was a deliberate departure for me — in the past I feel like I’ve often stretched things out to get to a certain length, and let them get a bit too repetitive in the process, so I deliberately avoided that here. In hindsight, there’s a lot going on in there, so perhaps it could’ve done with being a bit longer, but it definitely shouldn’t be boring at the very least!

In terms of sounds, the pads and bass are from the Blofeld, but everything else is software — Calf Monosynth for the sixteenth-note bleeps in the background, Linuxsampler for the Rhodes, and Hydrogen for the drums. The Rhodes is the excellent jRhodes3 soundfont, which I converted to SFZ format using sfZed, and the kick and snare come from the Microhammer Gnomehammer collection of wintry sounds.

The vocal sounds were a bit of fun. I recorded myself singing a note in to my mic, chopped out a small section that had a nice, stable pitch, and then time-stretched that to produce a longer vocal sound that sounds a little strange and ethereal. Each of the little vocal flourishes was created from that by pitch-shifting it to create the different pitches, and then performing a bunch of micro-edits for the glitchy, stuttery bits.

Effects-wise, I’ve already discussed Loomer Cumulus — it’s responsible for the messed-up drum break in the middle, and a few drum hits in the latter half of the track. I’ve also used the Decimator plugin a bit: the Cumulus drums, vocal sounds, and sixteenth-note bleeps all have automated Decimator plugins. The warbly, lo-fi delay on the Rhodes is courtesy of my Behringer VM1 analog delay pedal.