Tag Archives: Workflow

Why I Left SAC

I switched to Reaper from SAC because I wanted more flexibility to define my own workflow.

Please Remember:

The opinions expressed are mine only. These opinions do not necessarily reflect anybody else’s opinions. I do not own, operate, manage, or represent any band, venue, or company that I talk about, unless explicitly noted.

If you know me, you know that I’m a HUGE fan of my custom-built digital console. It has routing flexibility like nothing else I’ve ever worked with, is far less subject to the whims of manufacturers, and generally lets me do things that are difficult or even impossible with other setups.

What you may not know is that I didn’t always use Reaper as the main software package. I started off with SAC. I was actually very happy with SAC for a while, but the “bloom came off the rose” after a few frustrations popped up.

Don’t Get Me Wrong! SAC Is Rad

I won’t lie. I’m going to be pretty tough on SAC in this article.

The point isn’t to bash the program though.

Software Audio Console is a really neat, purpose-built labor of love. If nothing else, it shows that a reliable, live-sound-capable console can be run on a general-purpose computing platform. It has some great features and concepts, not the least of which is the “separate monitor console for each performer” workflow. That feature, coupled with integrated remote-control support, can potentially be VERY killer for the tech that works for professional bands who carry their own production. (Set everybody up with a remote, let ’em mix their own monitors, you run FOH, and life is dandy. Well, until one of the players causes a massive feedback spike. Anyway…)

SAC is efficient. SAC’s overall control scheme is great for live-audio, most of the time. SAC is stable and trouble free. SAC has very usable snapshot management. Using ASIO4All as a separate driver, I was able to use SAC for live mixing and Reaper for recording, with Reaper effectively running in the background.

SAC is a good piece of software.

If there’s any problem with SAC, it’s that the program is overly influenced by its developer’s (Bob Lentini) personal preferences and workflow. If you want something markedly different, you’re out of luck.

It Started With An EQ

I’m a massive fan of Reaper’s native EQ plug. The only thing it’s missing is variable slope for the high and low pass filters. I honestly don’t know why anyone would want to buy an expensive, annoyingly copy-protected EQ plugin when Reaper’s EQ is so powerful.

Yup. I’m a bit of a fanboy. Not everyone may share my opinion.

Anyway.

Wanting to use Reaper’s EQ with SAC is what quickly revealed a “blind spot” with SAC’s workflow. I found out that adding FX to a channel was a bit clumsy. I also found out that manipulating FX on a channel was almost horrific.

To instantiate FX on a SAC channel, you have to find the FX control, click on it to get the channel FX chain to pop up, then use an un-filterable list of all available FX to find the one you want, click “Add,” and hope that you’ve gotten the chain order right.

If you didn’t get the order of the chain right, you have to de-instantiate one of the plugs and try again.

In Reaper, plugin instantiation can happen by clicking the insert stack, picking a plug from a filterable and customizable list, and…that’s it. If you got the plugin in the wrong spot, you can just drag it into the right one.

That may not seem like a huge difference, but the annoyance factor of SAC’s clumsiness accumulates greatly over time.

On the live-manipulation side, Reaper is leaps and bounds ahead. If I need to tweak an EQ on the fly (which happens every show, many times), all I have to do is click on the EQ plug in the stack. Immediately, the EQ pops its UI into view, and I can get to work.

In SAC, on the other hand, I have to (again) find the FX control, click to open the channel FX list, find the EQ, then double-click on it in the list to get the GUI to display. A few extra clicks might not seem like much, but this truly becomes a very awkward slog in a big hurry. In fairness, SAC does have a channel EQ that is VERY much more immediate, but what that ended up forcing me to do was to run my beloved plug as a “basic” EQ, and use the channel EQ for everything else. I’m not bothered by complexity, but unnecessary complexity IS something that I dislike.

There’s also SAC’s stubborn refusal to recognize that drag-and-drop is totally “a thing” now. In Reaper, I can drag plugins and sends between channels. In SAC, you can’t drag anything to any other channel. You can drag channels into a different order, but it’s not simple to do. (Some more unnecessary complexity). In general, dragging things around and multiselecting in Reaper works exactly as you would expect, whereas SAC tends to be VERY finicky about where your mouse cursor is and what modifier key you’re using.

Artificial Scarcity and Workflow Lock-In

In a number of ways, SAC aims to provide a “crossover experience” to techs who are used to physical consoles. This is absolutely fine if it’s what you want, but going this route has a tendency to reduce flexibility. This loss of flexibility mostly comes from arbitrary limitations.

Most of these limitations have enough cushion to not be a problem. SAC’s channel count is limited to 72, which should be WAY more than enough for most of us in small-venue situations. With a SAC-specific workflow, six aux sends and returns are a lot more than I usually need, as are 16 groups and eight outputs.

The problem, though, is that you’re forced to adopt the workflow. Want to use a workflow that would require more than six sends? Tough. Want to use more than eight physical outputs on a single console? Too bad.

Again, there’s no issue if you’re fine with being married to the intended use-strategy. However, if you’re like me, you may discover that having a whole bunch of limited-output-count subconsoles is unwieldy when compared to a single, essentially unlimited console. You might discover that much more immediate channel processing access trumps other considerations. It’s a matter of personal preference, and the thing with SAC is that your personal preference really isn’t a priority. The developer has chosen pretty much everything for you, and if that’s mostly (but not exactly) what you want, you just have to be willing to go along.

Another “sort-of” artificial scarcity issue with SAC is that it’s built on the idea that multi-core audio processing is either unnecessary or a bad idea. The developer has (at least in the past) been adamant that multi-thread scheduling and management adds too much overhead for it all to be worth it. I’m sure that this position is backed up with factual and practical considerations, but here’s my problem: Multi-core computers are here to stay, and they offer a ton of available horsepower. Simply choosing to ignore all that power strikes me as unhelpful. I have no doubt that some systems become unreliable when trying to multiprocess audio in a pseudo-realtime fashion – but I’d prefer to at least have the option to try. Reaper let’s me enable multiprocessing for audio, and then make my own decision. SAC does no such thing. (My guess is that the sheer force of multi-core systems can muscle past the scheduling issues, but that’s only a guess.)

Where artificial scarcity REALLY reared its head was when I decided to try migrating from my favorite EQ to the “outboard” EQ plug included with SAC. I was happily getting it instantiated in all the places I wanted it when, suddenly, a dialog box opened and informed me that no more instances were available.

The host machine wasn’t even close to being overloaded.

I may just be one of those “danged entitled young people,” but it doesn’t compute for me that I should have to buy a “pro” version of a plugin just to use more than an arbitrary number of instances. It’s included with the software! I’ve already paid for the right to use it, so what’s the problem with me using 32 instances instead of 24?

I’m sorry, but I don’t get it.

There’s also the whole issue that SAC doesn’t offer native functionality for recording. Sure, I understand that the focus of the program is live mixing. Like the EQ plugin, though, I get really put-off by the idea that I HAVE to use a special link that only works with SAW Studio (which is spendy, and has to be purchased separately) in order to get “native” recording functionality.

Push Comes To Shove

In the end, that last point above was what got me to go over to Reaper. I though, “If I’m going to run this whole program in the background anyway, why not try just using it for everything?”

The results have been wonderful. I’m able to access critical functionality – especially for plugins – much faster than I ever could in SAC. I can pretty much lay out my Reaper console in any way that makes sense to me. I can have as many sends as I please, and those sends can be returned into any channel I please. I can chain plugins with all kinds of unconventional signal flows. I can have as many physical outputs on one console as the rig can handle.

In Reaper, I have much more freedom to do things my own way, and I like that.

As I’ve said before, SAC gets a lot of things right. In fact, I’ve customized certain parts of Reaper to have a SAC-esque feel.

It’s just that Reaper has the edge in doing what I want to do, instead of just doing what a single developer thinks it should do.