search

SFe-Team-was-taken / SFe

Bringing soundfonts to new heights
Other
2 stars 1 forks source link

Generator enums #35

Open sylvia-leaf opened 3 days ago

sylvia-leaf commented 3 days ago

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

Category 2: medium priority

Category 3: low priority

Category 4: not in SFe 4

Other things to do

Mirrored from here:

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

spessasus commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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:

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 commented 2 days ago

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 commented 2 days ago

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?