nickbugayev

The only way to tell if a track is in a group is by looking at the output routing. If it is set to "Group", then the track is necessarily grouped. However, it's possible to change the output of a grouped track to something other than "Group". In that case, there is no way to tell if the track is grouped or not, strictly from properties available in the API.

no-way-to-tell-if-a-track-is-in-a-group-or-not-strictly-from-the-api

It seems ridiculous that there is absolutely no way to tell whether a track belongs to a specific group. One can find out whether the track belongs to a group via "current_output_routing", but not to what group it belongs to.

It seems ridiculous that there is absolutely no way to tell whether a track belongs to a specific group.  One can find out whether the track belongs to a group via "current_output_routing", but not to what group it belongs to.

i must have stumbled upon this problem, and i think i had found some sort of solution, but it was 

quite a while ago, i don't even remember exactly what the problem was, let alone the solution.

unfortunately i am very deep into a different patcher at the moment which is using all of my time and mental-abilities, so i can not risk mixing up my current brain-map by diving into that old patcher to remember what i was trying to do and how i fixed it.

i will revisit it some point in the next couple of weeks when i am finished with the current one, and i will try and remember to post my discoveries here.

my problem had to do with some inability to automatically follow down (or up?) a parent-child relationship chain, and not knowing if a track is in a group or not was obstructing this?

but maybe it was not the groups but the chains/racks that were causing this, in which case my problem/solution may be irrelevant to yours and i apologize for giving any false hopes.

i will post when i have news, but i hope someone will provide you a better answer in the meantime 

i must have stumbled upon this problem, and i think i had found some sort of solution, but it was 
quite a while ago, i don't even remember exactly what the problem was, let alone the solution.
unfortunately i am very deep into a different patcher at the moment which is using all of my time and mental-abilities, so i can not risk mixing up my current brain-map by diving into that old patcher to remember what i was trying to do and how i fixed it.
i will revisit it some point in the next couple of weeks when i am finished with the current one, and i will try and remember to post my discoveries here.
my problem had to do with some inability to automatically follow down (or up?) a parent-child relationship chain, and not knowing if a track is in a group or not was obstructing this?
but maybe it was not the groups but the chains/racks that were causing this, in which case my problem/solution may be irrelevant to yours and i apologize for giving any false hopes.
i will post when i have news, but i hope someone will provide you a better answer in the meantime 


You can query the track property 'is_grouped'. And to get the corresponding group track scan the tracks to the left for the property 'is_foldable'.

Yes but is there any way to find out what group a track belongs to if you have multiple groups ?

You can query the track property ‘is_grouped’

the 2nd half of broc's sentence should work for that

hmm not sure how to "scan tracks to the left?" would it matter if there is another group to left?

get the path to the track that's grouped
subtrack 1 from the track number
get is_foldable
if yes, that's the group track
if no, repeat until yes

Ok so if anyone else comes across this thread this is where I'm at with a solution.

Broc's solution works until Live 9, but with Live 10's new groups with in groups you can run into problems. If there's a group between the original track and the group master then the iteration will stop at the group inside of the group because it is foldable.

My work around right now is to close and open the group and check if the track is hidden when its supposed to be. It looks glitchy but it works and for what I'm working on I only have to do it when the track count changes.

If someone has a better solution though, it would be much appreciated!

Ok so if anyone else comes across this thread this is where I'm at with a solution. 

If someone has a better solution though, it would be much appreciated!


in this case you will also have to do if re-ordering tracks i assume

I only have to do it when the track count changes.


No way to tell if a track is in a group or not, strictly from the API