Hi @jofemodo
I just created a pulll request (I hope I did this right, it’s the first time) for issue:
I really miss the preload on NoteOn option. For soundfonts the current solution is not workable.
I added the option to the Admin menu, so it’s easy for others to enable/disable it if they like:
The PR is
I hope it’s not a matter of principle you removed this. Will you please merge this if it’s according to you standards?
Kind regards,
Hans.
Hi @HansR !
Why do you say this? It works quite fine for soundfonts, at least for me.
Please, understand me, i’m not saying it’s perfect, but from my POV, it’s good enough.
Please, could you give some specific examples of how the current mechanism doesn’t work for you? A video could help …
Thanks!
Yes and not. Zynthian is too overloaded of features and config options, so i try to remove as much as possible from the menus and think twice before adding more.
Regards
This is a challenging problem. There are many different engines in zynthian which each behave differently. It would be fantastic if we could preload the preset before playing when auditioning in the presets list but some engines are very slow to do so, making this a poor user experience. We try to optimise this per-engine to give the best user experience but this has the side effect of some inconsistency in behaviour between engines. Any optimisation in this area is welcome but as @jofemodo says, we want to minimise the configuration choices and ideally, just make it work as best we can for all users. Specific descriptions of what doesn’t work for a user helps in this aspiration.
I think we discussed that before, but I agree with @HansR .
If you prefer very advanced and therefore huge soundfonts, you literally get stuck in the menus. I have quite some big drum (Virtuosity Drums) and brass sample libraries with a couple of GBs and don’t dare to navigate these menus lazily. Some libraries need up to 10s to load. Given you know what you want to load this library will be loaded twice anyway.
Switching preload off means you cannot use it with synth, which is were it really shines.
Raising the idle time doesn’t really help, because navigating huge menus causes “idle” times of couple of 100s ms if you aren’t an artificial inteligence.
Granted, if you only use 100MB-ish soundfonts it is not an issue.
So maybe giving the option of seperate setup for samplers is one solution. The note-on preload is another or can be combined.
By the way, aren’t there free encoder push actions in the preset menu? Maybe we add a preload push action.
(Another solution would be, without knowing if it’s possible, to stream from disc only while preloading and load it to ram only when fully loaded)
We could customize preset preload on soundfont engines, like sfizz, linuxsampler, etc. and prevent timer preloading with big soundfonts. Then use note-on preload for big soundfonts only. I think we could implement a nice hybrid solution, totally automatic, without adding extra configuration parameters. What do you think? What would be a good limit size for this?
Regards,
@hannesmenzel 's post above says it all
Understandable. From my point of view, the load on browse option can be removed 
As far as I’m concerned all soundfont (sfz and sf2) players (or even, all samplers if that’s easier to implement), regardless of size.
From my guts I would say about 300M. But it is possible that other parameters are important. Some of my problem scripts e.g. use sub scripts with include statements, but not sure if it’s the cause.
But I would maybe consider it confusing if some soundfonts preload and some do not.
Here are some of my ideas, while I don’t know if these are possible:
The option to interupt preload is preferable if it can be made to work. This way we have the dynamic menu response we expect and auto loading of presets. Slow loading presets would have some latency before being available but that will always be true. An indication of preloading would also be beneficial to give an indication to the user that the sound is not yet ready, especially on slow loading presets.
Agreed. Apart from that, I don’t see any benefit in a different approach for smaller fonts. If the soundfont loads quickly, it’s no problem if it only loads on note-on. The difference between load on browse and load on note-on is minimal.
However, searching the current preset list does not benefit from ‘load on browse’; it actually hinders it.
If it’s not possible (I don’t see any abort loading patch option in the sfizz man page) then at least the menu navigation and the loading could maybe somehow run “in parallel processes” or however you wizards call that.
True. The only issue with note-on is the little clicky sound it sometimes produces due to loading on just note-on. But that’s a minor issue and otherwise, when should be a good moment for the preloaded sample to play than on note-on?
I think the clicky sound is only produced if a note is still sounding.
It definitely sounds like a sudden signal jump, so it might be from a suddenly silenced previous note or a preloaded note that is just loaded after the attack phase. But anyway, I find that acceptable.
You can then simply press “SELECT” to load the preset. IMHO Having to perform a specific action to preload is against the very concept of “preload”.
Using the note-on is kind of acceptable because you play notes to test the sound, so it’s an action you are going to perform anyway. Listening the first note you play with the currently loaded sound (before preloading) is bad UX and one of the reasons because we changed to the current approach, that is, indeed, the most extended approach (most software do it like this).
This is already implemented, as much as possible (we cancel the previous timer), but we can’t abort the preset loading operation when it’s sent to the engine. Sfizz nor linuxsampler implement the option of cancelling an ongoing preset load.
This is already implemented by linuxsampler and sfizz. They never load the full soundfont in memory. Only the minimal needed amount to start working.
Complex. And it requires writing on disk, what takes space and it’s against our policy of reducing disk writes as much as possible. We could analyze this solution more deeply, but for sure, it’s not for now.
Regards,
When using the “preload on note”, the first note you play, plays with the currently loaded sound, not the sound you want to preload. This is bad UX and lot of people complained about this. Avoiding this “first note with the wrong sound” is quite complex to fix and we would need to tweak the MIDI routing in twisted ways. This is the main reason we changed to the timer behavior.
I could accept to restore the “note-on” behaviour for large soundfonts, but there is a subtle problem here, that is “knowing the soundfont size”. It’s not so simple and for doing this well, we should parse the SFZ file and then get the size of all used samples. Not trivial at all. If we want this to work nicely, we should consider to precalculate & cache this info.
Regards,
I don’t exactly understand this. For me while preloading the zynthian UI freezes completely.
I do not think this is true. When I (pre)load my 1.3 GB drum soundfont I can see in htop that exactly 1.3 GB of ram are occupied.
I think the internal sfizz note head cache is something internal and doesn’t have to do with memory allocation. Maybe they just fill a vector for each note head already, don’t know.
Yes. It does. It’s difficult to do in other way because of the way we interact with the engines.
Perhaps we could work to improve this.
I’m pretty sure that sfizz and linuxsampler use on-demand loading, unless the opposite is consigned in the SFZ file. If the SFZ tell to load ALL, then they will load ALL.
Regards,
Yes, this is the hint_ram_based=1 opcode which defaults to 0 and is not included in the above mentioned drum sfz.
Then both sfizz and linuxsampler will be using on-demand sample loading.
Regards,
Ok, let’s say aborting patch loading and improving the loading time by only disc streaming is not possible, in that case I’d vote for free up compute time for menu navigation during preload if possible, if not, having note-on preload or selectable action for soundfonts and definitely the visual indicator.
By the way, I just compared the preload time of a certain drum sfz (1.3 GB) with another huge trumpet library (900 MB) where the second one loads considerably faster (~5 s against less than 1 s). The drum library has many include statements and definitely loads into ram completely.