V5.12 Linux short key problems

Hi All, with Ardour 4.7 there was the problem that you could change short key codes by accident. That is fixed with Ardour 5.xx.
Now you are getting a warning when you try to assign a key that is already used in the same section (e.g. try to assign Global->Transport->StartRecording = “Space”. It’s already used for Global->Transport->Start/Stop). But when you try to use a key (e.g. “1” for StartRecording) that is used in another section (for “1” is that Editor->Zoom Focus Next) there is no warning and the key seems to be assigned but won’t work as desired.
Maybe that could be mentioned in the manual, because i had to find out that behavior by try and error.
And now question:
I changed some short keys in 4.7 to control recording with a remote control from the bargain bin and it worked perfectly. I used it for some live recordings. With 5.12 some keys on the remote don’t work anymore. The others have new names.
When I saw with Ardour4.7 the remote rewind key as XF86Audiorewind I see now PreviousCandidate. I don’t care for the names, but i would like to know how the interpretation of the keys have changed and if i could fix my remote some how

We don’t use “PreviousCandidate” in our key bindings. I suggest you try “Reset to Defaults” in the key binding editor.

It is possible that your system is generating “PreviousCandidate” when you press that key.

@paul: Thanks for the quick answer. I have reset to defaults already. I checked before whether this behavior comes from the system. But with the terminal program xev (Linux) you can see that the system is not generating PreviousCandidate but XF86AudioRewind
But the names don’t matter. But with Ardour V5.xx the key codes(scan codes) seem to interpreted different from the Version 4.7. PreviousCandidate is only an example of changed key interpretations. The key XF86AudioRecord vanished in the V5.xx. When i use Ardour 4.7 again with the same Linux PC. Everything works as before. That is the reason i wondered what happened.

As I mentioned, we do not use the name “PreviousCandidate” in any of our files. It just isn’t a key-name that we know about or use. We also do not use any of the XF86* key names either. So I do not know where these key names are coming from in your bindings.

What happens when you reset to the defaults (in Ardour)?

Hi Paul, it does not make any sense to sweat any longer over this issue. It’s something about the key mapping in Linux, which seems to be i little bit different in V5.12. When the kernel sends some keycodes, there are layers which assigns some “keysyms”. I 've tried to understand it, (all about xve, xmodmap, showkey -k ) but all the information in the internet is either outdated or not valid for my linux mint. The keycode 176 (shown with xev) has the keysym 0x1008ff3e with the textXF86AudioRewind. Somewhere in the internet I found a Xmodmap table with PreviousCandidate and the keysym 0xff3e. The new Ardour analyses only 16bit of the keysym. I have not understand even the basics of the keycode mapping, therefore I can not provide any ideas or recomandations, except to stop further examinations.
Thanks for Your help again

Ardour does not have the capacity to change the keycodes generated on your Linux system.

Ardour does use specific key names in its key bindings files, but the defaults do NOT include any of the XF86* keys, or any key with the name PreviousCandidate.

You are working too hard to understand this.

Do you have a file whose name ends in .keys within ~/.config/ardour5 ? Where did you get Ardour from?

Hi Paul, Yes I have a .keys in~config/ardour5. And i bought and downloaded it from the ardour download page.(Transaction code:8MU36935JF9931134). I never meant that Ardour changes any keys or maps any keys. Maybe i described my problems a bit ambiguous. The default key bindings were there when i started Ardour 4.7 (month later 5.12) the first time. When i did reset( is it reseted ?) the key bindings to default, they worked as before. But with 4.7 I went to keyboard shortcuts with Alt-K and changed some keys (eg. StartRecord) by pressing the correlating keys on my remote. In the shortcut menu the same names showed up as in a terminal window using the program xev (eg: XF86AudioRewind. And the changed short cuts worked. Then I upgraded to 5.12 not least to being up to date when i post some questions. Then tried my remote again and realized the changed key bindings were gone. I went to keyboard shortcuts with Alt-K and changed the keys again (eg. StartRecord) by pressing the correlating keys on my remote. That’s when in the shortcut menu those strange names like PreviousCandidateappeared and other changed keys did not work any more. And this is reversible. ( using 4.7 everything works as before, using 5.12 not). Therefore Ardour 5.12 must interpret the key bindings respectively the changes different. The XF86*keys are in my Linux system, and as long as Ardour used the keycodes (eg.:165) or the keysym names (XF86AudioRewind) my custom keys worked. But when interpreting the keysym numbers eg:0x1008ff3e (for XF86AudioRewind) ardour5.12 used only the lower 16 bit (resulting in the misterious PreviousCanditate = 0xffe). Those names assigned to the keysym numbers are somewhere in the linux keyboard tables. Ardour 5.12 does not change anything, but uses different information (scancodes, keycodes or what ever) as 4.7 to assign actions to shortcut keys .
And I would like to know how it is different ( getting rid of X-server dependencies maybe). And I have to admit, that it’s nagging me, that the remote does not work anymore
Thanks for your concern

Hi Andreas.
Stripping the upper bits in the keycode scanning seems to be a bug and you should file it in the Bug Tracker.

Except that Ardour doesn’t do this.

Where did you get Ardour from? If not ardour.org, please try a free/demo build frm ardour.org and report back on whether or not the behaviour still exists there.

Paul, he bought it from here, as seen at the top of his previous post.

Why is it impossible that there’s a bug in recent Ardour versions that strips the upper bit of the scan code?
His remote control sends keycode 0x1008ff3e and he wants to map it to Rewind. Ardour5 thinks it’s 0x0000ff3e, suggesting that there’s something masking the upper bits.

Because those kinds of changes would be in GTK, not Ardour, and we haven’t changed the version of GTK that we use.

Andreas does say that “The key vanished in the V5.xx. When i use Ardour 4.7 again with the same Linux PC. Everything works as before”.
So it seems that when he uses v5 he gets a stripped keycode and when he switches to v4.7 it’s not stripped.

I also see that at least one key mask has been added after v5 was released, GDK_SUPER_MASK in libs/gtkmm2ext/keyboard.cc, if that could have anything to do with this.

Andreas, can you assign that remote button to something else in v4.7 and verify that it still gets the correct 0x1008ff3e, XF86AudioRewind code.
You can also take the working Rewind entry from your ~/.config/ardour4/ keyfile and insert it into the ~/.config/ardour5/ file and see what happens.

Peder, thanks for the reminder that we do, in fact, do some operations on keyboard masks. It is possible that could have some effect.

Hi Peder , Paul
I tried, and edited the ardour.keys file in ~config/ardour5/. I didn’t crash ardour, but the short curt key page entries stay the same. Therefore the masking will be done not only when keys are changed, but also while using Ardour. As soon as you change some keys with the (ALT-K) short cut page again, the manually edited entries in the ardour.keys files are changed back or are vanished.
I will have a look into libs/gtkmm2ext/keyboard.cc. Meanwhile i tried a different approach. With the help of the program “evrouter” i could map all keys to the default keys. But maybe the ardour guys think it’s worth to have another look to the key bindings rules in ardour5.

Short cut keys again
Hi again,
still the short key issue bugs me. Not only all of the multimedia keys (XF86Audioxxx) on a keyboard won’t work as short cuts, but simple keys won’t react sometimes as expected.
I started with a 5.12 demo version with Windows 10 to test if the multimedia key would work with windows. OK, my remote didn’t work at all (not a surprise without drivers). The multimedia keys on my standard usb keyboard won’t work either. I am not familiar with the windows key mapping, therefore i haven’t examine further. When I looked into the standard ardour shortcut key binding, I saw “start record” bound to the key “1”. (This binding is default in windows 10, but the behavior described as follows is the same in Linux). When I opened the editor window to record some tracks, the key “1” switched the zoom focus instead. This is not changeable (Or I’m to dump to do it). I tried the “3”, just to test it. Even when the short cut key window shows the “1” successfully bound to “start_record”, this key keeps being bound to “snap/grid units”. The problem I see here is that you get pretty confused. Some keys work, some pretend to, some won’t. Especially the multimedia keys I used in ardour 4.7, some of them pretend to be bound. Only for Linux E.g.: When I bind the rewind function to the multimedia key “X86FAudioRewind”(it’s the keysym name by xorg with the hex number 0x1008FF3E ) Ardour cuts the upper 16 bits and binds the keysym number 0xff3e(with the name “PreviousCandidate”) to “rewind”. So far so good. I don’t care for names. But when you use this “X86FAudioRewind” key ardour seems to interpret the whole number “0x1008FF3E” and of course finds no binding. OK, i am looking through the Linux glasses, but it must be allowed to mention some confusing things here. I wasted a lot of time searching what i did wrong this time. Eventually I looked for a possibility to remove(not reset) all key bindings in one action. Is that possible somehow ?

When I looked into the standard ardour shortcut key binding, I saw "start record" bound to the key "1".

where were you looking?

Upthread contains a discussion of a likely issue with some keys that have “high bits” set in their keycodes.

There is no option to remove key bindings from within Ardour. They are just a text file however, which you can edit in a text editor.

where were you looking? (This binding is default in windows 10)
The key binding "1" to Start record was in the Windows 10 Demo Version. I downloaded it to compare the Linux and the Windows version


I believe the question was intended, “Where did you look to see that the record action was bound to key ‘1’”.

Meaning, did you look at the associated text file, did you look and see ‘1’ in the menus next to the transport action, etc.?


I tested again and realized that a key shortcut reset requires a restart of Ardour at least in Windows. When I tested in Windows and Linux with and without the remote, maybe I switched the record binding by mistake and got confused when the reset didn’t switched the binding back. As you can see from my posts, Ardour and I, we understand each other not so easily . Actually, I want to work with Ardour and not on Ardour. Meanwhile I made my own key bindings with the help of evrouter.