Load from Purge

[Christoph Hart]

Hi everybody,

I'm currently working on along requested feature where you could skip the preloading of the sample until it is about to be played for the first time - this reduces loading times of super large sample sets.

I've got the basic functionality done but I'm a bit undecided about the interface:

1. There is already the Purged attribute, which is either 0 (not purged) or 1 (purged) and I could add another value (maybe something like 2) for a "Play from purge" mode. Selecting this mode will unload all sample's preload buffer and reload it one by one when the samples are played.
2. I could make this a dedicated attribute which acts independently from the static purge state.

I'm currently leaning towards 1., but maybe I'm forgetting a use case where the second solution is better, so let me know if you disagree.

[d.healey]

1 sounds good to me but I'd like to hear from someone who's used this feature in Kontakt because I never did. They may know something we don't.

[d.healey]

Actually the more I think the more 2 sounds better. I can think of scenarios where you want some samples to always be loaded, like if there is a background drone that triggers with every other sample.

So I think a per sample or per group setting would be better rather than per sampler.

The ability to purge per group would be very useful in general, for example allowing a user to purge individual round robin groups or articulations.

[Christoph Hart]

Hmm, that wold be option 3. But making this a per sample property will complicate the implementation pretty drastically with lots of implications of the data model of samplemaps and possible order of initialisation issues (eg. it gets loaded by default because the sampler has a "unpurged" state, then unloaded because the true property of the sample is true).

And in your example the background drone would be preloaded the first time along side with the other sample and then it's loaded so I'm not sure whether this is a strong argument for the per sample property.

But this is also an argument for 1. vs. 2: having this as a single attribute together with the purge state gives me the option of implementing the loading inside one function call which might prevent double loading, eg. if you first call "purge = false", then "load from purge=true", it will first load all samples, then unload them again which is super pointless.

[Christoph Hart]

BTW, ChatGPT says this when I paste my first paragraph into the chat line:

It might be more intuitive for users if you implemented the "Play from purge" mode as a separate attribute, rather than adding another value to the existing Purged attribute. This way, users can still use the Purged attribute to control whether a sample is preloaded or not, and the "Play from purge" mode can be used to specify that the sample should be loaded just before it is played, rather than at the beginning.

This approach would also allow users to use both the Purged attribute and the "Play from purge" mode together, if they wanted to. For example, they could set the Purged attribute to 1 to unload the sample's preload buffer, and then set the "Play from purge" mode to 2 to specify that the sample should be loaded just before it is played.

It's also a good idea to consider how you will communicate this feature to your users. You might want to consider adding documentation or in-app explanations to help users understand how the "Play from purge" mode works and when they might want to use it.

[d.healey]

@Christoph-Hart Well it looks like this chat bot gives more useful answers than I do. Dave.exe has stopped working.

[lalalandsynth]

@Christoph-Hart this is crazy , speechless.

[ustk]

@Christoph-Hart ...

[Christoph Hart]

Alright, I've added the feature using the first option as this is most convenient for the standard use case.

I've also thought a bit about the option of purging only a subset of the samples and I added a function Sampler.purgeSelection() which you can give an array of sounds and it will purge only those (while unpurging all other sounds).

// I'm pretty sure nobody knows that funky function...
var list = Sampler.createSelectionWithFilter(function()
{
    // it will be called with every sound as `this` object and you just
    // need to return true if you want it to be included in the list...
    return this.get(Sampler.HiKey) > 72;
});


Console.print(list.length);

// now you can purge every sample that is mapped above note number 72
Sampler.purgeSampleSelection(list);

I'm curious how it will hold up in a real world use case, but the only problem I can see so far is that changing the purge state of the sampler will overwrite the "custom" purge selection so you need to make sure you call this method and restore the sampler in the correct order as the information which selection must be purged is handled on the scripting layer alone.

It might be one of the things that I'll regret adding like the Ghost panels, so take this feature request with a disclaimer that I might remove it if it becomes too annoying :)