MUCH NEEDED: Remove SF2 Generator Count limit!

[spessasus]

The SF2 uses WORDs to point to generator indexes in pbag and ibag. This means an effective limit of 65k generators which is not good and terrible and horrible and bad and agghsdhhfhsd

Change them to DWORDs at least, 4,294,967,295 should be enough. not to mention that this limit affects instrument and sampleID generators, effectively limiting them too!

[sylvia-leaf]

The SF2.04 generator count limit has been the bane of many SF bank developers (including me). It means that the format was oftentimes not used to its full potential, with banks containing large numbers of samples to support MIDI formats such as later Roland DTM modules (SC-88Pro/8850) or Yamaha XG (of course with "hacks" to accommodate the single-bank format of legacy SF) struggling to fit into one file not due to the 4GiB size limit, but rather hitting the 65535 Instrument Generator limit.

However, we can't upgrade the generator counters to DWORDs. This was something that was proposed as early as 4.00.1, and it was determined that it would break compatibility with legacy SF. The better solution is likely to listify the generator lists. While this is also incompatible, it has the same advantage as dynamic RIFF. So, it would be limited to SFe-D and not available in SFe-S.

---

Another solution may be to allow SFe banks to reference samples and instruments in sample "blobs" or even other SFe banks. This would increase the generator limit to 65535 for each part while storing samples just once, and would likely correspond to AL3 in the planned SFe abstraction levels system. Such an AL3 bank would appear similar to an existing split bank, but would be much smaller due to not storing duplicate samples. An AL3-like system has already been proposed by someone else in the Polyphone SF enhancement proposals repository.

However, there are many questions to be asked about this kind of solution:

• how much benefit does AL3 have over a truly non-monolithic format such as SFZ?
  • versions of SFZ are to be declared as AL4 and AL5 in the abstraction level system
  • most SFe banks will be AL2 with SiliconSFe as AL1
• will development programs such as Polyphone support AL3?
• will playback programs such as FluidSynth support AL3?

---

What are your thoughts about the solution proposed above? Please give feedback!

[stgiga]

Would AL3 be like SiliconSF used as a ROM sample in another bank?

[sylvia-leaf]

Yes, we would use the same system as the ROM samples to allow users to import almost any data from another bank. This can be anything from a sample to even entire instruments and presets.

Here's a diagram to explain what AL4 to AL2 look like.

[sylvia-leaf]

Instrument generator limits will only be increased in SFe 5 because there must not be a difference between the file structure of versions of SFe with different chunk headers.

The only exceptions are variables that directly reference a 32-bit index field, which share the same size as the chunk header in use. DSFe will also include a dynamic index field.