Shortcuts unbinding randomly

[Michal Ochedowski]

34 minutes ago, msmcleod said:

The assignment for the current area is always shown on the right, whereas the current assignment for the Global area is always shown underneath and on the left.

What you're seeing for CTRL + R, is your "Track View" assignment on the right ( i.e. Rename Clip ), and the Global Area assignment underneath and on the left.   For CTRL + J, you're seeing the description for your "Track View" assignment to Bounce to Clip(s) on the right,  and it shows that it's unassigned in the Global area on the left.

 

Yes, it's all clear to me. What I don't understand is when and why Global Bindings take priority over Track View bindings. I'm sure that I had the same situation with 2 different outcomes while working in the same project, without even closing it. Sometimes my assignment for Ctrl+R did work and sometimes it just didn't. Then the Global Binding was prioritized. 

[Will.]

44 minutes ago, msmcleod said:

The assignment for the current area is always shown on the right, whereas the current assignment for the Global area is always shown underneath and on the left.

What you're seeing for CTRL + R, is your "Track View" assignment on the right ( i.e. Rename Clip ), and the Global Area assignment underneath and on the left.   For CTRL + J, you're seeing the description for your "Track View" assignment to Bounce to Clip(s) on the right,  and it shows that it's unassigned in the Global area on the left.

 

Also to point it out, Ctrl+R in Track view is the default shortcut to Arm a track for Record in both CbB (and to record in windows 10 with the built-in voice recorder from microsoft) - hence to why the user is saying this . . . .

1 hour ago, Michal Ochedowski said:

Perhaps that's the reason why I had so many situations with Ctrl+R randomly unbinding and performing the original assigned function. 

 

Edited August 19, 2022 by Will.

[GreenLight]

2 hours ago, msmcleod said:

The assignment for the current area is always shown on the right, whereas the current assignment for the Global area is always shown underneath and on the left.

What you're seeing for CTRL + R, is your "Track View" assignment on the right ( i.e. Rename Clip ), and the Global Area assignment underneath and on the left.   For CTRL + J, you're seeing the description for your "Track View" assignment to Bounce to Clip(s) on the right,  and it shows that it's unassigned in the Global area on the left.

It would be fantastic if the "Global" aspect/concept you describe could be indicated more clearly in the Preferences GUI. It is a bit confusing the way it's currently displayed. 🥴

[Peter Hintze]

+1

my keybindings dissapear every now and then`also. I suspect that changing the Cakewalk Version could be the reason perhaps?

I export my bindings often, to revert if i have to.

[David Baay]

9 hours ago, Michal Ochedowski said:

What I don't understand is when and why Global Bindings take priority over Track View bindings. I'm sure that I had the same situation with 2 different outcomes while working in the same project, without even closing it. Sometimes my assignment for Ctrl+R did work and sometimes it just didn't. Then the Global Binding was prioritized. 

Renaming a clip is only applicable to the Track View. If focus is in another view (e.g. the PRV in the multidock), then the Global assignment will apply. If you don't want Ctrl+R to do anything outside the Track View, you should assign it to 'Do Nothing' in the Global context.

[Michal Ochedowski]

9 minutes ago, David Baay said:

Renaming a clip is only applicable to the Track View. If focus is in another view (e.g. the PRV in the multidock), then the Global assignment will apply. If you don't want Ctrl+R to do anything outside the Track View, you should assign it to 'Do Nothing' in the Global context.

It doesn't happen as you described. That's the thing. I specifically checked this scenario earlier today. Just like you mentioned, I thought that window focus could have something to do with unusual shortcut behavior. I had Piano Roll open and still I could rename the clip in which MIDI notes were enclosed. In the past, with the exact same settings and Piano Roll open as well, Ctrl+R started arming all tracks for recording.

Like most of us here I have specific way of working and doing things in Cakewalk. That's how I know that while doing the same thing, I had 2 different outcomes on different occasions. No logic behind it. At least for me. 

[David Baay]

27 minutes ago, Michal Ochedowski said:

I had Piano Roll open and still I could rename the clip in which MIDI notes were enclosed.

That can only heppen with a clip selected which would mean focus is still in the Track View.. Click in the open PRV, and then try it.

If you haven't changed the Global assignment. Crtl+R will arm/disarm all tracks.

[Michal Ochedowski]

18 minutes ago, David Baay said:

That can only heppen with a clip selected which would mean focus is still in the Track View.. Click in the open PRV, and then try it.

If you haven't changed the Global assignment. Crtl+R will arm/disarm all tracks.

You are totally right. I also checked that when I close and open PRV, Cakewalk maintains the focus on the Piano Roll and then I can't rename the clip. Thanks. 

[Milton Sica]

12 hours ago, msmcleod said:

The assignment for the current area is always shown on the right, whereas the current assignment for the Global area is always shown underneath and on the left.

What you're seeing for CTRL + R, is your "Track View" assignment on the right ( i.e. Rename Clip ), and the Global Area assignment underneath and on the left.   For CTRL + J, you're seeing the description for your "Track View" assignment to Bounce to Clip(s) on the right,  and it shows that it's unassigned in the Global area on the left.

 

Very good. I finally managed to understand this format.

However, it is well to agree that this interface deserves a better approach so that, in fact, the user can more transparently and directly understand what, where and how he is assigning a certain keyboard shortcut.

[GreenLight]

4 hours ago, Peter Hintze said:

+1

my keybindings dissapear every now and then`also. I suspect that changing the Cakewalk Version could be the reason perhaps?

I export my bindings often, to revert if i have to.

Thanks for chiming in, Peter, interesting to know there's more with the same problem.

[Toy]

I too have the shortcut randomization happen often.
Sometimes a registered "CAL file" is executed, sometimes it is not found, sometimes a previously registered CAL is executed....
I don't understand why.
I have cleared all the shortcuts and imported them, but they are still randomized.

[GreenLight]

On 8/18/2022 at 9:53 PM, Will. said:

I have had this issue in the past and spend hours with the bakers trying to fix this in the PM section. 

I've manage to fix it myself, but i'm trying to remember now how - to you help here. 😑 It's literally just a setting. 😐 

Check if your "Apply workspace to project" is ticked, right at the bottom of teh workspace dropdown menu. 

I'm trying to think now. 😣

In Preferences > keyboard shortcut TAB -- make sure "Save Changes For Next Project/Session" is ticked.

I have now checked how my Cakewalk is configured: "Save Changes for Next Session" is checked under Preferences/Keyboard shortcuts. I don't think it's ever been unchecked.

Workspaces are configured as seen below. Are you saying I should enable "Apply Workspace on Project Load" even though I'm not using workspaces? 🤔

[Will.]

16 hours ago, GreenLight said:

I have now checked how my Cakewalk is configured: "Save Changes for Next Session" is checked under Preferences/Keyboard shortcuts. I don't think it's ever been unchecked.

Workspaces are configured as seen below. Are you saying I should enable "Apply Workspace on Project Load" even though I'm not using workspaces? 🤔

Yes. Like i've said: I also dont use workspaces - never have, but apparently the default screen is a "Workspace" I was told once upon a time by one of the staff members and one "mysterious undercover" staff member.  😐 

Edited August 21, 2022 by Will.

[Starship Krupa]

I've also experienced random shortcut deletion. It's very infrequent. Also, I've had it happen more than once that I'll absolutely verify that a shortcut is not working, then I'll go into Preferences to check whether it's bound, observe that it is, then exit Preferences and the binding will suddenly be effective again.

I'm confused as to the Global vs. View binding thing, I need to sit down and sort that out.

On 8/19/2022 at 12:34 AM, msmcleod said:

The assignment for the current area is always shown on the right, whereas the current assignment for the Global area is always shown underneath and on the left.

This is the first whiff I've had of being able to assign a given key one action in one view and another action in another view. It explains why when I assigned Alt-Shift-T to "Track Manager" it only worked in Track View. In order for it to work in Console, I have to select that view and bind it again.

And then there are global bindings that should apply no matter what view you're in?

I'm confused by this, or at least how it's implemented.

When I choose Global Bindings, there are a bunch of commands in the resulting list that apply only to Track View, such as Unlink Clips, Clip Mute Toggle, some Scale Waveforms commands, multiple Arranger Track commands, Zoom to fit project horizontally, etc.

Aha! Repro! See next message.

[Starship Krupa]

With the Event List View (and maybe others, I haven't tried them all yet, but not in the Console View at least), some if not all key bindings fail to work if a view is opened in the Multidock and focus is switched to another window and back before invoking the keystroke.

Steps to repro:

(test condition is that there is no prior binding to Ctrl-Alt-E)

1. Bind Ctrl-Alt-E to Event List View/Close View
2. Open Event View (either by Alt-8 or Views/Event List)
3. before changing window focus to any other pane, press Ctrl-Alt-E.
4. Observe that Event List View closes (as expected)
5. Open Event List View again.
6. This time, click on the main window title bar to bring Track View into focus
7. Click on the Event List tab in the Multidock to bring both the Multidock window and the Event List tab to focus
8. Press Ctrl-Alt-E.
9. Observe nothing happens

Expected behavior is that the view would close whenever the Multidock and the Event View tab have focus

Actual behavior is that this fails if any other Cakewalk window is given focus and then returning focus to Event List View (if you also have Console or PRV open in Multidock and click on one of those tabs and then click on the Event List tab, Ctrl-Alt-E will also fail)

Alternate cases tested:

With other Event List commands, like binding Ctrl-Alt-O to View/Notes, and those commands also failed.

With Console View, behavior was as expected.

With Event List floating outside the Multidock behavior was as expected.

[Michal Ochedowski]

18 minutes ago, Starship Krupa said:

I've also experienced random shortcut deletion. It's very infrequent. Also, I've had it happen more than once that I'll absolutely verify that a shortcut is not working, then I'll go into Preferences to check whether it's bound, observe that it is, then exit Preferences and the binding will suddenly be effective again.

I'm glad someone else wrote the exact same scenario, which I also experienced multiple times. As I previously wrote - no logic behind this behavior.  

18 minutes ago, Starship Krupa said:

And then there are global bindings that should apply no matter what view you're in?

Not exactly. To paraphrase what David Baay wrote above, Global Bindings take priority in different scenarios. So far I only learned that when focus is on Piano Roll View, your Track View assignments won't work. Global Bindings will be the first to react to dedicated keyboard shortcuts. 

Edited August 21, 2022 by Michal Ochedowski

[GreenLight]

Ok, my aim is always to try to write forum posts that have constructive content and that are useful and interesting for the topic at hand, but...

[David Baay]

9 hours ago, Starship Krupa said:

Click on the Event List tab in the Multidock to bring both the Multidock window and the Event List tab to focus

This is where you're going wrong.  Clicking the tab in the Multidock does not focus the view. You have to click inside the view.

You can verify this by trying to cursor down the list of events after clicking on the tab. The cursor will not move because the view isn't actually focused.

[Will.]

Have any of you tried to delete your current "saved" kbn file - not the Sonar key assignments.kbn file.

Copy your current ssved keybinding file and paste it in a safe location and delete the original. Close CbB and create a clean template. Re-assign a few shortcuts, hit apply, okay and relaunch Cakewalk. Confirm if that worked. 

Edited August 21, 2022 by Will.

[Starship Krupa]

7 hours ago, David Baay said:

This is where you're going wrong.  Clicking the tab in the Multidock does not focus the view. You have to click inside the view.

You are correct in that clicking inside the Event List does restore expected keystroke behavior.

I respectfully submit that it ain't me that's "going wrong" here. 😄 It would violate Windows' rules about "focus." So, if I have clicked away to the main window, then back to the Event List tab in the MD, which Cakewalk window does have focus? It's not the Main one, because its title bar has gone pale.

Also, why does it work with Console and not Event List? I don't have to click inside Console to get keystrokes to work.

I found another case where it works as expected: if I have Event List in the Multidock, click away to bring the main window/Track View into focus, then come back to the Multidock, click on the Console tab, then click on the Event List tab, Event List-specific keystrokes start working again. This is all without clicking inside the window.

These things suggest that what you say about clicking on the tab not giving focus is not the whole story. If that were the case, then my clicking on the tab is not supposed to give Event List focus, therefore it's unexpected behavior.

Something is broken among all this. Expected behavior, to me, is that if the dock has focus, and the view's tab is in the front, then that view has focus, and should accept keystrokes.

Whatever, bug report submitted.

Edited August 22, 2022 by Starship Krupa