If an official API should be released, would it not be trivial to write an interface to other languages?
More thoughts:
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.
Yes, exactly. Python was just one example which we “could” settle on.
Having/supporting lots of languages also doesn’t make things easier for those who want to learn how things work, by just “reading” the existing scripts Renoise would come with.
Also before we settle on a language, lets first prototype on how to access the interface at all. As said above: Advanced Edit scripts would be one example, a terminal in Renoise another one. MIDI/OSC interaction could also be interesting.
Back by popular demand! 
https://forum.renoise.com/t/idea-for-a-simple-advanced-edit-scripting/18824
Page 2 (after a mandatory flamewar caused by resident asshole me) is worth reading
Yes, you’re right in that regard and in the end it’s up to each dev to decide how to accomplish the task.
My thoughts for some sort of ground would be more like this:
-
Get a team of some persons together and build an API in a language most of us would agree to use is much more productive than each of us doing his own thing. Having most of the ground covered in a widely used language would probably also encourage more people to join the fun.
-
The chosen language should be fast, well documented and platform independent.
Thinking further into the future:
-
Some sort of GUI programming without much hassle would be a big plus. I’ve never programmed Python but had a quick look at it, it does come with a GUI library and all sorts of other useful libraries.
-
One well sophisticated API could be maybe integrated directly into Renoise at some point offering even more features to the scripts.That only works with a language, which is directly embeddable into software. Kinda like Blender also uses Python, Photoshop, Paintshop Pro or other bigger programs, which offer to record or write scripts.
I’m not favoring Python here, but only stating it seems to me like a good choice because it offers a lot.
Well, I’m not against Python. Sorry if it sounds like I am.
I just feel that this is blindly ignoring the current structures of Renoise’s scripting society, and imposing some sort of utopia where chaos is thriving. Furthemore, it’s based on the failure that is XRNS-LIB so I don’t see how this is intelligent reasoning. Outside of Renoise, history has a few big catastrophes when it comes to doing this… No?
I say support them all, poorly. Then work on supporting one, well. Because to be honest I doubt the second one will happen (vaporware, wasted hours on a feature no one uses, etc), whereas the first will happen regardless.
I think the argument of “learning by studying how others did” is very good. Python is platform independent, well documented and easy to learn for beginners (even easier with code snippets to study). I wouldn’t mind having Python as the ‘default’ scripting language… to be honest I have recently chosen to learn how to program in Python just so that I could create some Renoise scripts!
Basically I think some button(s) in the Advanced Edit window would be enough (or a dropdown menu of script items and a ‘Run script’ button which also had a hotkey). Pressing that button would write the selected pattern data to a temporary file, execute the script assigned to that specific button with the temp file as argument, paste the processed xml back at the cursor. Whatever scripting language could then be used (but Python could be the ‘default’).
Following just that particular implementation, the gun powder should be spent on documentation and examples (preferably using the ‘default’ scripting language). I’d love to help in this regard and I’m very happy to see that this discussion is actually going on today.
I have just registered the haXe project at sourceforge (awaiting approval):
https://sourceforge.net/projects/haxx-rns/
If haXe is cool because there’s an X in it, haxx-rns is twice as cool 
I don’t doubt the coolness factor of the haXe project. But can I make a suggestion? Please, please, please stay out of the Sourceforge jungle. Learn from past experiences and instead use this forum for everything (use free upload services such as speedyshare or sendspace and easy zipped files) . Otherwise the project will just die for sure.
I’m curious. Why?
If this project is supposed to be accept contributions from more people than /me, we need a CVS system. I was hesitant when I first joined the XRNS-PHP group, since I had no experience with those things, but it turned out to be really simple. In addition, Sourceforge will allow the project to create RSS feeds, so you can keep up to date on progress without actually having to go to their website.
The incentives for development and/or other participation/support/input is probably higher when it’s fronted to the Renoise community at large (= this forum). Sourceforge is just too “off the map” and while it may be easy for dedicated coders to handle, regular interested users such as myself have a very hard time navigating that site.
Stuff will happen if you keep it in this forum. It will certainly die if you emigrate to that alone island called Sourceforge. Mark my words. Place your bets now.
Python is a good language choice. It has very easy ZIP and XML usage, so data access is piece of cake. I made this script in a couple of minutes, it prints some info included in a demo song:
import sys
import os
from zipfile import ZipFile
def main():
file = 'DemoSong - Diggin for Gold.xrns'
unziped = ZipFile(file, 'r')
for file_path in unziped.namelist():
print file_path
if __name__ == '__main__':
main()
Result for those without Python installed:
Song.xml
SampleData/
SampleData/Instrument00 (Unnamed)/
SampleData/Instrument00 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument02 (Unnamed)/
SampleData/Instrument02 (Unnamed)/Sample00 (tom_lo).ogg
SampleData/Instrument03 (Unnamed)/
SampleData/Instrument03 (Unnamed)/Sample00 (Sabian 20'' china [edge]).ogg
SampleData/Instrument04 (Unnamed)/
SampleData/Instrument04 (Unnamed)/Sample00 (Unnamed).ogg
SampleData/Instrument05 ( diggin for gold)/
SampleData/Instrument05 ( diggin for gold)/Sample00 ([c]sewen).ogg
SampleData/Instrument06 (Unnamed)/
SampleData/Instrument06 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument07 (Unnamed)/
SampleData/Instrument07 (Unnamed)/Sample00 (Zildjian 20'' ride [bell-tip]).ogg
SampleData/Instrument08 (Unnamed)/
SampleData/Instrument08 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument09 (Unnamed)/
SampleData/Instrument09 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument10 (Unnamed)/
SampleData/Instrument10 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument11 (Unnamed)/
SampleData/Instrument11 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument12 (Unnamed)/
SampleData/Instrument12 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument13 (Unnamed)/
SampleData/Instrument13 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument14 (Unnamed)/
SampleData/Instrument14 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument15 (Unnamed)/
SampleData/Instrument15 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument16 (Unnamed)/
SampleData/Instrument16 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument17 (Unnamed)/
SampleData/Instrument17 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument18 (Unnamed)/
SampleData/Instrument18 (Unnamed)/Sample00 ([c]sewen).ogg
SampleData/Instrument19 (Unnamed)/
SampleData/Instrument19 (Unnamed)/Sample00 (hh_open_hv).ogg
Transcender: It sounds like you don’t know what an API is/does. You need to understand that an API will do nothing by itself. In essence, it’s basically a developer tool that makes other, more exciting things possible (or at least faster or easier to do). Moving it to a place like SF is simply ‘obvious’. The most important reason for doing so, is that each new release of Renoise should be reflected in the API. But if you know of a way to work that you would personally find more attractive, please tell us.
HaxX-RNS progress
- All classes have been built, basic properties added (I based it off v10 of the xrns format, are previous versions compatible?)
- Investigating how to use the Lambda class, it’s a real swiss knife!
I don’t think so. For example, I ran into a problem with the merge script when it came to VSTi AutoAssignedTrack. The XML node in version 4 was named: VstiProperties, in version version 8 (and up, so far) it’s: PluginProperties
You can always ask the user to save their XRNS to the latest version though. I wouldn’t worry about anything below version 10.
This particular developer had a HDD crash last week (I’m posting this while restoring the backup
But now I’m back at track, and expect to update the project website in a week or so.
Wo-hey! A lot of things have happened since my last post. Most importantly, Renoise 2 went into beta, and with that, a whole new way of working with speed/tempo. So, while I really haven’t had sufficient time, I’d like to state that I haven’t abandoned the project. Actually, the release of Renoise 2 proves one of the fundamental point about an API: we need a way to work with xrns files that doesn’t break every time the format is updated.
thats good news danoise,looking forward to see what you come up with 