Update tools request

Ideas & suggestions
1

I’ve been using Renoise since 2.7. My recent album “Rushware” was written, produced and mixed in Renoise. I LOVE RENOISE WITH A PASSION!!!

My only gripe:
User-made add-ons are never compatible with the updates. Every time the new version of Renoise comes out, I have to hope and pray that the users who made the tools, of which my workflow is heavily based around, decide to make a new version that works with the Renoise update. And if they don’t, then I have to choose between my deeply effective and efficient workflow and the new features.

Why can’t Renoise have a standardized system where all the user-made tools work, regardless of the Renoise version?

Example: Ableton’s user-made Max for Live tools work on any version of Ableton that supports Max for Live. The tools from Live 10 don’t just stop working on Live 10.1 and so on. Why can’t Renoise have the same type of compatibility with its tools?

1 Like
2

I don’t use that many tools, but they all auto-updated just fine when going from 3.1 to 3.2, are there specific ones you have trouble with?

3

What???

Auto-update???

Is that an option??? Has that always been an option?

Usually I get the new version and there are no tools on it at all. How does this Auto-update work?

1 Like
4

Whoa I just read up on the auto-upgrade … and I am now ecstatic … hopefully everything worksauto-update

5

Just to clarify that ‘auto update’ really just bumps the API version in the tool manifest file. It doesn’t modify the code of the tool. So if a tool uses a particular feature of say API version 5, taktik removes or changes that feature in a new Renoise version, the tool will in all likelihood break in the new Renoise version even after ‘auto upgrade’ until the writer of the tool (or someone else) modifies the code to reflect the new API changes.

So wasn’t the original question something along the lines of:

If Renoise follows a fairly strong backward compatible model with its sound and user interface facilities (since 2002), why is it okay to just add/delete/modify the lua API without really any regard whatsoever to previous tools written with lower API versions?

6

Not everything is so easy. When someone creates an API of this type, they are aware that later on they will have to add, or worse, change (delete something old to replace it with something new). Are two totally different things. Adding generally does not imply breaking back. In fact, version 3.2, just add new features for API6, does not change anything, as far as I know (maybe I am wrong). In this case, there will be no problem automatically updating the tools. The only thing that makes the auto update is to edit the file “manifest.xml”, replacing a 5 with a 6 in a line <ApiVersion>6</ApiVersion>.

However, removing something old to replace it with something new does mean breaking something backwards. In fact, version 3.2 includes some “patch” added precisely to avoid this. Anyway, I think that if something is “badly designed” in the previous versions of the API, it is better to correct it for something new, instead of keeping that code and adding a patch. That patch is very likely to confuse programmers, even. And if there are tools that do not work, it is not the fault of Taktik or Renoise, but of their creators. If there is no support desisnteresado by these users (who do not charge anything, and in most cases do not receive any kind of gratitude, but rather the opposite), forget about that tool. It is the best. You will lose the tool, but “obsolete tools” will also be cleaned.

In summary, if you have used 3.1 and you change to 3.2 you will not have problems with the tools autoupdates. But, if you use a 3.2 tool and change to 3.1 for whatever reason, you will have problems, as usual. But this scenario is neither logical nor usual.

Finally, if you are so concerned about the issue of tools, it is enough to learn a little about the API and LUA and solve these problems yourself. They may only involve changing a line of code, even a single character.

What does all this mean? That it is very likely that all tools for 3.1 or 3.1.1 are fully compatible with 3.2. But if the tool programmer wants to use the new features of API6, he must launch a new version of his tool for 3.2 or higher.

  • Renoise 3.1.0 or 3.1.1 use API5.
  • Renoise 3.2.0 use API6.

By the way, version 3.2 is quite important. It is not a minor update, but it has a lot of weight. It is likely that a series of bugs or problems are detected that should be solved soon with a new version 3.2.1. In this case, you will continue to use the API6, unless that new package has something new in API6, something unlikely. If so, it will surely be an aggregate.

7

Most auto-updated tools will work, basically which didn’t work were tools mangling with samples and were updated from pre 3.0 to 3.0 or later, since the api calls changed here, new layers were added to instruments. But even that would be quite easily fixable, by anyone who has a bit experience with the Renoise API. So maybe, if the tool developer isn’t around anymore, just fix it yourself?

Doesn’t it auto-string-replace simple name changes of the API in the actual code?

8

It might apply some simple text manipulation(?)…IDK to be honest ffx you would have to ask Raul. Chances are though you’ve got to modify/check your code.

The way in which I get around the ‘chasing taktik’ upgrade tool(s) thing is to not write any tools at all :slight_smile:

9

Thanks guys,

I’ll just deal with the changes.

10

This could even be “unethical.” I doubt that there is any kind of “automatic” manipulation of the LUA code written by another programmer. In fact, this could be a bit complicated to do. It would surely confuse the programmer directly.

However, it seems reasonable to be able to “automatic manipulate” the “manifest.xml” file, if it does not imply breaking anything.

The correct thing is, in case of not “updating automatically”, you change manually the version of the API (5 replace it with 6) inside the “manifest.xml” and then check that the tool loads correctly. If there is any LUA line with errors (the typical error window will appear), it will be necessary to correct it (reprogram).

11

It doesn’t change any code. It simply checks if the changed or removed API calls are contained in the tool’s lua code by doing a very simple text token search on all lua files in the xrnx bundle. If no changed or removed API calls are present in the code, it’s auto upgrading the tool, else it’s disabling it.

1 Like
12

Thanks for clearing it up! It is good to know these details. Thus, if the tool is not updated automatically, it is probably because it would return some error that will have to be examined.