Proposal: DLS file loading

[frabert]

I am writing a DirectMusic compatibility layer of sort, and I found myself in need of a softsynth for DLS files, which are in principle similar to SoundFonts. Currently, my approach consists of feeding the DLS files to a converter that outputs SF2 files, which are then loaded normally. However, this procedure is expensive both in terms of memory and in time. If I were to develop a patch to enable FluidSynth to directly load DLSs, would it be accepted (if it met the quality requirements, ofc)? Please note that I have not yet looked into the FluidSynth architecture, so it's all speculative for now, but my main concern was for the "Based on SoundFont 2" tagline.

[derselbst]

That would be nice feature indeed, esp. for a major 2.0 release. I'm not familiar with DLS, but I think starting a development from scratch would not be appropriate. You should rather have a look at libinstpatch. The "Future" wiki page suggests to make this library an (optional) dependency and by that bring DLS and GigaSampler support as well.

@elementgreen What is libinstpatch's current status of supporting DLS? (How) Could it help fluidsynth to implement this feature? Could you give some pointers for further reference / starting points?

[frabert]

Is the Glib requirement a hard one or is it optional? Seems like a big dependency, especially on Windows...

[derselbst]

For fluidsynth it's a hard one and has been extensively discussed before, see mailing list and #145. But that seems to be off-topic, where's the reference to DLS loading?

[frabert]

I was referring to libinstpatch, I didn't actually notice that FluidSynty already needs it, sorry.

[elementgreen]

libInstPatch is completely dependent on glib/GObject and does support DLS loading/editing/saving. The DLS synthesis model is very similar to SoundFont (I suspect they borrowed it from SoundFont), but has increased parameter resolution (32 bit parameters instead of 16 bit). Seemed like a nice format to me when I wrote support for it in libInstPatch. However, it seems like the format is not that popular? Maybe that is my own limited impression though. Because of this though I never really did add full editing capabilities to Swami. It was also a shame that the specification cost money to download previously (not sure about now, seems like it may just require registering an account?).

The FluidSynth plugin in libSwami synthesizes DLS using the SoundFont loader API that FluidSynth has and the SF2VoiceCache subsystem of libInstPatch. This means a loss in parameter resolution, though it does work. There was talk a while back about converting the internal synthesis of FluidSynth to be more DLS based and converting SoundFont parameters instead of the other way around.

I proposed in the past adding optional libInstPatch support to FluidSynth to take advantage of other formats it supports (DLS, very limited Gigasampler, SLI and virtual banks) and implement something similar to the libSwami FluidSynth plugin for synthesizing the voices in FluidSynth. I suppose of course the DLS file loading code could be ripped directly from libInstPatch and just integrated in FluidSynth without the added dependency, like the SoundFont loading support was lifted so long ago from Swami's previous incarnation (Smurf SoundFont Editor) for FluidSynth's current SoundFont loading code. The license should be compatible and if not, I would make it so.

Of note is that libInstPatch and Swami development has not been very active for a while, due to other priorities. Otherwise I would certainly like to help with such efforts.

[frabert]

Both DLS level 1 and 2 specs are free to download from the MIDI website after registering. It is not a popular format anymore, indeed, but it's what DirectMusic used. The approach you describe is pretty much what I am doing right now, with the exception that I generate full-fledged sf2 files on the fly. It seems to me that the DLS model is somewhat more modular than SoundFonts', so maybe a transition is not so simple. Thanks for your insights, @elementgreen !

[elementgreen]

Well libInstPatch technically works with native DLS data structures. Only when synthesizing to FluidSynth does it convert the parameters to the correct SF2 units for synthesizing, which happens on the fly similar to SoundFont files themselves in Swami. So no "conversion" process actually occurs prior to being able to use them.

[derselbst]

I suppose of course the DLS file loading code could be ripped directly from libInstPatch and just integrated in FluidSynth without the added dependency, like the SoundFont loading support was lifted so long ago from Swami's previous incarnation (Smurf SoundFont Editor) for FluidSynth's current SoundFont loading code.

As a SF2 synth, borrowing the relevant code from swami to natively support SF2 loading was comprehensible for fluidsynth. As DLS however being a foreign format, I would prefer making libinstpatch an optional dependency to reduce maintenance effort. I mean the necessary sfloader construction stuff could be done by fluidsynth ofc, but the relevant load, iteration and noteon functions should be provided by libinstpatch. Would that be possible that way?

[elementgreen]

As a SF2 synth, borrowing the relevant code from swami to natively support SF2 loading was comprehensible for fluidsynth. As DLS however being a foreign format, I would prefer making libinstpatch an optional dependency to reduce maintenance effort. I mean the necessary sfloader construction stuff could be done by fluidsynth ofc, but the relevant load, iteration and noteon functions should be provided by libinstpatch. Would that be possible that way?

Yes, this is possible and I think makes the most sense too. As I mentioned the libSwami plugin already has most of the code needed, just need to cut out all the FluidSynth GObject related stuff. There are some glib data types that are used like hashes, but that should be fine, since libInstPatch would depend on that anyways (even if FluidSynth removes it at some point). Of note is that this would basically automatically add support for any other libInstPatch formats as well. This task seems interesting enough to make me want to work on it too!

[derselbst]

Great! I'm currently about to refactor the soundfont loader API in a separate branch: https://github.com/FluidSynth/fluidsynth/compare/sfloader You dont need to care right now, you could just work against 1.1.9. Once you're done I will see how to glue libinstpatch and fluidsynth together and porting everything to the new loader API.

[derselbst]

@elementgreen Any news?