Factory soundfonts library

[hannesmenzel]

Cool these ideas resonate with you.

@jofemodo

@hannesmenzel has started the thread, so i propose he leads the team to go ahead with the task.

Oh dear. I prefer flat hierarchies, let’s do this together. I do have the capacities to edit some sfz’s one by one.

By the way, this may be the best time to reevaluate this feature request about the soundfont “info box”, but without mentioning the keyswitches and controls, because these can be shown on the UI using the *.yml anyway. Thinking more like: creator, license, sound/instrument description.

In thinking about these matters we must ask ourself the question what these patches really are. The zynthians soundfont factory library is a starting point and exists parallel to the user soundfont location, which might be customized by every user to their likings. It should be a rewarding experience to use them anyway. This actually brings the freedom to regard these factory patches as a customized set following own guidelines. I see it this way: It does not approach to be a comprehensive collection of SFZ sample patches (other websites do this already: sfzformat etc.) but a set of zynthian specific sounds which happen to be in SFZ format.

Here a couple of thoughts on your remarks:

The repository question: pull upstream vs. own repo

@jlearman

Rather than including everything we can possibly find, we might provide pointers to available resources.

@ToFF

Provide SFZ + YAML files directly for Zynthian, and additionally link to a maintained upstream git repo when available

I would personally tend to keep an own, customized factory sampleset in an own repository. Reasons for that:

• Most of the sfz’s publically available are not even in repositories.
• Many upstream repositories only contain the scripts, not the samples
• Most sfz’s available are tested in Sforzando I think. We might want to edit them meeting Zynthian specific needs (see below). The main point here is: It’s the zynthian factory samples, and these may meet other needs than the Sforzando/ARIA sfz on Win/Mac user.
• We might want to include the control *.yml files
• It would be possible anyway (and we might need to do this in case the samples have a ND license) to include them as git submodules from upstream.
• Maybe in some cases/in general we could fork the upstream libraries for editing?

Selection and Size

@jofemodo

Regarding licenses, we should review carefully and drop any soundfont that doesn’t have a license file or can’t be traced to an open source.

There may be one first question, which is: Edit the existing set of soundfonts or build a new one from the start by chosing the best options for each instrument category? Of course by revising the existing ones.

@jofemodo

But the SFZ is quite trivial, so … what to do with this?

Good question. Everybody would certainly write the file exactly like this (apart from using note names instead of note numbers).

@jlearman

I’m also happy to help curate additions to the default set. As I see it, we have plenty of SD card space; I’m using a 32G card and have 17G available

I think we should consider the download size of the image. Otherwise maybe it would be an option do deliver the sd image without any soundfonts and leave this to an extra webconf operation.

Zynthian specific customizing

@jlearman

I prefer to maximize capability rather than compatibility between sfizz and liniuxsampler.

@ToFF

Engine preference: I strongly prefer sfizz.

I think we should treat these patches as Zynthians soundfont “factory library”, which happens to be in sfz format. So it should certainly just work out of the box in zynthian, which is why I think we should customize them for use with sfizz and/or linuxsampler, so opcodes only supported by sforzando should vanish or being replaced. There was already a discussion about deleting one of them, the result was to keep both because of the nature of the project (user decides). But of course one could say the factory sample sets are optimized for sfizz and the user is recommended to use these with sfizz, while linuxsampler stays on zynthian.

Specific editing of sfz’s

@jlearman

#6, volume leveling: worth a try but a LOT of work and hard to be universal.

I don’t think so, in many cases it’s global_volume changes until the VU-Needle hits yellow. I’m not talking about leveling every region individually.

@jlearman

One option: using sfz #include to pull in settings for things like polyphony, rather than building sfizz and linuxsampler with limited polyphony.

Raising limits in engines: yes, please. I’m not a huge fan of #include statements which refer to files outside the soundfont because of portability issues.

@ToFF

I’ll attach an image showing how I want to solve the mapping. Additionally, I plan to create type-based drum sets (kick/snare/hats/etc.) so I can split them across MIDI channels and use different FX chains per group.

I personally would rather drop the type based patches, because the tidyness of the soundfont list would weight more than the advantages of multiple-instances-multi-out on a system that “normally” just has stereo output. The GM mapping idea is tricky, but I’m mainly thinking about the main kitpieces, so that you can switch patches on the fly. We may not unify the mapping for “cowbell 3 shallow hit edge” for every patch.

Possible roadmap

1. 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
2. Drafting the distribution process (including in download image, github pull, webconf package?). Immediate distribution vs. distribution on finishing the project.
3. Writing guidelines containing infos on license files, READMEs, target size, target engine, general and category specific common controls and editing notes
4. Choosing candidates for including, preferably with CC-0 license
5. Editing

An example guideline could be:

1. 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 (see feature request above).
2. Sampleset is usable out of the box by sfizz (or linuxsampler) omiting or replacing opcodes these engines cannot use
3. CC-BY-ND licences samples are included by git submodule, but only if it is usable in sfizz (or linuxsampler)
4. (Unsure) samples with existing upstream repo including samples are forked by zynthians git repository and edited there.
5. Maximum target size is X (100 MB, but dependent on instrument type. Like a piano can have 300 MB, but the Pan Flute shouldn’t exceed 30 MB). To get this multiple mic positions or poorly chosen numbers regarding velocity layers, round robins might be dropped (i.e. Salamander Drums hihat: 2 velocity layers, 20 (!) RR, where 6 might be sufficient?)
6. For more “exotic” instruments one patch per instrument is sufficient. For more “common” instruments there may exist up to 3 (?) different patches (i.e. Grand Piano + Upright Piano + Honkytonk, or Solo Jazz Trumpet + Ens orchestral trumpet or mellow jazz bass + gritty rickenbacker rock bass)
7. Where possible, number of sfz scripts (articulations) reduced to one, maybe using keyswitches. This leads to a cleaner list of soundfonts.
8. Where possible, we prefer a simple common folder structure: sfz in root, samples in “samples”, include-mappings in subfolder.
9. May contain a *.yml file. But for simpler sfz the autogeneration might be sufficient.
10. May contain common controls like volume, pan, filter, adsr
11. May contain instrument specific controls (vibrato for brass and strings, tremolo for electric pianos or organs)
12. Patches are level matched by global_volume opcode (according to the zynthian VU meter or to 0dB peak or 18 db rms or whatever)

By the way, I’m looking into the Salamander drumkit and some patches from VSCO right now.