Proposal for Default Modulators in SF2 files

[spessasus]

Hi Ian,

I'm writing this to ask you for supporting an SF2 format extension I created that adds default modulators to SF2 files:
https://github.com/spessasus/soundfont-proposals/blob/main/default_modulators.md

I also wrote to fluidsynth devs and polyphone devs too.
But getting support from BASS would mean a lot and help this extension get adopted, as it would fix one of the major SF2 issues.
I hope it'll be relatively easy to implement too, since parsers from IMOD can be reused.
If you have any questions or concerns about my idea, let me know!

Kind regards,
spessasus

[Ian @ un4seen]

I think the ability to create SF2 files with the new option is needed first, not least for testing purposes. So please let me know when support has been added to Polyphone.

[spessasus]

Hi Ian,
thanks for your response.

I've added a test soundfont to the proposal and I've implemented the support for it in my synthesizer to show the proposed behavior.

I hope this helps,
spessasus

[Ian @ un4seen]

Thanks for the test file, but I think for your idea to take off, support in SF2 editors is a prerequisite. If you can get it added to them then it'll be added to BASSMIDI too. No point players supporting the feature if there's no way for it to be used in SF2 files

As well as Polyphone, you could also ask about support in Viena:

   http://www.synthfont.com/Viena_news.html

[spessasus]

Hi Ian,
Firstly, I've simplified the proposal, suggested by the developer of Polyphone: the DMOD chunk now simply overrides the default modulator list, making it even easier to implement. It also removes the ambiguity of the Velocity to Filter modulator!

Regarding the editor:
I've started working on my own SF2/DLS editor in the browser and, while it's unfinished, it allows full DMOD chunk reading, writing and editing. So you can test the proposal for yourself with your own files. Simply load the file, click the "default modulators" button and you can edit them before saving. Then you can load the file into my SpessaSynth synthesizer and hear the effects :-)

Editor is here:
https://github.com/spessasus/SpessaFont (it's not live yet, but the instructions for building are in the readme)

SpessaSynth is here:
https://spessasus.github.io/SpessaSynth/

I hope you consider this feature again.
If you have any questions or concerns about my idea, let me know!

kind Regards,
spessasus

[Zenxia]

Hi Ian,
Firstly, I've simplified the proposal, suggested by the developer of Polyphone: the DMOD chunk now simply overrides the default modulator list, making it even easier to implement. It also removes the ambiguity of the Velocity to Filter modulator!

Regarding the editor:
I've started working on my own SF2/DLS editor in the browser and, while it's unfinished, it allows full DMOD chunk reading, writing and editing. So you can test the proposal for yourself with your own files. Simply load the file, click the "default modulators" button and you can edit them before saving. Then you can load the file into my SpessaSynth synthesizer and hear the effects :-)

Editor is here:
https://github.com/spessasus/SpessaFont (it's not live yet, but the instructions for building are in the readme)

SpessaSynth is here:
https://spessasus.github.io/SpessaSynth/

I hope you consider this feature again.
If you have any questions or concerns about my idea, let me know!

kind Regards,
spessasus

SpessaSynth supports several modulators that BassMIDI doesn't yet support.

The next text is a feature (Mobile DLS)

A good feature you can add to the standard is to omit Presets 123, 124, and 125 from the MSB 121 LSB 6 events. Actually, Presets 123, 124, and 125 are events like dim-screen vibration on/off and on old phones buttons lights dim.

On haptic phones like the Nokia 1616, the velocity is equivalent to the intensity of the vibration. If smartphone web browsers can support vibration events, a future implementation would be good.

MXMF is equal to Mobile DLS feature of above + Embedded .sf2

falcosoft has provided support. Embedded .sf2 support.

[Ian @ un4seen]

Firstly, I've simplified the proposal, suggested by the developer of Polyphone: the DMOD chunk now simply overrides the default modulator list, making it even easier to implement. It also removes the ambiguity of the Velocity to Filter modulator!
...
If you have any questions or concerns about my idea, let me know!

Thanks for the update. If I understand correctly, this is intended to make it simpler for SF2 authors to change default modulators for all instruments. I wonder if it'd be possible to do that in a way that's 100% back-compatible by having the editor also apply those modulator changes to each instrument in the saved SF2 file. Basically, the new chunk would only be used by supporting editors to tell what the default modulators are and which instruments have been customised. What do you think?

[spessasus]

Firstly, I've simplified the proposal, suggested by the developer of Polyphone: the DMOD chunk now simply overrides the default modulator list, making it even easier to implement. It also removes the ambiguity of the Velocity to Filter modulator!
...
If you have any questions or concerns about my idea, let me know!

Thanks for the update. If I understand correctly, this is intended to make it simpler for SF2 authors to change default modulators for all instruments. I wonder if it'd be possible to do that in a way that's 100% back-compatible by having the editor also apply those modulator changes to each instrument in the saved SF2 file. Basically, the new chunk would only be used by supporting editors to tell what the default modulators are and which instruments have been customised. What do you think?

Thanks for the response, Ian.
However the idea is for the synthesizers to explicitly support the DMOD chunk. Here's why:

The proposal you've suggested won't work in practice. The DMOD chunk provides the complete default modulator definition, yet at the instrument level you can't do that, you can only disable individual modulators. And here's the thing: both your BASSMIDI and my spessasynth have additional custom modulators for extra CCs like the brightness or resonance. Both are similar, but have different values and different curves from what I can hear. And the DMOD chunk is here to provide consistent and predicable results, intended by the soundfont engineer. For example, if there's no modulator defined in the DMOD for brightness CC, both BASS and spessa would not respond to it. If there is, both of them would respond according to the modulator, providing consistent results, regardless of the engine. Same with fluidsynth which doesn't support CC#74 by default (assuming it will hopefully support DMOD as well, I've opened an issue there too). And also if the bank creator doesn't want any extra CCs supported, they cna just throw in the default SF2 modulator list into DMOD, so both BASS and spessa will ignore all extra CCs. This not something you can currently do.

Also another thing: if the editors were to write the default modelators into each instrument, there would be a chance that the user loads the bank into an editor that doesn't support DMOD , like Polyphone (hopefully it will soon) and make some modifications and save. They won't be able to tell that the DMOD isn't working since the modulators are baked in at the instrument level and it will be removed upon saving. Then even when they load it into an editor that supports DMOd, all of the modulators will have to be removed manually before rebuilding the DMOD chunk. Imagine having to remove modulators from a thousand instruments! There are 4GB banks that have this many, so it's not totally unrealistic :-)

So that's why I think the DMOD should be a synth-level extension, not just editor level. To provide full and consistent CC response along with easier editing. The extra CCs exist (at least in my case) because no sf2s bother to implement them. And that's understandable, given how tedious adding those modulators to every instruments is. And with DMOD, it's just a few clicks. (And my editor inserts them automatically :-)

Sorry for the wall of text, but I'm really hoping to get this added to all major Sf2 related software. I hope you can understand my reasoning. If you have any more questions, feel free to ask :-)

PS: I've updated the editor, it actually has a keyboard now so editing DMOD now responds in realtime!

[Ian @ un4seen]

As the new feature is for the benefit of SF2 authors rather than end-users, I think it'd make sense to try to make it so that only editing software would need modification for it and playback software/hardware wouldn't need any, eg. the soundfonts would even work as intended on old SoundBlaster hardware. It seems to me like that should be possible by including the new default modulators in each instrument's global zone. SF2 authors currently need to do that manually when they want to override the SF2 spec defaults, and your feature would just automate that.

The editor could detect when an instrument's global zone modulator has been customised by comparing it to the stored default, and if it has been customised then it wouldn't be affected by any subsequent changes to the default. A complication I see there is if a customised modulator happens to be the same as the default. So the editor should probably instead maintain a list of which instruments have been customised, which also gets written to the SF2 file along with the default modulators for future reference. The editor could have a button to revert an instrument to defaults, which would also remove the instrument from that customised list.

Regarding information being lost when loading the soundfont into an editor that doesn't support the new feature, that would be the case no matter how you implement it, but at least the soundfont would still sound correct this way ... A supporting editor could try to auto-detect customised defaults by checking if the instrument global zones are all (or mostly) identical, and offer to use them as defaults if so.

Let me know if I've overlooked something.

[spessasus]

Hi again, Ian.

I think you overlooked a few points. So here's why synth engines should also support DMOD:

Note: When I refer to BASSMIDI, I'm using Falcosoft MIDI Player 6 with the latest BASS DLLs as I don't know of any official GUI for it. If there is, please let me know and I'll test there.


1. Extended Modulators

In BASSMIDI and my synthesizer there is built-in support for additional controllers, like CC#74. When it goes below 64, the low pass filter frequency decreases on the channel.
This is not a standard SF2 modulator.
Same with SpessaSynth (and maybe other SF2 synthesizers which want to support extra CCs out of the box). However, they cannot be disabled via instruments. Or, maybe they, can, but what if they differ? For example if BASS uses convex and spessa uses linear and some other synth uses concave and what amount?
Not to mention that editor would have no idea that a given engine has extra modulators, so it wouldn't disable them at the instrument level.

With the DMOD chunk, all of these issues are resolved:
- DMOD overrides SF2 default modulators AND the extra modulators if the engine has any. So:
- All extra modulators in the engines are disabled, regardless of what they are
- If there is an explicit CC#74 modulator defined in DMOD, all engines will have a consistent response, exactly as the modulator described.
- This gives the bank engineer full control over the default modulators, be it SF2 or more. For example, they make an XG bank and create a carefully XG-tuned CC#74 modulator that provides XG-like response to the CC. Then all supporting engines will respond in exactly the same way.

You can't achieve this without synths explicitly supporting DMOD.


2. SF2 Inconsistencies

SF2.01 and SF2.04 define different Velocity-To-Cutoff modulators. Polyphone, for example implements version 2.01 by default. What if BASS or spessa, or some other synth use version 2.04?
Which version should the editor disable?
DMOD doesn't disable modulators, but it *overrides* them, so regardless of the default modulator list implemented, the response will always be the same (whichever velToFc modulator SF2 engineer chooses to support)


3. Smaller file size

For example:
Writing 15 default modulators is 15 * 10 + 10 = 160 bytes.

Writing to instruments, in stgiga's SC-88Pro HiDef bank (a very viable use-case: Defining SC-88Pro CC responses), would take:
15 *10 * 1493 + 10 = 223960 bytes! (1493 instruments)
And that's not even accounting for extra modulators that would have to be added to disable the default ones!


4. Signaling unsupported software

The idea is to make the DMOD bank sound "wrong" in a non-DMOD software. This would give users a clear indication that the software doesn't support DMOD.
I see no problem in adding a "legacy modulator export" (without the DMOD chunk) in the SF2 editor, that would do what you describe, but it would still have limit of not removing extended modulators, like described in point 1.
Also, a lot of software rejects DMOD chunk in the INFO-list for some reason. Even though the spec states to ignore them. So DMOD will probably not work in legacy software, hence the limited export.


5. Simple to implement

While I don't know if it will be as easy for you to implement as me, but my implementation in JS is just a few lines of code:

Code Select Expand

// in the INFO reading loop (switch(fourCC))
// dmod: default modulators
case "dmod":
    const newModulators = readModulators(chunk);  // IMOD reading function, returns an array of modulators

    // override default modulators ("this" is the soundfont class)
    this.defaultModulators = newModulators;
    // flag the bank as having DMOD
    this.customDefaultModulators = true;
    text = `Modulators: ${newModulators.length}`;
    this.soundFontInfo[chunk.header] = text;
    break;


I hope that these points are enough for you to consider adding this proposal :-)

[Ian @ un4seen]

The idea is to make the DMOD bank sound "wrong" in a non-DMOD software. This would give users a clear indication that the software doesn't support DMOD.
I see no problem in adding a "legacy modulator export" (without the DMOD chunk) in the SF2 editor, that would do what you describe, but it would still have limit of not removing extended modulators, like described in point 1.
Also, a lot of software rejects DMOD chunk in the INFO-list for some reason. Even though the spec states to ignore them. So DMOD will probably not work in legacy software, hence the limited export.

In that case, there seems no need for the new chunk to be in the "INFO" list chunk. It could instead be in the "pdta" list chunk (alongside the "pmod" and "imod" chunks), which seems the more logical place for it?

- DMOD overrides SF2 default modulators AND the extra modulators if the engine has any. So:
- All extra modulators in the engines are disabled, regardless of what they are

Regarding BASSMIDI specifically, please note that only a subset of SF2 modulators are currently supported (listed in the BASS_MIDI_FontInit docs). That includes the "MIDI Note-On Velocity to Initial Attenuation" and "MIDI Note-On Velocity to Filter Cutoff" modulators (the latter defaults to no effect rather than the 2.01 or 2.04 spec) but none of the other default modulators. CC7/10/11 are hardcoded to the MIDI spec (which matches the SF2 spec defaults) and the rest are controlled by other means (eg. RPN or sysex). So BASSMIDI unfortunately wouldn't be able to meet the requirement to disable all modulators by default.

[spessasus]

In that case, there seems no need for the new chunk to be in the "INFO" list chunk. It could instead be in the "pdta" list chunk (alongside the "pmod" and "imod" chunks), which seems the more logical place for it?

While it is logical, the SF2 spefication does not allow new chunks anywhere but in the INFO list, so adding it there would break every SF2 player out there (including my own). Adding it in info is fully legal as the spec states that there may be unknown chunks. And that's the whole point of this proposal, to not violate the spec.

Regarding BASSMIDI specifically, please note that only a subset of SF2 modulators are currently supported (listed in the BASS_MIDI_FontInit docs). That includes the "MIDI Note-On Velocity to Initial Attenuation" and "MIDI Note-On Velocity to Filter Cutoff" modulators (the latter defaults to no effect rather than the 2.01 or 2.04 spec) but none of the other default modulators. CC7/10/11 are hardcoded to the MIDI spec (which matches the SF2 spec defaults) and the rest are controlled by other means (eg. RPN or sysex). So BASSMIDI unfortunately wouldn't be able to meet the requirement to disable all modulators by default.

That's a shame, but even if the subset can be altered by them, it would be appreciated as well!

Though, is there a technical limitation causing only a subset to be supported?

From what I'm reading over here https://www.un4seen.com/doc/#bassmidi/BASS_MIDI_StreamEvent.html
it seems like a lot of these behaviors can be turned from being hardcoded into modulators, since they are relative. Then the default modulator list would have these added and they would work just like the old behavior, but now they could be altered!

For example:
MIDI_EVENT_CUTOFF: linear bipolar positive -> initialFilterFc
MIDI_EVENT_VIBRATO_RATE: linear bipolar positive -> vibLfoFreq
etc.

And the NRPNs could simply be mapped to a cc change:
 NRPN 120h Data: 32 -> set CC#74 to 32. Both send the same event so the NRPN would just call controller change which would actually trigger the event.

The full list I think can be done with this is:
MIDI_EVENT_MODULATION -> SF2 default
MIDI_EVENT_VOLUME -> SF2 default
MIDI_EVENT_PAN -> SF2 default
MIDI_EVENT_EXPRESSION -> SF2 default
MIDI_EVENT_RESONANCE
I'm not sure about the volume envelope, since it's timecents. Maybe convex or concave instead of linear?
MIDI_EVENT_CUTOFF
MIDI_EVENT_VIBRATO_RATE
MIDI_EVENT_VIBRATO_DEPTH
MIDI_EVENT_VIBRATO_DELAY
MIDI_EVENT_REVERB
this is an important one as they allow disabling reverb on kick sounds, which is something GS does.


You also mentioned that CC#7/10/11 are hardcoded, so turning them into modulators would allow users to redefine them. For example, from what I could read somewhere (i don't have a source on this one so I could be wrong), the GS volume curve differs from SF2. So modulators would allow the soundfont's creator to program in the GS volume curve into their GS soundfont, making it great for listening to GS MIDIs, especially coupled with BASSMIDI's already extensive support of the standard (from my testing it recognized almost every GS sysEx I threw at it!)

So, what do you think Ian? Would this work for BASSMIDI? Let me know.

Edit: DMOD support in BASSMIDI would also allow its writer to copy the chunk, so DMOD could get preserved in Sf2pack as well.

[Ian @ un4seen]

While it is logical, the SF2 spefication does not allow new chunks anywhere but in the INFO list, so adding it there would break every SF2 player out there (including my own). Adding it in info is fully legal as the spec states that there may be unknown chunks. And that's the whole point of this proposal, to not violate the spec.

I'm not sure you need to stick to that part of the SF2 spec, as a DMOD soundfont won't be compatible with software that sticks exactly to spec anyway. And if it increases the chances of unsupported software rejecting a DMOD soundfont then that's good for a clear indication to users that their software doesn't support DMOD

That's a shame, but even if the subset can be altered by them, it would be appreciated as well!

Though, is there a technical limitation causing only a subset to be supported?

It is partly for technical and performance reasons (a fixed calculation is faster than a modulator calculation), but also I generally don't like the idea of soundfonts changing how standard CC (eg. CC7/10/11) behave. That's why only CC21-24 are currently supported for modulators (because they aren't used for anything else). When it's wanted, CC behaviour modification can be done by modifying the MIDI events.

MIDI_EVENT_REVERB
this is an important one as they allow disabling reverb on kick sounds, which is something GS does.

I think that's generally best handled by the synth rather than the soundfont. For example, BASSMIDI applies the GS drum reverb and chorus levels by default, which can then be modified via MIDI_EVENT_DRUM_REVERB/CHORUS events or NRPN/sysex (some MIDI files customise things this way).

So, what do you think Ian? Would this work for BASSMIDI? Let me know.

When you earlier wrote "All extra modulators in the engines are disabled, regardless of what they are", I guess that means all CC procesing is disabled, including things like CC71-78? I'm not sure that's a good idea in general. It might be useful in some specific cases, but I don't think most SF2 authors (or end-users) would want to disable those things and they may not know (or even think of) how to define them as modulators. Perhaps it'd be best to revert to your original proposal?

   https://github.com/spessasus/soundfont-proposals/blob/870e717b7bf520d0d989c7ed47dcbe454661015a/default_modulators.md

Or you could make it that any DMOD-defined modulator replaces any default modulator with the same source (even if the destination or transform are different), and other default modulators remain.

Reverting would allow BASSMIDI to generally be more compatible with it, assuming that most users won't want to change standard CC behaviour.

Edit: DMOD support in BASSMIDI would also allow its writer to copy the chunk, so DMOD could get preserved in Sf2pack as well.

A DMOD chunk would already be preserved, as BASSMIDI's packing and unpacking process only modifies the smpl/sm24 chunks with the rest passed through as is.

[spessasus]

I'm not sure you need to stick to that part of the SF2 spec, as a DMOD soundfont won't be compatible with software that sticks exactly to spec anyway. And if it increases the chances of unsupported software rejecting a DMOD soundfont then that's good for a clear indication to users that their software doesn't support DMOD

Software that sticks exactly to spec has to read DMOD soundfonts as stated in SFSPEC section 10.2. For example, fluidsynth which is very spec compliant, confirmed that rejecting INFO chunks is a bug: https://github.com/FluidSynth/fluidsynth/issues/1580#issuecomment-2953364342

It is partly for technical and performance reasons (a fixed calculation is faster than a modulator calculation), but also I generally don't like the idea of soundfonts changing how standard CC (eg. CC7/10/11) behave. That's why only CC21-24 are currently supported for modulators (because they aren't used for anything else). When it's wanted, CC behaviour modification can be done by modifying the MIDI events.

I know that it might seem like a rare use case, however I can already think of two:
- GS volume curve being different than SF2 I mentioned earlier
- mono samples and stereo pairs are panned differently. I.e., hard-left is only the left speaker in mono, but in stereo both play. A custom pan modulator (that, let's say, doubles the transform amount for stereo pairs) can fix that.

And regarding performance, the code could either:
- use lookup tables for transforms, so the modulator calculation is effectively one multiplication. This could be combined with the modulators holding their last value so all modulators for this destination wouldn't have to be recomputed and could just be added together.
- check if a modulator overrides the fixed behavior at load time. If not, flag this cc as fixed and perform fixed calculations for every CC received.

or both! I don't know how viable is it with the current codebase of BASSMIDI, but I implemented the former in my code and the modulations are very fast, even for an interpreted language like JS.

I think that's generally best handled by the synth rather than the soundfont. For example, BASSMIDI applies the GS drum reverb and chorus levels by default, which can then be modified via MIDI_EVENT_DRUM_REVERB/CHORUS events or NRPN/sysex (some MIDI files customise things this way).

Soundfont may want to alter the reverb too, for various reasons. For example, GeneralUserGS 2.0.1 (a great soundfont btw, look it up!) firstly overrides all modulators to use 1000 instead of the default 200 for full effects, though from what I remember, BASSMIDI does that by default too.
However, it defines less for some instruments, like a square wave. Probably because square wave has a really harsh sound and a lot of reverb with it can really sound unpleasant. And quite a few MIDI files like to just crank up the effects to max, at least quite a few of the ones I have.

When you earlier wrote "All extra modulators in the engines are disabled, regardless of what they are", I guess that means all CC procesing is disabled, including things like CC71-78? I'm not sure that's a good idea in general. It might be useful in some specific cases, but I don't think most SF2 authors (or end-users) would want to disable those things and they may not know (or even think of) how to define them as modulators.

I thought of that, actually :-). If you've taken a look at my spessafont editor, you'll see that if there's no DMOD, it automatically inserts the default SF2 modulators, along with the filter, tremolo and envelope modulators. So the users don't have to define anything at all and all the behavior is preserved. But now as a bonus, synths that don't support extra CCs out of the box (like fluidsynth) will work for that too (assuming DMOD support). The list is currently 15 modulators, so there are some extra CCs that could use default behavior, let me know. The software is still in the development phase, so we could adjust the list to maintain the same behavior BASSMIDI has right now, without users requiring to code in the behavior in. Only consciously changing it would alter things.

Or I could make it so when the default modulator list is unchanged, the DMOD chunk isn't written at all, so everything works like usual (like it is now)

What do you think? Let me know!

Even if the current behaviors remain hardcoded, having DMOD support in BASSMIDI would be appreciated, especially for the velocity-to-something modulators.
And having a popular sf2 sotware supporting DMOD would help me convince others to do the same :-) Kind of how SF3 became a thing because everything started to support it, not just musescore.

[Ian @ un4seen]

I know that it might seem like a rare use case, however I can already think of two:
- GS volume curve being different than SF2 I mentioned earlier

I think things like this are best handled by the synth because it's more flexible that way: things can be enabled or disabled with a switch (or GS sysex in this case) when handled by the synth, while a separate soundfont is required in each case when it's left to the soundfont. For an SF2 modulator-based synth, it could mean changing modulators just like you would in a soundfont.

- mono samples and stereo pairs are panned differently. I.e., hard-left is only the left speaker in mono, but in stereo both play. A custom pan modulator (that, let's say, doubles the transform amount for stereo pairs) can fix that.

This also looks like something that should be handled by the synth. For example, the XMPlay MIDI plugin has a stereo sample detection option, as does the latest BASSMIDI build, described here:

    www.un4seen.com/forum/?msg=144369

If you've taken a look at my spessafont editor, you'll see that if there's no DMOD, it automatically inserts the default SF2 modulators, along with the filter, tremolo and envelope modulators. So the users don't have to define anything at all and all the behavior is preserved. But now as a bonus, synths that don't support extra CCs out of the box (like fluidsynth) will work for that too (assuming DMOD support). The list is currently 15 modulators, so there are some extra CCs that could use default behavior, let me know. The software is still in the development phase, so we could adjust the list to maintain the same behavior BASSMIDI has right now, without users requiring to code in the behavior in. Only consciously changing it would alter things.

I can see how that could be useful for ensuring specific playback of specific MIDI files (without bloating the soundfont with modulators), but less so more generally, eg. such a soundfont could prevent some CC working properly (because they're undefined or defined in a non-standard way) for other MIDI files.

What do you think? Let me know!

Basically, I'm of the opinion that standard CC handling and things like GS/XG emulation should mostly be left to the synth.

Even if the current behaviors remain hardcoded, having DMOD support in BASSMIDI would be appreciated, especially for the velocity-to-something modulators.
And having a popular sf2 sotware supporting DMOD would help me convince others to do the same :-)

Given that BASSMIDI wouldn't be able to fully support the DMOD feature, I'm not sure it'd be a great advert for it

I don't want to be too negative about your proposal, as you've obviously spent some time on it, it's just that it won't be possible for BASSMIDI to fully support it. The original proposal seems more compatible, but I understand that doesn't go as far as you would like in disabling all modulators/CC by default.

[spessasus]

I don't want to be too negative about your proposal, as you've obviously spent some time on it, it's just that it won't be possible for BASSMIDI to fully support it. The original proposal seems more compatible, but I understand that doesn't go as far as you would like in disabling all modulators/CC by default.

Well, this proposal was aimed mostly at synths that support the full SF2.01 synthesis model, which I thought BASSMIDI was as well.
But still, at least partial support would be nice :-)

And I generally dislike the original proposal because:
- it's more complicated (all modulators have to be compared to see which one is overriden instead of just replacing).
- there are a few sf2 synths that implement the sf2.01 vel-to-fc modulator, and ones that implement the 2.04 version, so you'd have to disable both.
- and there are synths like mine which implement additional modulators for extra CCs, which there would be no way for the sf creator to be aware of.
- projects like SFe can extend their own default modulator lists while using DMOD to keep the sf2 default modulators when converting from SF2 to SFe.

[spessasus]

So, what do you say, Ian?

Will you add the limited support for DMOD to BASSMIDI?

[Ian @ un4seen]

Sure, but it would have to be very limited

It doesn't seem like such limited support would really make a difference to other software adding support for it. Have you been able to get it supported by some other software already?

[spessasus]

I've contacted both fluidsynth:
https://github.com/FluidSynth/fluidsynth/issues/1582
and Polyphone:
https://github.com/davy7125/polyphone/issues/205

I also got this proposal integrated into the upcoming version of the SFe project:
https://github.com/sfe-Team-was-taken/sfe

One more thing: Polyphone's developer was the one that suggested changing DMOD into the complete default modulator definition, which I agreed with and changed it later:
https://github.com/SFe-Team-was-taken/SFe/discussions/38

[spessasus]

Hi Ian,

I'd like to let you know that fluidsynth has added support for this proposal today:

https://github.com/FluidSynth/fluidsynth/pull/1599