This is a RFC PR that attempts to support DLS as requested in #320 (perhaps also GigaSampler and SLI). I intend to bring this feature to the mailing list when it's ready, but for now, see this as alpha test.

This opens the door to other soundfont file formats by selecting at Cmake time the sfloader(s) need by the application. This is nice.

when loading a DLS file the defsfont loader complains that it's no SF2 file, which is a little annoying... one might need to rethink that

When fluid_synth_sfload() is called it uses all the fluid_sfloader_t loader (in the list) until loading is successful. Assuming the following loaders list: sfload1, dls loader, defsfont. When loading a file fails for sfload1, and dls loader this failure should be done silently. But when defsfont fails, as it is a sf2 loader and the last in the list it seems normal for a message to be displayed. Isn't it ?

But when defsfont fails, as it is a sf2 loader and the last in the list it seems normal for a message to be displayed. Isn't it ?

Nearly: The instpatch loader is the last one in the list. This is because libinstpatch would also accept sf2 files, which we want to be loaded by the defsfont loader though. Anyway, yes, a message should only be printed if all sfont loaders failed. However every loader keeps printing messages as soon as it encounters an "invalid" soundfont, which in fact is useful if an application only uses the API, but is annoying when using the fluidsynth executable.

I really like the fact that adding libinstpatch loader support to Fluidsynth seems to be fairly non-intrusive to the rest of the codebase. I know that it's not complete and still has issues (which probably means more intrusive changes), but still... I think it's a sign that Fluidsynth has quite a good architecture.

What I'm not really sure about is if it's a good idea to add support for other sampler formats to Fluidsynth. If the foreign format is less expressive than Soundfont, it would be fine. Same if the foreign format is exactly like Soundfont, just with a different file structure.

Where I have problems is adding support for sampler formats that are more expressive or that rely on features that are difficult to reproduce in the Soundfont model. Where loading the foreign file would mean that Fluidsynth would perform worse than a synth native to that format. We would have to be very clear about what users should expect when loading these files. Otherwise I'm afraid that we will get lots of "X can play this much better than Fluidsynth" bug reports.

TLDR: I'm very fond of the fact that Fluidsynth is currently focussed on being an extremely good (if not the best) Soundfont synth. And I'm afraid that if we open up to other formats, we will loose some of that focus.

PS: At least the linuxsampler code is a strange form of GPL, because the authors forbid the use for commercial projects (even if those projects comply with the GPL). Not sure if that also applies to the libgig code.

To clarify my thoughts: my opinion is that adding loaders for advanced formats like GigaSampler would only make sense if we would also change and extend the synthesis model at the same time. In other words: if we were to move more into the direction of LinuxSampler and implement different synthesis engines for the different formats. Otherwise we would simply add code that would make Fluidsynth a bad GigaSampler synth. And there is already a very good GigaSampler synth out there: LinuxSampler.

And I'm afraid that if we open up to other formats, we will loose some of that focus.

Sure, I understand this. I think that's a matter of documentation. We could claim smth. like limited or partial DLS support. Similar to like it's said in the sfont loader API:

This API allows for virtual SoundFont files to be loaded and synthesized, which may not actually be SoundFont files, as long as they can be represented by the SoundFont synthesis model.

We can keep this limited to DLS support for now, as this was the intention of #320. Citing ElementGreen, DLS and SF2 are very similar, except that DLS is "more" expressive because it supports 32 bit parameters, rather than 16 bit as SF2 does.

The idea of GigaSampler only came up because libinstpatch supports them as well by loading DLS files and then recognizing those as GigaSampler files. But I can't tell anything about the relation between GigaSampler and DLS.

In other words: if we were to move more into the direction of LinuxSampler and implement different synthesis engines for the different formats.

You're right. And I'm not intending to shift our focus. Fluidsynth should stay a SF2 synth. Supporting DLS just seems to be a nice idea as much/most/all (?) of DLS can be represented by the SoundFont synthesis model. And if there are any incorrect envelopes or attenuation calculations for DLS, keep in mind that there is limited / partial support.

As next steps I suggest:

1. Test more DLS files to figure out the current state of support (I have not been very successful in finding them on the web, if you have any it would be nice to submit them)
2. Test a very few GigaSampler files just to see how it works (well/barely/not at all ?) and how to treat them
3. Decide whether to go with libinstpatch or not (I'm confident though)
4. Fix libinstpatch upstream + new release

PS: At least the linuxsampler code is a strange form of GPL, because the authors forbid the use for commercial projects (even if those projects comply with the GPL). Not sure if that also applies to the libgig code.

No, it doesn't.

Fluidsynth should stay a SF2 synth. Supporting DLS just seems to be a nice idea as much/most/all (?) of DLS can be represented by the SoundFont synthesis model.

I agree, if DLS really is like "high-resolution Soundfont", then it seems like a very good fit and adding support is a good idea, especially as there is actual user demand for this feature.

I have not been very successful in finding (DLS files) on the web, if you have any it would be nice to submit them

To be honest, I had never even heard of DLS before reading the ticket. Maybe @frabert (the original reporter of the ticket) could supply some?

Your proposed way forward sounds good. And going with libinstpatch instead of libgig feels better to me (regardless of code quality / maturity) as libgig looks to be a GigaSampler library first and foremost. And using such a lib when we can't completely support that format would send the wrong message, I think. Granted, a message that not many people will hear or understand... :-)

Make use of libinstpatch to add sfloader seems a good choice. This should helps later to propose a virtual soundfont loader optional component (or at least documentation to do that). This kind of sfloader should simplify the integration of fluidsynth lib into soundfont editor application. Actually free soundfont SF2 editor aren't massive. Also there is few or none free SF2 editor integrating a full SF 2.0 synthesizer engine with modulators capabilities. Probably the reason is that data edition and synthesis are two jobs so different that coupling a synthesizer inside an SF editor is really a hard task for most SF editor developer. Thanks to this PR, libinstpath lib and author(s).

@mawe42 Unfortunately I do not have any freely redistributable DLS file, but every Windows copy ships with c:\windows\system32\gm.dls, which is used for General MIDI patches by the system's softsynth.

Meanwhile, I've tested a bunch of DLS files and they all play fine. Gig files are problematic though, because they currently cause lots of crashes in libinstpatch due to a nasty int to pointer cast.

As this seems to be a very popular feature, open TODOs right now:

• implement IO callbacks (postponed until really needed, only workaround possible, instpatch loader isn't currently public anyway)
• make sure it doesn't crash when dls font is unloaded while its samples are still used for rendering
• check for memory leaks (samples unloaded correctly)

Considering this ready for squashing.

@mawe42, @carlo-bramini Any of you available for a review?

Thanks for the quick review Marcus! Hope I've addresses all issues. (I should have executed make format earlier)

Will keep this open for another 3 or 4 days. Anybody, feel free to test or give feedback.