But I meant in this particular case cause the behaviour didn’t make sense.
Resetting preferences default made it work as intended.
Reproduced it, works for me ok
Did you import the preferences from the previous version? For me it produced loads of issues.
Hey thanks, but I don’t have any issue with coloring per se, just that events get priorized over tracks, which is by design. 
It doesn’t happen for me after deleting the prefs.
Why would you want to do that? Press CTRL+left click on the track is much faster.
No it is just working by default.
Just when you want to colorize separate events and not tracks then you have to use the upper one or “alt+shift+c”
It all depends on user needs
You can just do the same as with tracks CTRL+ left click
Yeah sure, if you got the color tool though. If you don’t then alt+shift+c works with any tool in hand. The pallete even stays open if you wish to colorize more. Lot of option on how to do it. That’s great tbh.
Yep, I can confirm. This looks like a bug.
I could reproduce it here on 12.0.40, and the moment you set “Select Colors by Name” in the project color settings, you cannot change your tracks color anymore with CTRL+Left Click, if an event is selected as well.
As you showed in the video, if you unset “Select Colors by Name”, it works again.
@Martin.Jirsak Can you perhaps report this issue to Steinberg?
EDIT: @Voxango perhaps you want to rename the title of the thread, since this happens no only to folders, but to all type of tracks?
I’m currently demoing Cubase Pro and thought I learned a new shortcut. But I’ve been using the “by name” setting and would hate to have to deselect events before coloring.
Not bugs, but I’m coming across a few odd design choices, at least coming from Studio One. I’m happy with the feature set so far, but the workflow is a bit clunky. I’m hoping this improves as I learn/create shortcuts & macros before the 30 days is up.
1 Like
Hi,
Reported to Steinberg. Thank you.
4 Likes
Thank you Martin, much appreciated!
Let’s say that you have selected a part. You now want to move on and scroll away. You go to another track and you want to change color. You click on the track (I mean in the column where the mute button, rec button, speaker button is) you go to select a color to change, it won’t change. Only after you have deselected the part in your previous track will it change.
It’s easy to find your self puzzled by this but whether it is counterintuitive or a bug, I am not sure. It’s just something (new) users would find problematic.
1 Like
Yes, because even basic operations in multiple OS we all know and use everyday work on the last selected/focused object. This principle of one object gets priorized over the other doesn’t exist there, as it would cause more confusion as it would help. So why reinventing the wheel?
2 Likes