Generator enums

[sylvia-leaf]

Generator enums

Introduction

To add extra features such as round-robin sampling, we need to use unused generator enumerator values. However, there is insufficient research about how enum values are used.

Right now, work is being done to reverse engineer SFCF. We've already found out that SFCF uses unused generator enum values for DLS features. Once this reverse engineering process reveals all of the enum values used by SFCF, we can then fit in our extra features.

This is the reason why the partial reverse engineering of SFCF (to find unusable enum values) should be completed before we attempt to fit in extra generator features.

---

List of features to work on

Category 1: high priority (SFe 4 must have these features)

• [Generator Enum 42] - Round Robin Sample Playback Class (rrSamplePlaybackClass)  #42

  • Priority: The highest out of everything on this list
  • Difficulty: Low
  • ETA: Ver. 4.2

• [Generator Enum 54] - Sample Modes (sampleModes) improvement #43

  • Priority: High
  • Difficulty: Medium
  • ETA: Ver. 4.2

• [Generator Enum 49] - Initial Attenuation Mode (initialAttenuationMode) #55

  • Priority: High
  • Difficulty: Low
  • ETA: Ver. 4.2

Category 2: medium priority (SFe 4 should have these features)

• [Generator Enum 55] - Exclusive Class Mode (exclusiveClassMode)  #44
  • Priority: Medium
  • Difficulty: Low
  • ETA: Ver. 4.2
• [Generator Enums 61 ~ 72] - Independent envelopes/LFOs for pitch/attenuation/filter #45
  • Priority: Medium
  • Difficulty: Medium
  • ETA: Ver. 4.2 or 4.3
• [Generator Enum 59 ~ 60] - Filter Type (filterType) and Filter Depth (filterDepth) #46
  • Priority: Medium
  • Difficulty: Medium
  • ETA: Ver. 4.3

Category 3: low priority (SFe 4 could have these features)

• Rest of DLS features #48
  • Priority: Low
  • Difficulty: High
  • ETA: Ver. 4.4 to 4.10
• Conditional start/key switch #47
  • Priority: Low
  • Difficulty: High (may be impossible with generators)
  • ETA: Ver. 4.7 or 5.0

Category 4: not in SFe 4 (SFe 4 won't have these features)

• Subtractive synthesis
  • Priority: Low
  • Difficulty: Really high
  • ETA: Ver. 5.0
• FM synthesis
  • Priority: Low
  • Difficulty: Really really high
  • ETA: Ver. 5.1
• Multiple loops
  • Priority: Low
  • Difficulty: Likely to be impossible with generators
  • ETA: Ver. 6.0

---

Other things to do

Mirrored from here:

• What happens if a generator beyond 60 is found? Nothing - it works fine.
  • If it works, what is the maximum that's allowed? 65535.
• How do legacy soundcards react to undefined (in SF2.04) generators? In the same way as SF editors
• Use spaces before 60 for category 1 features.
• Use spaces between 60 and 127 for category 2.
• Use spaces after 127 for category 3 - Not necessary, we've got loads of spaces left and DLS is likely to fit before we hit 127

---

If you've got anything else to add to the list, please send a comment here.

[spessasus]

What happens if a generator beyond 60 is found?

Where? I'm sure it differs on implementations. On some it may work, others might reject it. What then?

[sylvia-leaf]

You actually have a good point. Maybe the question I asked was bad; I should've asked "are there any commonly used programs that error out on a generator value beyond 60?"

[spessasus]

You actually have a good point. Maybe the question I asked was bad; I should've asked "are there any commonly used programs that error out on a generator value beyond 60?"

What counts as commonly used? I can only think of fluidsynth and BASSMIDI.

PS: Did you read the discussion I started in this repo?

[sylvia-leaf]

If FluidSynth and Bassmidi are the only frequently used players, then we should just test on these two? Even though Davy mentioned "FluidLight" in the original SF update proposal repository, I can't find a project on GitHub called that. And even if I could, it seems like it would be a fork of FluidSynth, right?

Also, talking about the conversation you made, you are right. We shouldn't care about legacy players. But the problem is that I worry that people will attempt to run SFe banks on their legacy player and then complain and blame many different people, whether that be whoever made the bank, or even the SFe team for doing something that doesn't work.

You say that the multiple different variants of SFe are problematic. Well, davy7125 said that it is ok to delay 64-bit support until it's truly ready with a good foundation, because the format would be incompatible anyway:

Reading 64 bit indexes should be moved backward so that existing soundfont readers can read soundfont with the new format.

We can thus safely get rid of SFe64. This would eliminate one variant of SFe, leaving just two variants:

• the "kinda compatible" 32-bit SFe-static (SFe-S) variant (with its subset SFe-L)
• the incompatible 64-bit SFe-dynamic (SFe-D) variant

While this would still be two formats, SFe-S would eventually stop getting features (this was what I envisioned with SFe32/64 in the first place!). Eventually the only format left would be SFe-D. I think that this strikes the perfect balance between compatibility and feature potential. What do you think?

The SFe-L subset would stay within the limit of generator 60, and it would include the most important features that davy7125 stated (listed above). But I've been wanting to do more esoteric things with the format that uses way more generators than can be accommodated by the limit. But again, I really want SFe32 banks to load (with a quality reduction) on legacy players. But you say that even structurally compatible changes can break **** in the most weird ways. I don't know what to say at this point...

Sorry for sounding angry, and sorry if I annoyed you with how I was structuring the format. Thank you for your feedback.

[spessasus]

But the problem is that I worry that people will attempt to run SFe banks on their legacy player and then complain and blame many different people

@sylvia-leaf looks like you didn't read what I wrote. I addressed this. I proposed changing sfbk to sfen or something similar. Changing the main chunk ID should make players reject the file. And even then, using dynamic riff will make them incompatible. This + .sft should be enough to tell people that it's not SF2.

[sylvia-leaf]

Ah, I get it now!

So you are wanting to rename the sfbk fourcc to sfen, so legacy players intentionally do NOT load the file? That's an interesting idea, and something that I'll almost certainly consider for the current or a future version of SFe! Sorry for not reading the proposal written in your discussion properly.

---

Update: The plan is to actually now have one unified specification with the same data. Instead of three incompatible specifications, we will just maintain three RIFF header types that start with identical data (at least for 4.0).

There may be divergence, but not in 4.x versions. While sfbk would be used with 32-bit static RIFF headers, we'll use sfen as you recommended for 64-bit static and dynamic headers. What do you think? Is this still too much, or is this a good idea?

[sylvia-leaf]

All features in categories 1-3 are now being tracked in their own issue. Won't close this issue yet, as there are features in category 4 that need to be tracked.

[sylvia-leaf]

Generator enums are limited by the field size. Because it is a WORD, the maximum value is 65535. More information available at #7.

Provisional generator enum assignments for some features are now listed, with adjustments made to compensate for SFCF features. These are not to be confused with the original assignments proposed in 4.0.1 (the original 2020 draft specification!), but we will definitely be considering bringing some of these concepts to future versions of SFe.