Oh so it’s that that causes the saving to take so long?
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.
My take on the pros and cons:
Good things:
-
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.
+1!
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.
as long as such a feature would be optional, I’m all for it! +1
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.
1 Like
+1
Yes, would be great to save versions without saving the samples all the time.
1 Like
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.
1 Like
Usually there’s also a clean up function to clean unused files.
1 Like
+1 still waiting for this to make versioning smaller.
Perhaps the best way to cover this issue is a cumulative save of several xml versions of the song, with the same sample pack, within the same ZIP.
That is, in a single file, several versions of the same song (the XML information) would be saved, always using the same number of samples. If the user deletes samples before saving, there should be an option that says “clean old samples and song versions” or something like that. Any changes to the layout, naming, or number of samples will influence previous versions of the song, and that needs to be fixed.
We save different versions of the same song so we can go back. The point is to be able to do it in the safest way possible. Having duplicate XRNS (ZIP) files somehow guarantees not to lose progressions in the same project.
For me this issue is not a problem, because I use a PC with a lot of capacity. But I understand that it is an important matter for laptops with little capacity or old computers.
Given the risk of this matter, this should only be a very clear option for the user.
The smartest person will tell you: “use an external drive or increase your hard drives. Spend your money.” But this is a very interesting option, closer to something professional.
This would allow sharing projects of different versions very easily. You know, when selecting a song to load, you will have a list to select the version of the song, which could be linked to the save date. Even this would allow you to save an entire album!
That would be magnificent. The point is to find a “smart” way to save samples without duplicating them and for the XRNS file to work correctly with all saved XML versions of the song.
To maintain compatibility, I would suggest a new format: XRNA, (if free).
1 Like