Group track doesn't work like a true bus...

[Forge.]

been doing a lot of work in Pro Tools lately and I was loving coming back to Live and being able to just select some tracks and CMD+G after all the faff with creating an aux track and routing everything in PT

one thing I do like IN PT groups though (different to busses) is the way it's easier to work with everything in that group as one block - i.e. not having to go and select all clips/regions before moving them together

[Forge.]

But Ham Hat, you really aren't being very clear about what exactly it is you're missing

[HamHat]

Still not clear on what you're after. Any examples? Like the ability to route other tracks outside of the group to the group channel or something? Just make the Group channel a normal audio channel?
I for one would like improved/easier routing on normal audio tracks to facilitate what people are looking for in 'bus' tracks, rather than add a new track type or something. If there was some kind of quick drag'n'drop method of routing, with all of the flexibility of normal audio channels, we'd almost not need groups or buses. Those input/output lists get pretty long and unreadable in large projects. Would be cool if we could multi-select a bunch of tracks and drag their output to the input of another or something (and vice versa for inputs)

But Ham Hat, you really aren't being very clear about what exactly it is you're missing

You can't use a bus through a bus with group tracks. I.E if you have a bus that has your dry signal and you want to switch between the dry bus and the aux sends it takes a few extra clicks and routes. Where as a normal bus all you have to do is mute the dry bus and you instantly have only your aux sends playing. Hopefully this makes sense.

[Forge.]

set the sends to "pre" (to the right right on the master track) then when you mute the group track it will still go to the returns.. unless I'm still not following

Also, the tracks in the Group track have "group" as an output by default, but you can still have them routed elsewhere if you prefer - likewise, the group has an output

[HamHat]

set the sends to "pre" (to the right right on the master track) then when you mute the group track it will still go to the returns.. unless I'm still not following

Also, the tracks in the Group track have "group" as an output by default, but you can still have them routed elsewhere if you prefer - likewise, the group has an output

While setting the tracks to pre is an option, it does technically effect your over all sound when using send tracks. And yes the group track still works to achieve what i need to do it just involves many extra clicks because it doesn't work like a true bus. I'm wondering if group tracks aren't armed as "in" and this is the cause of the extra routing needed.

[A Few Williams]

Still not clear on what you're after. Any examples? Like the ability to route other tracks outside of the group to the group channel or something? Just make the Group channel a normal audio channel?
I for one would like improved/easier routing on normal audio tracks to facilitate what people are looking for in 'bus' tracks, rather than add a new track type or something. If there was some kind of quick drag'n'drop method of routing, with all of the flexibility of normal audio channels, we'd almost not need groups or buses. Those input/output lists get pretty long and unreadable in large projects. Would be cool if we could multi-select a bunch of tracks and drag their output to the input of another or something (and vice versa for inputs)

But Ham Hat, you really aren't being very clear about what exactly it is you're missing

You can't use a bus through a bus with group tracks. I.E if you have a bus that has your dry signal and you want to switch between the dry bus and the aux sends it takes a few extra clicks and routes. Where as a normal bus all you have to do is mute the dry bus and you instantly have only your aux sends playing. Hopefully this makes sense.

Funny reading this as its exactly this topic which I've been thinking about a lot of late - even so far as to make a YouTube video about it, discussing exactly this issue.

My own personal solution to this is to not use Send/Return tracks at all. Rather, set up parallel processing using a multi-chain Audio Effects Rack; have one Chain labelled 'Dry', which is just your original audio unaffected, and then using additional Chains build up your what might be called 'Psudo-Sends'. You would set up those Chains exactly as you would the equivalent Return channels, and then the Chain level would become analogous with the Send level. Unless I am missing something key, this set-up is identical from and audio-routing perspective as using a traditional send/return arrangement.

An added advantage of this approach is that you can add additional processing AFTER the effect rack, to process the Dry channel together with any Effect channels - something I almost always will do on say my master drum bus (drum submix split into a dry channel and a 'Room emulation' channel and then processed together, much as one might do with the close-mics and the overheads on a live kit).

The problem with this approach is that you lose the CPU savings we all know about to do with sends/returns, but the benefit is that irrespective of how complex your prior audio routing, grouping etc, you can still solo each your 'Psudo-Sends' without any of the audio feeding them dropping out.

Does that make sense to people? I really need to pull my finger out and finish that video...

[HamHat]

Still not clear on what you're after. Any examples? Like the ability to route other tracks outside of the group to the group channel or something? Just make the Group channel a normal audio channel?
I for one would like improved/easier routing on normal audio tracks to facilitate what people are looking for in 'bus' tracks, rather than add a new track type or something. If there was some kind of quick drag'n'drop method of routing, with all of the flexibility of normal audio channels, we'd almost not need groups or buses. Those input/output lists get pretty long and unreadable in large projects. Would be cool if we could multi-select a bunch of tracks and drag their output to the input of another or something (and vice versa for inputs)

But Ham Hat, you really aren't being very clear about what exactly it is you're missing

You can't use a bus through a bus with group tracks. I.E if you have a bus that has your dry signal and you want to switch between the dry bus and the aux sends it takes a few extra clicks and routes. Where as a normal bus all you have to do is mute the dry bus and you instantly have only your aux sends playing. Hopefully this makes sense.

Funny reading this as its exactly this topic which I've been thinking about a lot of late - even so far as to make a YouTube video about it, discussing exactly this issue.

My own personal solution to this is to not use Send/Return tracks at all. Rather, set up parallel processing using a multi-chain Audio Effects Rack; have one Chain labelled 'Dry', which is just your original audio unaffected, and then using additional Chains build up your what might be called 'Psudo-Sends'. You would set up those Chains exactly as you would the equivalent Return channels, and then the Chain level would become analogous with the Send level. Unless I am missing something key, this set-up is identical from and audio-routing perspective as using a traditional send/return arrangement.

An added advantage of this approach is that you can add additional processing AFTER the effect rack, to process the Dry channel together with any Effect channels - something I almost always will do on say my master drum bus (drum submix split into a dry channel and a 'Room emulation' channel and then processed together, much as one might do with the close-mics and the overheads on a live kit).

The problem with this approach is that you lose the CPU savings we all know about to do with sends/returns, but the benefit is that irrespective of how complex your prior audio routing, grouping etc, you can still solo each your 'Psudo-Sends' without any of the audio feeding them dropping out.

Does that make sense to people? I really need to pull my finger out and finish that video...

My computer can handle the extra cpu hit, please post this video! and make sure I get the link

[rtcardinal]

Still not clear on what you're after. Any examples? Like the ability to route other tracks outside of the group to the group channel or something? Just make the Group channel a normal audio channel?
I for one would like improved/easier routing on normal audio tracks to facilitate what people are looking for in 'bus' tracks, rather than add a new track type or something. If there was some kind of quick drag'n'drop method of routing, with all of the flexibility of normal audio channels, we'd almost not need groups or buses. Those input/output lists get pretty long and unreadable in large projects. Would be cool if we could multi-select a bunch of tracks and drag their output to the input of another or something (and vice versa for inputs)

But Ham Hat, you really aren't being very clear about what exactly it is you're missing

You can't use a bus through a bus with group tracks. I.E if you have a bus that has your dry signal and you want to switch between the dry bus and the aux sends it takes a few extra clicks and routes. Where as a normal bus all you have to do is mute the dry bus and you instantly have only your aux sends playing. Hopefully this makes sense.

Funny reading this as its exactly this topic which I've been thinking about a lot of late - even so far as to make a YouTube video about it, discussing exactly this issue.

My own personal solution to this is to not use Send/Return tracks at all. Rather, set up parallel processing using a multi-chain Audio Effects Rack; have one Chain labelled 'Dry', which is just your original audio unaffected, and then using additional Chains build up your what might be called 'Psudo-Sends'. You would set up those Chains exactly as you would the equivalent Return channels, and then the Chain level would become analogous with the Send level. Unless I am missing something key, this set-up is identical from and audio-routing perspective as using a traditional send/return arrangement.

An added advantage of this approach is that you can add additional processing AFTER the effect rack, to process the Dry channel together with any Effect channels - something I almost always will do on say my master drum bus (drum submix split into a dry channel and a 'Room emulation' channel and then processed together, much as one might do with the close-mics and the overheads on a live kit).

The problem with this approach is that you lose the CPU savings we all know about to do with sends/returns, but the benefit is that irrespective of how complex your prior audio routing, grouping etc, you can still solo each your 'Psudo-Sends' without any of the audio feeding them dropping out.

Does that make sense to people? I really need to pull my finger out and finish that video...

Actually, that makes perfect sense to me. I do a lot of parallel 'sends', and pretty much never use sends and returns normally now, maybe a bit near the end of a mix when I'm working largely from rendered stems. I do this for very similar reasons, but honestly, the CPU savings of using sends and returns seems to get lost a lot of the times on my 6 core system, since using sends and returns from multiple channels seems to (a lot of the time) dump a LOT of processing on one core, and bottoms it out before I'm even using 10% of my total processing (according to the task manager). I'm not sure what it is, but it must have something to do with ableton's 'full signal paths are calculated on a core' setup for multi-core processing. If I have a processor heavy channels, and start 'linking' them together with sends and returns, my single core CPU usage goes through the roof sometimes. It's honestly more efficient to have reverbs and delays on every channel sometimes on my own system in larger projects. Depends on how I use it.

[Forge.]

funny, I guess we're doing different things, but I have been quite frustrated with the way pro-tools safe solos effects on busses etc because I'm used to working with Live and prefer it

[HamHat]

Another benefit to groups I would like to see is groups inside of groups. Graphic wise n such.