Some feedback of SFZ community

[jpcima]

Hello,
there was a short discussion on #sfzformat IRC about the soundfont proposal, I thought I'd report some of the feedback. The reception has been mixed, there have been some suggestions to open discussion, and it was met with strong rejection from some.
It was a tiny part of SFZ community, not necessarily representative of the whole of it.

Following points of criticism were raised. (not mine)

• the future open instrument standard is SFZ, this is duplication of time and effort.
• the feature proposal is not going to bring soundfont to modern standard
• it's like proposing extending LADSPA with a GUI, in a day where LV2 exists.
  SF2 should be the one legacy format and remain as such.

There was not much elaboration, but anyway, you have some obvious expertise and I thought it may be valuable to have you in the discussions.

Some points which are thing positive personally, not covered in SFZ

• distributing as single files
• assignment of MIDI program and bank numbers

[davy7125]

Hello,

Thank you very much for this valuable feedback. I expected such reactions given that the sfz format is considered to be an update to the sf2 format in some respects - which may suggest that this work is a waste of effort. But this is worth a brainstorming as you will see.

The issue I want to address is to have a format

• open and royalty free (1),
• accepted by the open-source community (2),
• with clear specifications (3),

For the creation of virtual musical instruments

• based on audio samples (4),
• providing all the essential synthesis features (5),
• drivable by MIDI signals (6),
• embeddable (7),

With further consideration for

• an easy editing (8),
• an easy upgrade for the existing libraries (9).

The closest state of the art consists of the existing formats sf2 and sfz and we can either start from one format or the other. The following table shows the differences in light of the above points.

	sf2	sfz
1	OK	OK
2	OK	OK
3	Existing specifications for both the format and the sound engine, that can be reused.	The opcode specification is almost complete (v1, v2), but nothing - to my knowledge - is written for an sfz sound engine yet. More work to be done here since a possible standardization is to be done across the different sfz editors / players. Possible exotic opcodes must be dropped or replaced if not all players implement it.
4	OK	OK
5	A lot of features are missing (listed in the document), more work here.	OK
6	OK	NOT OK? (MIDI program and bank numbers)
7	NOT OK, sample compression needed	NOT OK, monolithic packaging needed

Regarding point 8, this is more an editor concern. I'd like to point out the fact that the human readable sfz mapping, contrary to what we can read, is definitely not an advantage. At best it can be useful for a beginner that needs to understand the basics but for big and / or professional instruments this quickly becomes a nightmare and this could even prevent a user from introducing complexity in the instrument, this complexity being sometimes necessary to add realism. So point 8 can be excluded from the comparison.

At this stage, the preference would be to simply add an extra packaging to the sfz format so that we gather all needs, instead of drastically improving the sf2 format with additional possibilities.

But in doing so, there is no chance for the sf2 format to improve and this project, through its activity, shows how it is important: https://github.com/FluidSynth/fluidsynth
To my knowledge, there is no such a cross-platform project around sfz.

Let's speak now about point 9. If the sf2 format is improved in such way that all additional features meet one of the core feature of the sfz format, providing there is a converter between sf2 and sfz, sfz players will be able to read all soundfonts v3 with a high quality. Regarding the existing sf2 libraries, the first step that should not involve a big work would be to provide a way to read soundfont v3 in a degraded way, and later add one by one the extra features.

So my message to:

• the future open instrument standard is SFZ, this is duplication of time and effort.
• the feature proposal is not going to bring soundfont to modern standard
• it's like proposing extending LADSPA with a GUI, in a day where LV2 exists.
• SF2 should be the one legacy format and remain as such.

is that the first winners of a soundfont format update are the sfz users. Soundfont libraries will then provide more and more features but the sfz format, through its flexibility with opcodes, shouldn't be worried.

[mawe42]

Regarding point 8, this is more an editor concern. I'd like to point out the fact that the human readable sfz mapping, contrary to what we can read, is definitely not an advantage. At best it can be useful for a beginner that needs to understand the basics but for big and / or professional instruments this quickly becomes a nightmare and this could even prevent a user from introducing complexity in the instrument, this complexity being sometimes necessary to add realism. So point 8 can be excluded from the comparison.

I have the exact opposite feeling about point 8. While I agree that editor support is extremely important, it is not a good argument against a human-readable format. I think especially "power-users" could benefit a lot from being able to open the file (or the human-readable control file in a packed archive of samples and control files) and edit things by hand. Or even go and check if the file written by the editor actually looks as expected. Its great for debugging and testing out new features that are not supported in any editor yet. And it is properly diff-able, so checking the file into version control and looking at the diff compared to previous versions is possible.

Using a binary format for declarations, control-code and parameters in a Soundfont would be a step backwards, I think. Human-readable files is one of the things I find really compelling in SFZ.

[t9999clint]

I agree with mawe42. The importance of being editable by a program is very important, but I still think being human readable is just as important. Even if it's just a CSV dump of varables it would still be handy to have.
I want something that I can share on my GitHub and have multiple people contribute to. If the indexing is binary then that makes it incredibly difficult to merge/track changes.