I mentioned this in a previous thread, but I think it warrants it’s own post. Let me just say that I’ve no experience with any of the architecture behind Renoise, so I unsure how feasible this is.
It’s clear, I think, that tools influence quite a number of user’s workflows, and using Renoise 3 without them is a bit of a compromise. I’d like to urge the devs to consider creating some sort of sandbox, or backwards compatible mode for old tools. I figure it may be a bit late to add for 3.0, but this functionality could seriously improve later versions. In addition to getting rid of these beta “transitional” periods, where we must wait for updates, developers will be able to stop working on and updating their old tools and move on to new ideas.
Again, just my opinion, and it may be hard to implement. What does the community think of this?
I’d go as far to say that it’s impossible to do as foolproof.
It should be noted that those tools that are compatible between API versions already are auto-upgraded. I speculate R3 (no pun intended) checks the lua-code through for keywords that are changed/removed in the new API version and if none are found, the tool is simply ‘upgraded’ by changing the API version tag in manifest.xml.
But if the checking runs into a changed keyword I think it just is not feasible to try and guess what the tool code should look like in a new API version. At least not in ALL cases. There might be some exceptions if one really thinks this through, but in general I really think this a tough (as in obsidian, or titan) nut to crack.
People who write tools can actually provide backwards compatibility if they want - you can always check the API version, and provide different features depending on the version of Renoise.
But, even with just relatively simple tools it could become a hell to support for the script author - most scripts are done for fun, not for profit?
How does that work? Wouldn’t there have to be a manifest.xml in which there is an API version specified, and if renoise version is running a different API, the tool would just not load because it’s incompatible?
Backward compatibility is pretty much impossible.
A lot of stuff in the instrument architecture has changed, positions and options has changed, minimum and maximum values have changed or turned dynamic regarding their relational fraction to what they represent (e.g. pitch range goes from 0 to 1, but intermittent float values van represent -12 to +12 or -96 to +96 (which is a whopping 16 octaves!))
If there would be such use of backward compatibility, such tools would then only work on instruments in compatible mode, but as soon as they are upgraded, no longer work.
Conversion is currently done as KMaki mentions. It is even such a raw detection algorithm that it doesn’t care if the keyword is part of a comment section or not (which is quite unfair if it is only part of non-active code this way)
I personally would consider it a fair option for the devs to let the detection routine automatically add comment lines above the lines containing the found keyword and hinting towards which alternative API function script developers should resort to, this will make it a bit more comfortable for script developers to upgrade their tools.
If script developers would not like such kind of comment injection, they could always resort to the original code in the former version preference folder. But i would love to use the latter option to diff the commented and disabled 3.0 script against the original 2.x script.
How does that work? Wouldn’t there have to be a manifest.xml in which there is an API version specified, and if renoise version is running a different API, the tool would just not load because it’s incompatible?