I was thinking about how a thirdparty API for Renoise would be really useful. Every time one of us is doing a thirdparty tool, the methods for accessing instruments, patterns, notes, etc., are likely to have been written from scratch, and might even break if/when a new version of xrns is released!
I think a unified concept for accessing Renoise data, is something everybody could benefit from. And the more languages supported by the API, the better! So, when I discovered this haXe language, it got me thinking.
Had totally forgotten about that, perhaps since I’m neither proficient in Python or C?
If haXe could compile to the Java VM as well…that would be killa (jrenoisetools)!!
Edit: No source was contributed to the CVS at all? Just had a look, and found nothing…
Swig only solves the problem to “port” the interface to other languages. These ports usually work, but are far from optimal IMHO. Every language has its own “unique” good way to express stuff. Swig can not take care of that. You then end up in wrapping the interface twice to make it pretty which usually makes the original C interface even more ugly.
Also we first need something to port and an environment where this interface can be used. Via MIDI, via OSC, a “terminal” in Renoise, via Advanced Edit scripts , … ?
I have used swig for several years together with python. There was some other soft intended specially for C++ and Python, but I don’t know what happened to it. Atleast when I tried it, I still chose Swig cause it seemed to be more solid.
I see a “real” API somewhere on the horizon, but that’s not what I aiming for right now. ECMA/java/actionscript and PHP are pretty much the most documented languages on the internet, and seems like the logical choice if we’re talking about the thirdparty tools done so far. And inspired by the mod-player, I was thinking that a xrns port should be possible …
Edit: I’ll come up with something based on actionscript…will need some help porting it to haXe though…
OK, I think I’ve settled on haXe, it’s way cool. But there’s still a couple of drawbacks. For example, I was hoping that it had support for E4X (an alternative way of parsing XML). And obviously, some will miss the lack of Java support.
Now, the million $ question is, how to design an external API? What features should be implemented, how should it be structured…Well, I think the obvious starting point is to make a “Song” class, since songs contain Instruments, Samples, Patterns etc. An obvious extension to the Song class could then be an “Editor” class, which could bring extra features that deal with realtime user input (I’m thinking about functional prototypes here). So, if you don’t need realtime interaction, just instantiate a Song class.
We also need to settle on a way to access data. Dom XML is complex, and possibly slow. E4X has obvious benefits, but isn’t supported by haXe. Still, it could be simulated in the API. Imagine working with something like
One step closer - here’s the xrns data structure, divided into classes. This is a great step towards exposing most song properties to a script, but some of them require an extra bit of functionality. For instance, song comments are actually an array of strings (one for each line). For such a case, I imagine a convenience method, Song.setComment(), that accept a string and automatically creates the required XML.
By simply choosing one “major/common” language like Python which is perfectly suited for this task…
Everyone who knows any scripting language can easily adopt to for example Python. Its very well documented, so why bother with 100 languages which no one uses?
I disagree, In fact I find that this statement is preposterous.
Languages used to write programs that take advantage of Renoise, so far:
Publicly available scripts written in Python for Renoise, so far:
Support for Python and nothing else is cruel and unusual at this stage of the game. I know it’s every “real” programmer’s favorite choice, but Renoise scripting isn’t academia. It’s near anarchy at this point. To come in with the clue stick at this stage will certainly discourage me from writing anything else.
I’m not saying PHP is the best choice, I’m more than willing to accept that it’s the worst, but if I am to put time into something new it will be OBJ-C and VST/AU programming.
The reasons I chose PHP is because it takes me minutes to write stuff. I’m not interested in learning another language to do stuff that won’t give me transferable skills into my own life. When I write PHP for Renoise, i learn stuff applicable to my real life. Python? Won’t be using it, ever. Regardless of it’s “superiority.”
I would imagine it’s the same for ActionScript. Why write Python when your job is Flash?
AutoHotKey, I never heard of it until RPG. Does that make AutoHotKey unworthy of support? No. RPG is one of the better applications for Renoise right now.
I strongly feel that this is one of those things that has to evolve on it’s own and be extremely simple, flexible, opensource, and dirty. I feel any time put into a closed source tightly integrated unilingual API would be time better spent doing something else.
The user’s are certainly not asking for this feature.
I think the whole point he wanted to make is we have to settle on some standard. So far we had all our own approach. I wouldn’t have any problem to settle on one project which wouild grow over time. Also a thing to consider would be it should be a language with an own well established standard library supporting most things out of the box.
Renoise is XML data and choosing one language to read and write to it very, very odd.
The whole point of XML is any language can read/write it.
If by standards we are talking about naming conventions and pseudocode for methods/functions that manipulate Renoise data, then i’d be willing to write something in PHP that clones someone else’s API, so long as it’s opensource.
That way, when we discuss stuff we can do it our own way, but we talk using very similar terms when posting about it.
I guess that is what Danoise is trying to do, and I support that.