"Select Colors by Name" bug in Cubase 12

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.

You need to delete preferences imported from Cubase 11 the issue will be fixed. @Tj99

Hey thanks, but I don’t have any issue with coloring per se, just that events get priorized over tracks, which is by design. :slight_smile:

It doesn’t happen for me after deleting the prefs.

And if you use the color palette on top instead?

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

I have customised the palette and same thing happens again. @Martin.Jirsak

Found the root cause… @Martin.Jirsak

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


Reported to Steinberg. Thank you.


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?