How many features should we add into each version of SFe?

[sylvia-leaf]

When adding features into the format, we should be careful about how fast we add them. Too slow and people will not be happy, but too fast and nobody will ever make something that implements everything. Also, adding too many features per version would overwhelm format developers that see an update.

E-mu usually only added one major feature to each SF revision, with 2.00 being the first public version, 2.01 adding the legacy modulator implementation and 2.04 adding 24-bit support. While SFSPEC24.PDF claims that E-mu added "a number of refinements" in 1.5, no specification for a 1.x version of legacy SF was ever released to the public, so that cannot be verified. This trend was continued with 3.01/3.04 being identical to their 2.0x counterparts, but simply with compression.

SFe in its current state already has new versions planned with multiple updates, but is this how things should be done? Or should we split such large updates into smaller, bite-sized parts, to make it easier for developers to implement?

[davy7125]

Developers in the open-source world are most of the time volunteers and time-limited. My opinion is that even if a perfect solution is found in term of development plan, the reality will possibly show a different story. Features will be progressively added from version to version in each piece of software, should we have a progressive or full plan.

The version of the specifications should not be correlated and synchronized with the software versions. Fluidsynth will for example have a future version reading X more kind of generators, then another version reading the default modulators, etc.

To easy the development however, we could have a first complete specifications integrating all features that can be ignored by current soundfont synthesizers easily:

• all extra features we could think of, based on currently unused generator (provided the number can be stored on a uint16 ranging from 0 to 65535 - or as a precaution a uint8 ranging from 0 to 255 - we already have room for a lot of thing)
• other kinds of inputs / capabilities for the modulators
• extra chunks such as DMOD or a chunk defining different key switches

This is indeed easy to adapt the code for ignoring unknown values / chunks. Then, a target is set and will be achieved progressively and possibly adapted if too much is added of course. One update at a time would be really slow.

If I can, because I haven't seen the full extent of the addition yet, Polyphone will be able to edit - and possibly play - everything quite fast (I'll first release version 2.5 but then I'll include new stuff from the new specifications). The key is an editor that will not lose data after a save. To me it's less of a problem if soundfont readers doesn't provide a full support of the extra features because time will fix this.

[sylvia-leaf]

The current plan is to group features that use similar structural parts into one version, with the exception of changes in major versions, which happen when the structure is changed to be incompatible.

However, when the major version is incremented, we can still support older major versions with new features for as long as possible. Thus, SFe 4 will be the only version that's compatible with legacy SF players, and only when 32-bit chunk headers are used. Features that are backwards compatible with legacy SF but released after SFe 5 or later versions would still become available, but they'd just be referred to as SFe 4. At some point, we may rename SFe 4 to something else.

If this is confusing, then sorry! However, this should strike a balance between "not caring about what legacy players think of an SFe bank", and "maximising usability and compatibility of the SFe format".