There is some very noteworthy tools which never were updated. How can a non programmer deal with this?
Native Instruments managed to convert all the ensembles in the user library when the format changed between version 3 and 4. This would be a good idea considering that there are very few Renoise tools to begin with and so its a big loss when those few precious tools fall into the past.
It seems like a point of contention. Its obviously no’ones duty or responsibility to keep things straight but its a bit weird to think that at some point I might end up with 3 versions of Renoise installed for cases where the tool updater doesn’t work on a valuable script.
For example http://www.renoise.com/tools/module-splitter this alone is probably worth keeping a legacy version of Renoise installed.
In many cases, the tools do not even need to be re-programmed, they simply need to have their manifest file updated to show the correct Renoise API version (API 3, as of Renoise 2.8).
All Renoise .XRNX tools are simply ZIP files which you can freely open and edit their contents. At the very least you’ll find the files main.lua and manifest.xml inside. You can simply open the .XRNX in your preferred ZIP archive tool (I recommend 7-zip), extract the file you want to edit, make the changes, then add the modified file back into the ZIP’ed .XRNX file.
You can edit manifest.xml and change the property to 3, then re-enable the tool in Renoise’s Tool Browser and see if it works.
The Module Splitter tool you mentioned appears to work just fine when this simple change has been made, for example.
If it doesn’t work, then you should simply contact the tool author directly and politely ask them to update the tool. You can typically find their name and email address in the Tool Browser (which gets its info from the manifest.xml in the tool), and it usually only requires a few small changes for them to fix the tool.
That is good news, it worked just fine. It’s a bit curious that the autoupdater didn’t catch it though its such an easy fix.
When we change to a new API version, we sometimes make changes to existing features, or even completely remove certain features.
If a tool is using some old features that no longer exist in the new API, then we obviously cannot auto-upgrade it.
Likewise, if the tool is using some old features that were modified in the new API, then we cannot guarantee that the auto-upgraded version will still perform in exactly the same way as before.
We obviously made some pretty big changes to the pattern editor in Renoise 2.8 (renamed effect commands, group tracks, etc), so there were also a lot of changes to the API related to the pattern data. Since the Module Splitter tool makes heavy use of the pattern data, the auto-updater could not guarantee that it would work correctly.
It’s definitely an easy fix for a human to make, but not a computer. It’s surprisingly difficult to actually interpret the code written by a human, and then perfectly analyze all of the logic in order to predict what the end result will be.