My idea for a soundfont successor protocol

[t9999clint]

I do like your Ideas for a new SF2 type format, and having some ideas on how to incorporate backwards compatibility is very admirable, however I've been thinking about this for a few years now and I have an alternative Idea.

I'm thinking that we ditch any ideas for backwards compatibility with older programs with the new standard. We should instead focus on making the new format as simple and easy to make/implement as possible. The tools for making SF2 files will still be around and we should still be able to make them for long into the future.

Now here's what I think that we should do for the new format...

Indexed SFZ in a Containerized and compressed filesystem. (Maybe call it SF2Z or SF4 )

Instead of competing with SFZ on a new standard we should instead embrace SFZ and pick a small subset of their protocol to implement for a first version. Ideally it would be best to implement all of SFZ, but that's probably a little too much of a goal at the moment. First things first would be to support all the SFZ features that would replace the existing SF2 features and slowly add other stuff like Round robin samples once a stable code base has been implemented. The SFZ standard is a bit of a mess, but by picking a subset and enforcing certain metadata be included with the soundfont standard then the mess should be kept manageable.

The basic idea is to have a compressed file structure inside a single file that contains a series of .sf2 and/or .SFZ files and sample files (.wav, .ogg, .flac etc...) with an index.xml at the root that describes what sf2/sfz files are to be mapped to which msb/lsb/preset. Complete with Volume and Note offsets for each preset.

A well optimized soundfont using this standard can have sfz files cross-reference samples that other sfz files use limiting the total space used, also by incorporating SF2 support inside the "SF2Z" wrapper it will allow for easy importing of the older standard, and allow for multiple SF2 files be used for those that still want to use older editors while not being limited by some of the limits of the older format.

The main goal I would like to achieve by proposed format method would be that the entire soundfont could be human readable and editable. Also it'll allow for far easier coordination because these files can be shared on github as their internal filestructure instead of giant 4gb behemoths that have to be uploaded everytime there's a minor 50kb setting change.

Sorry for not responding to your email when you first sent it. I've been more busy school and doctors appointments than I had anticipated.
Regardless of your decision of how the successor of the Soundfont Standard goes you can rest assured that you already have the support of me and the small group of soundfont creators that I hang out with.

[t9999clint]

Just read #2
Should have read that first. Most of my ideas seem to have been already thought of by you. While I understand the points you've made about this I still feel that the SFZ wrapper method is the most likely to gain traction.

The largest issue with this approach is of course convincing BassMidi and FluidSynth devs to implement it, as SFZ is a fairly large beast. That being said, I believe there is already limited SFZ support in Bassmidi and there are a few open source SFZ "compatible" programs out there already. As long as we don't bite off more than we can chew and only standardize a small subset of SFZ than this shouldn't be a large issue.

[mawe42]

Hi!

Let me add my voice in favor of ditching the backwards-compatibility idea. I think it would make the new format more complicated than it needs to be and backwards-compatibility doesn't really offer much benefit. After all: who would want to load a SFv3 file in an SF2 synth and loose all that expressive power?

I'm very sympathetic to the whole idea and would love an open-source, cross-platform synth like you propose. And I don't really mind if the file format is similar (but quite different) to SF2 or some form of containerized SFZ. After all, the changes you propose are so extensive that I'm not sure the new format even needs SoundFont in its name. So far it seems the main ideas taken from SoundFont are

1. good specification of both file format and synth engine, and
2. monolithic file structure.

And while I can't speak on behalf of FluidSynth... but as a FluidSynth member and contributer I feel like adding support for all the feature that you propose would require major(!) rewrite of FluidSynth. So I think having this new synth and format would be great. But it might not be very beneficial to us at FluidSynth and therefore I would not use that as a reason to add SF2 backwards-compatibility and ignore the work that has gone into SFZ already.

Just my 2 cents, would love to see this progressing and would also be interested in helping out.

Cheers
Marcus

[t9999clint]

I've been talking with a few of my synth nerd friends and we've been working out a really rough proof of concept for a containerized SFZ format.

Having an actual dev would be handy though. I've been mostly just waiting to see what davy decides before officially starting anything on my own. I'd rather work together than create an opposing standard.

The current plan is a index.ini file with the msb lsb preset and name, then a = pointing to the sfz filename.

soundfont-name = Example Soundfont

soundfont-description = Random text

000,000,000,Acoustic Grand Piano = ./Salamander-Piano/Salamander-C5.sfz

000,000,004,Rhodes Piano = ./Rhodes/Rhodes-Velocity.sfz

This index.ini file will be in the root directory of the container. Current plan is just to use a Tar as compression if probably better left handled by the sample codec it's self.
Also the main target of this format is to run on lowpowered ARM devices so extra compression is probably best avoided for now.

Currently we have a Bassmidi wrapper that looks at the SF2Z file, mounts it as a virtual folder, reads the index.ini file and uses that to map the sfz files to the appropriate midi presets.