Just read this… So apparently rns is being ditched for some xml derivative.
May i inquire as to the brainwork behind this decision, and why it has not been discussed with the community (afaik)?
As someone that works with XML parsing/writing professionally on a daily basis: URGH! URRRGHH!! loud vomiting sounds
I am also intensely opposed to the idea of externalized samples, which i assume is similar to Live’s projects.
I pray this is an OPTIONAL format and not the new mandatory standard. I have absolutely zilch value in being able to edit my patterns in an external editor (XML is a p.o.s format to hand-edit), and i have no idea on this earth as to how i’d get any use out of the XML outside of renoise considering how tragically junky XML is to get anything out of without hand-crafting a ton of shit.
So what the hell is up? This isn’t small news in the very slightest.
If Renoise still loads/saves “modules” in a way which is transparent to the end user, then really what difference does it make what the file format is?
Personally I’m very much looking forward to the extra possibilities of being able to manipulate the song data via other methods (ie. writing my own code/scripts).
Much in the same way that I’m excited by the idea of the expressions concept that you’ve mentioned yourself in the past, which to many other people would probably seem completely useless.
It’s all about perspective really. Different users have different needs.
I do agree with you though, I think it would be best realised as an optional extra, with Renoise providing both the traditional .RNS file format and an optional .XML format for those who need/want it. Trying to shoe-horn all users into a specific way of thinking is never a good thing.
Imagine the scenario of doing collaborations over the internet. It’d be much more convenient to send samples+pattern data once (which is often several megabytes), then simply exchange new pattern data after that (a few kilobytes at most after compression).
The way I would like to see it approached though is that the “keep on disk” option would be in the individual sample properties, rather than a global setting for the whole song. This way you can choose to keep redundant samples on disk but also have the ability to include a new sample with the song (or choose to re-send a modified version of an existing sample) the next time the song is exchanged with your friend/colleague.
Anyway, this is beside the point really. I personally feel that more flexibility when it comes to the song data and other options for new workflow methods can only be a good thing.
Not everybody would be happy to distrubute a song containing separate samples.
If it is just the problem that you suspect you have to manually wrap everything up:no that is what Renoise will do for you.
having separate samples have some advantages, but i think it have more disadvantages. I want to be sure that if o make a backup of the song or something like that, then i have all samples there… I have huge sample library and if renoise will just link to samples and i for example move some samples there to another place or directory then i dont want to discover one day that my song cant find samples i used there
Also if programs start to link to samples then i would have to copy samples to another places from my library so i can edit them and not ruin them in my sample library. FL studio links samples and i really dont like that. In renoise its very good, i just load some sample up and can mess with it as much as i want and be sure that i didnt change the original one that my library contains. It can also lead to conflicts when i compose a song with some sample and then compose another using the same sample but i etit it a litle bit… and then that edited sample will also be in my first song and it will sound different
Is it too much to ask for some specifics on how this issue is being dealt with?
This mystery-meat treatment for something as significant as a format change is something i would like to see the end of.
It-Alien, not to be a bitch, but if you don’t see how external samples can be a detriment to some users, you need to broaden your scope a little.
Sending a file back and forth. Some of us do edit samples IN renoise, and the render-to-sample functionality also figures into this. When i coop on a track, i don’t want to send a rar with 95 files and HOPE my co-operator will overwrite the right files on his end.
DOES the new file format reference waves on the HD or don’t it? This is the crux of the problem. I take my work with me a lot, i DON’T necessarily take my entire sample library with me. I produce on a workstation, but play live with laptops.
If the new format is like an archive file that holds an xml file and samples, i’m totally happy with that, but if it works in the way that users have to be careful not to mess up the prerequisites for renoise to do its job well, that’s a significant portion of users eventually going to swear loudly at you.
The very simplicity of the rns format is part of the reason i have been able to push this thing on people. I kid you not.
I don’t get the secrecy about this, from what vvois and bantai has said this decision seems written in stone, so why pussyfoot around the issue so much? How about releasing a specification, or making us aware of how your changes are going to alter our lives, if this will be the case?
Here’s hoping the change is either optional or utterly similar to the current rns file format with regards to functionality.
And i’m still concerned with the way this XML will be formatted. I’ve seen far less complicated data in XML look like someone took a lawn mower to a yard full of dogshit, so i pray you know exactly what you’re doing. XML for the sake of XML is a bad, bad idea.
As Bantai said: Nothing will change for the user. The new format is saved as one single self-contained file. No folder. Just one file as it is now. You have to extract this file with some tools (unzip it) to see its sub components. The sub components are one XML file with the document structure, and a folder with all the samples that the document uses.
About using XML: XML does not solve everything, and your mom wont be able to write new Renoise songs with just a text editor then, yes, but have you ever tried to read or edit a binary file? Try the current Renoise song format. Compare it with that. The new format will just make us and third party developers happy. Users will never never have to extract or edit these files. Further we choosed XML, because there exist so many APIs and tools that already support it. Reinventing the wheel would be quite stupid here…
It all depends on what you desire to do with the XML data outside of Renoise as it isn’t intended for an ordinary user to fumble with it in the first place.
When i have to take your remark as concerned from a third party developer point of view, i would say:be pleased the next format will be open in the first place and that you get a format that is humanly readable and workable.
My hopes are other music applications would take the same example so that content conversion between host applications can be done much easier.
Well, we already agreed on replacing most of the existing commands and advanced features by using a very advanced and complicated script engine, but we all figured that you would probably pull out all of your grey hairs if you had to suddenly code your actions rather than have intuive buttons do the lots for you automatically.
If you aim for a compo that shares a samplepack, you would need tools to reassemble the complete rns song as the song archive does contain the samples.
And also:you would limit the possibility to alter and manipulate samples, how would you parse an rns xml that is based upon altered samples?
I thought about an “zip”-archive-format where the Meta-information about the track is xml and the binary-data is in a subfolder.
Unzipping is not problem with PHP and after I unzipped the archive, I have a fine XML and in a subfolder the binary-samples (at least that’s how I’d do it)
i just replyed to dBlue 
