Tool idea: Toolbox tool

I’m throwing this out to see if there is any love or hate. I’m convinced that it’s a superb idea, but I could be wrong

“Tools” as presets in a tool. I think this would be a good idea. It would be like a swiss army knife with the ability of importing new functionality via XML (or pasting code). This would eliminate some of the need for installing lots of small helpers tools separately. Instead, gather these in one tool and select the tool you want to use in a popup list.

It would also be a sandbox / rapid development / unified platform / meta / WYSIWYG tool editor.

Basically the sandboxing could allow anything that a normal tool does, BUT it would probably be more suited to “one-shot” or “action” tools with simple GUI:s, rather than tools that are “patches” or very frequently used shortcuts.

Any thoughts or ideas?

(PS. I’ve thought about the technical aspects of it all, and the only thing you’d have to do differently from coding a normal tool, is to use a simple wrapper for observables. The toolbox would then be able to handle these behind the scenes to avoid any errors when switching preset/tool.)

A simple visualization to give you a feeling:
7482

It’s an intellectually stimulating challenge to make such a ‘meta-tool’, but you’d need to convince everyone that what you offer is ‘better’.

And this is not easy - I prefer tools that enjoy deep integration - context menu, shortcuts, MIDI mappings, whatever it takes. So your ‘launcher’ would need to facilitate these things before I would consider using it.

Instead, I would recommend that you choose a particular approach, and focus on that with laser intensity. For example, what about a toolbox that could replace the Advanced Edit panel? It would be very clear what the tool does (working on the selected ‘scope’, selection in pattern, column in song, etc.), and the extent of it’s functionality (do something with the pattern and automation).

Then, as a script author, I would no longer have to code the surrounding GUI (the selection of the scope, assigning key-mappings etc.). This is probably 50% of the work being done for me already. Furthermore, you could provide methods for iterating through those scopes, and now I’m having to do even less coding. Alright, you got my attention!

As a user, it would also be clear what it does. It kind of looks like the AE panel, and it kind of works like it. But with more bells and whistles.

Thanks! Well, the initial main “USP” for this idea was to provide a WYSIWYG live coding environment when prototyping small tools (including GUI - that could be returned by a build_gui function in the environment table). My experience from using VBSandbox is that this really speeds things up (for an avarage scripter, at least). This is quite similar, but more general.

It was only later that I thought it could also become a “real tool” in its own right, with this toolbox idea. That might be overkill, yeah.

It’s quite simple to make this tool btw. The only thing that I lack experience with is user preferences (profiles?). I looked at your classes but wasn’t sure on the teminology or how to implement them, and what kind of structure they implied.

Ok, I consider myself still a novice with this LUA and Renoise API.But I think any “unifying” type tool is a great alternative.Personally, I do not really like having to include several “tools” that are small patches here and there. I like a tool that unifies the most used by me.So I go into something that is more personal.

What I would like is a simple tool, with several tabs and sub-tabs that allow you to do virtually everything you need that Renoise does not offer.But that’s a huge job.

However, any tool that helps build other tools could be positive for the community. Any newbie has to face learning the API documentation.If there was a tool that would unify the entire API and could show GUI examples along with the exact code used for this GUI and the corresponding functions, it would be a bestial tool.

For example. I want a vaulebox that controls in real time the “step length”. Ok,The gui is like this, and code and function as well.A fairly complete tool that shows how to build parts of tools. The code shown can be copied and pasted into another tool.This same tool could contain all the code of the available API, and a simple search engine, to locate code and a clear index and good order.I think this could be built “a tool to build tools”.

In the documentation there are some examples of how to build small things. But it is very poor and is scattered.

I just wanted to comment on this.

…

This would eliminate some of the need for installing lots of small helpers tools separately.

…

As long as the GUI is simple to understand.That implies that the tool must be very intuitive. Otherwise, only expert programmers will use it.On the other hand, a tool that makes “bridge” can be a little uncomfortable.I guess people want it all at a click of a mouse, not having to look in a drop-down list. The speed.

Any development of this topic can be useful. But it must be understandable by new people. But always the same ones who create/use the tools.At the end of the road, I think we all want tools for speed in the composition.The same would happen with a tool to create tools. How to create a tool faster? Ok, here you have this support tool, do not miss out on the documentation, here you have practical examples that work.

Yes, a GUI-builder would be great. And you’re pretty close to having made such a thing already.

The only thing that I lack experience with is user preferences (profiles?). I looked at your classes but wasn’t sure on the teminology or how to implement them, and what kind of structure they implied.

I’ve dabbled with both XML (Duplex - makes sense for controlmaps, but otherwise a bloated format) and .json (vLib, but too much focused on machine-readability - it’s tricky to e.g. add comments).
So lua is the better choice, I would say.

Using cLib to serialize, unserialize andsandbox things, it shouldn’t be too much work to implement some kind of import/export.

I like a tool that unifies the most used by me.So I go into something that is more personal.

Which is also why you would most likely not have the need for an overly “generic” tool, but rather make something deeply customized.

I would have a hard time imagining the GT-Colors tool working within the context of what joule suggested