If it ain’t broke, fixing it won’t help much.
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.
In regards to troubleshooting:
“Rocket surgery” can be a great thing…
As long as you’re working on the right rocket.
(Consider the implications of this carefully.)
A great price on something that doesn’t work for you is not a good deal.
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.
The wrong gear at the right price is still the wrong gear.
Digital audio is not inherently compressed, but it is inherently limited in its representational scope – kinda like analog gear, actually.
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.
One of the great things about being an audio-human is that you get to answer your friends’ questions. I don’t know exactly what it is about having an audio discussion between the sets at a show, but it’s just a fun thing to do.
Maybe it’s because there’s a sort of instant reward to it all.
Anyway.
The other day, I was using some between-set time to transfer sound files from a recording of a Please Be Human show. As the process was moving along, I got into a conversation with “Mills” (the bass player) about the file sizes. As it turned out, Mills was a little mystified by all the filetypes that a person working with digital audio can encounter. Because so many files containing audio are encoded for the purposes of compression, Mills was under the impression that all digital audio is, inherently, compressed. (That is, compressed in terms of data size, as opposed to signal dynamic range compression.)
The idea that this would be the case is easy to understand. We live in a world where digital audio files containing compressed data are commonplace. MP3, AAC, WMA, OGG Vorbis – all of these are formats that can utilize data compression to save space. If every digital audio format you’ve encountered involves a file encoded for data compression, then it’s just natural to start assuming that all digital audio files use some kind of compression scheme.
This is not actually the case, though. A file that stores LPCM (Linear Pulse Code Modulation) audio data is definitely not compressed – but it IS limited to a useful “information domain.”
What on Earth did I mean by that last sentence? Well, let’s start with this:
Uncompressed digital audio has inherent restrictions on the sonic information that it can represent. These restrictions are determined by sample rate and the size of each sample “word.” Sonic information that falls outside these restrictions is either excluded from digital conversion, or included and then later represented inaccurately.
Let’s use a common recording format as an example: 24-bit, 44.1 kHz LPCM. This format is commonly wrapped in “Broadcast” WAV files or AIFF files.
The length of each sample word (24 bits) imposes a limitation on a stored signal’s dynamic range. The theoretical domain-size of a 24-bit integer (whole numbers – no fractions) sample is 144 decibels. So, if you set up your system such that a signal peaked PRECISELY at the clipping point, the file could theoretically be used to store and retrieve a signal that was equal in level or less, down to 144 dB less. Below that level, signal information would be totally indistinguishable from quantization noise. As such, the signal’s information would be totally unrecoverable.
(As an aside, 144 decibels of dynamic range is performance that is far in excess of most gear, and still in excess of even very good gear. To the best of my knowledge, the very finest analog systems in existence are limited to about 120 dB of dynamic range.)
On the other side of things, the sample rate (44.1 kHz) imposes the limitation on a stored signal’s frequency range. The theoretical domain-size of a signal sampled at 44.1 kHz is from 0 Hz to 22,050 Hz. Unlike the dynamic-range domain, signal information that exceeds this domain is not “drowned.” Instead, the information is misrepresented as an incorrect lower-frequency signal, known as an “alias.” (This is why there are anti-aliasing filters in analog-to-digital converters. The filters block sonic information above 22,050 Hz from entering the conversion process.)
What I’m getting at with all of this is that, yes, LPCM digital audio has restrictions on what it can represent correctly. As such, even if we’re not conscious of exactly what we’re doing, we do EXTERNALLY impose data reduction on the signals that we intend to store in the file. We do this because of the file’s limited data domain.
HOWEVER (and this is the key bit), the information stored in the LPCM file has NOT had any further data-size reduction applied to it. Whatever signal actually made it to conversion and storage is contained within the file at “full data width” for each data point. Every single sample utilizes the entirety of whatever sample-word length has been specified: 16-bit, 24-bit, whatever. Five seconds of perfect, digital silence occupies the same amount of storage space as five seconds of anything audible. The data is not compressed in any way.
What understanding the above allows us to do is to distinguish between the concept of a limited information domain, and the situation where information within that domain is represented in a compacted manner.
Any piece of audio equipment has an effective information domain. For instance, just like a digital audio file, a power amplifier has a limited dynamic range and usable frequency range. The amplifier’s electronics can only handle so much input and output voltage, and the unit’s noise floor imposes a lower limit on usable signal level. In the same vein, amplifiers can behave unpredictably (or even destructively) when asked to reproduce ultrasonic signals, so it can be helpful to filter very high frequencies out of the amplifier’s inputs.
Now…
Consider the case of the amplifier that can be set so that a mono signal of appropriate scope is duplicated across two channels or more. In a sense, what has happened is a rudimentary form of data compression. Instead of directly “storing and retrieving” two channels of duplicate audio throughout the amplifier (which would require two outputs from, say, a mixing console), we’ve instead combined a simpler input with an electronic “directive.” The directive says:
“Hey, Amplifier! I need you to mult this one input signal to both of your outputs.”
What happens is that a signal of the appropriate information domain (dynamic range and frequency content) is effectively encoded to have 50% of its otherwise required data-size, and then decoded into its full size at a more convenient time. In this case, the data size is the channel count, as opposed to anything within the signal itself – this analogy is far from perfect.
Even though the metaphor I just presented is both flawed and simplified, it still gives you an idea of the difference between a limited scope of information storage, and compressed information storage of data falling within that scope:
A digital audio file that stores compressed information effectively has the same signal storage domain as an uncompressed parent file or counterpart file. However, information within that domain is represented in such a way as to occupy less storage space. This can be done in a matter which ultimately loses no information, or in a destructive manner which relies on human perception to ignore or imagine the missing data.
As I mentioned before, an uncompressed format stores information such that each data point occupies the same amount of space. Silence is just as big as the most complex sonic event that you can imagine. This can be something of a waste, which is why data compression is often useful. The downside to compression is that it requires an extra “decoding step” in order for the stored data to be extracted. In the case of data stored on computers, this creates a tradeoff – you save storage space, but reading the data requires more processing power. If processing muscle is at a premium, and storage is cheap, then large, uncompressed files are the best solution.
…and the good news is that, just because audio is in a digital format, it doesn’t mean that you can’t have an uncompressed file.
Polishing your recorded vocals involves a number of different processing steps.
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.
When setting up your own console layout, usability and easy access are key considerations.
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.
This video is an overview of the major tips, tricks, and tactics involved in setting up a software console interface for live-audio. Building your own console layout from scratch can be a bit challenging, but it also allows you a LOT of freedom.
Also, if you’re using Reaper (or have software that allows custom track icons), you can download my “number” icons here.
I switched to Reaper from SAC because I wanted more flexibility to define my own workflow.
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.
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.
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.
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.
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.
I built an online utility that helps bands create neatly formatted patch lists.
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’re a new act, or if you’ve just never created an input list before, you may have some questions about what to do. It’s not that input lists are hyper-complicated creatures, but building one isn’t necessarily an instinctive act. You might wonder about what information to include that will actually be relevant for a venue tech. You might also wonder about what kind of formatting to do for the list.
…and, even though input lists aren’t huge documents, you still might look at that blank page in your word processor or text editor and go, “I don’t WANNA!”
(I’ve been there. I sympathize.)
Well, I’ve built a web-based utility that might be helpful for you.
The Input Listerizer is a web form that asks you for information about your act that I, as a small-venue tech, have found useful over the years. When you’ve put all that info in and clicked on the arrow that submits the form, the utility parses what you’ve provided. When it finishes, you get a nicely formatted input list and monitor patch.
At that point, you have some options. You can manually print the output page, if you like (making sure to enable the printing of backgrounds so that all the formatting comes across). You can also grab the request URL from the output page. The cool thing about the request URL is that dropping it into a web browser should regenerate your input list inside that web browser. In this era of tablets and smartphones, this can be a pretty handy thing – and it saves a bit of a tree, too.
Here’s the link: inputlisterizer.smallvenuesurvivalist.com
I’ve tried my best to debug The Input Listerizer, but there’s always that one “edge case” that gets away. If you discover a bug, have a feature request, or otherwise want to tell me something about the utility, please use the comment system available from this post’s dedicated page.
Here’s hoping that you find this little project to be useful!
You can make an upward expander with two signal lines, a gate, and a summing bus.
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.
On Twitter, I was having a conversation with @GibsonGirl5775 about gates and expanders. Expanders are the complementary process to compressors – they act to increase dynamic range, whereas compressors reduce dynamic range. A gate is just an “extreme” expander, because it expands signals all the way down to silence.
“Down” being key.
I had begun the conversation by mentioning that the version of Logic that I had (way back when) included an UPWARD expander, and that I kinda missed that plugin. Upward expanders can have a markedly different sound than a gate, because they are very well suited for gentle expansion versus full gating. You set your threshold, attack, and release as normal, but then you also get a “ratio” control. The ratio is similar to what you find with a compressor, except it works in reverse. For every dB that a signal EXCEEDS the threshold, some specified amount of gain is ADDED to the signal.
I don’t see a lot of upward expanders out there. Hey, I don’t even see many expanders, period. Full gates are very common. (The software that I use, Reaper, has a gate that you can transform into an expander by simply adding in some “dry” signal.) The nifty thing about expanders is that you don’t completely lose a signal when it drops below the threshold. This means that you can keep certain subtleties of the processed sound – albeit at a lower volume.
Anyway.
The Twitter conversation got me thinking: “If the Reaper gate allows me to make an expander by adding dry signal to the gated signal, can’t there be a way to make an upward expander as well?”
The answer is “yes, pretty much.”
It turns out that, with a bit of signal routing and a bog-standard gate, pretty much anybody can “hack” an upward expander together. The result isn’t exactly the same as a true upward expander, because the gain addition is a fixed amount and not directly ratio driven. Still, the similarity is fairly close.
Essentially, what we’re doing is parallel gating, as opposed to parallel or “New York” compression.
The cool thing is that this trick can work everywhere. You can do it on an analog console, or in the digital realm. All you need is a signal, a summing bus, and a way to send that signal down two channels that are connected to that summing bus. An aux send returned into a channel can serve well as a split.
The setup works like this:
Here’s a diagram:
To give you an example of how this sounds, here’s an unprocessed original signal of kick and snare, followed by a processed version of the same thing. (The “double-hits” you hear at times are kick-beater bounces and snare ghost-notes. The gate output is right on time, I promise.)
Figuring out where upward expansion is more handy than downward expansion is up to you. Like I said before, I kinda miss the option of an honest-to-goodness upward expander. However, I also have to admit that having an upward expander has become mostly just a curiosity. I’ve become plenty comfortable with downward expanders, and so I’m not suffering for lack of toys.
I’ll close by saying that I think there’s a more generalized upshot to all this, which is probably the most important element:
Audio processing is just a bunch of basic operations being strung together – Gain, time, level detection, summation, etc. If you don’t have the exact processing you need in an “already boxed up” fashion, you can often construct something very like what you want. You just have to figure out how the pre-built device puts the pieces together.
I only speak for myself, and bands should always feel welcome when I’m on duty.
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.
Back in high-school, we had a piece of paper tacked up in the sound and lighting booth. To this day, I still quote it:
“I know you understand what you think I said. What I’m not sure you realize is that what you heard isn’t what I meant.”
Just a few days ago, I posted an article suggesting that bands do a lot of homework while looking for venues to play. As I was writing it, I (of course) knew exactly what I meant. However, it was later pointed out to me that the presentation of what I meant might not be clear to everybody. The issues are:
What people heard isn’t what I meant.
If you read that article, and your feelings were hurt, I apologize – big time.
Also, let me say the following:
So, with that out of the way…on with the show!
A walkthrough for building a computer-controlled lighting system from the ground up.
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.
Back in 2010, or thereabouts, I was finishing a Bachelor of Science in Information Technology. To actually graduate, I had to prepare a capstone project – a cross-disciplinary work that would show that I had actually internalized my coursework. I decided that I wanted to apply my knowledge to the process of building a DMX lighting computer with a remote.
I did actually build and test a prototype system. Indeed, a simpler system based on my project is what I use to drive the lighting rig at Fats Grill.
At the time, my perception of the project was just that it was a way to finish my degree. The ironic result of this was that the manual, which was clearly written as a document to help lighting techs do things, was never actually given to anyone who would do something with it.
That’s changing today.
I went through the project, corrected some things, removed some overly specific bits, and saved it as a PDF.
It’s completely free – Click here to download.