External samples


(Mark2) #1

Advantages:

  1. Smaller XRNI (XRNS) size.
  2. Faster instrument pre-hearing and song saving/loading.

Disadvantage:

  1. XRNS saved without the samples will ask for them.
  2. 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.

(Carbonthief) #2

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.

I definitely agree it’s something we need.


(pat) #3

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


(Meef Chaloin) #4

Oh so it’s that that causes the saving to take so long?


(pat) #5

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.


(danoise) #6

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.


(Carbonthief) #7

^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.


(Mark2) #8

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. :slight_smile:


(ilski) #9

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 :open_mouth:


(fladd) #10

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).


(jiku) #11

Hopefully these options (external XRNI’s and external samples in them) will be close behind when Redux is out. :slight_smile: To solve stuff like thisand really push XRNI as a format.


(pat) #12

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…


(jiku) #13

Let’s just edit XML to begin with. :slight_smile: But yeah…shouldn’t be too hard to implement something like NI’s (auto)locate missing with optional starting points and so on.


(k_amlie) #14

+1!


(fifagifs) #15

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.


(Denim) #16

as long as such a feature would be optional, I’m all for it! +1