I wanted to try some of the tools for Renoise today, and got the message they’re no longer compatible, and that I had to download new versions.
Note to the developers: this has to be adressed. No matter how this is explained due to technical difficulties, to the end user this is unacceptable.
Apparently I now have to search for the upgraded versions, something that’ll probably take a while. I’m not interested in doing this, so I consider instead firing up Ableton Live.
Your loss!
Although if you check the Tools there is now a Tool which will automatically update other Tools to the latest version 
the tools (lua scripts) are created by renoise users just like yourself and has nothing to do with the commercial application renoise as such
the renoise developers are not responsible for upgrading the users’ tools
As .xrns they are Community built and if you say you wish for the API to never get any better just so that old Tools never become broken I think you may be in the minority. Many of them only require the changing of one line which states which API version they were built with but Renoise doesn’t risk loading them without this being changed in case the tool will make things unstable. I (and I expect most users) consider this a good thing.
If it is indeed so that the Renoise developer team cannot take any resposiblity for compability being broken, they do have a problem justifying the plugins being hosted at the products very own site.
If the plugins development option is pushed as a major feature of Renoise, indeed if only a minor feature, steps should be taken to ensure that working plugins in one version are indeed still working when Renoise is updated. Let’s say I’ve come to depend on one of the plugins, or at least found it central to the production I’m doing, it is unacceptable that a simple upgrade of the program shoulod render it useless. What if the developer seizes to do further updates? In the software world there are of course many examples of this, but a serious company should take every step necessary to avoid such scenarios.
I think Renoise is a fantastic program, but as I have a really tight schedule, I don’t have time to trying to figure out problems such as these. You may say it’s “my loss”/“my problem”, and from one perspective it obviously is. But if this is something that p*sses off many users, the problem is definatly also the Renoise developer’s.
btw: I’ll try to find the tool you mentioned, thanks for the heads up. Unfortunately I’ve now lost the two hours I had for making music, and have to rush off to a meeting.
If I experience the same loss of time next time I’m jamming, I’ll certainly have to reconsider which software I’ll be using in the time to come.
Edit: I just saw the link for the updater, thanks again!
No!!! This kind of attitude means that Renoise would have to limit itself in the way it can enhance and improve the likes of song structure, the instrument section and many other parts of the program! I have to very strongly disagree with you on this one.
Many Tools needed nothing but the line that said “APIversion:xx” (or similar, unsure on syntax) changed but some, mainly those working with the Instrument Editor as it had a massive overhaul, required further changes. As all Tools are effectively open anybody can step in and attempt it, or in fact improve and add features if they wish. But attempting to load Tools that did not work could cause Renoise to be unstable and crash so makes sense not to load them until this line has been updated (or the tool officially updated.)
Why don’t you continue using the older version until you are on a less time-critical project? Nothing was stopping you from doing so!
no, this is not a problem at all, since the tools are not part of the official product renoise
i don’t see the point in having renoise.com refraining from informing users about external resources
tool developers must follow renoise development, not the other way around
what i think the renoise team might do is to make a clearer official statement about the fact that users’ tools/scripts are not part of the software and that it’s not recommended for users to depend on such unofficial tools
also it’s important to send out the signal to hobbyist tool developers that it’s perfectly ok to post them “as is” and that just because you share your tool with the world you’re not bound for life to provide support or upgrade your code to meet tomorrow’s standards
very important actually, otherwise people are discouraged from publishing their creative solutions to small problems or custom demands
regular tool users need to understand that they can’t expect tools to get updated as soon as the renoise api gets updated or improved, it’s just an impossible equation
again, tool developers must adapt to renoise development and not the other way around
and tool users must adapt to tool developers, not the other way around
No it isn’t, Renoise development and scripting tools are two complete different assets.
Renoise Development does update scripting API so that the tool developers can at least adjust their scripts and the Renoise development team describes the changes and announces these changes nin the changelog. But the adjustment of the third party scripts is completely in the hands of the script writers.
Some feature changes simply cannot be kept backwards compatible because the complexity expanded of the feature. Like the sample layering required a different approach to how the instrument structure had to be set up in contrast to how the old 2.6 version instrument structure looked like.
Some instrument features that were in 2.6 tools have a native Renoise solution in the new structure, be it still somewhat limited, but not unavailable.
And what Kazakore already wrote: A lot of scripts only require one adjustment in the manifest.xml and that is simply changing the API version number to 2.0 and re-enable the script in the tool browser. In most cases that is sufficient, in some cases you get errors because API functions have changed that really require a structural reprogramming of the script.
If you need a specific old script, you can post a request in the scripts forum with a link to the script on the tools page and see if the script writer wants to pick it up.
As I already stated in my previous post; any attempt to lay the “blame” for this on programming aspects will not go down with a lot of people.
The simple fact is that end users don’t generally care what kind of explanation developers come up with for this of that perceived shortcoming.
Having said that, I realise I may have over reacted slightly, as the Tools updater tool seems to work as promised. My suggestion is that this is made
a standard feature in order to avoid unnecessary confusion.
So, let me get this straight. You’re basically stating the rough equivalent of this:
If anyone gives me a Delay with one tap, and then they add 30 taps to it to improve it, add feedback, add dry/wet signal, add loads of stuff - and if they then dare make this enhanced Delay not support previously saved Delay presets (when it had less features and therefore less data in the preset) - you’ll write angry messages about it and talk about end users not wanting that kind of stuff and then pull out the “perceived shortcoming” cards etc.
So you can’t deal with the fact that the Renoise API got updated and that it has more features, more functions, more possibilities and is over-all way better, and you want to rant about it on the internet? Weird.
Do you want Renoise to go back to 2.6 and not have the features added to 2.7? So you’d rather not have any sample slice functions, no automation improvements, no additional native track dsps?
fairly weird.
yeah you’re right, cos “we improved the software and added new and better features” is never an explanation that the poor end-user would ever accept?
there are probably quite a few people who have no tools installed.
also, duty calls.
esaruoho:
It is obvious that you don’t take the point, either. And it is understandable that someone who loves Renoise will do his best to “defend” the product, I often do that myself.
The point is that many users will have very little patience when it comes to technical explanations of why this and that can’t be done. The product must work, and any necessary update MUST be streamlined. This is a FACT. The more confusion and trouble a user has to go through, the more likely it is that the customer will look elsewhere.
These are simple FACTS.
Having said that, I do think I overreacted somewhat on this particular issue.
no, it’s not a fact, it’s your preference projected as fact
i myself prefer creative destruction, that things develop and get better
take a close look at the lua logotype and note that the moon is a satellite to earth, not the other way around
people who write their own scripts for renoise must adapt to any changes future renoise versions bring, not the other way around
fact: the product “renoise” works and the updates are streamlined
fact: the product “user created renoise tool x” mostly works and are updated by the users who created the tool, but that’s up to them to decide - it’s not a human right to have updated tools
the point you seem to miss is that the commercial application renoise and the user written scripts for renoise are two separate things
instead you make sweeping and arbitrary claims that “many users” have “very little patience” when it comes to technical explanations of why this and that can’t be done
on the contrary, i think it’s safe to assume that most renoise users actually do understand that ‘renoise’ and ‘user created tools for renoise’ are two separate things, this would be especially true for those who have been digging deep enough into the application to discover lua scripting and external tools
but i agree with you if your main point is that the renoise team could make it more clear to new customers that the user tools are not officially supported, and that it’s not recommended to depend too much on them due to the fact that the api is in development
This obviously goes nowhere, so there’s little point in reiterating my previous points.
My statements in post #11 are hard facts every developer needs to take into consideration.
It’s as simple and as hard as that. Deal with it.
My sympathy to the impatient user, but this is how it is being dealed with: The user is the one who has to bring up the understanding and approach the direct responsible script programmer or simply change the script themselves rather than annoy the host-developer with incompatability complaints, they won’t be heard. Period.
I agree with everyones(the longer term renoisers) sentiment here…
however, maybe the tool updater should indeed be native?
even if people dont have tools it does no harm to them or the program to be installed…?? right?
There appears to be a lot of emotion in this thread.
As a developer of multiple various Renoise tools (7 stable and 2 in testing at the moment) I try my best to keep them up to date.
However, all Renoise tools are written by ‘hobbyists’ who enjoy working with Renoise. When a new version of Renoise is released we will endevour to update our tools to work with the new version. However, we do not always have a large amount of time to do this and so there may be a delay. I do not think this is unreasonable.
I could have taken the opposite approach with my tools and only released one or two of them for general use as it would be much more likely to keep them up to date when new Renoise versions are released, but this would be to the detriment of all the users of the many other tools.
There is no requirement to use the new version upon release. So the user can always wait until their ‘must have’ tools have been updated.
I see the situation as not unlike the same with the FireFox web browser. Most of the add-ons, themes etc are written by amateurs and when a new version is released there is a small delay while all the developers ‘catch up’. This is not a Renoise specific issue.
From what I understand the new version of OSX (Lion) also created some incompatabilities with previous software, so even large corporations occasionally have to break compatability in the persuit of progress.
However, I think this thread has been well and truely beaten to death now.
[edit: spelling]
Bantai,can we also have the crash log / preferences / crashed song sender/emailer/helper/browse_folderer native in a future version of Renoise? 
Technical reasons or not: That tools need to be upgraded with each new Renoise release definitely sucks. No need to discuss this, but avoiding this is really really hard (damn, now we are back at discussing technical reasons).
Beside of integrating the tool updater into Renoise, which we will try to do in one of the next updates, we maybe can experiment a bit with automatic upgrading routines. Aka, trying to find out if a tool really gets broken with a new API release, and maybe even trying to automatically fix them. So you at least don’t have to upgrade every single little tool with each new release. Problem with this is, that this never will work perfectly. But maybe nearly perfect working auto upgrading is better than what we have now. We’ll experiment a bit with this…
Another approach would be maintaining multiple 100% backwards compatible old + new API layers within Renoise (the Microsoft way). This obviously is a big big pain for us to maintain, so we have to carefully weight how much of time and sweat this is worth against the benefits.
TBH I would say it would be better to integrate some of the more popular tools as native renoise features here. Would be more efficient?