Faster instrument pre-hearing and song saving/loading.
Disadvantage:
XRNS saved without the samples will ask for them.
Optionally longer Renoise start-up.
Note:
The idea seems like made out of two separate ideas (non-self-contained XRNS + preload at startup), but it just goes along and would be comfortable.
File structure:
External samples will be these: “Renoise\External Samples[hash].flac”.
E.g. “Renoise\External Samples\d41d8cd98f00b204e9800998ecf8427e.flac”.
If "Use External Samples" setting is enabled:
When Renoise starts up:
If "Preload External Samples At Start-up" setting is enabled:
Preload all external samples from "Renoise\External Samples" into a map<hash, loaded>.
When a sample is saved:
1. Create a hash of the sample and stored it in the XRNI instead of the sample.
2. Saved the sample as "Renoise\External Samples\[hash].flac".
When a sample is loaded:
If there is a hash of the sample:
In this case there won't be the sample inside the XRNI, it's either hash or sample.
When the hash is found in RAM in the map<hash, loaded>:
The already loaded sample will be used.
else:
The folder "Renoise\External Samples" will be searched for the hash. If it was found:
The sample is loaded into the map<hash, loaded> and will be used.
else:
The user is told that they need an external sample with this hash, along with the name from the XRNI.
The sample slot will be disabled (see "Plug-in not found") to prevent killing the reference when saving the XRNS.
When a sample is unloaded:
If it is external (the hash is found in "External Samples"), the sample will not be unloaded from RAM.
I am hazarding a guess that this will come when Redux comes. It wasn’t too much of an issue before 3.0 because of the tiny samples per .xrni cap, although still annoying if you’re working with large recordings and you have to wait for them to be rewritten every time you save. But with the increased sample cap it seems like the logical next step.
If nothing else we’ll be able to just use Redux in Renoise, but I feel like the next Renoise update after Redux comes out will likely just have this feature.
That would be neat… I’m not a fan of the long saving times. Plus it would be cool to be able to easily index the samples that are currently zipped up in the .xrns
Oh so it’s that that causes the saving to take so long?
yes. a .xrns is self-contained (music data + samples, excludes plugins). so when you save, it saves all the samples as well. if you’ve got lots of samples, or big samples, then it takes a while.
Less disk space being used. Especially when working with large samples, and multiple versions of the same song.
Ability to craft different sounds from the same set of samples (with 3.0 we lost the ability to alias a sample, this sort-of brings it back)
Faster saving time (obviously).
Bad things
There is opportunities for screwing up a lot of things if you (or someone/something else) mess with your sample pool.
We are used to the selfcontained nature of an xrns. I would like to (still) have the option to save self-contained songs and instruments.
As for preloading samples - hmm. Not sure if this is a good approach. You’d often want new materials to craft songs from, so that folder would have to be “managed” quite often. Not to mention the increased startup time. Here, “pluggable” sample libraries seem like a much better approach.
^Oh god yeah, I would never dream of removing the typical self contained style we’re used to, that’s too important to its identity as a tracker and would also be a pain in the ass. Just, if we had the option to designate an .xrni as external, and an option to load an existing .xrni as external, that would be tremendously helpful. Noone wants external handdrawn single cycle waveforms, hell I won’t want most of my samples to be external. But large drum kits and recordings (like guitar, vocals, etc.) really need to be external.
Also this would open up the realistic possibility of implementing a “save as new version” feature like Reaper.
As for preloading samples - hmm. Not sure if this is a good approach. You’d often want new materials to craft songs from, so that folder would have to be “managed” quite often. Not to mention the increased startup time. Here, “pluggable” sample libraries seem like a much better approach.
You’re right. The aproach with one such library (“external samples” folder) came into my mind because these days I mosty do song with general multisamples, nothing that would be specific to a song or genre (or be there to craft a new song).
As for the loading time at startup: What about just marking these hashes for a “stream-load” at the time they are played the first time, and when that happens it would immediately stream an uncompressed 32-bit-float-file memory mapped from disk and by that also load it into ram? Loading times absolutely gone, just more cpu usage on the first play.
I would really like to see long samples being saved in a folder outside the xrni… when the xrni gets larger than 500mb it becomes tedious and difficult to save, despite using an SSD. Every “save” has to be planned
I would also like to see this. But definitely as an option. Like Tracktion does it. You can save the project, or you can create what they call a Traction archive (which would be the XRNX equivalent).
Hopefully these options (external XRNI’s and external samples in them) will be close behind when Redux is out. To solve stuff like thisand really push XRNI as a format.
One major consideration is that if you have external samples, you need some process for locating missing samples. Even if it’s just requiring the user to point to the new sample location on disk, one by one…
Let’s just edit XML to begin with. But yeah…shouldn’t be too hard to implement something like NI’s (auto)locate missing with optional starting points and so on.
While I love the self-contained nature of an xrns for my own production, +1. Once tried to run an outboard mix session to 2 track into Renoise, each take as its own instrument. Had to wait until the band needed a break just to save.
Renoise and Redux already have robust sampling abilities, having an external sample saving option would make them much more viable for large sample libraries.
I would still love to see this personally, definitely making it optional “per instrument” as the self contained nature of XRNS files is still awesome.
One thing I would add, if something like this was ever implemented, I’d love to see the ability to define a “root” folder for user samples, to make it easy to share projects across different computers/platforms.
For example:
on my Mac laptop I point Renoise to a folder called “/Volumes/Stuff/MySamples/” as my “external sample” folder.
I create a project with a sound using an sfz library stored there. And designate it to be store externally.
On my PC I have an “external sample” folder at a different location “D://MySamples” which has a similar folder structure and contents to the one on my laptop.
If I load the same project on my PC Renoise will search “D://Mysamples” for the files that were previously found on my laptop.
As long as we keep the same contents on both sample libraries we can have portability across machines.
I also would like a new saving philosophy with local samples/instruments.
saving many versions of a song can quickly eat up a lot of disk space. Also saving all the samples each time the song is saved can take a long time if you have a lot of sample time inside of the project. Would be nice to have a quick save option, that is valid as long as the instruments/samples are untouched.
Ofc for backup and distribution purposes the old way of saving everything inside of a container would have to remain an option.
Maybe a function just saving a single Song.xml.xrns or so, and link it to another .xrns file to fetch the samples from. As soon as you add or edit samples (other than remove or reorder), a new complete .xrns would have to be saved.
To solve stuff like