While working on my current music project, my DAW suddenly started to act up. My current DAW is Cubase 7.5 (the “Pro” version in the new terminology, with the current maintenance release applied), and I’ve been a Cubase user (with interruptions when I didn’t really work with a DAW during my improvisational period) ever since native DAWs existed (read: 1995 or so).
Cubase has mostly been a rather stable platform for me, unless I used some specific plugins which would equally challenge other VST hosts, so these hiccups came as a surprise. And the oddities were small at first sight, but there were a lot of them: plugin screens would come up all white or rather as a window frame to look through, patch loading in HALion would stop at about 75% of the progress bar, parts in the mixer (like the actual faders) would disappear…all in all, not something that allowed for continued productive work.
I already had a suspicion, and bringing up the task manager (of Windows 7 Professional x64) showed me that the Cubase process had something like 2.9 million KB (yes, that’s the way it’s displayed), and interestingly, that didn’t change if I unloaded or loaded patches. So I assumed it had to do with memory. Quickly getting rid of a granular synth patch based on some rather longish field recordings confirmed that: by freeing up memory in Cubase, I could make the problems go away.
Now there is a simple solution to that, or so it seems: simply use Cubase x64. That’s what I did, discovering that the strange issues had gone – but instead, average system load had roughly doubled, and some short-time CPU load spikes were added, which made work completely impossible. It seems that in a failure-mode-oriented view, I had eliminated the failure mode (program hitting some memory redline) not by eliminating the root cause (project eats lots of memory), but by moving that memory redline – but that way, arrived at a new failure mode, that led to the very same failure effect from before (“work is impossible”). What to do?
Windows and Memory
Back in the day (the day was around ’93) when 32bit Windows was first released, the inherent address space limit of 32bit architectures didn’t seem a problem: with an OS with a specified memory minimum of 12MB, 4GB were already far away – so far away it seemed, that the designers even reserved half of that space for the system alone, only to revise that later and make at least 3GB available to the user. But how far away was that back then? Taking Moore’s revised Law (or rather, projection) as an indication and combining that with the computer I had assembled in ’93 including 16MB of RAM, we arrive at 32GB in 2015 for a typical computer system, or getting into the 2-4GB spot at around 2007. That was, in fact, the case, and the solution for this was (and is) a 64bit OS, which I’ve been using since around 2006 (or roughly around that time) on all my new computers except for a netbook. And one thing I had discovered throughout many years of 64bit OS use is that while driver availability was an issue in the beginning, and even later on for XP x64, legacy (read: 32bit) applications all seemed to work flawlessly.
But how does that work in detail? If I run a 32bit application within the 64bit OS, does that 32bit app get 4GB? Or 2GB? Or 3GB? And do all 32bit applications share one address space, or does each one get its own? This Microsoft Article brought some light into the darkness:
- Each 32bit process gets its own space.
- That space is normally 2GB.
- It is 4GB if the application has been linked /LARGEADDRESSAWARE.
- For 64bit applications, the limit is generally 8TB, i.e. enough by today’s standards.
In consequence, it seems I have a total of three options:
- Reduce the memory demands of my music project.
- Somehow move memory demands to another 32bit process.
- Switch to a 64bit application.
(3) is what I had already tried – with the described result. Both (1) and (2) are options I decided to look at, as is somehow fixing the problem in (3). Note that while (1) and (2) can be addressed in parallel, (3) is a completely different route.
Now before we go into those details, it’s time to tell you a little about my music production workflow – simply because it plays a role in how I can work on those different paths to a solution.
Excursion: The MoinSound Production Workflow
In my work on composed material (which is what I’ve been doing almost exclusively since 2011 for all of my new work), I tend to stick to something that software and system engineers would call the “V-Model”. It means that you start on the top left of an imagined “V” letter by giving a very rough, top-level description of what you’re going to do (e.g. “make an album of music”), and then further refine that as you go down the V (“let’s make it electronic with lots of synths and have four main tracks”, define musical structure, write parts), until you record the actual stuff at the bottom of the V and then move up the other half integrating it (editing, mixing, mastering etc.).
In this workflow, I typically fire up the DAW when I’m about halfway down the left side of the V, i.e. when a general musical structure has been defined and some parts are written. Then, while moving down, a lot of what I implement at first is more of a digital mockup than the final implementation: if I’m going to have an electric bass or trombone part (which somebody else might end up playing to begin with), that will be sketched out based on the score using a synth/sampler implementation. The same is true for some synth parts, as early in the design I tend to use VSTis exclusively, and bring in the hardware synths only at the very end. Of course, the same is true for some audio effects, which may later be replaced with some “outcomputer” (does that word exist? or do we still call it “outboard” even though we don’t have a board anymore?) processing. And finally, even for the plugins, the final implementation might use a different plugin altogether.
This is relevant insofar as it shows that the plugin (and thus: memory) count tends to go down, not up as the implementation progresses. And finally, mixdowns are typically done in realtime (at least for submixes) due to the hardware synths and processor present (unless I’m willing to turn my workflow into a completely counterintuitive one, which I won’t).
Solution 1: Reduce Memory Demands
Let’s call it evading a solution, because what I want to do is not limit myself in my workflow. Still, let’s see what we can do:
Firstly, as I explained above, some of the plugins are bound to go and be replaced either with hardware synths or proper (acoustic or electric) instruments later in the production, so there’s no use to have some fancy implementations for those – after all, they’re only there as a reminder that “a note with that pitch and loudness happens at that time”. And this is something I started to work on immediately: there was a guitar and an electric bass guitar part that was to get recorded with an actual instrument later, so it made sense to replace the 300MB-heavy sampled instruments with something as slim as the (free) Proteus VX or some generic GM voices which come with Cubase’s included Halion Sonic SE.
On the example of the two patches above, it becomes clear that obviously sampler instruments are the things to look for. There are some memory-heavy instruments in that project, like the aforementioned field-recording thingie (a granular rain type thing). Of course, taking those long field recordings and then cutting out the segments that get actually used and redesigning the patch accordingly helps. Another thing that works with all of the sample-based instruments in that project (which are HALion 5, Groove Agent 4 SE and the dated Kontakt 2) is to tell the sampler to optimize for low RAM use – which you can do in all of the aforementioned programs with a simple slider. You can then furthermore (once the project is done) use a function that identifies the samples that are actually used in the project and unloads the remaining ones – great if you have that 97-key grand piano sampled with super-long tails for 20 different velocity layers, but end up using only 20 notes (that’s sufficient for your standard pop music harmonic progression played with both hands), 1-2 velocities each and a maximum duration of two seconds or so. However, this is something you can only apply at the very end of the implementation, so in this example of the grand piano, it would mean to use a simple implementation for the time being, and bring in the big guns only when you’re ready to mix.
Bringing all that together, I was able to reduce the total memory demands of my Cubase project form 2.8 to about 2 GB – all in all, with enough space to the top for now, but you never know what might happen in memory demands once the implementation of that fourty-odd minutes composition progresses further. I decided to follow the other options.
Solution 2: Move Stuff to Different Process
The first option would be to get a DAW that spans separate processes for each plugin. Now I don’t know if any DAW does that, but I consider Cubase a given for my DAW needs, so that is not an option.
Another one is to move something not to a different process, but out of the computer altogether, and that is something that’s going to happen anyway when I start to use hardware synths instead of plugins later in the production flow. This could be taken one step further by running some plugins in a generic host on another computer altogether – with all the issues this might lead to. I decided not to follow this for now, rather leave it as a “future option”; after all, I still got this Nehalem-i7-powered laptop sitting in my live setup and collecting dust.
Finally, there’s the idea to use ReWire technology. ReWire is essentially a virtual audio patchbay running in your computer. Fortunately, Cubase supports this technology. You’ll still need a virtual MIDI patchbay (but those are readily available), but of course the plugins you’ll want to use in this context need to support it, too. And this is where the fun already ends: HALion has sopped ReWire support sometime between version 3 and 5, and Kontakt (or NI in general) has never supported it to begin with. Another idea was to use Ableton Live as a Rewire “slave” (or “device”, as the correct ReWire terminology is) and load some plugins within Live. Unfortunately, Live does not load plugins when run as a ReWire slave, so no result here as well.
All in all, this solution didn’t yield any tangible results, at least not ones already considered under (1) or achievable without the “other computer” approach.
Solution 3: Going 64 bit.
This is, without any doubt, the way to go, the way into the future. And here, the question is why it didn’t work.
It seems that this has to do with a Steinberg technology called the “VST Bridge”. This is something that runs some plugins withing a 64bit Cubase. Now which plugins? There’s a Steinberg-penned explanation that’s not helpful at all, but the cold reality the article fails to explain seems to go some like this:
- If you have a 64bit plugin done with the VST SDK 3.x, you’re good.
- If you have a 32bit plugin done with a pre-version-3 VST SDK, you’re screwed.
- Nobody (at least not Steinberg) knows for everything else.
I simply tried to get rid of the “screwed” category plugins, and then have a go at those “nobody knows” ones. It seems that there’s 64bit versions for all done with the 3.x SDK, so it really boils down to 64bit plugins done with the 2.x SDK, and you know what? If you only use VST3 plugins (which, as we just learned, are all 64bit) and stick to 64bit plugins otherwise, then the world looks nice (at least, the VSTBridge.exe process does not come up or does not do anything).
So which plugins were in the “screwed” category in my project? Quite a few, I’m afraid. They can be grouped into the following categories:
- Plugins where a 64bit version is now available – and that free of charge to registered users. This was the case for the KORG legacy plugins. Thanks, KORG!
- Plugins where a 64bit version is available as part of a later version – which means you have to upgrade, which means you have to pay. This affected in my project Kontakt2, FM7 and PODFarm.
- Plugins which don’t see any more development, and thus it’s either the 32bit version or no version at all. One example here was the excellent (and free) mda ePiano.
Kontakt2 was used in that project for a lot of things, either for everything orchestral, or for patches I’ve grown accustomed to. The guitar and bass guitar were quickly replaced by similar patches from HALion’s library. Now the orchestral instruments in this project were limited to timpani, bass drum and glockenspiel. I decided to simply load those into HALion, as they didn’t make use of Kontakt’s scripting engine, and thus HALion could understand them.
Now why wouldn’t I use the timpani from HALion’s library you ask? The short answer is because the library of HALion is really an insult. The slightly longer one:
Among the four big sample-based plugins on the market today (Steinberg’s HALion, NI’s Kontakt, MOTU’s Machfive and Spectrasonics’ Omnisphere), HALion is the one with the smallest library size-wise. Now size of a sampling library alone doesn’t tell everything about its quality: as a long-time user of the E-mu Proteus 1/XR+, I know what you can pack into just 8MB of sample memory.
Now the problem is that HALion’s library is sub-par in the orchestral department even for a library of that size. As a rough indication, the combined libraries of HALion and HALion Sonic contains 171 woodwind patches, 127 strings patches and 207 brass patches – which is almost exactly the same as the size of the “synth pad” category.
But it doesn’t end here: the timpani patch, while on paper using a multisampled setup, sounds like crap. Of course, the ten-year old Kontakt2 one sounds much better. My old Kurz and the aforementioned Proteus sounds much better. Hell, even a Minibrute trying to sound like timpani sounds better. The reason becomes apparent if you dive into the patch and discover that the “timpani” is generated by combining tom samples (one size/pitch) with a sample called “metal bowl”.
Now I understand that Steinberg essentially wants you to buy the Symphonic Orchestra extension as well. However, this should not be a reason to deliver something of such unacceptable quality (and by “unacceptable” I mean that in a product that is in the same league price-wise as the aforementioned competitors, the sound is worse than in an affordable hardware synth from 1990). All in all: why did I buy HALion instead of going for the NI alternative? Looking back, that may have been a very stupid decision.
[end of off-topic rant].
I also got rid of the “true legacy” mda epiano (which was, as described, only a digital mockup thing, so I could easily replace it with a HALion patch), and that left PODFarm as the only remaining plugin: as I had only used amp models in this project, I decided to simply replace it with Cubase’s own amp modeler plugin, and if I needed the specific Line6 sound later on, I could always run that through the hardware device…
I briefly considered another option, namely to get the 32bit plugins out via ReWire. Now by standard, ReWire does not allow you to connect a 64bit host (or “mixed” in ReWire lingo) with a 32bit device, but ReWire 64/32 bridge that will accomplish just that. However, with my findings from before, that wouldn’t have helped me any, as the thing that I would have really liked would be to run all those PODFarms, and for that I’d need a device that in turn would load VST plugins – and the only device I have on my system, Live, doesn’t do that.
With all those measures in place, I finally had a setup that worked well in a 64bit environment (and although system load seemed higher than in the 32bit version, still at a comfortable level below hitting glitches), and also one where I believed to be able to continue without either hassles or limitations for this project (or others to come).
So, what have we learned?
I believe that if you haven’t switched to a 64bit DAW already, this might be the time where this is possible rather easily: most plugins are now available in 64bit versions, at least in the programs’ current version, and so it’s manageable to switch to a true 64bit environment for current and future projects, the only issue possibly being a cost-related one.
The issue might really be legacy plugins: in addition to the aforementioned mda epiano, there’s quite a bunch of things I can think of that I used to use a lot in the past: MadShifta, SupaTrigga, cyclotron…
Now those will in theory run using the VSTBridge in Cubase, however this is not a very trustworthy solution in my eyes, and results might be even worse if your fave plugin is either weak (e.g. autocoded) or strong (i.e. heavily optimized) code…it’s just trial and error.
For me, it has really shown two things: it is possible, yes. However, some things I had done with old versions of plugins or old plugins might require me to take a step into the future – be it to get new versions of those products, or simply learn how to replace them with others I already have.
This is hardly a full-blown success story, or howto. So, what were your experiences in that specific scenario? Have you already done this transition long ago, or do you ever plan to do it (after all, a lot of very successful productions were done with things like the Fairlight CMI which in its latest version, sported a maximum of 64MB or RAM)? I’m looking forward to your very success (or failure) stories…