Category Archives: Sound, Lighting, and Venue Software

Handy applications for venues, techs, and bands, as well as reviews and opinions about those applications.

Ask Me Something For Thursday

I’ll be doing a live show with AMR.FM on July 9th.

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.

askanythingwebWant to use this image for something else? Great! Click it for the link to a high-res or resolution-independent version.

Just a reminder: On July 9th, I’ll be live on AMR.FM. If you’ve got a question about live production that you want answered, now’s the time to ask!

If you’ve subscribed to this site’s feed via email, you can email a question (or multiple questions) to me. You can also get in contact with me via Facebook or Twitter. Obviously, I can’t guarantee that any particular question will be answered, but I’ll do my best to get things in.

To listen to the show, you’ll have to go to AMR.FM and select “United States” & “Utah” in the appropriate dropdowns. The plan is to be on at 7:00 PM, Mountain Daylight Time.


How Much Output Should I Expect?

A calculator for figuring out how much SPL a reasonably-powered rig can develop.

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.

howloudWant to use this image for something else? Great! Click it for the link to a high-res or resolution-independent version.

As a follow-on to my article about buying amplifiers, I thought it would be helpful to supply an extra tool. The purpose of this calculator is to give you an idea of the SPL delivered by a “sanely” powered audio rig.

A common mistake made when estimating output is to assume that the continuous power the amp is rated for will be easily applied to a loudspeaker. This leads to inflated estimations of PA performance, because, in reality, actually applying the rated continuous power of the amp is relatively difficult. It’s possible with a signal of narrow bandwidth and narrow dynamic range – like feedback, or sine-wave synth sounds, but most music doesn’t behave that way. Most of the time, the signal peaks are far above the continuous level…

…and, to be brutally honest, continuous output is what really counts.


This Calculator Requires Javascript

This calculator is an “aid” only. You should not rely upon it solely, especially if you are using it to help make decisions that have legal implications or involve large amounts of money. (I’ve checked it for glaring errors, but other bugs may remain.) The calculator assumes that you have the knowledge necessary to connect loudspeakers to amplifiers in such a way that the recommended power is applied.


Enter the sensitivity (SPL @ 1 watt @ 1 meter) of the loudspeakers you wish to use:

Enter the peak power rating of your speakers, if you want slightly higher performance at the expense of some safety. If you prefer greater safety, enter half the peak rating:

Enter the number of loudspeakers you intend to use:

Enter the distance from the loudspeakers to where you will be listening. Indicate whether the measurement is in feet or meters. (Measurements working out to be less than 1 meter will be clamped to 1 meter.)

Click the button to process the above information:

Recommended amplifier continuous power rating at loudspeaker impedance:
0 Watts

Calculated actual continuous power easily deliverable to each loudspeaker:
0 Watts

Calculated maximum continuous output for one loudspeaker at 1 meter:
0 dB SPL

Calculated maximum continuous output for one loudspeaker at the given listening position:
0 dB SPL

Calculated maximum continous output for entire system at the given listening position:
0 dB SPL

How The Calculator Works

First, if you want to examine the calculator’s code, you can get it here: Maxoutput.js

This calculator is intentionally designed to give a “lowball” estimate of your total output.

First, the calculator divides your given amplifier rating in half, operating on the assumption that an amp rated with sine-wave input will have a continuous power of roughly half its peak capability. An amp driven into distortion or limiting will have a higher continuous output capability, although the peak output will remain fixed.

The calculator then assumes that it will only be easy for you to drive the amp to a continuous output of -12 dB referenced to the peak output. Driving the amp into distortion or limiting, or driving the amp with heavily compressed material can cause the achievable continuous output to rise.

The calculator takes the above two assumptions and figures the continuous acoustic output of one loudspeaker with a continuous input of -12 dB referenced to the peak wattage available.

The next step is to figure the apparent level drop due to distance. The calculator uses the “worst case scenario” of inverse square, or 6 dB of SPL lost for every doubling of distance. This essentially presumes that the system is being run in an anechoic environment, where sound pressure waves traveling away from the listener are lost forever. This is rarely true, especially indoors, but it’s better to return a more conservative answer than an “overhyped” number.

The final bit is to sum the SPLs of all the loudspeakers specified to be in the system. This is tricky, because the exact deployment of the rig has a large effect – and the calculator can’t know what you’re going to do. The assumption is that all the loudspeakers are audible to the listener, but that half of them appear to be half as loud.


Noise Notions

When measuring things, pink noise isn’t the only option.

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.

Want to fftanalyzeruse this image for something else? Great! Click it for the link to a high-res or resolution-independent version.

Back in school, we learned how to measure the frequency response of live-audio rigs using a dual FFT system. I didn’t realize at the time how important the idea of measuring would become to me. As a disliker of audio mythology, I find myself having less and less patience for statements like “I swear, it sounds better when we change to this super-spendy cable over here.”

Does it? Are you sure? Did you measure anything? If you can hear it, you should be able to measure it. Make any statement you want, but at least try to back it up with real data.

Anyway.

I’m by no means an expert on all aspects of measuring sound equipment. At the same time, I’ve gotten to the point where I think I can pass on some observations. The point of this article is to have a bit of a chat regarding some signals that can be used to measure audio gear.

Tones and Noise

When trying to measure sound equipment, we almost always need some kind of “stimulus” signal. The stimulus chosen depends on what we’re trying to figure out. If we want to get our bearings regarding a device’s distortion characteristics, a pure tone (or succession of pure tones) is handy. If we want to know about our gear’s total frequency response, we either need a signal that’s “broadband” at any given point in time, or a succession of signals that can be integrated into a broadband measurement over several points in time.

(Pink noise is an example of a signal that’s broadband at any given time point, whereas a tone sweep has to be integrated over time.)

In any case, the critical characteristic that these stimuli share is this:

A generally-useful measurement stimulus is a signal whose key aspects are well defined and known in advance of the test.

With pure tones, for instance, we know the frequency and voltage-level of the tone being generated. With pink noise, we know that all audio frequencies are present and that the overall signal has equal power per octave. (The level of any particular frequency at any particular point in time is not known in advance, unless a specific sample of noise is used repeatedly.)

Pretty In Pink

Pink noise is a very handy stimulus, especially with the prevalence of measurement systems that show us the transfer function of a device undergoing testing.

When folks are talking about “Dual FFT” measurement, this is what they’re referring to. The idea is to compare a known signal arriving at a device’s input with an unknown signal at the device’s output. In a certain sense, the unknown signal is only “quasi” unknown, because the assumption in play is that the observed output IS the input…plus whatever the measured device did to it.

Pink noise is good for this kind of testing because it can easily be continuous – which allows for testing across an indefinite time span – and also because it is known in advance to contain audio across the entire audible spectrum at all times. (As an added bonus, pink noise is much less annoying to listen to than white noise.) It’s true that with a system that computes transfer functions, you can certainly use something like music playback for a stimulus. Heck, you can even use a live show as the test signal. The system’s measurements are concerned with how the output relates to the input, not the input by itself. The bugaboo, though, is that a stimulus with content covering only part of the audible spectrum can’t give you information about what the system is doing beyond that input signal’s bandwidth. Because pink noise covers the entire audible spectrum (and more) all the time, using it as a stimulus means that you can reliably examine the performance of the system-under-test across the entire measurable range.

Now, this is not to say that pink noise is entirely predictable. Because it is a random or pseudo-random signal, a specific frequency’s level at a specific point in time is unknown until the noise is generated. For example, here’s a spectrogram of pink noise that has been aggressively bandpassed at 1kHz:

filteredpinknoise

The tone at 1kHz never completely disappears, but it’s clearly not at the same level all the time.

A major consequence of this variability is that getting a really usable measurement functionally REQUIRES two measurement points. Since the signal is not entirely known in advance, the reference signal MUST be captured during the measurement process. Although some test rigs can smooth un-referenced pink noise, and display the spectrum as being nominally “flat” (as opposed to sloping downwards from low to high frequencies), the resulting measurements just aren’t as good as they could be. It’s just harder than necessary to do something meaningful with something like this:

pinkonlyoneside

Further, any delay caused by the system being measured must be compensated for. If the delay is un-compensated, the measurement validity drops. Even if the frequency response of the measured system is laser-flat, and even if the system has perfect phase response across all relevant frequencies, un-compensated delay will cause this to NOT be reflected in the data. If the dual FFT rig compares an output signal at time “t+delay” to an input signal at “t,” the noise variability means that you’re not actually examining comparable events. (The input signal has moved on from where the output signal is.)

Here’s a simulation of what would happen if you measured a system with 50ms of delay between the input and output…and neglected to compensate for that delay. This kind of delay can easily happen if you’re examining a system via a measurement mic at the FOH mix position, for example.

uncompensateddelay

On the flipside, get everything in order and pink noise reliably gets usable measurements across a variety of test rigs, like these views of a notch filter at 1 kHz.

1kVA

1kSysTune

Hey, I Know That Guy…Er, Noise

I’ve known about pink noise for a long while now. What I didn’t know about until recently was a broadband stimulus that Reaper calls “FFT Noise.”

FFT noise is very interesting to me because it is unlike pink noise in key ways. It is dis-contiguous, in that it consists of a repeating “pulse” or “click.” It is also entirely predictable. As far as I can tell, each pulse contains most of the audible spectrum (31 Hz and above) at an unchanging level. For example, here’s a spectrogram of FFT noise with a narrow bandpass filter applied at 1 kHz:

filteredfftnoise

What’s even more interesting is what happens when the test stimulus is configured to “play nicely” with an FFT-based analyzer. You got a preview of that in the preview above. When the analyzer’s FFT size and windowing are set correctly, a trace that handily beats out some dual FFT measurements (in terms of stability and readability) results:

eqtransfer

Side note: Yup – the calculated transfer function in ReaEQ seems to be accurate.

The point here is that, if the test stimulus is precisely known in advance, then you can theoretically get a transfer function without having to record the input-side in real time. If everything is set up correctly, the “known” signal is effectively predetermined in near totality. The need to sample it to “know it” is removed. Unlike pink noise, this stimulus is exactly the same every time. What’s also very intriguing is that this removes the delay of the device-under-test as a major factor. The arrival time of the test signal is almost a non-issue. Although it does appear advantageous to have an analyzer which uses all the same internal timing references as the noise generator (the trace will be rock steady under those conditions), a compatible analysis tool receiving the signal after an unknown delay still delivers a highly readable result:

laptoptrace

Yes, the cumulative effect of the output from my main computer’s audio interface and the input of my laptop interface is noise, along with some tones that I suppose are some kind of EM interference. You can also see the effect of what I assume is the anti-aliasing filter way over on the right side. (This trace is what gave me the sneaky suspicion that an insufficient amount of test signal exists somewhere below 100 Hz – either that, or the system noise in the bottom octaves is very high.)

On the surface, this seems rather brilliant, even in the face of its limitations. Instead of having to rig up two measurement points and do delay compensation, you can just do a “one step” measurement. However, getting the stimulus and “any old” analysis tool to be happy with each other is not necessarily automatic. “FFT Noise” in Reaper seems to be very much suited to Reaper’s analysis tools, but it takes a little doing to get, say, Visual Analyzer set up well. When a good configuration IS arrived at, however, Visual Analyzer delivers a very steady trace that basically confirms what I saw in Reaper.

fftnoiseva

It’s also possible to get a basically usable trace in SysTune, although the demo’s inability to set a long enough average size makes the trace jumpy. Also, Reaper’s FFT noise plugin doesn’t allow for an FFT size that matches the SysTune demo’s FFT size, so some aggressive smoothing is required.

(As a side note, I did find a way to hack Reaper’s FFT noise plugin to get an FFT size of 65536. This fixed the need for smoothing in the frequency domain, but I wasn’t really sure that the net effect of “one big trace bounce every second” was any better than having lots of smaller bounces.)

There’s another issue to discuss as well. With this kind of “single ended” test, noise that would be ignored by a dual FFT rig is a real issue. In a way that’s similar to a differential amplifier in a mic pre, anything that’s common to both measurement points is “rejected” by a system that calculates transfer functions from those points. If the same stimulus+noise signal is present on both channels, then the transfer function is flat. A single-ended measurement can’t deliver the same result, except by completely drowning the noise in the stimulus signal. Whether this is always practical or not is another matter – it wasn’t practical for me while I was getting these screenshots.

The rabbit-hole goes awfully deep, doesn’t it?


Not Remotely Successful

Just getting remote access to a mix rig is not a guarantee of being able to do anything useful with that remote access.

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.

sorrytabletsWant to use this image for something else? Great! Click it for the link to a high-res or resolution-independent version.

The nature of experimentation is that your trial may not get you the expected results. Just ask the rocket scientists of the mid-twentieth century. Quite a few of their flying machines didn’t fly. Some of them had parts that flew – but only because some other part exploded.

This last week, I attempted to implement a remote-control system for the mixing console at my regular gig. I didn’t get the results I wanted, but I learned a fair bit. In a sense, I think I can say that what I learned is more valuable than actually achieving success. It’s not that I wouldn’t have preferred to succeed, but the reality is that things were working just fine without any remote control being available. It would have been a nice bit of “gravy,” but it’s not like an ability to stride up to the stage and tune monitors from the deck is “mission critical.”

The Background

If you’re new to this site, you may not know about the mix rig that I use regularly. It’s a custom-built console that runs on general computing hardware. It started as a SAC build, but I switched to Reaper and have stayed there ever since.

To the extent that you’re talking about raw connectivity, a computer-hosted mix system is pre-primed for remote control. Any modern computer and accessible operating system will include facilities for “talking” to other devices over a network. Those connectivity facilities will be, at a basic level, easy to configure.

(It’s kind of an important thing these days, what with the Internet and all.)

So, when a local retailer was blowing out 10″ Android tablets for half price, I thought, “Why not?” I had already done some research and discovered that VNC apps could be had on Android devices, and I’ve set up VNC servers on computers before. (It’s not hard, especially now that the installers handle the network security configuration for you.) In my mind, I wasn’t trying to do anything exotic.

And I was right. Once I had a wireless network in place and all the necessary software installed, getting a remote connection to my console machine was as smooth as butter. Right there, on my tablet, was a view of my mixing console. I could navigate around the screen and click on things. It all looked very promising.

There’s a big difference between basic interaction and really being able to work, though. When it all came down to it, I couldn’t easily do the substantive tasks that would make having a remote a handy thing. It didn’t take me long to realize that tuning monitors while standing on the deck was not something I’d be able to do in a professional way.

A Gooey GUI Problem

At the practical level, the problem I was having was an interface mismatch. That is, while my tablet could display the console interface, the tablet’s input methodology wasn’t compatible with the interface being displayed.

Now, what the heck does that mean?

Reaper (and lots of other audio-workstation interfaces) are built for high-precision pointing devices. You might not think of a mouse or trackball as “high precision,” but when you couple one of those input devices with the onscreen pointer, high precision is what you get. The business-end of the pointer is clearly visible, only a few pixels wide, and the “interactivity radius” of the pointer is only slightly larger. There is an immediately obvious and fine-grained discrimination between what the pointer is set to interact with, and what it isn’t. With this being the case, the software interface can use lots of small controls that are tightly packed.

Additionally, high-precision pointing allows for fast navigation across lots of screen area. If you have the pointer in one area of the screen and invoke, say, an EQ window that pops open in another area, it’s not hard to get over to that EQ window. You flick the mouse, your eye finds the pointer, you correct on the fly, and you very quickly have control localized to the new window. (There’s also the whole bonus of being able to see the entire screen at once.) With high-precision input being available, the workstation software can make heavy use of many independent windows.

Lastly, mice and other high-precision pointers have buttons that are decoupled from the “pointing” action. Barring some sort of failure, these buttons are very unambiguous. When the button is pressed, it’s very definitely pressed. Clicks and button holds are sharply delineated and easily parsed by both the machine and the user. The computer gets an electrical signal, and the user gets tactile feedback in their fingers that correlates with an audible “click” from the button. This unambiguous button input means that the software can leverage all kinds of fine-grained interactions between the pointer position and the button states. One of the most important of those interactions is the dragging of controls like faders and knobs.

So far so good?

The problem starts when an interface expecting high-precision pointing is displayed on a device that only supports low-precision pointing. Devices like phones and tablets that are operated by touch are low-precision.

Have you noticed that user interfaces for touch-oriented devices are filled with big buttons, “modal” elements that take over the screen, and expectations for “big” gestures? It’s because touch control is coarse. Compared to the razor-sharp focus of a mouse-driven pointer, a finger is incredibly clumsy. Your hand and finger block a huge portion of the screen, and your finger pad contacts a MASSIVE area of the control surface. Sure, the tablet might translate that contact into a single-pixel position, but that’s not immediately apparent (or practically useful) to the operator. The software can’t present you with a bunch of small subwindows, as the miniscule interface elements can’t be managed easily by the user. In addition, the only way for the touch-enabled device to know the cursor’s location is for you to touch the screen…but touch, by necessity, has to double as a “click.” Interactions that deal with both clicks and movement have to be forgiving and loosely parsed as a result.

Tablets don’t show big, widely spaced controls in a single window because it looks cool. They do it because it’s practical. When a tablet displays a remote interface that’s made for a high-precision input methodology, life gets rather difficult:

“Oh, you want to display a 1600 x 900, 21″ screen interface on a 1024 X 600, 10″ screen? That’s cool, I’ll just scale it down for you. What do you mean you can’t interact with it meaningfully now?”

“Oh, you want to open the EQ plugin window on channel two? Here you go. You can’t see it? Just swipe over to it. What do you mean you don’t know where it is?”

“Oh, you want to increase the send level to mix three from channel four? Nice! Just click and drag on that little knob. That’s not what you touched. That’s also not what you touched. Try zooming in. I’m zoomi- wait, you just clicked the mute on channel five. Okay, the knob’s big now. Click and drag. Wait…was that a single click, or a click and hold? I think that was…no. Okay, now you’re dragging. Now you’ve stopped. What do you mean, you didn’t intend to stop? You lifted your finger up a little. Try again.”

With an interface mismatch, everything IS doable…but it’s also VERY slow, and excruciatingly difficult compared to just walking back to the main console and handling it with the mouse. Muting or unmuting a channel is easy enough, but mixing monitors (and fighting feedback) requires swift, smooth control over lots of precision elements. If the interface doesn’t allow for that, you’re out of luck.

Control States VS. Pictures Of Controls

So, can systems be successfully operated by remotes that don’t use the same input methodology as the native interface?

Of course! That’s why traditional-surface digital consoles can be run from tablets now. The tablet interfaces are purpose-built, and involve “state” information about the main console’s controls. My remote-control solution didn’t include any of that. The barrier for me is that I was trying to use a general-purpose solution: VNC.

With VNC, the data transmitted over the network is not the state of the console’s controls. The data is a picture of the console’s controls only, with no control-state data involved.

That might seem confusing. You might be saying, “But there is data about the state of the controls! You can see where the faders are, and whether the mutes are pressed, and so on.”

Here’s the thing, though. You’re able to determine the state of the controls because you can interpret the picture. That determination you’ve made, however, is a reconstruction. You, as a human, might be seeing a picture of a fader at a certain level. Because that picture has a meaning that you can extract via pattern recognition, you can conceptualize that the fader is in a certain state – the state of being at some arbitrary level of gain. To the computer, though, that picture has no meaning in terms of where that fader is.

When my tablet connects to the console via VNC, and I make the motions to change a control’s state, my tablet is NOT sending information to the console about the control I’m changing. The tablet is merely saying “click at this screen position.” For example, if clicking at that screen position causes a channel’s mute to toggle, that’s great – but the only machine aware of that mute, or whether that mute is engaged or disengaged, is the console itself. The tablet itself is unaware. It’s up to me to look at the updated picture and decide what it all means…and that’s assuming that I even get an updated picture.

The cure to all of this is to build a touch-friendly interface which is aware of the state of the controls being operated. You can present the knobs, faders, and switches in whatever way you want, because the remote-control information only concerns where that control should be set. The knobs and faders sit in the right place, because the local device knows where they are supposed to be in relation to their control state. Besides solving the “interface mismatch” problem, this can also be LIGHT YEARS more efficient.

(Disclaimer: I am not intimately aware of the inner workings of VNC or any console-remote protocol. What follows are only conjectures, but they seem to be reasonable to me.)

Sending a stream of HD (or near HD) screenshots across a network means quite a lot of data. If you’re using jpeg-esque compression, you can crush each image down to 100 kilobytes and still have things be usable. VNC can be pretty choosy about what it updates, so let’s say you only need one full image every second. You won’t see meters move smoothly or anything like that, but that’s the price for keeping things manageable. The data rate is about 819 kbits/ second, plus the networking overhead (packet headers and other communication).

Now then. Let’s say we’ve got some remote-control software that handles all “look and feel” on the local device (say, a tablet). If you represent a channel as an 8-bit identifier, that means you can have up to 256 channels represented. You don’t need to actually update each channel all the time to simply get control. Data can just be sent as needed, of course. However, if you want to update the channel meters 30 times per second, that meter data (which could be another 8-bit value) has to be attached to each channel ID. So, 30 times a second, 256 8-bit identifiers get 8-bits of meter information data attached to each of them. Sixteen bits multiplied by 256 channels, multiplied by 30 updates/ second works out to about 123 kbits/ second.

Someone should check my math and logic, but if I’m right, nicely fluid metering across a boatload of channels is possible at less than 1/6th the data rate of “send me a screenshot” remote control. You just have to let the remote device handle the graphics locally.

Control-state changes are even easier. A channel with fader, mute, solo, pan, polarity, a five-selection routing matrix, and 10 send controls needs to have 20 “control IDs” available. A measly little 5-bit number can handle that (and more). If the fader can handle 157 “integer” levels (+12 dB to -143 dB and “-infinity”) with 10 fractional levels of .1 dB between each integer (1570 values total), then the fader position can be more than adequately represented by an 11-bit number. If you touch a fader and the software sends a control update every 100th of a second, then a channel ID, control ID, and fader position have to be sent 100 times per second. That’s 24 bits multiplied by 100, or 2.4 kbits/ second.

That’s trivial compared to sending screenshots across the network, and still almost trivial when compared to the “not actually fast” data rate required to update the meters all the time.

Again, let me be clear. I don’t actually know if this is how “control state” remote operation works. I don’t know how focused the programmers are on network data efficiency, or even if this would be a practical implementation. It seems plausible to me, though.

I’m rambling at this point, so let me tie all this up: Remote control is nifty, and you can get the basic appearance of remote control with a general purpose solution like VNC. If you really need to get work done in a critical environment, though, you need a purpose built solution that “plays nice” at both the local and remote ends.


Always Try To Fix The Thing With The Actual Problem

If it ain’t broke, fixing it won’t help much.

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.

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.)


“It Was On Sale” Is A Bad Reason

A great price on something that doesn’t work for you is not a good deal.

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.

The wrong gear at the right price is still the wrong gear.


Compression vs. A Limited Domain

Digital audio is not inherently compressed, but it is inherently limited in its representational scope – kinda like analog gear, actually.

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.

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.”

A Limited 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.

The Distinction

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.


Mixing A Live Album: Vocals

Polishing your recorded vocals involves a number of different processing steps.

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.


UI Setup For A Custom Console

When setting up your own console layout, usability and easy access are key considerations.

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.

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.


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.