When working with projects that have very large instruments with many samples, the time taken to save an intermediate copy of the project can be significant, owing to the need to compress and package up the instruments into the .xrns file.
This might have been suggested and ruled out already, but how about having an intermediate “project file” format which doesn’t package the samples into the file, but retains them on disk (perhaps using the “bundle” principle similar to Mac OSX, whereby the project is a directory containing all of its resources)? This could be used for quick loads and saves during composition, with the final packaged .xrns format used for distribution.
shouldn’t it be possible to only recompress the samples that have actually been added/changed?
even if you first make a backup copy of the last save, put the changed stuff into it, then validated it, then overwrite the original with the new saved file, it would probably be faster than compressing all samples to flac and zipping them every single time a file is saved, no? and just as safe.
AFAIK, that would only take longer, because this means that the zip-routine would have to unpack the whole library to a temporary folder, then add the changed files and then pack the whole deal again.
At least that’s how most zip oriented programs seem to work.
Having a project folder with instruments / samples and song-file separated and then use the XRNS format by “Save as distributable” has my +1
no. unless the archive is packed as “solid”, each file can be deleted, recompressed, added, without having to RECOMPRESS the files that are not affected…
if zip can’t do that, ditch zip. but I would be surprised if it didn’t.
and Renoise already creates a temporary file, anyway. It’s just that it needlessly recompresses samples that have already been converted to flac and zip-compressed.
for me, it’s one off the best features that everything is in one file! we are talking about some seconds,right ?
i don’t want to have a cubase styled save model. so the first suggestion from johann is good. but all in all i think there is no need for a change, because saving needs max. 20 sec here (when my project is very huge). my average save needs round about 6 seconds, so what ?
it would still be nice to reduce those 20 seconds to 2 seconds when saving a file after just changing some pattern data… and those 6 seconds to 0.5
especially when autosave and a slow CPU come into play.
I’m all for a project style save format, but not to speed up saving, when that can (very likely) be drastically sped up without losing the convenience of bundled samples…
20 seconds is one hell of a long time when you’re saving frequently. We shouldn’t have to compromise on sample size/quality in order to keep save times down to an acceptable level.
Johann’s incremental ZIP idea sounds like it might work however, although I believe that modifying a ZIP does actually require creating a new file and moving data around, so it won’t be quite as fast as a project directory (but still much faster than recompressing every sample).
Another option would be to have a distinction between packed/unpacked .xrns files, similar to SVG files which can either include packed images or just refer to images on the hard disk. Unpacked .xrns files could similarly just contain paths to .xrni or sample files on the disk, rather than packing in the data.
Are you sure? Disk access is usually cached… and RAM = not a slow medium. For me, the big songs take most of the time at the “compressing to flac” stage, but of course it’s hard to know just by looking at status messages and making thought experiments… ^^
Reading a file from disk and writing it to a new file == slower than compressing to flac from memory? Is FLAC really that fast? I’d have to see benchmarks to believe that o_O
I would like this very much… maybe with an config option for maximum cache size and a sensible default… oh, speaking of that, is there a way to point Renoise to a specific temp folder? I’d love to use my Ramdisk, but I can’t point the system temp there because that can suddenly grow very big when installing stuff etc.
It is not only about time… if you have autobackup turned on and tell it to save 6 copies, you have 6 large files on your harddrive.
Imho that part could be done a little more efficient.
I’ld rather have 6 small song.xml files and then all loose samples on disk (using backup01/samples structure only containing the altered or added samples).
i know what you mean. as long as renoise saves the samples into the folder where the xrns is, everything is fine for me. i just hate the way how cubase handles this (i dont know how this works today), because only the sample location was saved. so if you delete a sample from the HD which is used by a song, the song is destroyed. hope you know what i mean. thats why i like the way how renoise handles this, no posibility to accidental delete a sample.
another thing is that i have to send folders around when i do a collab.
maybe my xrns files are not big enough to understand the save-speed issue
80% of my tunes needs 3-5 seconds for saving and this is fast enough for me.
a good solution whould be the possiblity to choose between old/new save style i guess.
