Things to do

[sylvia-leaf]

Mirroring the SFe to-do list from the Polyphone repository

• [x] Decide on a file extension to use for banks that aren't fully compatible with SF2.04
  • Done in 4.00.9
  • We're using .sft
• [ ] Decide on how we're going to change the ifil value
  • Proposal in 4.00.9
  • Feedback appreciated
• [ ] Communicate with FluidSynth to get a well-specified target specification for WernerSF3
  • Is it okay to use the August 2021 draft specification of WernerSF3?
  • We'll keep SFe's Werner requirements up-to-date with the WernerSF3 spec.
• [ ] Agree with FluidSynth about a version of SFe to implement
  • Version 4.00? 4.01? 4.02? Who knows?
• [ ] Listen to feedback and release 4.00.10

[spessasus]

Decide on how we're going to change the ifil value

How about we change it to 3 WORDS? ifil does not have a fixed length in the file, it has its own chunk. then we can translate the current versioning system. For example:

• wMajor
• wMinor
• wPatch

For example 4.00.9 will have:

• wMajor: 4
• wMinor: 0
• wPatch: 9

Or we could even change it into a string. Then anything is possible (like 4.00.2b or something)

[sylvia-leaf]

The idea to add a third WORD value seems good on paper, but the problem is that SFSPEC24.PDF strictly defines it as 4 bytes (2 WORD values). Any divergence from this will result in legacy players rejecting files as Structurally Unsound.

This is where the ISFe-list chunk comes into play! By defining a new sub-chunk in ISFe-list, we can include extended version information, such as patch numbers.

However, it actually isn't necessary to use a third WORD under most circumstances! If you read section 0.1a of SFe specifications, then you will notice that the 9 in the current version doesn't represent a patch to the specification, but rather a draft milestone number. Final specifications won't have such a third value. For example, let's say that it takes three draft milestones before specification version 4.01 is finalised. Version 4.01.3 would represent a draft, while 4.01 would represent the final specification based on draft 4.01.3. The end-user will almost always see just 4.01.

Maybe, we can scrap the leading zero from the versioning system, and rename 4.01 to just 4.1, as the zero is a thing from legacy SF. Some SF players also refer to 2.01 and 2.04 as 2.1 and 2.4 respectively, so shall we standardise using versioning that do not include leading zeros?

The good news is that the lack of a third value in a final specification doesn't mean that your idea of more advanced versioning information being available isn't without merit. In such a version sub-chunk, we can include much more information, such as:

• the actual SFe specification version (the ifil value would start from 2.1024/3.1024 and increment every time the versioning subchunk format is changed)
• whether the SFe specification the bank is created to is a draft
• the draft version it is based on (if any)

So, we propose a new SFvx (SF version extended) sub-chunk. It is found in the ISFe-list chunk, conventionally after SFty but before flag (the feature flags system for 4.0.10).

---

SFSPEC24.PDF-style listing for the SFvx sub-chunk

The SFvx sub-chunk is a required sub-chunk identifying any extended SFe version attributes. It is always 46 bytes in length, and contains data according to the structure:

struct SFeExtendedVersion
{
    WORD wSFeSpecMajorVersion;
    WORD wSFeSpecMinorVersion;
    CHAR achSFeSpecType[20];
    WORD wSFeDraftMilestone;
    CHAR achSFeFullVersion[20];
};

The WORD values wSFeSpecMajorVersion and wSFeSpecMinorVersion contain the SFe specification version. This can be used by players for any purpose.

The UTF-8 character field achSFeSpecType contains the specification type expressed in UTF-8. It must be a defined value, but implementations may define custom values for internal purposes. For the purposes of SFe, the defined values are:

• Final for final specifications.
• Milestone for draft specification milestones.
• Dev for rolling draft specifications.

The UTF-8 should be treated as case-sensitive. In other words, final is not the same as Final. If the contents of achSFeSpecType are an undefined value, the field should be ignored and Final assumed.

The WORD value wSFeDraftMilestone contains the draft specification milestone that a bank was created to. This varies depending on the value of achSFeSpecType:

• If a bank is created to a final specification 4.0, then achSFeSpecType=Final, wSFeDraftMilestone=0. It is safe to ignore the value of wSFeDraftMilestone, but you should write the value as zero.
• If a bank is created to draft specification milestone 4.0.10, then achSFeSpecType=Milestone, wSFeDraftMilestone=10.
• If a bank is created to a rolling specification created after 4.0.10 but before 4.0.11, then achSFeSpecType=Dev, wSFeDraftMilestone=11.

The UTF-8 character field achSFeFullVersion contains the full version string of the specification used, for example 4.0, 4.0.10 or 4.0.yyyymmddx.

If the SFvx sub-chunk is missing, or its size is not 46 bytes, the field should be ignored and these values assumed:

• wSFeSpecMajorVersion and wSFeSpecMinorVersion correspond to the highest version declared in the flag sub-chunk
  • If there is no valid flag sub-chunk, then assume the highest SFe version supported by the program.
• achSFeSpecType=Final
• wSFeDraftMilestone=0
• achSFeFullVersion corresponds to the other assumed values

The file may optionally be rejected as Structurally Unsound.

Note: The following text in 5.1a will be deleted: "To signify that the SFe file has been created to a draft specification, please use the description."

---

Do you have any feedback on this proposal? If you would change anything, then tell me!