This could happen if using many sample layers with short samples that are mostly preloaded. The preload mechanism acts per-sample. The engine can’t make any assumption about how notes/sections are triggered, so it loads a little bit of each sample. If you use a lot of short samples, you would end loading ALL.
OK! Note-on preload is re-implemented so now preset preload works like this at the engine level:
-
Engines define a flag “allow_preset_preload” that allows to enable/disable the preload for the engine. This is currently hardcoded for each engine. The list of engines with preset_preload disabled:
- Audioplayer
- MOD-UI
- PureData
- SooperLooper
-
Engines define a function “allow_timer_preload(preset)”. This function can be implemented for each engine. The default function returns “True”. For sifzz and Linuxsampler there is a customized function that returns “False”, what enables “note-on” preload instead.
Next step would be to implement soundfont size calculation so the function can determine accurately the soundfonts to preload using the timer behaviour.
Anyway, the current implementation works quite well and perhaps you are happy enough, so we don’t need to move to the next stage 
Enjoy!
4 Likes
Just tested it, it’s great! I mean, what would be great is to set it up in webconf for certain groups of engines.
Regarding the size calculation. It might be you’re right on this recent question. “Note head” preload of sfizz is around 32000 samples, which is somehow exactly 2/3 seconds. This means that drum libraries are loaded by at least a considerable amount. This again means that size itself isn’t the key, but the ratio of size and number of samples. It would mean that a 1 GB organ library with 50 long samples loads quicker than a 1 GB drum library of 1000 short samples.
Alternatively we could check if lowering the cache size would affect the performance.
1 Like
It would be great to have a good real-case analysis to find the sweet spot for the sfizz preload parameters.
Step by step. I think i have implemented a good foundation that leaves us room for improvement.
1 Like
Do you know a way to measure sfz loading times?
- Drums - 1370 M - 5200 files - ~5s
- Drums - 463 M - 539 files - ~0,5s
- Brass - 888 M - 425 files - ~0,5s
- Brass - 114 M - 144 files - immediatly
- Organ - 916 M - 254 files - ~1,5s
- Organ - 3240 M - 1020 files - ~6s
- Strings - 2380 M - 3137 files - ~13s
- Piano - 1000 M - 358 files - ~2s
- Piano - 1380 M - 2 files (monolith) - ~20s
- Perc - 40 M - 250 files - ~1s
- Vibraphone - 1220 M - 798 files - ~6s
Loading times are estimations, size and filecount are the total folders, so including scripts and all, but all are single scripts, so we can assume all samples were loaded.
What’s pretty obvious is that file count is more important than size.
When preload is visually indicated I’d consider up to ~2 seconds ok. Which would mean that the sweetspot would be at around <500 files logical AND 1 GB maybe, assuming there is no Monolith inside? Maybe the amount of regions is the determining factor then.
Yes, thanks! Works fine this way! I’m happy!
I’m not at my zynthian so can’t do treats but logically it feels like we could have banks that preload. I would expect any other platform to allow loading a sample library then to select patches/instruments within that library instantly. I don’t use sfz often so may be missing something but could we organise the libraries so that selecting a library preloads it and then selecting an instrument within the library plays instantly? I wonder whether we have created an artificial problem by how we access the libraries?
The “libraries” are actually instruments, i.e. single patches and sometimes are that big.
If you refer to these: These are single instruments. One drum instrument containing 5200 files, which are scripts and single note samples for this instrument.
So, if loading libraries / instruments can take a long time (many seconds) then we should avoid that which is what @jofemodo has done. We should really add a display of load progress so that we can see what is going on. We have the busy mechanism that could be used for this which can show an animation during loading.
1 Like
Yes, I think so. Finally loading the instrument already has a visual feedback (with no progress indicator though), but preload has not.
Please not!
I think @jofemodo 's solution is very elegant.
If the preload on note-on is removed again I’m no longer happy!
A progress indicator is fine, but as an extra, not instead of.
I really HATE preload on note-on. That means, mute output, change sound, hit an extra macro on the keyboard (or simply hit all needed notes) to load the sounds, then unmute output and continue playing.
What a crippled $'!+!
When coosing a sound, one has to know by experience that this one sound loads longer than others, but after all, it is loaded reliably. Scrolling past a sound means it will not be loaded until timeout. That is how it should behave. And this is how other instruments, E-Mu, whatever, behave.
There could always be an option to kill the process when scrolling past during sound selection, in case preload had been fired up already, but this would waste an amount of RAM until garbage collection kicks in, then taking the sweet little cycles away from the CPU… and the next one complains about Xruns!
Please, do not disimprove the working system!
Leave a bit of responsability to the user!
If one does not want preload, ok, they shall deactivate it by unsetting an option.
The approach of limiting options is a path started by Apple with their Macs, many years ago, and suddenly people found themselves forced to jailbreak their own devices. They have learned from that and now it is more open again. M$ now follows years behind, leaving their windwoes now a clikck-and-submenu-dive heap of garbage.
I just call it “bestriding the commodious”!
Or the supid? Who knows… ask AI?
1 Like
Can one consider this as another well gallant vote for user defined preload action?
Not sure if the comparison to other instruments stand because I don’t know any instrument where you can theoretically add terrabytes of custom sampled instruments. Time dependent preload for me is the best option among all of them, given you must not go make you a cup of tea after you scrolled to the wrong instrument.
Have a great sunday!
Perhaps you are confusing preloading with loading a preset? You can always load the preset by selecting it. This has not changed.
Preload is not intended for stage.
Preload is useful when you don’t know exactly the preset you want and you are browsing the list and testing with different ones, so you play some notes to test the sound and, if it’s not the one you are looking for, test a different one. This is the intended workflow for preset preloading.
We can’t pretend users remember how much takes to “preload” every preset in a long list. Indeed, if i could remember this, i would better use my neurons to remember the sound itself so don’t need preload. I would load the preset directly.
It’s not acceptable to have preset browsing blocked for several seconds when preloading heavy presets, so we need to prevent this to happen. As currently we don’t have a mechanism to cancel preset loading once started, we need another solution. This is the reason i have re-enabled note-on preload for sfizz and linuxsampler and it works quite nicely, at least from my POV. (I suppose you tried before complaining … right? 
)
This solution is not perfect. I would like note-on preload were only enabled for “big” soundfonts, so i have prepared things to allow this to be implemented easily. For this to happen, we need a reasonable way of measuring the “preload time” for a soundfont. This is not a trivial task. Perhaps we could implement something like this:
- launch preload for first time
- measure the time it takes to preload
- cache this value and use it next time to decide if we should avoid preloading
This is a simple scheme, easy to implement and that will work very nicely. The only issue is that first time you preload a soundfont, it could block the browsing for a bit.
A variation could be defaulting to note-on preload when no preload time value is cached.
Of course, if we would have a mechanism to cancel preset loading, this would be the best solution, but this is something that needs to be implemented in Linuxsampler and sfizz.
Regards,
I’ve tried in the past. Loading a set of effect samples resulted in pauses on every key, until all had been triggered at least once. Then came that preload option and it takes a while to load a preset after staying too long on a preset in the list, exceeding the timeout, but all samples worked on the spot.
And yeah, I’m stupid enough to play presets live from the list…
This is much easier to switch presets, when using Zynthian just as an expander, instead of going back to mixer and returning to preset list later.
And yeah, my three neurons – two of them mechanical and constantly ticking while the third is always complaining – do remember the sounds and know the ones that load slower. 
I think you are confusing things. The preset preloading mechanism is not related with this issue:
Loading a set of effect samples resulted in pauses on every key, until all had been triggered at least once.
This is normally related to slow SD-card access. Perhaps you updated your SD-card, or your RBPi to a higher version.
Please, try current implementation and if you find it unpleasant, then you can complain, but complaining before testing things is not much fair.
All the best,
BTW, “visual feedback” for preset preloading is already implemented. Simply update and test.
All the best,
3 Likes
For me that is not necessary. I don’t think the (very small) time saving is worth the effort.
Works perfect, thanks!
2 Likes
When thinking in this direction please note that when I did the “measurements” above I had some soundfonts that occasionally loaded very slow one time and shorter the subsequent times. I don’t know the reason.
I’m honestly still not a huge fan treating different patches of the same engine type differently. I’d do the behavior user definable but consistent.
1 Like