Tool Keyboard shortcuts won't stick?

Hello. I’ve made a video of the problem.

Sorry it’s fuzzy but What I’m doing there is -

1)starting renoise
2)Assigning a bind to a tool that will rename track (shortcut wizard)
3)renaming the track
4)closing renoise (which would save the assigned bind)
5)restarting renoise
6)trying to use the bind
7)finding that the bind is not there

First noticed this this morning, after restarting my system. Last night I updated a tool that assigns multiple shortcuts. The problem actually manifested as having ALL my tool based shortcuts reset to zero. None of them had any bindings any more. Which is why I pulled the tool out of public, and which is why I’m suspecting this tool is doing something it’s not supposed to.

This is my suspect - handle with care…?
3913 com.kmaki.Shortcutwizard_Rns280_V0.2.xrnx

I installed your tool to give it a quick test, but did not look very deeply into it yet. I did experience the same problem you’ve described with the rename binding being ‘forgotten’, but my other tool bindings remained safe and untouched, so I think you can relax a bit there.

OK. Whew. But something’s obviously wrong. Could the tool keyboard shortcut wipeout possibly happen if one loads this tool, and it bugs out (with say… Referencing to renoise.song() when there is none loaded yet…). Maybe it would interrupt the loading of other tools and/or their shortcuts, then somehow…? Wild speculation with no basis whatever, but i really did experience that so I’m trying to come up with some explanations…

I noticed this too. It usually happens while I develop a tool.
If I bind a function belonging to my tool to a key and then reload
all the tools, and on that reload there is a syntax error in the tool I develop,
then the keybinding is removed and I have to rebind it all again.

That is quite bothering me, as it is usually that function that I bound
that I want to test :slight_smile:

Hey, that’s actually another ‘glitch’ I’ve noticed, but failed to report because it’s A)something I’ve gotten used to and B ) something I assumed to be part of the bleeding edge tool developer’s fate. But now that you mention it, yes, whenever a specific error hits, the keybind(s) for the tool in development is(are) lost. About the ‘specific’; I’m not sure myself what it is.

The problem I’m having, I suspect, has similar origins. Something about loading the tools and generating shortcuts…

In my experience the only times shortcut settings disappeared, was when I change the shortcut name/description/“path”.

They also disappear when there’s some kind of error with the tool, which causes it to not load… doesn’t happen in many situations, but kind of annoying when it does, ie. when you just make a few changes to a script or something, but you made one little mistake - boom, shortcuts all gone.

I see there’s a small horde of tool keyboard shortcut related glithces. Just to clarify a bit, the ones that have appeared in this thread (separate as issues) are:

-Tool kb shortcuts unbind when changing the bind description in lua code (unfortunate, but unavoidable afaik)

-Tool A kb shortcuts unbind when a tool A fails to load properly due to lua error

-shortcut wizard’s keyboard shorcuts won’t stick at all (issue started when moving the shortct creating into a separate .lua file which loads only after renoise.song() document has been loaded)

-SOMETHING COULD MAYBE POSSIBLY PERHAPS under special conditions erase shortcuts in every tool. speculation, pure. Unconfirmed.

Doesn’t happen in many situations??? Happens every single time I try and load a tool and it has a error and thus doesn’t load in the shortcuts to the Renoise preferences. What else do you expect it to do? Populate the preferences with shortcuts for a tool it has disabled as it wouldn’t load?

I expect it to not forget shortcuts for a tool that does not compile. I don’t say anything about
non-existent tools, but for those that are there and just have some syntax problem the shortcuts
should somehow be preserved until the next reload of the tools.

Alternatively make it possible to assign default-shortcuts for a tool’s key actions or make it
possible to reload my key assignments without navigating through 3-5 dialogs until I reassigned them.

I guess it’s not a big deal for the “normal” Renoise user, who doesn’t develop any tools themself
so I will probably manage to live with this, as other features are more important.

Renoise only ever reads the tool until it reaches the first error as far as I can tell. It finds an error, disables the tool, sends a message to the user and does not try and work out what the rest of the tool after the error should have been. As keybinding are usually at the bottom they are not going to be read if Renoise finds an error before them. So it could think the shortcuts have been removed, as it may see it as the tool ending where it meets the error.

There are a couple of ways this could probably be got around though. One would be a new MissingShortcuts.xml (similar to the CachedVST.xml I guess) where and keybinding and their shortcuts name (EG. Global|Tools|Nibbles) could be saved. On created of a “new” shortcut (from a newly install, re-enabled or rescanned/edited tool) the name could be checked against this list and the previous binding added (if not used elsewhere. Otherwise I guess it’s best skipped with maybe a message to the user.)

Or a more complicated method might be possible, where they are never removed from the list but only greyed out and unchanged on an error being found in a tool, or it being disabled by the user.

I’ve never seen Renoise lose keybinds because of a faulty main.lua… Of course at that point in time it won’t be visible in the Prefs but when you fix the bug, reload tools, it should come back.

You have to Reload All Tools but it does every time. Even just Disabling a tool, reloading tools, re-enabling and reloading them will clear all shortcuts. Obviously a lot of errors will be caught before you reload the tools but some slip through this net.

Dis/Enabling auto reloads. But you are right. Never saw this as a bug though, and I must admit I haven’t tried KMakis kbshortcuttool yet.

Neither did I. But I can see it as a worthwhile feature request to change it. Maybe with a hidden setting in the preferences.xml

Any progress with this one? I’m still experiencing the ‘non-stickiness’ of Shortcut Wizard shortcuts. A great number of my most used shortcuts are based on this beast. And a Shortcut Wizard with no Shortcuts is just a… Wizard. With no shortcuts.

Or should I try some alternative approach for now? I broke this when trying to be smart and loading the functions that reference to renoise.song() only after one is succesfully loaded…

Just to confirm/clarify the issue - 4004 com.kmaki.Shortcut_tester_Rns280_V1.xrnx
a dummy tool that defines four shortcuts for functions to display a message in the status bar.

(Global:Tools:Shortcut tester ONE, … TWO, … THREE, …FOUR)

First one is defined “normally” in a main.lua
Second is defined via a require, from an external file, loaded “instantly”
Third is defined in main.lua, but only after the renoise.song is loaded
Fourth is defined via a require, after renoise.song is loaded

Binds three and four do not stick between sessions.

I’ve got ideas to divert this, and it shouldn’t be too hard. But I think this behaviour should be either documented or fixed…

So your idea is to have a tool that makes and removes kb shortcuts according to what’s in the song info?
I mean, I just can’t figure out why you need this functionality… Most of the time you can be sure that shortcuts only get pressed once a song is fully loaded, so, just read renoise.song() in the function and everything is ok, no?

Some other thing, there was a com.renoise.MoreShortcuts tool that I used to use, I think I’ve used it in 2.8 too, that makes shortcuts every upstart of renoise, to have keybinds for every (!) effect in the system (VST/Native). Maybe you can find something useful in that code.

TLDR; Yes, in Renoise scripting, keybindings are probably more static than you wish for. But I still can’t see why it would need to be any other way. Not that my ability to see matters to anyone in the dev team or anything :P I’m just saying. I’m the developer of the highest count of public tools though.

Absolutely! As I mentioned, it’s most probably very easy to divert with an alternative approach to this. I just was surprised when things did not work as I supposed they would work. I think it’s more a case of documenting this properly, if it’s not a simple matter to fix.

Should probably check that out! Anyways I had my dabbles with dynamic shortcuts before, though, with a project that became a bit too ovewrwhelming for me to handle… :P Had some issue with shortcuts there too and IIRC it was fixed in 2.8.1. As it seems, the keyboard shortcut section of the API is still somewhat murky though.