Which of the currently existing Tool do people feel would really benefit from being a native function?
Please only post a single Tool per reply, with the name of the Tool and a brief description (means you will have to wait if you have more than one suggestion, as I will have to wait before starting myself.) Please use discretion and only post Tools you think have a wide usage and will be helpful to many people, rather than a small, niche group. Also bear in mind that tools that are constantly expanding and updating are not suitable for inclusion into the main Renoise program for obvious reasons. Think along the lines of added keyboard shortcuts and basic functions that really do fit in with the core program.
If you agree with the suggestion please use the +1 button on the post.
(Devs/Admin: Sorry if you don’t like the idea of this thread, and I hope it doesn’t get out of hand, but I thought it might help see what minor tweaks by the users people think are greatly beneficial. It might also help people find some simple Tools they have missed. Had original gone to post in Ideas & Suggestions but as it’s not a suggestion in itself decided General was a better place for it.)
Huh?!! I had copy and pasted the text body and gone into General. Why has it still posted in the Tools section? Admin may want to move it… (Or did they?)
Title says it all really. This tool will take a sliced instrument and create a new instrument with each of the slices as a discrete sample, making editing and modifications easier while breaking continuous play and ability to affect multiple parts at once.
How many unique IP hits does this or the Tools site get a week/month?
How long does it take some tools to be updated between versions of Renoise when they are basically functionality?
Should people who are trying out the demo not have access to these functions first time they try the program?
Is it a bad thing to try and gather collection opinion?
Or do I misunderstand you completely and you actually mean you are for it and the easiest way for the Devs to integrate would be to keep it as a LUA extension, but in a different place and remove the tilde? Bit of a messy hack but guess that could be one way to integrate them…
If the Renoise devs were maintaining the scripts and releasing them with Renoise, then there is no difference between Tool and Native IMHO.
From the thread this idea spawned from I’m more interested in why people don’t use available Tools. Is it because they want some sort of guarantee of maintenance? Even here, this is very philosophical because , again, from the thread where this idea spawned from we can see that even Native changes gets people pissed off. Maintenance is a double edge sword. In this case, I would argue that a Tool is better because at least you could change it back to however you liked if you had some sort of adeptness.
Renoise is a weird place between open source, extremely cheap and liberally licensed software, and users who feel they are entitled to something by blurting it out in public.
The discussion is interesting, but to me the underlying philosophical reasons for the discussion is more interesting… Hence “If a tree falls in a forest…”
Good times.
Edit: For the record I’m not against Tools becoming Native. Just broadening the scope of discussion to ask what exactly that means for the user.
An intuitive integrated tool browser/downloader in Renoise would be good though. Downloading .xrnx and drag&drop isn’t a very consumer friendly solution.
Probably minor savings in efficiency, being coded in the C(?) core program, rather than a LUA extension. (Minor.)
When there are updates to a section, EG the Basenote changes in the latest release, having to go through multiple files to find and replace relevant line and further test their operability with the main program. I think integration into main code is the neater way and on the whole it should not be too much work to translate from LUA to C/C++ or whatever it is renoise uses.
(Slight shame this thread had gone into discussion, rather than suggestions, but I can live with that )
(Also maybe the Renoise Update Tool but that says it replaces the existing functionality, which I can’t remember existing and thus what the difference is…)
Somthing like zynsilla or whatever it is called , constructing waveforms based on partials , hm but that might eat up a lot of cpu resources…Anyway
+1 for native waveform gnerator
I understand the idea to select one of the most useful tools and convert it to the native renoise language programming code. But I must keep in mind that the LUA script language allows power users to add something personal to Renoise without the need for them to put the hands in the native C++ code and being members of the official Dev Team. Tools coders have then a “special status” to my eyes. They control the evolution of the script and the features of their tools what is a great thing. I see them as “additionnal” but also “independent” dev team members. And if the integration of their LUA scripts in the native renoise sourcecode can be psychologically seen as a recognition mark, on the other hand their script could be considersd as obsolete as it is and they could feel that they have less control on the evolution of their tool and features.
I also have to keep in mind that I 'm actually using all the time a “group of tools” and not just one of them, that’s what happens.
In the end, I think that Renoise should be natively installed with scripting language turned ON and a LUA-based “toolpack” with an auto-update feature.
Example of the toolpack content :
pattern edition improvements :
pattern resizer (how could we work without it?)
split into separate tracks (I simply use it all the time)
automation cleaner (50% of my hand made automation curves are made of redundant points, then this tool makes my .xrns songs lighter)
notes randomize (perfect for adding a bit of inspiration in a track)
scale finder
progressor
module splitter (easily re-arranging in Renoise your old .MOD songs from the past is a something that has to be done)
sample edition improvements :
generate custom wave (even milkytracker has a native sample generator, a basic thing that a soundtracker always needs)
zinzilla (same thing but different approach)
rubberband (a timestretch is perfect when my loops don’t exactly match the song tempo)
import-export :
midi convert (export song to midi)
additionnal file format support
(Yep I know that’s not a single tool but I never use just one of them).
)