Would something like this work for you? Done a graphic of the pallet and how text could be toggled on or off… Just a simple suggestion.
(scroll down to suggestion 7)
Looks good, I would suggest that because there are people with 100+ colours, that in addition to the pages user could just resize the colour window to be as big as they want, even full screen on a second monitor if they need and then the pages would adjust to this in real-time. (less pages or more, depending on how many colours are fitting in the user defined size, or if colour titles are enabled/disabled.)
I agree that editing colours should just be part of the colour palette itself instead of previous version colour editor, but all that stuff should just be tab pop outs, or if you enter “colour edit mode” the wheel automatically appears just as you have photoshopped it.
A search filter would also likely go appreciated in the colour palette for example, searching “cello” to quickly get all the cello colours.
+1
…and those people who defend a failure… What is your motivation? Are you getting paid?
You know you could hold shift+click and highlight multiple regions than select the color you want.All the regions highlighted will change colors at the same time
What would be nice if they can put they color bucket inside the color picker floating window.
I’m upset I can’t change multiple track colors in the mixconsole view
Yes I do know, you could also do that with the previous colour tool. But that’s presuming you know which events you want to colour all at once, when you might not.
They should add the color bucket inside the color palette. There’s plenty of space for it
First, I will say “Thank you” to Matthias for the post immediately above commenting on the this subject in relations to the first maintenance update. I applaud this sort of timeline visibility for specific issues of importance to people.
That said …
I very much agree with those who are lamenting the destruction of their workflow, and the disappearance of long-standing, well-functioning aspects of working with the program. IMO, this simply should not happen. The fact that it does reflects a deep and profound failure to value the user base (the customers!), their time, their money, and their support.
Was there ever a public discussion in advance of such a change? Correct me if I’m mistaken, but I think not. And that is a major problem! There should have been, with the onus on those proposing the change to justify it.
In no way am I saying that the program should not grow in features and capability - and it is never a problem when features and capability are ADDED to what is already there without breaking existing workflows.
However, when an existing workflow is removed, that is ALWAYS an issue.
Only the most necessary reasons justify removing an existing workflow, and IMO in almost all cases those supposed “necessary reasons” should be aired publicly in advance to help determine if they are really necessary, if there are alternative paths to the “goal”, if the pain to the user base would be in fact much higher than the optimist anticipates, and if the effort involved in the implementation would be better expended on other things of more importance to the user community.
The “new way” here (if undertaken at all) could almost certainly have been added side-by-side with the old way. In that case it should have been (again, if undertaken at all).
Alternatively, if it was literally not possible to add the new way side-by-side with the old way then implementing the new way and removing the old way should NEVER have been done without extensive public consultation with the users in advance.
I am deeply disappointed with what has (and has not) taken place here.
For me, updating to Cubase 10 is now on extended hold while I wait to see, for this issue specifically, as well as in general, whether the management of the Cubase product is or is not going to re-evaluate their approach to valuing the user base and addressing their real needs and wishes rather than creating arbitrary disruption in their lives.
i cannot agree more with sj1!!!
workflow is paramount and this nilly willy changing of perfectly implemented functions is just mad!
on top of it those changes are NOT DOCUMENTED!!
new for the sake of new is just the dumb mantra of software designers these days. i think one of the reasons for the market dominance of ProTools is that they are not misguided by this trend.
I was able to create a key command for getting the track color I want by using the Project Logical Editor as suggested above. It has made things so much easier to create a key command to change an event to any given color. I use one color if I want to use the range tool in the project editor so I can see the range and another that I like for using the audio editor. You can assign them to a macro and I have what is needed and I really learned something too. I just need to spend more time with the manual.
Update on this subject - the color tool has returned in Cubase 10.0.15 (but is not necessarily identical with v 9.5).
Discussion of the return can be found here:
Yea. Removing color pallete was a downgrade