Refactoring Zynthians factory soundfont library

Zynthians internal sfz soundfont library needs a revision. This is based on a lively discussion in the Zynthian community. On this page we collect some of the discussions key points.

1 Theory / Key design decisions

1.1 Motivation: Why do we need to refactor the library?

The existing library is a very comprehensive set of soundfonts which meet many users requirements. Nonetheless, even though all soundfonts currently included are likely originally intended for public domain use, some license files are missing. We need to clarify for every patch that we are allowed to use these samples in the given form.

Additionally we need to make sure that every patch is usable and enjoyable with the given soundfont engine.

At last, we need a platform where Zynthian users can contribute by editing soundfonts for the use of everyone.

1.2 Location: Where do we store the library content?

1.2.1 Pulling upstream soundfont libraries vs. hosting own repository vs. hybrid approach

The ongoing discussion is about using upstream libraries maintained in other sources vs. hosting an own copy of a set of soundfonts, e.g. on Github. Up to now the soundfonts are distributed together with the ZynthianOS image. The question is where to store the storage intense sample files.

1.3 Licenses: What are issues with script and sample licensing?

Every patch in the library needs a license file, stating the limits of usage in this context. It should be unproblematic to use patches where the license for the scripts and samples are clarified. Usage up to CC-BY-NC may be acceptable, CC-BY-ND must be complied to in an adequate form.

1.4 Library: How do we chose soundfont libraries to include here?

1.4.1 Curating vs. collecting

The question here is simply: Which soundfonts to include in the library? Do we want to collect everything available or curate a set of samples with the best ones of each instrument sub type?

2 Practice

2.1 Roadmap

1. Make decisions concerning the key desing decisions above
2. Initiating a publically available github repository based in the existing patches OR create a new blank one only containing folders for categories and edit away
3. Drafting the distribution process (including in download image, github pull, webconf package?). Immediate distribution vs. distribution on finishing the project.
4. Writing guidelines containing infos on license files, READMEs, target size, target engine, general and category specific common controls and editing notes
5. Choosing candidates for including, preferably with CC-0 license
6. Editing

2.2 Editing Guidelines: What is best practice of a finished entry?

It is a bit too early to name guidelines already before making key design decisions. Here's an outline:

• Complying with given license is mandatory. Missing license files are being added from original sources, otherwise soundfont must be dropped. This doesn't apply for missing licenses of the sfz script if that script is obviously trivial (list of regions connecting files with note values). Each Instrument contains a license file regarding samples and scripts and at least a zynthian specific README which can be displayed in the patch selection window. CC-BY-ND licences samples are included by git submodule if it is usable in the recommended soundfont player (i.e. Sfizz)
• Sampleset is usable out of the box by preferred engine (i.e. Sfizz) omiting or replacing opcodes these engines cannot use
• Issues are being fixed
• [Target maximum size and how to achieve it]
• [Limit the number of patches per instrument type?]
• [Unifying multiple files (e.g. articulations) into one]
• [Common folder structure]
• Instrument contains a *.yml file. But for simpler sfz the autogeneration might be sufficient.
• [Common controls]
• [Instrument specific controls]
• [Level matching]