Currently all my tools are in:
/home/dac/.renoise/V3.0.1/Scripts/Tools/.
With symlinks or whatever I can more-or-less accomplish things, but it’s a bit painful, and when I upgrade or accidently move files all my configuration changes die a horrible death.
I propose having the ability to add more directories, example:
/home/dac/.renoise/V3.0.1/Scripts/Tools/.
/home/dac/code/MyLuaScripts/.
/home/dac/code/github/SomeOtherUsersLuaScripts/.
/my_files_here/.
Thank you for your consideration.
With symlinks or whatever I can more-or-less accomplish things, but it’s a bit painful, and when I upgrade or accidently move files all my configuration changes die a horrible death.
You mean, when you upgrade Renoise and it’s using a different folder for scripts/tools?
If I understand your suggestion, the “config.xml”, the main Renoise configuration file -which is (mostly) carried over from installation to installation - would be able to define alternative entry points for tools.
But - this could become messy if you are running multiple versions of Renoise with different APIs. I mean, I could imagine a tool being auto-upgraded in a newer version of Renoise, only to stop working in the previous version.
If I was pointing to a code repository, I would definitely try to make sure that I’m the only one making changes 
For a short time I was symlinking from the scripts folder to some core repos. I figured this would make it easier to see code changes as I was working on tools. I was mostly using 2.8.2. But stuff would break when i tried things in 3.0.x; Renoise rewrites the manifest when it loads a tool from an earlier version.
Now I have a script that copies files to their assorted homes and all is good.
I’m unclear on how config settings would get borked under the current setup. If anything it seems that having all Renoise-related files under a common folder path would make it easier to manage.
If you are keeping files in multiple disjoint paths then any time you move something you’ll need to update something else to ensure nothing is broken, whether that be a symlink or config setting.
If I was pointing to a code repository, I would definitely try to make sure that I’m the only one making changes
I’m unclear on how config settings would get borked under the current setup. If anything it seems that having all Renoise-related files under a common folder path would make it easier to manage.
If you are keeping files in multiple disjoint paths then any time you move something you’ll need to update something else to ensure nothing is broken, whether that be a symlink or config setting.
These are good points. Clearly symlinks aren’t the problem. They are a solution. I use them and they work fine.
From the added feedback you both gave me what my thinking is:
More categories in the Tool Browser. Currently we have Bundled Tools and Installed Tools. The stuff I am suggesting would go in a third, yet to exist, category. Maybe “Tools Under Development.”
Let’s say I’m working on com.renoise.Nibbles.xrnx, and the version I have is from Github. I’ve made a bunch of changes but haven’t released them as a XRNX. For some reason in the near future, a user says the version they got from the site doesn’t work, not just code that I could revert to test, but that when they drag & drop the XRNX onto Renoise the installer throws a weird error. For me to test this, I have to jiggle a lot of configs that would be easier to manage if “Installed Tools” were separate from"Tools Under Development"
“Tools under Development” could be added to Renoise with a [Select Folder] dialogue instead of a self-contained XRNX.
“Tools under Development” would not automatically try to upgrade,not be carried over to incompatible versions of the API.
Cheers.
Here’s yet another hack of possible use:
Put ~/.renoise into a local git repo. Add everything, check it in. This is master; don’t mess with it 
Create a new branch, dev-empty. Remove all the tools. Check in the changes.
Now when working on a specific tool you have no other tools in the way. When you’re happy, go back to master. Always keep the dev-tools branch empty of tools.
The downside is you need to keep master up to date when making permanent changes to your Renoise setup. And possibly have to merge over changes to dev-empty.
But it’s a maybe plausible way to have a clean tools environment when looking at a specific tool under development.
do you guys have issues with symlinks? that’s what I’ve been using, and they’re working fine so far. I’m just wondering if they’ll blow up on me one day and leave me confused (maybe after an upgrade?)
I have issues, but more along the “geez this is tedious” lines, no show stoppers.
The stuff I am suggesting would go in a third, yet to exist, category. Maybe “Tools Under Development.”
Yes, good idea.
As you can’t have two identical tools running, I would want Renoise to give priority to the development version.
For example, loading up Renoise with an ‘stable release’ ofcom.renoise.Nibbles.xrnx as well as an in-dev version,it would be the development version that was launched. But you could still disable the development version in the tool browser and reload tools - this would enable the stable version.
Otherwise, no need to disable tools manually - Renoise would simply load the tools in a particular order:
Bundled → Installed (== stable), and → Development
As you can’t have two identical tools running, I would want Renoise to give priority to the development version.
I see this as adding complexity to Renoise to satisfy a minority edge case.
When I’m working on a development version of tool I don’t have a need for both the dev version and the stable version to be installed and available. I just overwrite the installed version with the dev version.
If I did need to have both (perhaps to compare behavior) I would use a different package name in the dev branch.
Likewise, if I were to ship a dev version and wanted people to be able to run both dev and stable I’d use a dev namespace for the beta version of tool. And I’d use a submenu for the beta version so it would appear under Tools | BETA | .
Or something like that.
While this might not be as convenient as having specific dev options built into Renoise the alternative is to add new code and new behavior to Renoise, which increases the chance of new bugs in Renoise, for something that I bet 98% of Renoise users have no need.
The only issue I had with symlinks was when I updated a version of Renoise. In copying the tools from an earlier version it altered the manifest files to up the API version number. Since the files were symlinks these tools (my own) no longer worked in the earlier Renoise version (API version number was now too high).
I do not understand why Renoise alters manifest files. If a tool with a lower API number will still work, why not just leave it alone. Especially since changing the manifest file means nothing if the code itself is unchanged.
In any event I’m moved away from symlinks to using install scripts that copy development files to Renoise tools folders as needed.
While this might not be as convenient as having specific dev options built into Renoise the alternative is to add new code and new behavior to Renoise, which increases the chance of new bugs in Renoise, for something that I bet 98% of Renoise users have no need.
The probability is low.
Sure 98% of the user’s don’t need this but in all likely hood the code that handles this case will never be run by 98% of the users.
Also, Tool Browser already does this, the GUI already shows:
+Bundled Tools (/usr/local/share/renoise-3.0.1/Scripts/Tools/.)
It won’t be that hard to modify and add a 3rd (or more)?
The probability is low.
Sure 98% of the user’s don’t need this but in all likely hood the code that handles this case will never be run by 98% of the users.
It would get run every time the Tools menu is rendered, no? Code would have to go see if there are dev versions of tools and react accordingly.
It won’t be that hard to modify and add a 3rd (or more)?
“It won’t be that hard” are words to make a developer cry.
You have to figure out how to do it; add the code; test the code; prepare a new release; be prepared to handle support complaints if a bug was introduced.
It’s work.
It’s work.
Hence why I requested the feature…
In any event I’m moved away from symlinks to using install scripts that copy development files to Renoise tools folders as needed.
You’ve created an entire workflow to work on your tools, and all your suggestions are good, they definately “solve the problem.”
But what if you want to work on my tool?
Or create a patch for some tool you use every day, but don’t want to keep the tool around in dev mode after you do a patch?
Or a whole bunch of other scenarios that any clever developer can obviously solve (psst, i’m a dev too, 8 hours a day at a 9 to 5 job as a 40 years old man) but damn, it’s annoying, no?
I requested this feature because I want new functionality in Renoise. I’m not unaware of this.
I’m willing to discuss the implementation, but not the merits. Sorry.
Sorry, I feel dumb for harping on this, but here’s a thread I wrote in Jan 2011 called Symlink Showcase:
https://forum.renoise.com/t/symlink-showcase/30935
I was like, yeah man, working on Tools is easy! Stop hating on the Tools workflow people. And it still is.
But I’m older and lazier now so I want it to be easier.