Maybe there is a good reason to not do this, but I would find it good if tools would be in the side panel on the right instead of windows, to better integrate them into Renoise. I would imagine the Panel would be scrollable depending on how many tools you have loaded and it would be able to pin tools to the top, and have a launch in window button if they need that.
I would agree if a tool can only add one button (would mostly be used to show its interface). Otherwise you will have scripters spamming the section with various buttons.
Main reason I would wish to see them in a panel is that the editor won’t lose focus. Right now if you use a tool like ChordGun, once you clicked a chord you can’t hit up or down to move in the editor because the tool window is in focus and so you have to click into the editor window every time to gain focus again, same with xstream and other tools.
If they would live in a panel, it would make tools like that feel much more integrated and accessible.
renoise.tool():add_toolbar_entry(toolbar_entry_definition_table)
I would suggest each tool gets one button, which can be a menu of whatever depth. Otherwise, cesspit.
Huh, why only one button then? If a tool would spam the toolbar, don’t use it. Would be nice to able to add other controls to the adv. edit section.
1 Like
I think that the best idea here is not to move a tool in a panel integrated in Renoise, but rather to have an dedicated entire panel to load in it several window tools (to be chosen by the user).
The best integrated solution would be a “new tool tab” under the pattern editor, with a frame that occupies the same area as the DSP Chain, with the ability to load several “tool frames” without any relationship. Each frame should have the ability to use the keyboard commands of the tool itself or always use Renoise commands (with a checkbox maybe in each frame; in fact the API should offer that option).
(Edit: Better above the pattern editor)
This new area would give freedom to tool programers (with certain size restrictions), and full integration. If there is a tool that returns problems, simply do not use it. If you want a larger window, use a floating window.
If the user wants to use their preferred window tools, display the “tools tab”. Unpinning or anchoring them to the panel would be another feature.
Integration is important and I am sure there would be interesting and “more cared and maintained” tools.
Even maybe the tab should be on the top right, and instead of placing the panel below, place it above. It is appropriate that it should be possible to display the panel in any case, whether the pattern editor is used or if any tab of the instrument editor is used.
The “advanced pattern editor operations” panel would only be displayed if there is the pattern editor (which seems too limited for such an important feature).
1 Like
Why would it be best to have it under the pattern editor? What if you have the mixer detached and a tool that affects the mixer and mixing aspects of a song? It wouldn’t make much sense having such a tool stuck under the pattern editor. And some other tool may reside more naturally in the sample editor, which btw is also detachable.
I could see there being some sense to having a tool tab OTOH (like the edit/mix/sampler/plugin/midi tabs). But then again, is it really worth the effort…
As I wrote the comment I edited it, rectifying the position “above” the pattern editor (below it would only appear if there is the pattern editor, which it is not very appropriate).
I think it would be worth the effort, if it is well designed. It would be a good way to get closer to adding “more integrated” or less invasive capabilities (such as some floating windows) and using more modular frames, integrated in a fixed panel, optional.
I’ve had another Idea, that at least I would find quit great when working with the pattern editor. Since the Modules in the A&E Column are able to collapse, why not let users script and load mini Tools here that are all about doing transformation on the pattern editor or as raul suggested mini controller frames that can access a tools features:
I have a feeling this would be too much work to implement, since it’s a whole new concept of working with tools or would need the introduction of a different kind of tool - something like xstream that primarily deals with changing the pattern editor that lives in the A&E panel (but maybe easier to script than a regular tool?), but here’s my nonsensical pseudo mock-up
1 Like
That doesn’t make any difference to the objection.
Anyway, it isn’t possible to design some kind of tool panel(s) very well and consistent without putting a lot of restrictions on it. Ultimately it would result in pretty much what we already have, namely the context menus. It’s either that, or something complex that caters to this or that very specific need. That’s the scale we’re dealing with, and I’d be surprised if “the team” would put a lot of effort on the latter.
“Tool buttons” (expand) here and there (like the suggestion above) seems most viable, but still need a lot of restrictions. And it doesn’t seem likely to happen, no.
@joule I don’t see it as complex, nor would it even be necessary to restrict. Simply, the tool programmer would have an accessible area to present his tool (the equivalent of a window tool), within a panel with limited width and height (or not). It will be your problem, as a programmer, if you adjust to the available area or program an inadequate GUI (especially the height). The panel, all you have to do is be able to stack frames horizontally, and allow you to design anything that can be done with the API.
Whether it is implemented or not, that is another issue. But I think only a specific area (as above the pattern editor) would be the most appropriate. Even the supposed top panel of tools could have a variable height.
That would be complex. Renoise has a “strategic” cast on controls in many parts of its GUI, adjusted in a certain way. Invading certain spaces by adding “extra buttons” would be too invasive. And it would also be very limited. Why only buttons?
A single fixed panel would be much more “controllable.” But ok, we’re just commenting. We both know that this will never develop.