+1 for this… but what I’d REALLY like is a metadevice SDK 
An SDK would be great … +1 from me too.
I might get around to building a php class that generates Renoise XML, but I’m not 100% confident about how to put it together from a design aspect. Rather than do it all by myself, I’d rather get it perfect the first time.
I’m very right-brained, so I’m looking for some left-brained intervention … forget that it’s PHP …
My first thoughts are something like this.
$song=new song();
$noteSelection=new Selection($song);
.//
$noteSelection->addNote("C#3", 1, 1, 1); // track 1, row 1, column 1
$noteSelection->addEffect("7", "FF",1,1,2); // track 1, row 1, column 3
$noteSelection->addVolume("65",1,1,1); // track 1, row 1, column 2
.//
//
$clipboardXML=$noteSelection->generateClipboard(); // Return (string) note selection as clipboard data
.// OR..
$clipboardASCII=$noteSelection->generateASCII(); // Returns (string) note selection as forum friendly/monospace ascii
.// OR..
$song->addPattern($noteSelection, 1); // append note selection into pattern 1
$song->render();
.//
$songXML=$song->generateXML(); // returns (string) XML
.// OR..
$song->generateFile($filename); // saves entire song to $filename (returns BOOL)
I think the philosophy of 1. building the data, and then 2. assigning a role … is perhaps the most versitile… One thing I’m unsure about is the addNote/Effect/Volume methods. Is that a little too parameter-happy? is “C#3” right?
Other functions like addChord(“C#2, C#3, F-3, G#3”, 1,1); spring to mind. Although from a scripting point of view, it might be easier to optionally express a note in “semi-tones from $rootNote”… (something like figured bass, good for transposing). Different noteModes could be the answer - or perhaps just create a whole lot of functions which interpret a whole variety of datatypes to cater for whatever type of information you want to give it. [Including (something like) clipboard data from MPT springs to mind].
A good (php) class can be wrapped into a decent scripting engine.
Hotness i assume. I have to admit, though i’ve been super up on scripting for renoise before, i wasn’t ever interested in manipulating pattern data through scripting. You get ridiculous things like algorithmic music, avant garde junk that is truly just random notes, glitchy breaks that are truly just glitches. The list of terrible results goes on and on.
However, if i understand you right Taktik, is there a good reason why a script executing on each individual effect chain is more complicated? It’s a question of querying a given node of the song xml and getting its children after all, and allowing some kind of IO on those children.
My first post on this topicwhine
Leaving xml parsing to the script seems kind of out of whack with reality if this was ever intended to execute continuously. But i assume it wasn’t? I think about selections entire songs in length and something in me curls up and dies.
For an API to facilitate this kind of scripting, i’d expect the script to be given access to an array of relevant nodes parsed down to object structure, not have to perform its own xml parsing. Sequence and properties is all it’d honestly need.
Any news on this one?
If this will work as an substitute for a real API I would say NO NO NO! If I understand it right this little function will be limited to just edit the pattern clipboard buffer, and it would not be possible to for example automated things in real time, manipulate the sound and write own meta devices, effects and generators etc etc. It will only manipulate the clip board in a non real time manner, just as it works when you press a button in the advanced pattern editor, which will make it just too limited to be useful in the long run…
The whole thing sounds pretty half-hearted to me and not very well thought-out… and I predict we will see just more than max a handful of useful scripts for this function and those scripts would probably only be used by a few enthusiasts because of the nature of the functionality, especially if thous scripts that will be written going to need that you install a handful of obscure script engines on your machine before they will work 
To be honest this sounds like what we in Sweden call “fulhack” (direct translation is “ugly hack”, and means a fast, easy, temporary, ineffective and ugly solution to a bigger problem) and if it is realized it will probably be the biggest “fulhack” in the history of renoise so I say, please put some effort in a real API instead. If the API will allow to plug in for example GUI-parameters inside Renoise (for example a new box in advanced edit dialog) a script executor will be possible to write as a plug-in for those who want it later on…
A realtime API would be nice of course, but is it really worth the effort? Adding support for midi fx and some more flexible routing would allow you to code similar solutions if needed which would even work in other hosts. I’m somehow dissappointed by the amount of applications, which were currently released for processing the new xml based formats. To me it seems like most are simply waiting for others to do the “dirty” job. If i could process pattern data in a quick way through advanced edit, i’m all for it.
I know this is a cheap shot meant to be a joke, but this falls under the Worse Is Better reality that all the so called “good programers” have managed to do what we call in Canada “f.u.c.k. a.l.l.” (i.e. nothing) with an XML text file and some directories with wav files in them. It doesn’t get more open and obvious than that…
I’m not saying your suggestion is bad, but I highly doubt that an API will magically make programmers do cool stuff if they can’t already do it with XRNS as is, now.
I fully agree here. It depends on what you want to solve with this. From a programming point of view its nice to have a “perfect” full blown API, but who cares about this except programmers if no one uses it?
Creating an API that allows you to do virtually anything in Renoise, does not mean that we will then get a lot of scripts, devs that use it. In contrary: The more simple the thing is, the more attractive its for musicians and “hobby” (forgive me - found no better word for that) programmers. Big APIs as for example in Photoshop were made so that some customers can hire programmers to write scripts for them. Thats not really a scenario that works for Renoise…
No news, sorry. Will definitely not happen in the upcoming release…
I still have the hope that many people use it, but just don’t want to “share” it. As sharing means another big bunch of work…
it isn’t totally unthinkable either…? how about some kind of “renoise extension packs” ? for us users that want fancy scripts but just don’t know how to write those and don’t want to learn it either.
(i’m pretty sure there’s lots of that kind of users out there, i mean it just can’t be only me 
)
Uhhh, If you don’t know how to write and don’t want to learn, an API really won’t help you? In fact, that statement makes no sense. You pretty much said the equivalent of “I want books but I don’t know how to read and I don’t want to learn?”
Programming takes time. An API doesn’t solve your problem. If you are willing to pay a programmer for a script, it can be done with the XML file as is, now… If you just want more scripts… an API doesn’t make this happen unless a programmer writes a script.
In the case of Photoshop, the file format is a closed format. The reason programmers need an APPLICATION PROGRAMING INTERFACE is because there is no realistic or direct way to do anything without going through Photoshop.
In Renoise, it’s a friggin’ text file in XML. The API is redundant. In contrast, a library of functions to do everything for you, that would be cool. But that’s not an API. And that can be written in any language, and that could be done using the proposed “Simple” idea independently of Taktic’s involvement.
think i didn’t make myself clear enough. what i mean is that i would like programmers to be able to build users like me a ‘dummy proof’ interface for script making. then we, the users, could buy that from whoever offers it. in other words, taktik and the team could work on more global futures of renoise while other people make sure the not so obvious wishes could also happen. that way renoise keeps interesting for a wide variety of users.
hope that makes more sense to you.
Cool, well Taktik’s “simple” idea is the dummy proof interface. An API is something entirely different.
You as a user won’t need to do much if it gets implemented as suggested and programmers make programs compatible with your system.
Cheers!
Sure, a simple solution can sometimes be as good, or sometimes even better as a complex solution. But if this script executor will completely replace all thoughts about a real API I think it isn’t a very good idea and as it sounds to me, this idea sounds, not just simple, but also extremely limited, correct me if I’m wrong but the only thing you will be able to do with this is to manipulate the XML in the clipboard non-realtime…?
Sure, it is probably not very likely that people are going to hire programmers to make plugins for Renoise, but look at for example Buzz, one of the biggest reasons why buzz still is alive is most likely because of the buzz machine community, without it the uses would probably moved along to new “living” software… and that community is a living proof that it isn’t just hired programmers that will do plug-ins
Yes, it is extremely limited, but does its job. And it was never thought as a replacement to a “real” API.
I also see no reason why the “real” API and this hack could not exist side by side.
No, you are right… I probably misunderstood the initial post, but when I read this line “and do not need to publish any new APIs” I thought this little feature would replace the thoughts about “real” APIs
My fault then. This was meant as “and do not need to publish any new APIs to get this job (the AdvancedEdit patterndata manipulation) done”. As the proposed way just works with the XML (and its definition → Schema).
Bump
It’s been over a year since taktik posted this excellent idea. Would be nice to continue the discussion…
Personally I would want the script trigger to be a key combo… like in the martial arts video games:
Press Up, Up, Down, Left, Left, Right and Punch and Renoise will call the SuperScript™. 
I want this very very badly. I would love to be able to edit the song dom inside of renoise. I think this could be done using html/css/javascript.
Add a panel with an instance of the default browser
send it the song dom/selection
receive response xml
Browsers already have script security. If we allow exes there is a chance that renoise will execute a virus.
Well, if we allow VSTs there’s a chance that Renoise will execute a virus too. There’s no difference between a VST and an External Script in this case. Both are executables. Both could be viruses. The user shouldn’t install them in either case. It’s their responsibility to know what they are doing.
Furthermore, I don’t think a web browser will work as a scripting engine? Can it write to files? Can it return values? I’m asking?
In taktik’s original idea you could use whatever scripting language of your own choice. That’s how it should be done, not limiting the user to any specific framework.
Renoise only writes to temp_file and reads from temp_modifed_file – that’s how it should be. What will processes the temp_file is up for the user to decide for himself. And regarding viruses, no, that’s also the user’s responsibilty. If the user knows how to run scripts, we can assume he knows how to handle that matter.