Erlanger Programm: Pieces Falling Into Place

This will most probably be the last or second-to-last full-blown blog post before those going with the actual release (I’m reserving the right to post one announcing P7 completion in my logic)…bug first things first:

Release Announcement

Erlanger Programm will be released Thursday, March 31st 2016, 1800 UTC*.

Sound Design

The lead synth in part B (now a Pulse 2) has seen some parameter modulation, and now sounds both bold and agile. Nice!

EP_Pulse2_Klein_Bottle.jpgAnd that, following a decision, ends the Sound Design task group for good. Only the second arp synth and both pads (all of them also in B) had been marked for further action, but with low priority, and some work on the pad sounds (and simply listening to them) had showed me that they are actually rather good, mostly in how they complement each other. I might actually have a go at the arp2 part (using maybe the Q, or the Evo), but only if I don’t have anything better to do.

Mix and Master Details

I’m already going into some very detailed work here right now. The bass (guitar+synth) in B sounds fantastic on the Dynaudios, and fine on the cans, but seems to only consist of high frequencies (by bass guitar definition) on the T&As – and too much of that. An approach was to raise the ca. 130Hz region some, and cut widely higher up. Now this might conflict with the bass drum – let’s see, maybe I need some of my fancy band ducking later on?

Part D (and also a’) made me remember an article very long ago about compressor use, where the author said that a compressor is a must-have on an (electric) organ if the player is not an organ player and consequently does not use the pedal properly. I’m not an organ player, so that compressor really worked wonders. Whoever that author was – thanks!
With b having become so quiet and intricate, the orchestral bass drum levels are once again open for review – they might need to be higher, as bringing down b in its entirety by a considerable amount (around 10dB in RMS, although it sounds nearly as loud as before) has made the attenuation of those very low frequencies even stronger – maybe EQ is in order, too? And finally, working some fader-riding in B and D has had exactly the intended effect: although the tracks are now “less loud” by simple RMS/R128 measurement, they feel much louder due to the dynamic changes – Wagner loud, not Motörhead-loud.


Traditionally, my toolchain was Cubase (for the composed projects at least) for the edit/mix stage, and WaveLab for the master stage. For Erlanger Programm, I had moved to Cubase for the master as well, mainly because WaveLab 6 had the issue that it crashed if you added more than one instance of my treasured LP10 EQ.

There’s some disadvantages to this – mainly that Cubase is not an audio editor. And advantages: Cubase’s potential for automation. But in essence, this has resulted in exporting the mix from one Cubase project, generating the master in another one (in individual tasks for each of the nine parts), and for the 44.1kHz IUO MP3s running that through WaveLab (as Cubase lacks sample rate conversion).

As WaveLab 9 has just been released, I decided to make the move. This is a wholly different beast. The user interface has been changed, and radically so (which one user, based on the preview videos, described as “no longer looking like Windows 95”). Finally, there’s some proper plugins for mastering-style treatment, including more contemporary options for dither/noiseshape than UV22. And rendering to multiple files and multiple formats has been expanded a lot – nice!

Some of the limitations, however, remain: the most important one being very limited automation options: automation can only be applied to clips (in the logic of clips/tracks/output in their montage multi-track format), and there only to level, pan and plugin send level. How things like that seem sensible when mastering engineers even when working fully in the analogue domain still (or again?) perform fader-riding is beyond me. This feature gap also has kept me from moving the whole mastering task to WaveLab. Right now, I go from the prints from Cubase’s master project (without 2bus limiter or dither as 32float) into WaveLab as a single file, and then generate the individual files and formats in WaveLab. Works, is the same number of tasks as before, but a more streamlined experience. How to further optimize this? Putting everything that happens in the Cubase master project into the main project, then exporting full-length renders per track into WaveLab, and have that do the rest seems feasible – I might just do that.

Path Forward

Leaving the potential change in mastering workflow aside (a low-priority thing), I’m already in bugfixing territory all the way. Touch up that level a little. Slightly nudge an EQ on a track. With that in mind, I’m confident to have a RC-style version of all audio artifacts by Good Friday, and of the remaining things by Easter Sunday, to be good to prepare the release package by Easter Monday.

And maybe there’ll be another countdown on twitter, as it was for oscillator theory.

*) In that last post, I gave the date as “Thursday, April 1st”. As I don’t want to travel five years forward or six years back in time, I’ll settle on Thusrday, March 31st (2016), thus keeping the older “Q1/2016” target.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s