SFt Proposal #2: Generators

[spessasus]

This is a continuation of my SFt format proposal (#6) SFt aims to be a mix of DLS, SF2 and SFZ: infititely expandable, unconstrained, and flexible enough to be used in DAWs.

Generators

Here's a list of changes i propose to the SF2 generators. These are the static parameters that shape a voice.

Upgrade to 32-bit float

The generator value shall be upgraded from 16-bit signed to 32-bit signed, IEE-754 float. This allows for a greater range of values with more precision,

Values using linear units

Most values of the generators will now be linear instead of logarhitmic. That is:

• envelope times are now in seconds
• attenuation and sustain levels are now expressed in linear gain
• filter cutoff frequency is now in Hz
• filter Q is now expressed in gain, rather than dB
• LFO frequencies are now in Hz
• LFO delay is now in seconds

Notable exceptions include all tuning generators (LFO to pitch, fine and coarse tuning and pitch envelope to pitch)

Reasoning:

Timecents are confusing, so are absolute cents, especially when I want to modify them at the preset level. Using linear values make this problem go away. And upgrading to float allows us to be precise when using them. Using linear values also the software to omit conversions when modulating in real-time.

Split up the "pan" generator

The pan generator will be replaced with two generators: gainLeft and gainRight. Both default to 1.0 and both have a default modulator

Reasoning: This generator is technically described as linear in the SF2 specification, but most synths use sin/cos functions for it. It also leads to some confusions, like this one'

Multiple values

Each generator is now an array with up to 255 values. This will be explained in proposals regarding envelopes and samples.

New Structure

Here's the new structure of a generator expressed in C:

struct SftGenerator{
    unsigned short generatorType; // 16-bit unsigned generator type. Up to 16k types. Should be enough.
    unsigned char valuesAmount;   // a single byte showing the amount of values for this generator
    float[] values;               // values for this generator. One after another. 4 bytes each, forming a 32-bit float. This always has size of 4 * valuesAmount bytes
};

Summary

This new structure allows for specifying parameters in a flexible and simple way.

[stgiga]

Assuming 64bit, IEEE 64bit floats may be useful.

[spessasus]

Assuming 64bit, IEEE 64bit floats may be useful.

Not really IMO. 32 should be precise enough, and if the file is smaller than 4GB, it can be read and played via a 32-bit synth, since the only part that makes use of 64bit are the chunk sizes (indicated with "64" replacing the two last characters of fourcc). So if the file doesn't exceed the 32bit limit in file size, it can be played just fine due to not using any 64-bit values inside other than the chunk size (which could just be a simple check: if any of the top 4 bytes is not zero, then the file size exceeds 32-bit limit and can be rejected. Making generators 64-bit also makes 32-bit synths fundamentally incompatible.

[sylvia-leaf]

Indeed, talking about bit-depth is a very interesting topic.

If we switched from the segmented 16-bit/24-bit system, then it would be completely incompatible with SF2.04, and would be limited to SFe64. This is exactly what the wMajor value of SFe64 is intended to do; highlight modifications that are fundamentally incompatible with the previous version.

Right now, SF2.04 and later, including the Werner 3.x and SFe version 4 draft formats, have fixed bit depths. This means that 64-bit floats, which aren't used often, cause bank size bloat. A future version of SFe64 featuring variable sample bit-depth would permit the inclusion of 64-bit floats.

However, to make it easier for SFe64 developers, we plan on only making one or two major structural changes (major changes break backwards compatibility) for each wMajor version. And because SFe 5 is planned to include the length limit extension/removal from the sister SFt project, this would probably have to wait for SFe 6. Additionally, SFe64 4.x will remain very similar to SFe32 to eliminate the need for complete rewrites of SF player programs.

SFe64 5 will be the first version with major structural changes, and "SFe64L" 5 will be based on SFe64 4.x.