… please move the saving and loading functions into a separate thread. on some project it takes 30-60 seconds to save and windows reports renoise as “not working anymore” and asks whether I want to quit it… that’s a bit scary and could be changed if loading/saving was done in a separate thread while locking everything else at the same time.
Cheers 
ilski
Honestly, in the past issues like this were more rare because each xrni was limited to I think 256 samples. Still a problem for people working with long samples like guitar recordings. Now each xrni can hold approximately a jillion samples. This makes instrument grabbing more appealing, and it makes big multi velocity instruments like drumdrops kits possible.
So the point I’m getting at, and it’s brought up before, is I really think it’s time to move past the “everything compressed into one .xrns” paradigm. It just doesn’t work anymore. It already didn’t make sense if you used VST’s, you effectively kill the portability of an .xrns if use even one plugin. And now it just super doesn’t make sense to keep forcing it, because .xrni’s are getting larger. In your other thread I saw you had a project that was approaching 1 GB. My projects are getting pretty damn large too. It’s just happening as a natural consequence of the changes made in Renoise 3.0.
So we need external .xrni’s now. If you haven’t made a change to an instrument slot, you should have to wait 30-60 seconds for it to resave it every time you hit ctrl-s. If the only thing you’ve changed is pattern data, it should be possible for that to be the only thing that is saved when you save.
Other DAW’s save audio externally, so they don’t experience these long save times. I’m not saying it should be saved to only save .xrni’s externally, certainly I think it should still be possible to do things the oldschool tracker way. But external .xrni’s should be possible too.
I suspect and hope this change is coming with Redux, but who knows… and who knows when we’ll find out. Another year? Next week?
edit: Another point I want to make in favor of this, is that cloud storage is becoming the norm. Long save times really screw up automatic cloud backup programs, because they see the temp file Renoise creates while it’s compressing the .xrns and tries to back it up, and it screws up Renoise’s saving and it just fails to save properly. I actually have to turn off the syncing until I’m done working in Renoise, which kind of defeats the purpose of using the automatic cloud backup. Whereas in other DAWs, audio is saved externally and it’s just not an issue.
So we need external .xrni’s now. If you haven’t made a change to an instrument slot, you should have to wait 30-60 seconds for it to resave it every time you hit ctrl-s. If the only thing you’ve changed is pattern data, it should be possible for that to be the only thing that is saved when you save.
…
edit: Another point I want to make in favor of this, is that cloud storage is becoming the norm. Long save times really screw up automatic cloud backup programs, because they see the temp file Renoise creates while it’s compressing the .xrns and tries to back it up, and it screws up Renoise’s saving and it just fails to save properly. I actually have to turn off the syncing until I’m done working in Renoise, which kind of defeats the purpose of using the automatic cloud backup. Whereas in other DAWs, audio is saved externally and it’s just not an issue.
I’ve run into the problem of saving being blocked because some auto-cloud process (maybe Google Drive, maybe OwnCloud; not sure) locked a temp file. There are workarounds but it’s annoying, as is simply having to wait each time I save a largish song (something I like to do fairly often lest anything crash and I lose work).
But the One Big Binary file approach has another issue related to the comment about having to save every single bit for even the smallest song change: Playing nice with version control.
I have no idea how many Renoise users are also software devs or have some other reason to know about and use revision control tools such as git or mercurial or svn. It can be a real life-saver.
There are many times I want to try some variation of a piece, but not lose track of what I currently have. My method now is to copy off a version of the song file with a time-stamped name. What I would rather do is have my songs tracked by git so I can make easy branches and try out different settings, mixes, etc. Because of how git works this uses less disk space and is faster for moving around among versions.
Doing this with a single large file doesn’t work so nice. I’ve even given thought to writing a command-line tool to manage unzipping/re-zipping songs just so I can get better usage of version control.
So another vote for having the option of loading/saving songs into unzipped folders (the way tools are, for example).
I don’t even have so many samples, maybe 60… but they are long FLACs, like 10 minutes some of them. I usually cut away stuff in the sample editor, but sometimes you’re “work in progress” and don’t know what you don’t use yet.
I also sync stuff, but I use BitTorrentSync and it takes a few minutes over WIFI, but syncing over 700mb via internet after each save would be totally crazy.
One more thing which could be related is about that renoise loads all samples into memory and has no streaming from disk, which is cool for most people, but I know that I can’t go further than this project size anymore, especially when rewiring. I would like a streaming option (like autoseek) for long samples, with intelligent caching of points that you jump to (slices etc).
This would be amazing.
I haven’t had renoise crash on me, or get killed by the OS for taking too long…
but it is really irritating when it locks up to save a bunch of big samples.
I’ve given up on renoise with multiple samples of 60s or more. It’s just frustrating when it slows down…
Instead, I rewire it in to live, and when I want to record stuff to audio I just export / resample through live.
Live works great at handling big audio files.
revision control tools
It wouldn’t be too hard to do version control for Renoise songs, or any other Renoise format, in fact.
Since songs are saved as a zipped XML, you could come up with a tool that did XML specific diff’ing (specialized “dialect” of diff, better than normal line-by-line) and then a special UI could tell you which aspects of the song were changed.
The samples themselves are quite easily compared with checksum and likely wont change very often. It’s the UI and the logic driving that interface that would be the hard part to make.
I wonder if someone has experience usingSplice? They might have created something that actually works.
It wouldn’t be too hard to do version control for Renoise songs, or any other Renoise format, in fact.
Have you done this?
“you could come up with a tool that did XML specific diff’ing (specialized “dialect” of diff, better than normal line-by-line) and then a special UI could tell you which aspects of the song were changed.”
Cool. Let me know when this is ready. 
I mean, I can think of several different ways to handle diffing/versioning of an archiveof files, butwriting a robust tool that is is easy to use, highly reliable, works on multiple OS’s, and integrates wellwith git (for example) is non-trivial (at least for me).
Versus just having the files Renoise-ready outside of some packaging format (as tools are, for example) and you can use use whatever version control you like without a second thought.
I’m guessing that Renoise is reading the xrns file into memory,then unpacking that into memory as well. Perhaps it then frees up the memory used for that initial read. Reading straight from disk feels like it would be more efficient.
I agree an option would be good for large projects but I really really really love not having to search for missing samples ever. One of my fav things about Renoise.
I’m guessing that Renoise is reading the xrns file into memory,then unpacking that into memory as well. Perhaps it then frees up the memory used for that initial read. Reading straight from disk feels like it would be more efficient.
Just speculating, but to read the xrns I think Renoise asks the zip deflate for each of the files buried in the xrns. So, firstly renoise asks for the all important Song.xml file. The zip deflater reads in the xrns and writes the uncompressed Song.xml version to a temporary directory. Renoise then reads this Song.xml from the temporary directory. Parses the XML…blah blah. Renoise now knows all the sample file names, song structure and whatnot. Renoise then requests each of the samples from the xrns zip. So the unzipper grabs the first sample from the xrns and writes the (let’s assume flac format) flac sample to the temporary directory. Renoise then reads in the flac sample from the temporary directory, uncompresses it into memory etc… Move on to the next sample…rinse and repeat for all the samples in the song doing this temporary reading/writing of each sample file. Any VST instruments will also have to be initiated. That’s how I thought it kinda worked anyhow.
To be fair to the Renoise devs, while I (and others) can imagine how Renoise works and how it “just has to …” in order to useunpackedzip folders as song data, I’m betting things are not that simple in practice. (As a software developer Icringewhen I hear the words “just” or “simple”.)
It’s the sort of change you may need to really think through to ensure you don’t spin off some nasty side-effects (aside from the details of how to actually implement it).
In my ideal version, Renoise keeps using xrns-as-zip format, but if you unpack the file and Renoise finds a that an xrns file is in fact a directory it shifts modes. And would always copy/remove samples, etc., into that folder if you alterinstrumentand sample data. In other words, zipping up such a folder would always give you the classic Renoise song file.
Knowing that an xrns file has everything it needs so I can copy it off to some other machine is a really great part of this.
Hm, better structure, more options? Like regarding the current state as release/backup/storage format, but allowing the same data to reside in a directory structure on disk, and saving undo steps, saved snapshots, only altered samples, whatever. The “search for missing samples” might be a problem with not saving samples directly with the project, also samples can be altered in the sample editor like mad. One major wish feature of people with low cpu power or the “bounce something and use it further fraction” could also be splitting rendered stuff from “source modules” within a tune, allowing to traverse through a tree of baked stuff (i.e. rendered tracks, or samples), and changing things in there to quickly bake new versions. Let’s make the devs life real hard by asking for such stuff all day.
Now putting saving to an extra thread that wouldn’t block renoise would mean everything that has to be saved needs to be copied in memory first, because else you couldn’t work on while it saves. Not being able to work on would defy the whole point in this request. You don’t want messed up modules because you change something in the middle while it is written to disk. Ups the ram usage (whole module must be there x2), and will give a blocking delay, too. Also cpu resources get eaten away in the whole process. But maybe faster in terms of being able to track on then having to wait for everything written to disk.
nah saving in a separate thread just so the ui is responsive to the OS. you can still block the editing or make a modal progress bar appear or whatever.
totally agree on marking selected samples as “save outside or xrns”, similar to autoseek.