Possibility of registers a keyboard command to start the tool

I think I asked this question months ago and it was not very clear to me. A week ago I saw a tool, which I can not find now, which registered a keyboard command that worked in Renoise, not in the tool.

My question is: Is it possible to register with an XXX tool an ALT + F1 command (the “New assignement” in Preferences/Keys), to then invoke the XXX tool when it is closed?

I use:

renoise.tool():add_keybinding {
  name = "Global:Tools:VPD",
  invoke = function() dialog_main() end
}

This not exist? :

renoise.tool():add_keybinding {
  name = "Global:Tools:VPD",
  invoke = function() dialog_main() end
  assignement = "ALT + F1" --<----------------------- THIS???
}

Any way to save this assignment through the tool?This way you prevent the user from having to enter Preferences / keys to register the command manually.

This seems so obvious to me that it surprises me if it is not possible…

What would be the same, a function that changes the empty value of assignement by a text ( “ALT + F1” ).Is there any way to do this?

No. It’s up to the user to select the keyboard assignment. Otherwise I guess we could have a bit too much fun overriding other shortcuts…

No. It’s up to the user to select the keyboard assignment. Otherwise I guess we could have a bit too much fun overriding other shortcuts…

I think it’s a shame. The creator of the tool already knows which commands he could use, to avoid overlaps. Moreover, it would be easy to avoid. If Renoise already uses this command, the tool can not overwrite it, and that’s it.

At least that way, the creator of the tool has more capacity over keyboard commands. This would be the scheme:

renoise.tool():add_keybinding {
  name = "the_namel:the_name2:the_name3",
  key = "the_command_keyboard, ie: CTRL + ALT + F1" <---include!
  invoke = the_function()
}

key = “the_command_keyboard, i.e.: CTRL + ALT + F1” (if the command is already in use (or poorly written) do not overwrite!)

key, assignement, command… no matter the name, “key” is shorter :lol:.

A week ago I saw a tool, which I can not find now, which registered a keyboard command that worked in Renoise, not in the tool.

Question, which tool was it, please? And are you absolutely sure it registered a keyboard command into KeyBindings.xml?

Question, which tool was it, please? And are you absolutely sure it registered a keyboard command into KeyBindings.xml?

I’m not sure. I think I had a confusion. There would have to be some way to have access to be able to write to the external xml file to register it. The API does not have anything to do it. I would like the programmer to have control, also of the command to launch the specific tool. You just have to make sure you do not use a command already used by Renoise.So, then with the command you can open and also close the tool.

I suppose that it is something complicated and for that reason it is necessary that the user registers the command manually.In addition, you also have to deal with the installed tools, if this feature is possible.There could even be a universal command, and a popup to choose the tool you want to launch, all under the hood of Renoise. This could be interesting.

When displaying your tool’s GUI/dialog, you may optionally provide a key handler function to intercept keyboard events and implement your own custom bindings that way.

Such bindings will of course be hard-coded (unless you implement your own key binding editor, too!) and will only function while your GUI is open and focused, but they can still be incredibly powerful.

For more info: Renoise.ViewBuilder.API.lua

When it comes to implementing “proper” key bindings, your tool may of course register them within Renoise, but we definitely do not allow tools to automatically assign their own defaults and potentially ruin a user’s config in the process.

Even if the tool dev was careful to check for existing keys, and if Renoise prevented existing mappings from being overwritten by the tool, this is simply a rather ugly and hackish approach to the whole situation.

A tool should never have the power to mess with your personal Renoise config.

I’m not sure. I think I had a confusion. There would have to be some way to have access to be able to write to the external xml file to register it. The API does not have anything to do it. I would like the programmer to have control, also of the command to launch the specific tool. You just have to make sure you do not use a command already used by Renoise.So, then with the command you can open and also close the tool.

I suppose that it is something complicated and for that reason it is necessary that the user registers the command manually.In addition, you also have to deal with the installed tools, if this feature is possible.There could even be a universal command, and a popup to choose the tool you want to launch, all under the hood of Renoise. This could be interesting.

I get what you’re after. For me, PakettiR3 would definitely benefit from going “here’s the shortcuts you should use, do you want to overwrite, are you sure, do you want to revert back to non-paketti shortcuts?”. But I wouldn’t want to have to code the interface myself. I would rather provide them as “preferred shortcuts”. but then that would have to offer the possibility of defining OSX/Windows shortcuts too, and they would have to be different. I could see add_keybinding having a preferred_shortcut, but while I understand that it could be made, I’m not sure if Renoise Devs really want to do that.

When displaying your tool’s GUI/dialog, you may optionally provide a key handler function to intercept keyboard events and implement your own custom bindings that way.

Such bindings will of course be hard-coded (unless you implement your own key binding editor, too!) and will only function while your GUI is open and focused, but they can still be incredibly powerful.

For more info: Renoise.ViewBuilder.API.lua
A tool should never have the power to mess with your personal Renoise config.

Wow, that does seem interesting. But I guess Renoise View Presets do not (or do they?) offer a method of opening a specific script by default? i realize that “renoise app starts” can be mapped to opening a specific script GUI or launching a function, and that would be pretty neat. but for me, it’s not a case of wanting to override shortcuts, i can perfectly well manouver around the shortcuts themselves and map stuff that isn’t set up, it’s more a case of having more API functions. I could see how someone might want them to all work in a specific way, but even then they’d have to code the functions themselves for the tool…

I have thought a thousand times how to make it easier, or even elegant. But I do not know exactly how it could be done under Renoise’s hood.I refer to the fact of installing a tool and that the user does not have to make the step of creating a specific command to be able to throw the window tool.

Could not there be something predefined that programmers could use?In the end it is not about having the power of the programmer, but about preventing the user who installs the tool from having to go through a procedure to register a command, because I consider it somewhat uncomfortable.Install the tool and use it.Do not worry about setting up a keyboard command to avoid conflicts.

The current form is quite simple and secure, which you can do after installing the tool.