Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stan Fordsen]

I know what a stem is in post-production and sound-for-film. But why rename it in live sound? Is it not just a sub-group or aux-bus? (I like that Yamaha calls these mix buses "fixed" and "variable")

[Andrew Hollis]

Hi Stan,

Good question. SSL chose 'stems' to highlight the capabilities that stems have beyond traditional console groups, namely 3 things:

• Stems can pick off from any point in the signal path, not just pre or post: input, post insert A, post insert B, pre fader, post fader, post all. This is further enhanced because each processing block in an SSL path is completely flexible, even the fader can be moved pre everything! So you could have a post insert, post fader send that is also pre-channel processing.
• Stems can feed any other bus type; masters, auxes, even other stems.
• Crucially to #2, stems are variable, not fixed, sends.

Thus stems can be used as inputs, subgroups, auxes, matrices (sub-subgroups), and in a monitor workflow, as further submixes into the aux sends. It really opens up mix possibilities that have otherwise required workarounds, and allows for many levels of organization and feeds if desired. It makes these tasks easy instead of clunky.

Attached is a screenshot of stems in use as 3 different parts of a workflow: as inputs, groups, and effects:

• The multiple kick and snare channels are combined to a simpler-to-manage single kick and snare stem input.
• These stem inputs are then fed to two stem drum groups, with minor send adjustments to the parallel group. These drum stem groups can then send to an aux or artist cue system.
• The single snare stem input is also fed to the snare verb stem. That snare verb stem is sent to the drum stem, or master bus, and to the artist cue aux. And so on...

More info here and in the SOLSA offline app:
https://www.solidstatelogic.com/live/l100/control-surface
http://livehelp.solidstatelogic.com/Help/OPStem.html
https://www.solidstatelogic.com/live/l100/solsa

[brian maddox]

Hi Stan,

Good question. SSL chose 'stems' to highlight the capabilities that stems have beyond traditional console groups, namely 3 things:

• Stems can pick off from any point in the signal path, not just pre or post: input, post insert A, post insert B, pre fader, post fader, post all. This is further enhanced because each processing block in an SSL path is completely flexible, even the fader can be moved pre everything! So you could have a post insert, post fader send that is also pre-channel processing.
• Stems can feed any other bus type; masters, auxes, even other stems.
• Crucially to #2, stems are variable, not fixed, sends.

Thus stems can be used as inputs, subgroups, auxes, matrices (sub-subgroups), and in a monitor workflow, as further submixes into the aux sends. It really opens up mix possibilities that have otherwise required workarounds, and allows for many levels of organization and feeds if desired. It makes these tasks easy instead of clunky.

Attached is a screenshot of stems in use as 3 different parts of a workflow: as inputs, groups, and effects:

• The multiple kick and snare channels are combined to a simpler-to-manage single kick and snare stem input.
• These stem inputs are then fed to two stem drum groups, with minor send adjustments to the parallel group. These drum stem groups can then send to an aux or artist cue system.
• The single snare stem input is also fed to the snare verb stem. That snare verb stem is sent to the drum stem, or master bus, and to the artist cue aux. And so on...

More info here and in the SOLSA offline app:
https://www.solidstatelogic.com/live/l100/control-surface
http://livehelp.solidstatelogic.com/Help/OPStem.html
https://www.solidstatelogic.com/live/l100/solsa

Fantastic explanation.  Thank you.

Ever since i started using Reaper as a DAW and Mix Engine about 8 years ago i've been waiting for Live Digital Audio Consoles to start moving away from being nothing more than a Digital version of the same Analog work flows we've been using for decades.  Much of that workflow was dictated by the physical limitations of the hardware, and those limitations just don't exist in a digital processing environment.  Once you've had the ability to just "build" your own audio "mixer" without any specific routing or I/O limitations, it really opens up a whole new world of ways to manipulate and process audio.  It's awesome to see that SSL is already starting to move in that direction.

Of course the real devil is in the details of how you create a UI that enables you to access all that power.  Now i want to spend some time on the SSL just to see how well they did.

[Andrew Hollis]

Thanks Brian. That is funny bringing up Reaper because Reaper mixing didn't fully click until I made the connection that their 'tracks' are somewhat like our stem paths.

Uniquely AFAIK, a Reaper track is a channel or a bus, there's no dedicated 'send' concept, just depends in how/what/where you route. That was a revelation, ha. Makes sense when you think about it and is flexible. One could argue there are not many reasons to not design mixing consoles this way. The reason not to is I think not everyone is quite prepared to go this far outside their nicely partitioned lanes; it requires a bit more thinking.

But it is close to what SSL has done with the 'path' concept. On SSL, everything is a path, so everything has the same featureset and the processing can be copied to and from each other no matter if it is a channel or a bus. The benefit of still separating them into channel, aux, stem, master, matrix, talkback, and solo paths, instead of just a universal 'track' like Reaper, is you can make each type behave differently depending on the user input, customized to your preferences. That is what happens in the surface options menu. It makes getting to things very fast.

[brian maddox]

Thanks Brian. That is funny bringing up Reaper because Reaper mixing didn't fully click until I made the connection that their 'tracks' are somewhat like our stem paths.

Uniquely AFAIK, a Reaper track is a channel or a bus, there's no dedicated 'send' concept, just depends in how/what/where you route. That was a revelation, ha. Makes sense when you think about it and is flexible. One could argue there are not many reasons to not design mixing consoles this way. The reason not to is I think not everyone is quite prepared to go this far outside their nicely partitioned lanes; it requires a bit more thinking.

...

It's definitely a different way of thinking, but i think we're going to get there.  I think we're going to see more audio people coming up from a software background and thinking about audio in very different ways without the 'linear lanes' inherent in analog architecture.  Might be a generation or two before the old ways [and the old guys like me] die off, but i do think it's inevitable.

I would argue that going in this direction could in many ways take LESS thinking [once we've adapted to it of course] since i lot of the planning needed to do things the way they're done now could be eliminated.  With our current consoles, the engineer has to take into account the architectural limitations of the console and try to fit the needs of the show into that architecture.  This can be tricky, especially when the needs change midstream.  If you could throw all that out [limited numbers of channels and busses and number of EQ filters per path, etc.] you could kinda 'build it as you go' and easily adapt to changes as they come.

I'm excited to see what the future holds.  And now i REALLY want to play with an SSL...

[John Roberts {JR}]

There has been a convergence happening between recording and big dog touring as larger acts want the same studio efx (plug-ins and all) on the road, to make the live performance more recognizable.

I am a little surprised to see SSL going after live SR, but that just means they still have a pulse.  High end live SR is smaller than high end studio "was"... but now who knows? Not me.

JR

[Scott Helmke]

Not to speak poorly of my own tribe, but those other folks over there with the lighting consoles have been taking automation much farther than we have.  There's a lot left possible.

That being said, it's still going to be a bit of a conflict between what's ideally possible and what an engineer can actually do during something like a one-off soundcheck, especially in regards to monitors.

One feature that I could have just just a few days ago would be a way to (quickly, easily, and easy to maintain) fork off some chunk of processing for a specific monitor mix... such as one musician wanting a source to sound significantly different than the other musicians. Sure, it would be possible to a) patch to a spare channel b) replicate mix settings as needed c) make the necessary changes and d) not get lost after doing a few of those.  But that last requirement is what gives me the worries.

[Erik Jerde]

And now i REALLY want to play with an SSL...

I did the training on them a couple years ago and I really liked what they could do and the innovative ways they were thinking about some things.  All my work is DiGiCo these days and I'd love it if they adopted some of the same ideas that SSL has.  I believe they are in the same family now...

[ProSoundWeb Community]