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.
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 
Another small update. This time, I have released some files on source-forge - it’s still too early for the API to support all the xrns-php scripts, but I’ve made a small test that takes a song (well, an xml-string, actually ;-), and looks for note and effect values in a given pattern, and then goes on to produce this output:
API.hx:72: Scanning track:Track 01
API.hx:101: 0: | C-5:00: : | E-5:00: : | G-5:00: :
API.hx:101: 8: | ---: : : | ---: : : | ---: : : | 33 03
API.hx:72: Scanning track:Track 02
API.hx:72: Scanning track:Mst
API.hx:72: Scanning track:S01
It’s a test song with just 3 notes and a single effect command. I probably should have used a more complex song to make it more impressive 
. But what is really interesting here, is the (relative) simplicity of the code:
// go through tracks
var i:Int = 0;
while(i<_pattern.tracks.length></_pattern.tracks.length> trace("Scanning track:" + song.tracks[i].name);
// go through lines
var o:Int = 0;
while((o<_pattern.numberoflines-1></_pattern.numberoflines-1> rslt="";
if(_pattern.tracks[i].lines[o]!=null){
// note column
var p:Int = 0;
var col:NoteColumn;
while(p<_pattern.tracks></_pattern.tracks> col = _pattern.tracks[i].lines[o].notes[p];
strNote = (col.note!=null) ? col.note : "---";
strInstrument = (col.instrument!=null) ? col.instrument : " ";
strPanning = (col.panning!=null) ? col.panning : " ";
strVolume = (col.volume!=null) ? col.volume : " ";
rslt += " | "+strNote+":"+strInstrument+":"+strPanning+":"+strVolume;
p++;
}
// effects column
var p:Int = 0;
var col:EffectColumn;
while(p<_pattern.tracks></_pattern.tracks> col = _pattern.tracks[i].lines[o].effects[p];
strValue = (col.value!=null) ? col.value : "00";
strNumber = (col.number!=null) ? col.number : "00";
rslt += " | "+strValue+" "+strNumber;
p++;
}
// write the line to the console
trace(o+ ":" + rslt);
}
o++;
}
i++;
}
Edit: New update, a lot more classes are covered.
I completely agree with this. I don’t care which language it is, but I’d much rather see one scripting language really well integrated and supported in Renoise than an api that provides varying degrees of support over 20 different languages, which I imagine would also be a support nightmare for the Renoise devs.
I’ve scripted in Perl, Python, Ruby and Javascript and it’s really not that hard to adjust to a new syntax.