Is there a bug with coloring tracks 2 levels deep in C11?
I am selecting the track in a folder inside another folder… and it just won’t color.
Works on tracks inside a folder, but not if the folder is nested inside another folder.
Bug???
Workflow stopped to research this… :((
Hmmm, update. Not sure what happened but I managed to get this unstuck.
Leaving the thread here in case someone else comes across this random issue or if it happens again.
Not sure what I did to unstuck it… colored a part, selected different tracks, moved around the nesting… not sure.
Every time I have a track coloring issue I always find it’s because an event is selected. And an event can also be an automation point! So when it doesn’t work. I just unselect all (set to ctrl-shift-a on Windows) and then set the color on the selected track.
1 Like
Thanks! I’ll keep that in mind!
In the meantime, do you know how to make it so that a nested folder doesn’t take on the parent’s color? (in this case the parent is teal, but I want the child to remain gray) Is there a preference for this kind of behavior?
Thanks for providing this link to much more info~!
I think the deeper inner workings of the current coloring system is not super straighforward but once you understand how the “Default color” setting works (that it’s not just about a color but actual behavior), it gets easier.
I think a big problem here that leads to much confusion is that CTRL-Clicking ANY track to access the color swatches will actually color whatever track is currently selected, not the track that the CTRL-click action is being executed on. This is really not intuitive. In my opinion, when you CTRL-CLICK a track to change its color, it should automatically select it as the target, and I think Steinberg should implement this slight change to make colorizing tracks a bit more intuitive.