Override fluid_stat for in-memory soundfont loader

[sykhro]

fluid_sfloader_set_callbacks() at the moment allows to override the basic IO functions (open, seek, tell, close); it would be useful to override fluid_stat as well: currently, with the sample cache codepath, fluid_stat is passed the pointer that open() gets and it obviously fails as it's not a real file handle.

[derselbst]

fluid_stat is passed the pointer that open() gets and it obviously fails as it's not a real file handle

fluid_stat receives the filename passed via fluid_synth_sfload. And it then fails, because filename does not exist.

Pls. tell me a bit more about your use-case of fluid_sfloader_set_callbacks. We've invented it to allow in-memory soundfont loading. Is that your use-case? According to the heading of this topic, I assume it is. The question then is why you care about the sample-cache at all? After all, the only purpose of the sample cache is to keep samples in-memory when they are used by multiple synths, and your "in-memory soundfont" is already in-memory.

If you now gave me an argument, why the sample-cache is useful in your case and why stat() is also important in your case, then the question remains how to make stat overridable. You've seen that the stat_buffer argument heavily relies on the platform used. You've just simplified that nasty triple-typedef in your fork. How to deal with that via the fluidsynth API? I surely won't expose this triple-typedef via the fluidsynth API. Hence one would need to use a custom struct, with currently only one member in it. But what if for whatever reason we wanted to change some minor detail deep down in the sample cache, and use another member of the stat_buffer. We would break our API.

So, this is tricky.

[sykhro]

The question then is why you care about the sample-cache at all? After all, the only purpose of the sample cache is to keep samples in-memory when they are used by multiple synths, and your "in-memory soundfont" is already in-memory.

Well, I don't care much about sample cache honestly; while debugging I saw the fluid_stat() call failing and thought it could be a potential problem since, at least with my implementation of the callbacks, it tries to interpret the SF2 header bytes as a filename. I now realize there's no other place where stat is used besides the sample cache so it's probably not that important