Yes, the APIs themselves are closed. Which is good, because if they changed too much then a lot of tools would constantly break.
Even though the API has not seen many changes from 3.0 to 3.1, the transition from 2.7 > 2.8 > 3.0 required changes to many tools.You can call it vScrollbar
But IMHO, you’re just pointing out what is potentially nice about using something like vLib:
- You don’t have to wait for Renoise to implement feature XYZ (assuming of course that the feature can be implemented with scripting).
- When/if the feature arrives, the vLib framework can replace it’s custom implementation with the native one.
- Usually without any need to change the source code of the tool itself, as vLib is closely modelled after the viewbuilder API
That’s usually the point with frameworks - that they abstract away the implementation details.
As for your checkbox suggestion, vLib features the “vToggleButton” which largely works like you suggest
You can see it working by cloning the vLib demo from githubI’m the one managing Renoise API suggestions, btw. Do you know of the API wishlist?
https://forum.renoise.com/t/the-api-wishlist-thread/29285
Wow. I still think that if one thing can be improved, there is no need to look at third-party tools. They will fix, and not slow Renoise’s development.I do not care if my tool is going to break in the future. I’ll sort it out.However, some things may be included for being new, and therefore, they do not break anything previous, because they are new, never used before.
I think vLIb, cLIb etc. is too advanced for most users, those who already understand enough of the code.The problem is not the code itself. It is read and can be studied. But rather its implementation in other tools.For example, a simple tool that weighs 40KB, would have to load more than half a MB of code libraries, in addition to adjusting the code of tool.Otherwise, it touches studying pieces and jumping from side to side to implement. However, they are a great help, you can find some very interesting solutions, and fix strange things that should not happen.
For example, in my case, I look for specific functions, the minimum necessary to optimize the code, and not add unnecessary things.I guess all programmers write like this.Now I’m at a point where I write faster, and some things I know will work without having to try them out.Less trial and error. ![]()
Look what I’ve built:
Is a valuebox for deploy a list.Another homemade invention. What do you think?
