Not being to solo 'input' tracks that are routed elsewhere?

Discuss music production with Ableton Live.
A Few Williams
Posts: 11
Joined: Tue Oct 29, 2013 2:30 am

Not being to solo 'input' tracks that are routed elsewhere?

Post by A Few Williams » Tue Oct 29, 2013 3:00 am

Of late I've been experimenting with slightly more complicated bussing / routing setups in Live than I've used previously, and have incorporated them into my workflow pretty well, including my default template; but I've run up against some problems which I'm hoping someone can help with.

I'll use drums as an example, please imagine the following:

kick, snare and claps routed into '_KICK/CLAP BUS'
all other percussion routed into '_PERCUSSION BUS'
'_KICK/CLAP BUS' and '_PERCUSSION BUS' routed into '__DRUM SUBMIX'

'DRUM ROOM' audio channel takes audio from from '__DRUM SUBMIX' i.e. creates a parallel channel - on which I'm trying to simulate a room mic as if this were a real kit.

'DRUM ROOM' and '__DRUM SUBMIX' have their outputs routed into '___DRUM MASTER' which then goes out to the Master channel.

(A bit convoluted for an electronic production maybe, but this is just some experimentation, and I like the control of having all the buses for separate processing. Drum mixes are sounding a lot fuller with this approach, to me. It also allows easy set up for parallel processing of whichever channel by creating a new audio track as described above for the 'DRUM ROOM' channel.)

Now my question: it seems to me that if I set up a mix like this, Live won't let me Solo channels that take an input from elsewhere; in this instance, the 'DRUM ROOM' channel. Obviously soloing the channel silences the track feeding it so we don't hear anything. I know the obvious solution to this kind of problem is to just set up a return channel with the Room Mic simulation on it, and send the '__DRUM SUBMIX' track to it... but if I want to route the output of the 'DRUM ROOM' Return back into my '___DRUM MASTER' audio track as intended, we get that huge latency which Ableton built in to avoid feedback loops or whatever the reason was.

I guess a workaround could be to have the '___DRUM MASTER' as a Return channel also, and just have the '__DRUM SUBMIX' audio channel on 'Sends Only', fully sent to '___DRUM MASTER', and then enable the send on the 'DRUM ROOM' Return channel and send that to the '___DRUM MASTER' Return channel too.

It all seems to be a monumental faff just to be able to Solo a Drum Room channel. I know Live is kinda shitty for complicated Routing (oh how I long for a Reaper-style routing matrix) but does anybody have any tricks up their sleeve for achieving this kinda of flexibility with busing? Requiring a messy combination of Returns and Audio Tracks to achieve the desired results seems very unwieldy.... I suspect people will tell me to KISS but I thought I'd ask anyway :)

Thanks all - this is my first post, please be gentle.

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Tue Oct 29, 2013 5:50 am

For soloing, the more simple obvious approach would be to either cmd/ctrl click all the required channels you need to hear the drums so you can solo more than one channel, or turn off exclusive solo in the preferences, but this can get tedious quickly if you have to solo more than one channel all the time.

So, a good remedy for that would be to use clyphx to set up a number of custom shortcuts for the number of channels you have to solo all the time.
If you always have to solo kick/clap, percussion bus, submix and drum room, then you could set up a command either in a clip or a clyphx script for your controller to solo all those channels at the same time.

You could do the same thing for routing as well, though the more channels you have the more latency there is when the i/o's are switched.

Another thing that came to mind was using a compressor on a track just to use so sidechain solo (headphone icon) and select which track you want to hear but I'm not sure how well that would work without testing it.

The routing to return/sends only method doesn't sound bad, but I'm thinking there's some drawbacks but not sure what specifically atm, plus that might add extra cpu(?)
ImageImage

A Few Williams
Posts: 11
Joined: Tue Oct 29, 2013 2:30 am

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by A Few Williams » Wed Oct 30, 2013 12:45 am

Gah, the multiple solo thing didn't even occur to me. Of course that is the solution.... *slaps forehead*

Thanks for your response. I think now steering clear of sends/returns for busing will be my approach, I'll leave them for mix/creative effects and keep busing separate... I'll look into those scripting things you mentioned too.

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 12:49 am

Yeah, if you have a leftover controller or buttons on one you're using, having shortcuts to press is a lot less tedious than soloing/unsoloing multiple tracks all the time. Check the x-controls section of the clyphx manual.

Or in general if it's more temporary workarounds, x-clips are fine.
ImageImage

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 9:27 am

Hey shadX,
do you know if it is possible in clyphX with xTriggers to make a function "lock control surface to device"? (And unlock obviously)

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 12:41 pm

Yes, it is. There's even a section for specific Push actions.
ImageImage

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 1:47 pm

shadx312 wrote:Yes, it is. There's even a section for specific Push actions.
Since you are mentioning Push. Maybe you know an answer to this scenario:
Push + Nocturn (with STC script). Push controls blue hand, Nocturn follows as "slave". I push the button I assigned to this xTrigger on the Nocturn. Nocturn stays locked to the device and controls it, Push moves away, taking the blue hand with it, controlling something else.
When I'm done tweaking two devices simultaneously, I push the xTrigger button on the Nocturn again (or another with a different xTrigger if need be) and it unlocks it from the device. Nocturn jumps back to be slave to the blue hand of Push. Can this be done?

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 3:49 pm

Yeah...just to be clear, you're talking about once a controller is unlocked it still controls that device even though the Blue Hand is somewhere else, right?

So, you'd have to select another device just to get the Nocturn away from it's unlocked device and then go back to where the Push one was and then lock the Nocturn to it.

I'm a little fuzzy atm so I'll check the Clyphx manual, there could be a no-brainer I'm not thinking of.

[]
ImageImage

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 4:00 pm

shadx312 wrote:Yeah...just to be clear, you're talking about once a controller is unlocked it still controls that device even though the Blue Hand is somewhere else, right?
[]
No, once it's locked I want it to still control the device. When I unlock it, I want it to jump back to wherever Push is at the moment.
This way I have on-demand two controllers, whose focus can be controlled by one of them (Push).

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 4:04 pm

This is obviously an attempt at a workaround to the fact that only one device can control the focus (blue hand). If two independent blue hands would be possible with two controllers, this wouldn't be necessary. (But I could live with this limitation if my workaround idea works)

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 4:23 pm

something needs fixing here but I think you can use the Control Surface actions of clyphx to tell the specific push device to move to another device, then move back to it, then lock the Nocturn, I think that would work. If there aren't any other devices in the Push device track, add an empty rack.

So let's say Push is the first control surface selected in the preferences and Nocturn is 2nd. You want to unlock the Nocturn, move the Blue Hand to an adjacent device, then move it back, then lock the Nocturn, which would be like:

[] CS2 Dev Lock (it's unlocking Nocturn because it was already locked) ; CS1 Dev < ; CS1 Dev> ; CS2 Dev Lock

I need to change my setup and I'll try it with an x-clip.
Last edited by regretfullySaid on Wed Oct 30, 2013 5:05 pm, edited 1 time in total.
ImageImage

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 4:36 pm

Yes it's definitely a workaround for the fact that an unlocked controller sticks to the device it was locked to instead of automatically latching onto the blue hand device. It can be convenient in some cases while not in others:|
ImageImage

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 5:01 pm

I'm not totally sure we are on the same page shadx, let me try to explain again.

In my example I would have several tracks with with several devices each.
All devices have their macros mapped.
Let's first only consider the Nocturn being controlled by the STC script. (Let's leave Push unconnected for the moment so it's easier to understand)
With the STC scipt my Nocturn has blue hand control and I can navigate between tracks and devices. Once I navigate that way with the Nocturn to a device it controls the 8 macros with its 8 encoders.

I now understand the blue hand situation in this way that If I now connect Push and it takes over the blue hand, I will loose the ability to navigate with the Nocturn. Right?!
So I guess the first relevant question is: in what way do I lose this ability: does it just get stuck on a device, or can I get it to move "slavishly" its focus along with the blue hand of Push?
If the later is somehow possible to achieve,
I have achieved the first step of what I want to do. But it is not very useful as both controllers are now controlling the same device.
But if I would now right click with the mouse the device header and choose "lock controller Nocturn to device" the Nocturn would stay (locked to the device), while Push is as free to move to other devices and or tracks as ever.
So let's say the locked to Nocturn device is an EQ8 on track1 and I move Push freely to track 2 where it also just happens to control an EQ8.
Two EQs on two different tracks controlled by two different controllers: immensely useful!

I want to achieve the above without touching the mouse and right clicking directly with a button from the controller. This what I'm aiming to do.

(If this is at all feasable depends, as stated above, on how the Nocturn moves or doesn't move as soon as Push is connected of course)

TomViolenz
Posts: 6854
Joined: Mon Dec 13, 2010 6:19 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by TomViolenz » Wed Oct 30, 2013 5:04 pm

shadx312 wrote:Yes it's definitely a workaround for the fact that an unlocked controller sticks to the device it was locked to instead of automatically latching onto the blue hand device. It can be convenient in some cases while not in others:|
Sorry I missed this while writing my reply:
So you are saying once another controller has control over the blue hand, the Nocturn doesn't move at all anymore? Damn! And there is no way to get it to follow Push? Well I guess there goes my nice idea :(

regretfullySaid
Posts: 8913
Joined: Thu Apr 22, 2010 5:50 pm

Re: Not being to solo 'input' tracks that are routed elsewhere?

Post by regretfullySaid » Wed Oct 30, 2013 5:50 pm

Ok, sorry, originally I explained the basic part but then re-reading
Push + Nocturn (with STC script). Push controls blue hand, Nocturn follows as "slave". I push the button I assigned to this xTrigger on the Nocturn. Nocturn stays locked to the device and controls it, Push moves away, taking the blue hand with it, controlling something else.
When I'm done tweaking two devices simultaneously, I push the xTrigger button on the Nocturn again (or another with a different xTrigger if need be) and it unlocks it from the device. Nocturn jumps back to be slave to the blue hand of Push. Can this be done?
I ended up think you already knew the basic part and were talking about the controller sticking to unlocked device.

So, BH (let's refer to the device with blue hand as BH) is controlled by any controllers that, by default, are not locked to a device. It doesn't matter what controller you use to navigate, they will all control the same BH (because there's only one), so there's no master/slave situation.

The only way you can control more than one device at the same time is by locking a controller to a device.

Once a controller is locked to a device, it controls only that device; it ignores BH.

So,
I now understand the blue hand situation in this way that If I now connect Push and it takes over the blue hand, I will loose the ability to navigate with the Nocturn. Right?!
No, not as I've experienced. Any controller that can navigate can navigate, I don't recall losing any functionality with a controller once another one is in use.
in what way do I lose this ability: does it just get stuck on a device, or can I get it to move "slavishly" its focus along with the blue hand of Push?
If Nocturn is unlocked, it should be "slavish" to wherever the BH is. Likewise, if you navigated to another track/device with the Nocturn, Push would also slavishly control the BH, as long as it's unlocked. That's why I don't think there's a master/slave dynamic, and I'm not saying that for some policitally correct level, I just mean that it doesn't matter what controller navigates to a device making it a BH, as long as any controllers are unlocked they will all control that one BH.
But it is not very useful as both controllers are now controlling the same device.
Right, but that's by default, hence the locking ability.
But if I would now right click with the mouse the device header and choose "lock controller Nocturn to device" the Nocturn would stay (locked to the device), while Push is as free to move to other devices and or tracks as ever.
Yes.
So let's say the locked to Nocturn device is an EQ8 on track1 and I move Push freely to track 2 where it also just happens to control an EQ8.
Two EQs on two different tracks controlled by two different controllers: immensely useful!
Yes, hence the locking ability.
I want to achieve the above without touching the mouse and right clicking directly with a button from the controller. This what I'm aiming to do.
Right, so you have options on both Push and Nocturn (as well as User Remote scripts) to at least be able to lock themselves to a device. If you had room on either controller you could set the other controller to lock/unlock as well.

What Ableton could update, and I think this has already been made as an FR but could be repeated, is to have a Hand per controller.
Just as each controller can have a different color box in session view (aka matrix), it could have a matching colored Hand on devices, at least just for locking for sake of organization. But let's have that go on a separate thread.

Anyway, I think you're worried over a potential situation you haven't been in before. Have you had 2 controllers at the same time? :lol:
ImageImage

Post Reply