After half a year and several supporting posts (including mine), the topic in the Issue forum called Ruler state not saved with workspace setting has just been locked with a message saying that the problem is not a bug but a feature request.
I am wondering in what way wishing for an interface’s state to remain unchanged unless you change it could be called a “feature request”.
BTW, the problem is not only related to workspace switching. The ruler display is also changed when you use the “Set Timecode at Cursor” command.
Well, he also wrote the function works “as intended”. I’m just curious as to what the intention could be. If the post means that it will be addressed in the next update, then it should be stated more clearly IMHO.
It simply means that the function is not broken, because the term bug refers to a broken function. As far as the intent, there isn’t an a priori assumption that the ruler should follow the workspace setting. While it makes sense for it to do so to you, I’m sure there are use cases where it would not be desirable.
As far as I can see, the ruler switches to the transport’s primary time display when you invoke ‘set timecode at position’. If the ruler is already set to the primary time display, it doesn’t switch. So I doubt this is a bug, it seems more likely that it’s a feature was implemented at some point in Cubase’s life to satisfy some request or requirement.
Thank you SteveInChicago. IMHO this still needs to be at least a user preference, since I can see no logical link between modifying a timecode value and changing a ruler display.
Moreover, I was using Timecode as the Primary Time display so I could see it better in the Project Window’s toolbar. Is there any way to have a larger timecode window somewhere?
