Very long loading time at first then very quick if reloaded...

[Sylv1o]

Hi,

I noticed that the loading time can become very long when using many samples... Of course it's normal that using more samples leads to a higher loading time but... More than 30 seconds for a 400mb library is abnormal IMHO.

It is also to be notice that once the instrument has been loaded, you can remove it, load another one, and then if you load the fisrt instrument agian, the loading time is divided by 5 !!!

I'm about to release a big work and this thing is now my biggest concern... Something to do here ? I'm convinced there's soething wrong here...

What is strange is that the problem is "cross DAW" : I mean that if you load a big instrument in Sfizz vst in Cubase, it's very long. Then close Cubase, open Reaper, load the same instrument : it's 5 times faster to load... To get the long loading time again you need to restart the computer....

Last thing ti notice is that SFIZZ vst show 1.2gb of used memory for a 400mb livrary (FLAC)... 630 mb vor a 270mb library... Abnormal too ?

Please, help !

[michael02022]

This is due to FLAC compresion in the library. AFAIK sfizz has to decompress the samples and then load it in memory (that's why in memory is huge while in storage is small). And of course the time to decompress it, the number of samples used and so on contributes to long loading times. If you use WAV for the library, it will load them a lot quickier since there's nothing to decompress.

If you really want to load libraries quickier in the first load, the most viable solution is to convert the library to WAV.

I believe it could be optimized, but that's the explaination I can give why that happens.

[Sylv1o]

Hello, no sorry, wav or flac, same thing on the first loading, about 30 seconds for 620mb wav file. Soooooo long... And fact is that once loaded somewhere (in sfizz vst in Cubase for exemple), if you reload the same instrument somewhere (cubase or reaper) the loading time is very fast, which is a very strange behaviour.

Please Help !

[Sylv1o]

I should have mentionned that it's a percussion library. So samples are very short but I use many (multi mic, round robin and many velocity layers). So all is loaded in RAM, not only the begining of each sample (hint_ram_based=1)

[essej]

I should have mentionned that it's a percussion library. So samples are very short but I use many (multi mic, round robin and many velocity layers). So all is loaded in RAM, not only the begining of each sample (hint_ram_based=1)

That was a very important detail to specify! Of course loading it all into RAM will take some time. As for the "weird" second time faster loading, I am almost positive this is due to OS level file caching... once those have been loaded, the OS has those filesystem pages in cache and re-reading them is coming from cache instead of disk. What operating system are you using?

[Sylv1o]

Windows 10. 30 second to load 400mb is normal to you ?

[Sylv1o]

The samples are stored on a SSD of course.

[essej]

I'm guessing the more files (regardless of their length), the more overhead there would be. I'm happy to test on my Mac system to see if the same sample set has similar behavior on my system if you want to contact me privately.

[Sylv1o]

Thanks, I will do. Just my instrument are not SFIZZ compatible, I use the sfizz module of Synthedit, and loading it in sfizz work but you can't here anything (cause the CC are set via synthedit, not with a dedicated file). So either I send you the instrument as it is, and you could just check the loading time, or I make an instrument compatible with sfizz... Stay tuned, thanks i advance

[Sylv1o]

Call me stupid, I can't find how to contact you in private... Are you on discord maybe ?

[essej]

Call me stupid, I can't find how to contact you in private... Are you on discord maybe ?

Yes, and I thought I already contacted you yesterday on discord since I’m pretty sure we’ve talked before. I’m Sonosaurus there…

[Sylv1o]

I'm guessing the more files (regardless of their length), the more overhead there would be.

Seems true indeed. I set SFIZZ to load only 4kb of each sample in RAM, set hint_ram_based=0 : loading time is still the same.

About 3000 files to load in some instruments... Nothing to do to load them faster ?

[Sylv1o]

Hi, I've just tested a super light windows10 version (debloated by an expert). On this system, indexation has been removed and my instruments load super fast each time.

So indexation is maybe not the real culprit. I'll try to investigate a bit more, windws defender could be part of the game... But I'm not an expert.

[Sylv1o]

Ok, verdict : just stop windows defender and big instruments that use several thousands samples files loads in few seconds... Activate it and this stupid defender scann each file each time its memory is erased (rebooting or intense use with other software), resluting in super slow loading, more than 30 seconds instead of 5....

Any idea how can we tell this stupid defender to stop scannning the same files again and again ?

[Sylv1o]

Adding an exception to the folder should do the job. I'll try

[Sylv1o]

This is what I wrote on the Synthedit yahoo group about this issue, if someone here read me, SFIZZ seems so asleep for mounths...

"Defender exception works. Now I have to find a neat solution to warn users that Defender cause very long loading time, and to give them an easy way to add the sample folder to Defender expections. Powershell really seems the way to go.

One question remaining , why other drum sampler don't suffer the same long loading time ?

I suspect that it is the number of files that matter. For exemple, Superior Drummer 3 uses packages of files which embed probably thousands of samples in one file. Defender probably just check if a file contains some executable, so the size of a file don't matter for him, just the number of files.

So, clealry, the best system would be to use many samples in one file...

In fact it's already possible with SFIZZ, you can specify the begening and the end of a sample in a long wave file... But what a mess to use... And acces time to a portion of a sample is unknow... If ever it adds few ms of latency, it's wothless.

It would be much better if we could load one file containing a batch of samples... But it's a SFIZZ problem, and SFIZZ is asleep for mounths... "

[Sylv1o]

Just an update to say that I ended up to convert all my sample library to use one wave file pr Mic/Arcticulation instead of one wave file per Layer/Mic/articulation. Having about 40 times less wave files solve the problem. Now I use Offset and End opcode to tell sfizz were the layers are. It was a hard work to convert all my sfz files but it worth it.

So if you plan to use many layers and multimic samples, you should definitly avoid to use one wave file per layer/Mic /articulation or Windows defender will not be your firend at all.