This is a wildish proof-of-concept -type thing I call OmniKeys. It didn’t quite seem fit to place it in the tool announcement forum just yet so I’ll put this out here.

----The problem: Tools don’t have customization options for their keyboard shortcuts.
------It’s a problem because: I want (and sometimes NEED) to customize the hard-coded shortcuts.
--------The cause: Unnecessarily hard to program
-----------The solution: A pre-made class to make that task simple (& standardized across tools)

Now I don’t think this is working perfect just yet, but here’s a dummy tool demonstrating what COULD be done with a properly designed class.
3721 com.kmaki.Dummyguiforomnikeyclass_Rns280_V0.1.xrnx

The actual tool is just a dummy gui that has some preprogrammed keyboard shortcuts the gui catches. OK. Now, the punchline is that the shortcuts are (hopefully) customizable by the user. The customization, which is admittedly quite clunky right now, is done through a dedicated gui.

To test, summon the actual tool gui from the tools menu entry “DummyGUIforOmniKeyClass”. It just displays uppercase or lowercase random greetings in the textfield. Default keys are “t”, “r”, “shift + t”, “shift + r”.

To customize the keys, summon the customization gui from under the OmniKeys entry in the tools menu. Select the keyboard shortcut you want to customize and modify the keyboard shortcut by editing the textfields under the buttons. After editing, the new shortcuts are immediately active.
(((alpha warnings: only use lowercase letters. only use renoise-lua-api acceptable modifier names and modifier combinations. only use renoise-lua-api acceptable key names and key combinations. disclaimer: too lazy to test and post accepted combinations. maybe will post some here later. hey. it’s friday. c’mon.)))

AND If all goes well, your customized tool shortcuts are written in the tool preferences.xml, under a dedicated xml-node, et voila: customizable per-tool GUI keyboard shortcuts for the masses.

I’m not encouraging anyone to actually use this just yet, but just to describe the usage: To use this in a tool the developer needs the omnikeys.lua -file, which includes the OmniKeysHandler -class.

To generate a dialog which is handled by an OmniKeysHandler -keyhandler, the developer must instantiate an OmniKeysHandler object (e.g. my_omnikeys), and assign my_omnikeys.keyhandler as the dialog’s keyhandler argument, when doing a

When generating the OmniKeysHandler -object the developer defines xml-valid names (for preferences storing) for the different functions that are to be triggered by key presses catched by the dialog, display names to be used in the customization gui, and the functions to be triggered on key presses. Et maybe cetera. And that’s mainly it. The class in turn handles all of the preferences storing, and customization gui generation for the tool.

A.) Whaddya think? Is there potential in something like this?
B.) Anybody want to do this proper?
C.) Should something like this (only working and better) be included ‘natively’ in the xrnx package, actually?

Hey I’m just giving you a well deserved +1 for looking into this, but remind me to look at this over the weekend! Your idea seems really promising.

Thanks! I think the idea is solid, but sadly it still lacks a good implementation… This here is just a quick stuff-things-together-until-it-kinda-works -piece of code. I actually made a version of the InstruMixer with this baby. Which is why I can say this does not work. :D for some reason it does not work nicely with the preferences.xml -file. Can’t figure out what I’m doing differently there, but it does not restore the xml-saved keys, but resets back to defaults… :(

Does the xml file get created though?

Yep. In “lab conditions” at least. Keeping the file open in Vim, when I exit renoise the values get updated (or this is how I recall it…) and when I open renoise, the values won’t stick, so it resets the defaults. Hmm.

If you change preferences,also take care they are saved: Only binding and setting doesn’t cut the cake here…

 midi_record_mode = true --Midi record mode should always be disabled  
 selected_device = value  

Whoa, there! I thought the whole preferences-thing was handled automatically by renoise? I must’ve missed something? What’s this save_as business about?