Factory soundfonts library

hannesmenzel · February 24, 2026, 12:10pm

Hi,

[EDIT:] I try to summarize the discussion on a dedicated wiki page.

I would like to discuss about the factory soundfont library zynthian offers with each provided image. It is indeed already a comprehensive set of sounds which makes much fun to explore.

Since @jlearman recently joined the chat and brought up the question for the source location for the factory library, it might be worth to ask some questions:

Need

Is revising the factory library needed? Do enough people use these? Do you consider it good enough already?

Repository

Would it be useful to move the factory library to a github repository (if size allows this)? This would make it easier for people to edit soundfonts and fix problems usable for all. Of course Zynthian could also pull from certain third party repositories where fixes can be initiated upstream. Otherwise with an own repository it would be possible to adapt soundfonts for best use in the context of Zynthian use (Besides things mentioned below also compatibility issues with the given soundfont players sfizz, linuxsampler, …, while upstream soundfonts might be potimized for sforzando/aria use).

Licensing

It would be necessary for new (and probably some old) entries in the factory library to be 100% compliant for distributing with the open source OS. I’m no expert in these matters, but it certainly comes down to that it is ok to use CC-0, CC-BY-NC (this question was raised multiple times if Zynthian is a non-commercial project based on the question of the commercially available kit and the open sourced OS), -SA but not for -ND that way. Licensing of script and sample files can differ.

Library content

Would it make sense to include every library you can find under the given license or would it be good to curate a set of the best soundfonts of each sub category?

Possible editing goals

So if in this forum some soundfont fanatics might want to take care of these here are some questions how we would like to edit files if the license permits this:

Fixing issues of course.
Some libraries come with different patches, sometimes differentaiting between single articulations and full keyswitched patches. We might want to just include one comprehensive full patch with keyswitches, which can be further integrated with the newish *.yml assignments. That way we keep the soundfont patch list readable and tiny. Also rename mapping and control files that are not supposed to be played but just included in the main scripts to prevent them from being shown in the soundfont list (if any in the factory library).
The *.yml assignments itself
Some category dependent common controls, like vibrato for strings, tremolo for electric pianos, velocity sensitive filtering or a set of basic controls commonly ordered, like filter controls or so.
Specifically for drums: What weights more? The intention of the original creator towards key mappings or unifying drum libraries e.g. for GM mapping (As far as possible?)
Trying to get every library to unity gain using global_volume opcode or similar.
Target maximum size: Can or should the library be reduced in size for better playability or storage footprint? Selecting one microphone position or even mix samples of these? Reducing Velocity layers and approximate with velocity sensitive filtering? Or keep as much as possible, even if loading/preview times are going over the top? What to target at? 50 MB? 200MB? 1 GB? Different for different kind of instrument?
Adding a suitable polyphony limit also regarding ressources to each instrument so we can raise the hard coded limit for each sfz player.
Compatibility to one/all sfz players (sfizz and/or linuxsampler for sfz)

jlearman · February 24, 2026, 5:06pm

I’m in favor and willing to do a fair bit of grunt work. I’d need some help getting started (like, where are the scripts that would pull from external repos.) I think we should use external repos as much as feasible, but probably only if the source has version control. (Unlike my own repos! I’ll be happy to fix those.)

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 (after loading a few gigs of my own stuff.) But we also don’t want undue bloat, which would just slow down some operations (builds, downloads, etc.) Regarding curating, I feel I can represent the “old school boomer music” crowd pretty well, their bread-and-butter sounds. I wouldn’t be much help selecting things for what we call pop and R&B today, though.

My thoughts on goals & issues:

#5, retaining original intent vs commonizing for Zynthian: I think it’d be best to start a convention so that when this issue arises, we offer both: orig and zynth-ized. A simple naming convention could make that clear. I suspect that going one way or the other exclusively would disappoint a fair portion of users.

#4, category-dependent controls: IMHO, take same approach as #5

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

#7, library size: I think we need to focus on minimizing the number of voices, for the zyn-ized setups, since it’s a serious limitation in many cases. Regarding space, I think only a few piano samplesets are big hogs in this regard, and even then I don’t recall any over a gig or two. So, we can be hoggish for a couple samplesets, but in general I doubt it’s an issue.

8, polyphony: I supsect it’s not an easy issue to fix and is beyond the scope here, but something we should address one way or another, since the limit varies depending on the hardware. One option: using sfz #include to pull in settings for things like polyphony, rather than building sfizz and linuxsampler with limited polyphony. But with that convention, we might be able to address a few other issues where samplesets have to make guesses about the context.

#9, compatibility: I prefer to maximize capability rather than compatibility between sfizz and liniuxsampler. Linuxsampler is significantly less capable than sfizz and I’d hate to restrict us to the lowest common denominator. However, maybe there’s a way to provide hints for a given sampleset which player it’s intended for, when applicable.

jlearman · February 24, 2026, 5:09pm

Rather than including everything we can possibly find, we might provide pointers to available resources. Whether this should be in the wiki or built into Zynthian is another matter. The former is easy, but the latter would be pretty nifty: an “external sources” chooser. It’d probably be hard to load an external resource completely due to differences in how repos are organized.

jlearman · February 24, 2026, 5:21pm

Also, there’s a larger issue here, above and beyond Zynthian, which is organizing some of the public resources that we (and others) already use, into repos where people can raise issues and fix things using the open source model, rather than someone’s list of files (like Index of /sounds/sfz .)

Here’s a discussion I started on this at Linuxmusican: I'd like to fix latency in DeepBass samples - LinuxMusicians – not much engagement yet. If there’s a better place, please LMK.

jofemodo · February 24, 2026, 6:53pm

Hi @zynthianers!

I like very much this initiative. it’s something really needed and i’ve procrastinated to undertake the task for long time.

@hannesmenzel has started the thread, so i propose he leads the team to go ahead with the task. Of course, i would bring the resources, name it github repositories under the zynthian project umbrella, disk storage in zynthian servers, etc.

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. It’s a pity, because there are a bunch of soundfonts that doesn’t have any license file inside, nor a disclaimer note in the SFZ, nothing. I simply included the soundfonts because they were in my collection, but i must recognize that i can’t remember where i downloaded or got all of them. Some of them had been laying in my disk for many years (more than 20!) and i simply can’t trace/remember the source for all of them. So, first step, let’s assume soundfonts that doesn’t have a license file are not free and must be removed from the official “Zynthian Factory Soundfont Collection”. I hope we still could trace some of them or find good replacements.

The remaining soundfonts can be classified in 2 categories:

1.) Those having a known source in the internet where you can download the soundfont. Most probably, they are actively maintained by someone. For instance, Bass/Fretless2:

Sound pack downloaded from Freesound.org
----------------------------------------

This pack of sounds contains sounds by jdstarrett ( http://www.freesound.org/people/jdstarrett/  )
You can find this pack online at: http://www.freesound.org/people/jdstarrett/packs/1394/


License details
---------------

Sampling+: http://creativecommons.org/licenses/sampling+/1.0/
Creative Commons 0: http://creativecommons.org/publicdomain/zero/1.0/
Attribution: http://creativecommons.org/licenses/by/3.0/
Attribution Noncommercial: http://creativecommons.org/licenses/by-nc/3.0/

or Guitars/Banjo2:

MUSIC SAMPLE LIBRARY PROJECT SAMPLES (OR: MSLP) WHERE CREATED BY ERICK KVIST WITH HELP FROM THE PERFORMING MUSICIANS 
AND IT'S AN ONGOING PROJECT. IF YOU WANT TO PARTICIPATE 
OR HAVE ANY QUESTIONS PLEASE CONTACT: INFO@MUSICSAMPLELIBRARY.COM 

IMPORTANT!!! 
I CHOSE THE 'CC BY-NC' LICENSE TO STOP ANYONE FROM SELLING THE SAMPLES. 
BUT THE SAMPLES ARE FREE TO USE FOR ANY CREATIVE MUSICAL PURPOSES. YOU CAN SELL YOUR MUSIC MADE FROM THE SAMPLES.
BEING A NO:1 HIT SONG, MUSIC FOR TV/RADIO COMMERCIALS OR A BLOCKBUSTER MOVIE SOUNDTRACK, IT DOES NOT MATTER! 
I ONLY ASK YOU TO (IF POSSIBLE AND CONVENIENT!!) GIVE THE PROJECT CREDIT, e.g. END TITLES OR CD SLEEVE. 
OTHERWISE, DROP ME A LINE, I'D LOVE TO KNOW WHERE THE SAMPLES ARE BEING USED.

(Simply changing the samples into another file format (e.g. from wav into aif or reason into kontakt) 
does not constitute 'creative musical use' and will not give you the right to sell a sample)

LICENSE:

These samples are licensed under the
Creative Commons Attribution non-commercial 3.0

http://creativecommons.org/licenses/by-nc/3.0/

You are free:

-to Share  to copy, distribute and transmit the work 
-to Remix  to adapt the work 

Under the following conditions:

-Attribution. You must attribute the work in the 
manner specified by the author or licensor 
(but not in any way that suggests that they endorse you or your use of the work). 

-Noncommercial. You may not use this work for commercial purposes.

-For any reuse or distribution, you must make clear to others the license terms of this work. 
The best way to do this is with a link to this web page. 
-Any of the above conditions can be waived if you get permission from the copyright holder. 
-Nothing in this license impairs or restricts the author's moral rights. 

THE BANJO PERFORMED BY JONAS NILSSON OF CASINO 66, LA JONES, LES NIPPLES...

2.) Those having a license file with just a name or email. We should host these soundfonts in an open repository. For instance, most Brass soundfonts, like Brass/SoloTuba:

Created by Jeff Glatt
License: http://creativecommons.org/licenses/by-sa/4.0

Another problem is that in many cases, the license file only refers to the samples and say nothing about the SFZ file. We could assume a SFZ file using free samples should be free too, but the true is we don’t know because it’s not explicitly said in the license file. Of course, some SFZs are trivial, like the Guitars/Banjo2, mentioned above:

<group> ampeg_sustain=0.01 ampeg_release=.3 ampeg_decay=25
<region> sample=3_D.wav pitch_keycenter=d3 lokey=a2 hikey=d3
<region> sample=3_Eb.wav key=d#3
<region> sample=3_E.wav key=e3
<region> sample=3_F.wav key=f3
<region> sample=3_Gb.wav pitch_keycenter=f#3 lokey=f#3 hikey=g3
<region> sample=3_A.wav pitch_keycenter=a3 lokey=g#3 hikey=a3
<region> sample=3_Bb.wav key=a#3
<region> sample=3_B.wav key=b3
<region> sample=4_C.wav key=c4
<region> sample=4_Db.wav key=c#4
<region> sample=4_D.wav key=d4
<region> sample=4_Eb.wav key=d#4
<region> sample=4_E.wav key=e4
<region> sample=4_F.wav key=f4
<region> sample=4_Gb.wav key=f#4
<region> sample=4_G.wav key=g4
<region> sample=4_Ab.wav key=g#4
<region> sample=4_A.wav key=a4
<region> sample=4_Bb.wav key=a#4
<region> sample=4_B.wav key=b4
<region> sample=5_C.wav pitch_keycenter=c5 lokey=c5 hikey=d#5
<region> sample=5_E.wav pitch_keycenter=e5 lokey=d#5 hikey=e5
<region> sample=5_Gb.wav pitch_keycenter=f#5 lokey=f5 hikey=g#5
<region> sample=5_B.wav pitch_keycenter=b5 lokey=a5 hikey=c6
<region> sample=6_D.wav pitch_keycenter=d6 lokey=c#6 hikey=d6
<region> sample=6_E.wav pitch_keycenter=e6 lokey=d#6 hikey=g6

The license file says nothing about the SFZ file, it only mentions the samples. But the SFZ is quite trivial, so … what to do with this? I’m kind of lost and i would like to hear your opinion.

All the best,

jofemodo · February 24, 2026, 7:18pm

I forgot to say that i suspect, but i’m not sure, that some soundfonts that doesn’t include a license file, use free samples from sites like:

and other similar places. This should be verified before dropping a nice soundfont from the collection.

For instance, Guitars/StereoLesPaul has a ReadMe.txt like this:

A Les Paul tone, recorded with a clean, dark (not too bright) pickup setting, and played with a pick.

This is a stereo (2 channel) sfz.

There are sustained, muted, hammer-off notes, harmonic notes, and "chord thrums". There is also a  selection of fret noise waveforms to add realism.

The SFZ files are:

sus.sfz
	Sustained notes. Pressing the soft pedal (CC # 67) selects hammer off notes. Notes D1 to B1 play a chord thrum.

mute.sfz
	Muted notes.

harmonic.sfz
	Harmonic notes.

sus_mute.sfz
	Low velocity notes (less than 58) play muted strings. Higher velocities play sustained notes. Soft pedal selects hammer off notes. Notes D1 to B1 play a chord thrum.

noises.sfz
	Fret noises and chord thrums.
	MIDI Notes c4 or higher are fret noises.
	Notes D3 to B3 play a chord thrum.

Amazingly, the author who created the SFZs, thought that it was important to clarify some details about using the SFZs, but says nothing about copyright or licensing. I want to believe he simply doesn’t care, but this is not enough and we should drop this nice soundfont unless someone could trace the source and verify it’s really free domain. Perhaps the license file was removed/dropped by accident at some point and only the ReadMe remains?

All the best,

ToFF · February 24, 2026, 8:21pm

Hi everyone,
I’d like to join the team as a maintainer/contributor for the SFZ files.

I’ll try to respond to a few of the many ideas and questions raised in this thread:

Engine preference: I strongly prefer sfizz. From a practical standpoint it feels more reliable and predictable. If the goal is to converge to a single SFZ engine, my vote is clearly for sfizz.
Mapping workflow: I prefer a SFZ + YAML pairing, tuned specifically for sfizz running on Zynthian (consistent controller mappings, naming, and predictable behavior on the device).
“Not-free samples + free SFZ mappings” approach: I really like the model where the samples are commercial / user-owned, but the SFZ mappings are free, e.g. the sfzinstruments mappings repo:
https://github.com/sfzinstruments/mappings
but this is beyond the scope of this initiative.
Hybrid approach for the factory library: Provide SFZ + YAML files directly for Zynthian, and additionally link to a maintained upstream git repo when available (so improvements and fixes can be tracked properly). Example:
https://github.com/sfzinstruments/virtuosity_drums
Licensing concerns about SFZ “scripts”: If there’s any ambiguity in licensing (samples vs SFZ mapping), we can create our own SFZ mappings for the free-to-distribute sample sets. I believe the team forming here has the skills to do that cleanly.
Drum mapping is tricky: Even on my E-MU Proteus 2000, drum mappings are not consistent across presets, so I understand the complexity. Recently I solved a similar problem for a TR family of SFZ instruments I created for the commercial samples from Samples From Mars:
https://samplesfrommars.com/collections/tr-drum-machines
(I bought the full bundle—once a year they run a discounted “complete collection” deal ). 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.

TR_table_custom_tight21273×1544 82 KB

have a nice day

hannesmenzel · February 25, 2026, 10:44am

Cool these ideas resonate with you.

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

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

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.

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

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

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

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.

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.

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

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

An example guideline could be:

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).
Sampleset is usable out of the box by sfizz (or linuxsampler) omiting or replacing opcodes these engines cannot use
CC-BY-ND licences samples are included by git submodule, but only if it is usable in sfizz (or linuxsampler)
(Unsure) samples with existing upstream repo including samples are forked by zynthians git repository and edited there.
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?)
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)
Where possible, number of sfz scripts (articulations) reduced to one, maybe using keyswitches. This leads to a cleaner list of soundfonts.
Where possible, we prefer a simple common folder structure: sfz in root, samples in “samples”, include-mappings in subfolder.
May contain a *.yml file. But for simpler sfz the autogeneration might be sufficient.
May contain common controls like volume, pan, filter, adsr
May contain instrument specific controls (vibrato for brass and strings, tremolo for electric pianos or organs)
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.

jlearman · February 25, 2026, 11:49am

I agree that we should focus on sfizz. The only advantage I see to linuxsampler is that we build it with higher polyphony count (possibly because it’s more efficient?)

Most samplesets at sfzinstruments · GitHub have license files or licenses stated in the sfz files. Also, for all of those where the license is ambiguous, we can fix it, because that’s an active community.

For cases where we can’t find the original source, I’m willing to host a github project containing the samples, with a clear indication that any owners should contact me about any license issues or to remove them from the repo. They’ll all be organized with a standard set of conventions, so we can write a simple script loaded on Zynthian, that users can run to install all these questionable resources. That allows Zynthian to be honest to its license, while also providing a simple way for users to load questionable resources. And even more important, an easy way for authors to make a challenge, allowing easy removal from distribution if necessary. My guess is we’ll hear very little from the original sources. (The bigger challenge will be weeding out false claimants, but that’ll be my problem.)

hannesmenzel · February 25, 2026, 12:09pm

Here’s a short example for the agrument not to pull from upstream sources. I recently edited the Karoryfer Black and Blue Basses (source), without the edits these issues would occure:

License is CC-0, so editing is fine. I would name the creator anyway.
Current Zynthian implementation seems to just look one level of sub directories. Since then this soundfont wouldn’t be recognized at the moment. Before that implementation changed it would have been recognized, but including all the unusable control- and mapping script in sfz format in the program sub directory. tl;dr: It wouldn’t load at all.
It would sound very muffled, because the cutoff=250 is recognized by sfizz, but the var1* and var2* opcodes modulating that filter in the controls/filter.sfz is not supported. Hence static filter at 250 Hz.
It has 11 articulations, including keyswitched patches including all of these. This is fine for desktop use, but not so much for a tidy groovebox patch list.
The controls are recognized by zynthians autoparser, but not in a usable order and without the keyswitch control. So you must read the script to figure out that there are keyswitches.
It contains gui/aria related files which cannot be used by the sfz engines in zynthian.

jofemodo · February 25, 2026, 2:20pm

Of course. Perhaps “coordinate” is a better word I think the task is big/complex enough to require some kind of coordination.

jofemodo · February 25, 2026, 2:46pm

I’m working on the infrastructure for this, but It would be nice to have the information ready to use on each soundfont. The YML file would be a good place to have it. A README.zyn file would be OK too When not available, we could parse the SFZ for some well-defined fields.

I think we should avoid forking or storing big soundfonts that are already well maintained and available in Internet. Of course we would want to customize some of them, modifying the SFZ files or adding the YML files. I propose we do something similar to what we currently do with LV2 plugins and custom TTLs:

We would have an install script for each soundfont or group (bank) of soundfonts. The script will download the samples, custom SFZ and YML files and will setup everything in the soundfont directory so the installed soundfonts are ready to play.

We would have a repository with those soundfonts/samples that are “free” but are not easily available in Internet. For the rest, i would download from the original sources and customize on top.

Of course, users don’t need to run these scripts normally. I will run the scripts to build the fresh SD-images when needed.

Not all scripts will be included in the “Zynthian Factory Soundfont Library”. Some of them will be available as “extension packages” from the webconf, so we can offer a curated selection by default and the rest as optional packages.

I would start from scratch. Let’s be ambitious!

I suppose we could stop being worried by license issues with a trivial SFZ like this
As you say, there is little room for creativity on it.

If we start from scratch, i would try to totally avoid Linuxsampler. Let’s try to have exclusively soundfonts that work with sfizz. Soundfonts that only works with Linuxsampler should be moved to extension packages and warn about it. I would love to disable Linuxsampler engine by default.

Regarding polyphony, i will do some checks and will adjust the limits trying to match the CPU capabilities.

All the best,

hannesmenzel · February 25, 2026, 2:51pm

Just as an inspiration for building the library, or as a proposal for categries: This is the draft I made when I started my zynthian-my-data collection as a basis how to order and what to look for:


A	Acoustic Pianos
01	Grand Piano
•	Steinway
•	Fazioli
•	Bösendorfer
•	Yamaha
•	…
02	Upright Piano
03	Felt Piano
04	Honkytonk
05	Harpsichord

B	Electric Pianos
01	EP Rhodes
02	EP Wurlitzer
03	EP Hohner Pianet T
04	EP Clavinet
05	EP CP70
06	Synth Keys
07	Sampled Keys
•	Mellotron
•	Kawai K1

C	Chromatic Percussion
01	Mallets
•	Celeste
•	Vibraphone
•	Marimba
•	Xylophone
•	Glockenspiel
•	Steel Drums
•	Kalimba
•	Music Box
02	Hammered Strings
•	Dulcimer
•	Koto
03	Bells
•	Tubular
•	Church/Charillon
04	Timpani

D	Organs & Reed
01	Drawbar Organ
•	Hammond B3
•	Farsifa
•	VOX
02	Pipe Organ
•	Church Organ
03	Reed Organ
•	Harmonium
•	Accordion
•	Harmonica
•	Melodica
04	Reed Pipes
•	Bagpipes
•	Duduk

E	Synth
01	Lead
02	Pad
03	FM/Keys
04	Bass
05	String
•	Solina
06	Brass
07	Organ
•	Eminent 310
08	Arp
09	Modular 
10	Theremin

F	Guitar
01	Acoustic Guitar
02	Electric Guitar (Clean)
03	Electric Guitar (Distorted)
04	Jazz Guitar

G	Guitarophone
01	Mandolin
02	Ukulele
03	Banjo
04	Oud
05	Lute
06	Sitar
07	Harp
08	Zither
09	Shamisen

H	Bass
01	Upright Bass
02	Acoustic Bass
03	Electric Bass

I	Strings
01	Violin
02	Viola
03	Cello
04	Double Bass
05	Solo Ensemble
06	Chamber Ensemble
07	Orchestral Ensemble
08	Fiddle

J	Brass
01	Trumpet
02	Flugelhorn
03	French Horn
04	Trombone
05	Tuba
06	Cimbasso
07	Solo Ensemble
08	Chamber Ensemble
09	Orchestral Ensemble

K	Woodwinds
01	Flute
•	Piccolo
•	Soprano
•	Concert
•	Alto
•	Bass
02	Oboe
03	Bassoon
04	English Horn
05	Recorder
06	Pan Flute
07	Tin Whistle
08	Solo Ensemble
09	Chamber Ensemble
10	Orchestral Ensemble

L	Reeds
01	Soprano Saxophone
02	Alto Saxophone
03	Tenor Saxophone
04	Baritone Saxophone
05	Clarinet
06	Bass Clarinet
07	Solo Ensemble
08	Chamber Ensemble
09	Orchestral Ensemble

M	Choirs
01	Solo Voice
02	Choir

N	Acoustic Drums
01	Rock
02	Jazz
03	Brush
04	Mallet

O	Electronic Drums
01	808
02	909
03	606
04	LinnDrum
05	…

P	Percussion
01	Hand Percussion
•	Cajon
•	Congas
•	Bongos
•	Djembe
02	Orchestral Percussion
•	Bass Drum
•	Snare Drum
•	Timpani
•	Metal
•	Wood

Q	Miscellanious
01	Found Sounds
02	Field Recordings
03	FX

Anyone can also contribute by suggesting for a specific category: “This “A” is the best CC-0 soundfont you can find for category “X”, because it has all the articulations but is very small in size, sounds great and is expressive to play. You can also add soundfont “B”, because it complements soundfont “A” in this and that regard.”

hannesmenzel · February 25, 2026, 3:11pm

I agree with everything you said, but have some thoughts about this:

The big soundfonts are well maintained for use with PC/Mac use with sforzando. Matching zynthian needs would in many cases need to:

Adapt the script for sfizz opcodes
Change the folder and file structure
Change the number of single articulation files
Well, everything stated here

The question would be how to add these changes by maintaining the connection to the upstream repository.

Of course, for some points above you can also adapt the Zynthian UI to meet the needs of the upstream repositories, but I think this would be more work than the other way round. Some topics are unlikely to be solved from the Zynthian UI side, for example how to distinguish between main sfz scripts and mapping files.

Maybe it would be an option to selectively pull just the sample files and the license file from upstream keep the scripts, *.yml and/or readmes in an own repository, enforcing the own folder structure as well. But I don’t have any idea how to solve this technically.

hannesmenzel · February 25, 2026, 4:42pm

I’m not sure it will be really helpful, but I thought about summarizing key points of this discussion in a wiki entry (see link under section 4).

Please feel free to edit along.

riban · February 25, 2026, 6:00pm

I like the idea of being able to install a light image without all the soundfonts and samples, then install the ones I want from a list. Maybe that is a webconf feature.

Linuxsampler has many issues. The main reasons we still use it are:

It supports Giga format.
It supports some opcodes that Sfizz does not (or better supports them).
It streams from file and will continue to work even y you reload or change the sfz. All others will mute the audio.

The last point isn’t that important but was why I was using it for Clippy until I realised I had to write the audio sample launcher from scratch.

hannesmenzel · February 25, 2026, 6:10pm

I’d personally not vote for disabling the engine or even deleting it, but for recommending sfizz as the primary engine for sfz and target the included library to be compatible with it.

wyleu · February 25, 2026, 6:41pm

There was some talk a while ago about ordering engines in lists based on submitted ( another webconf option) favourite endorsements.

hannesmenzel · February 25, 2026, 8:09pm

Here’s one way to handle it. If you want to try it, you must also download Versilian Studio’s CC-0 licenced VSCO2 CE library.

Here’s a patch:
VSCO Trumpet.zip (5.6 KB)

You may insert the samples from the original package root/Brass/Trumpet into the “samples” folder.

The patch contains the licence file of the mother library, a *.yml file and a README.zyn for being displayed on the UI in the future - with no specific scripting language, just as a draft.

Patch is heavily edited, just a few changes: Monophonic and polyphonic variants of al 5 articulations, accessable thought UI, modwheel controls artificial vibrato, all in one file.

The quality of some articulations are not top notch, but this is an example.

HansR · February 26, 2026, 11:36am

I strongly agree with you. There are only 2 sample players in Zynthian, and I use both of them. Of course Linuxsampler has more problems than Sfizz, but it is not so bad as to totally remove it. Until we get Sforzando on the Zynthian I think it is wise to take good care of what we have.