How To Simplify The Use Of All The Existing Xrns Tools?

I may not be a good thing for the development of such things, but from a user point of view it is. Right now its like:

“Yes, we have some tools to for example export MIDI, either download and try this this or that, but you need to install this for that and this for that while this doesn’t work with that on that OS”.

It would simply be great to offer people, who dont want to bother with programming, a simply link and tool which does the things they want/need. Aka, I would love to see a way to simplify the use of the tools that you all have created.
One idea might be that we only add/present one of the tools in our download sections, hide the others until they grow above the current “official” one. Another one that we bundle only one of the tools with the Renoise installation.

Any other ideas on how to simply this for the non programmers?

For me personally one of the biggest burden is platform compatibility. I liked the idea of using Python, since it also has a library for platform independent GUI scripting included already. I could code for example small tools in plain C, which would be probably quite portable with a few adjustments, but rarely a user wants to use the commandline to accomplish things. So far i’m only monitoring what other alternatives show up here at the board. Since i’m mainly a C coder a new API means also learning the new language for me, i don’t want to settle yet learning C#, just to find out later something more official in Python or some other language will appear. That means no new tools from me at the moment until things settle a bit.

A little sidetrack, the next Renoise project I am working on will be a way to make an electroacoustic score of a Renoise XRNS using Cocoa/OBJ-C. This is a medium to long term project. Basically, I want a horizontal “Garageband” overview of the information in an XRNS. The reason I am doing this is to learn Cocoa/OBJ-C.

Right now I get paid to write PHP. Between the time I started the XRNS-PHP project and today, my PHP skills have vastly improved. If I were to start again, I would rewrite the whole project. Scrap the procedural approach and start over. However, when I started it made sense to make it procedural because I had no idea if it would work. So I went with the brute force approach, then again, then again, then others joined, then more, then beatslaughter’s GUI saved the day, then more. It was a mild success considering the small size of the Renoise community. It was the natural evolution of a product. And every product has a lifecycle. It doesn’t last for ever. Tough shit. No big deal.

In contrast, I don’t see a future for myself in Python. I’m sure it would be easier to write Renoise scripts in Python but at the end of the day it’s not a language that offers me any benefits. Sure, it offers you the sole proprietor of Renoise some. It offers the users, who have not paid for any third party scripts, benefits. But at least with PHP I could justify working on the stuff “on the job” as part of R&D. Same for ALX’s .NET tools. He even said so himself; It’s for use with internal tools to make demos.

XRNS-PHP averages about 5 downloads a day. I think you grossly underestimate the users. Randomly, new scripts have appeared out of nowhere. Other cool stuff was posted in ActionScript, by people who obviously work and get paid with Flash, and whatever else in this forum.

In comparison, when you look at something like Blender and see all their cool Blender Python scripts it’s because there is a group of Blender users with 9 to 5 jobs, or doing masters/doctorates, working with Blender. Renoise doesn’t have a professional user base. Renoise gets what it can take. And, contrary to fantasy land, not the other way around as many would like it to be.

If the user really needs help with the tools as they are now, I’d gladly take money to walk him/her through it.

Right now, this is reality.

EDIT/PS: @Alx, sorry that this thread has derailed into an ideology battle. Your tools look awesome and users should CHECK THEM OUT!

Moving forward I don’t see any problems with making Python the default script API for Renoise. So long as people are willing to write the scripts.

But, if people don’t write scripts I’m assuming you (taktik) will have to write the scripts yourself so that the API doesn’t look like a huge waste of time, which in this case will turn out to be twice as much wasted time since you end up writing both the API and the scripts yourself?

Good intentions != scripts. Read my previous post.

I believe the simple Python script engine that was inserted in the early 1.6 Alpha is probably still lurking somewhere in the background ;)

I understand that for a end user experience, simplify the use of the tools is really important.

For this, i have just release a new minor revision NRenoiseTools 1.0.1 that includes a windows installer which add shorcuts in program’s menu and desktop as well as redirecting the user to download .NET Framework if not available on the machine.

Well, i’m not really confident with this official / non official policy. It is great that Renoise helps and host a web page to list the tools developed by the community as well as providing a forum for this… but they are community tools and not official (you should probably change the name on your website to avoid any confusion?).

That is said, i have just found the Windows Installer solution to be the most practical response to your suggestion. But i wouldn’t engage myself in the impossible task of regulating community tools… :)