Transport > Transport Commands > Exchange Time Formats bug analysis

I think it was mentioned several times on the net already, although I couldn’t find a detailed description of what’s going on, just people complaining about the “Exchange Time Formats” or dot (“.”) keyboard shortcut sometimes stopping to work.

First, i figured there’s multiple different states that are stored:

  • one of them being the project configuration in Project Setup (Shift-S) > Project Time Displays > Display Format, the other
  • the other two (or more) are the option chosen in the drop down menu all to the right of the ruler of any given window

Ruler configuration seems to be prioritized above project settings, yet the project configuration is still stored persistently. So if you change the ruler option, project settings remain untouched and can be restored.

Now for the exchange command:

There actually seem to be two stated stored in the project settings, only one of them we see. The other one being the previously chosen option, with a default setting of “seconds” I think.

The thing is: if you change the ruler options, dot-command (exchange) isnt affected, it switches the two states in the project settings. switching twice does bring you back to your project setting - which can be different to what you saw originally, if the ruler option was changed.

BUT: if you change the project setting to the same value that was stored as the previous state, both states are the same and subsequent dot-commands don’t do anything.

example / reproduce:

(+) create new project
(+) try dot-command (exchange time formats) → it should change from bars+beats to seconds and back (verify in project settings)
(+) leave it at seconds → the internally stored previous state should be bars+beats now
(+) shift-s (project settings) select bars+beats → selected state AND internally stored previous state is bars+beats now
(+) try to exchange time formats → nothing happens


some notes:

the ruler setting hasn’t got to do anything with this, yet it seems to confuse people a lot, it’s not obvious why and when which parameter is doing what. it’s also not obvious to me why we have both of them in the first place, or why they aren’t synchronized. following scenario is getting a bit weird:
(+) project settings: bars+beats
(+) exchange time formats
(+) project settigns: seconds
(+) exchange time formats
(+) ruler dropdown: timecode

you now see timecode
(+) exchange time formats
→ you see bars+beats
(+) exchange time formats
→ you see seconds

which is three different settings.

I also want to apologize for my rant the other day, although there’s a little “but”:

If you have two projects open. Please put them both on screen and make sure to have editor windows in the lower zone. see what’s happening when you exchange time formats, the time format for the inactive project changes also, it most definetely shouldn’t though.
Even worse: the project settings time format doesn’t change. Which means in the active window, the project settings is switched, in the inactive window the ruler format is changed.
That’s a temporary bug though, if you close the editor window and reopen another one in the inactive project, time formats won’t change anymore.
Which maaaybe a correct thing. Although: changing the project settings for time format in the inactive project doesn’t do anything at all.

And here comes the “but” to my apology: all of this together really doesn’t seem like a single bug anymore, it leaves the impression of a really not sane code environment. Like there hasn’t been any decision if those configurations are in a project’s scope or application-wide and it’s getting mixed all over.


I really hope this helps.

My suggestions for a quick (although dirty) fix:

assume:
previous_state: stored state that “exchange time formats” switches to
selected_state: current state, what’s selected when project settings open
new_state: temporary variable, that contains the newly selected time format, when the user closed the project settings window

if (new_state == previous_state) { previous_state = selected_state}
selected_state = new_state


This will at least prevent the confusion of the dot-command not working anymore. If you put the same configuration in both states, the previously picked one will be stored in the “off”-state instead.

Also, the handbook states: “Switches the primary and the secondary time display.”
Which is somehow a correct description of whats happening: there’s an A-setting and a B-setting, dot-command switches between them.
What a user would expect although, is probably switching to the last used setting, which the command doesn’t. It’s not very clear in the documentation AND we nowhere actually see a primary and secondary time display. So people don’t understand - at least from what I read.


Ok thanks & sorry for the wall of text, maybe all of this isn’t a bug but intended, in this case I would pledge for really poorly documented with just one unclear sentence.

Best regards