No, definitely not. I wrote this and I don’t want to get rid of caregories. I’d rather even add more sub levels. The table is solely to have a base for collecting libraries for each instrument type. Categories are letters, sub categories are numbers, and this is only a proposal. So feel free to edit.
1 Like
I think why I’m leaning towards minimizing the number of sfz files per instrument might be based on the current preset structure. We have categories, i.e. instrument families (brass, strings …). And there you find the different patches on only one level. This means, you’ll select mono and stereo patches of your rhodes on the same menu level as all the grand pianos. The result will be you’ll have to scroll through a huge amount of variants of a certain instrument to find the one you search for.
It could maybe be solved by only displaying one entry per folder, and then you get into another sub menu if an instrument has more than one patch.
1 Like
I’m ready to start making edits. As a first test, I picked the simplest recorder (woodwind) SFZ in the library to see whether I can adapt it for Zynthian and EWI use. Here’s the result.
recorder_ewi.zip (1.6 KB)
I’m attaching an updated .sfz and .yml. They belong in:
system-soundfonts/sfz/Woodwinds/Recorder/
Just upload/replace the files there.
If someone could try it on their setup and report back (especially with an EWI / breath controller), that would be really helpful.
1 Like
Ok, seems you are serious about keeping multiple sfz per instruments, which is fine. So we need to think together with @jofemodo about changes in the way sfz patches are presented in the UI.
My proposal: we need different menu levels of “instruments” and “versions of one instrument”.
I would really want just one entry per instrument, but then there would be some variants one level below, but indicating some kind of main/recommended patch.
Because I don’t want to scroll through hundreds of "Trumpet_A_Flutter_modwheelcrossfades_stereo_EWI.sfz"or similar, before I find my tuba.
I mean, look a this and tell me you don’t know what I mean 
1 Like
This is how I would propose it on my side.
I think most of the SFZ files we currently see under a single “instrument” folder can actually be merged into one SFZ. Let me explain with a concrete example and why it matters.
The SoloViola folder contains these files:
R1.sfzS1.sfzS2.sfzS3.sfzS4.sfzS5.sfzS6.sfzV1.sfzV2.sfzV3.sfzV4.sfzV5.sfzV6.sfzviola.sfzviola_legmode.sfzviola_legped.sfzviola_legsus.sfzviola_pizzi.sfzviola_vib.sfzviola_vib_legmode.sfzviola_vib_legped.sfzviola_vib_legsus.sfz
The files with a single letter + number (like S1, V3, etc.) are building blocks that are included by the more complex patches (legato, legato sustain, etc.). Interestingly, Zynthian’s UI does not offer these simple building blocks as selectable patches, but it does offer the higher-level patches.
If we switch to selecting articulations/variants via keyswitches or CC, the selection can still be presented nicely in Zynthian via the existing YAML definitions. In that model we could have one main SFZ for keyboard that contains all variants internally. This also makes it easy to:
- store the selection in ZS3 snapshots, and/or
- map it to a CC number chosen by the user, and/or
- use dedicated keyswitch notes.
Then, for something like SoloViola, I could also create an EWI-specific version. So instead of many visible patches, the folder would expose just:
viola.sfzviola_ewi.sfz
1 Like
It’s not just the display, the ability to select ordering is of great value.
If well handled it’s a great aid to locating things especially in an environment that ( at the moment) lacks a search facility.
Exactly.
Zynthian UI doesn’t offer these building blocks or mappings since it only showed sfz scripts on the first subfolder level. Otherwise it wouldn’t be able to distinguish.
We might need some conventions.
1 Like
Can, but shouldn’t, as I explained above. The more differences between our SFZ files and the originals, the worse. It gets harder to upgrade from a newer version of the SFZ from its source. I’ve been down this road with software and it’s a terrible road.
I agree with @hannesmenzel that when selecting an instrument we should choose among SFZ folders, and for that SFZ folder, the presets should show all SFZ files in that folder.
Ideally, articulations for an instrument and controller type should be offered as a selector control in the UI. Optionally they could be accesible with key-switches too.
Question: could we manager to define a master SFZ that calls articulations defined in separated SFZ files? So we don’t have to modify the provided SFZs but adding a master SFZ that combines the provided per-articulation files?
If this is not possible at the SFZ level, perhaps we could implement the mechanism at the UI level by extending the YML files?
Cherrs!
Not without modifying or chopping up the original SFZ files (usually.) But I think there’s general agreement that articulations are best left as keyswitches or CCs, which is how they’re done in the originals. So, the trick for Zynthian is to figure out how to convey this, how to clue in the user what controls do. IMHO that’s appropriate to do with added info somehow, anywhere from a text file to YML.
IHMO, it’s best not to get too far ahead of ourselves just now. We can definitely find a way to signal that different sfz files are for specific controller types, and figure out how to render that later. (As I said above, I’d like to see something like checkboxes in a panel above the categories. That is, it’s a second dimension of categorization.)
1 Like
One note on this: if a CC is assigned, we have a control option from zynthian encoder directly. Though I prefer keyswitches because of the point you raise: I prefer sacrificing keys instead of cc controllers.
Anyway: like already stated I’d be ok with having multiple sfz versions per instrument if these patches it’s clearly distinguished from different instruments UI wise. I’m not sure though if this applies to mono/stereo or with/without crossfades.
To be fair: Most of the good publically available sfz libraries are not subject to a huge amount of changes over time, let alone the sample sets itself.
And imo we should at least merge the files splitting performance articulations. We might be able to solve this through meta sfzs like @jofemodo suggested, because for some reason sfizz is relatively cool with multiple headers like <control> or <global>. But I’d prefer adapting them manually for best zynthian experience.
I changed the wiki page following your issue above.
Hi @zoundfonters!
It would be good to start completing the holes in the list that @hannesmenzel started in the wiki:
- Let’s start using the soundfonts we already have, removing those without a valid license.
- Then look for filling the empty holes.
- Finally let’s propose better alternatives when we can find them
The table should be categorized and have, at least, these columns:
- category
- name
- description (brief!)
- author
- license
- source (URL) => use “zynrepo” for those that we have to host in the project’s repos
- articulations => [none, keys, cc, files]
- YML => [yes, no]
- comments
Thanks!
2 Likes
Great suggestion, with one caveat:
Use “variations” rather than “articulations” because we have variations for different reasons; articulations is just one of them.
@hannesmenzel What do the numbers in the tables represent?
Nothing in particular. I just proposed the ordering system I use myself at home as a basis. There the numbers just have ordering purposes, so that more common instruments are above the more exotic, keeping some kind of instrument families together in the list and solo variations are above ensemble patches and so on.
E.g in woodwinds there are the main orchestral woodwinds together (1-4), then some special solo instruments (5-7) then ensemble patches (8-x). The list is, as I mentioned, totally open for changes and additions.
This list I just compiled together based on my own intention how to have a meaningful order of sample patches based on the insight that different instrument classification systems available lead to different difficulties identifying a certain patch. And while this obviously doesn’t follow a certain academic approach it seemed to me the most intuitive one (I.e. I want my upright jazz bass near my electric jazz bass and not below the celli). In fact it’s more like an extended version of the general midi ordering (without the gunshot and the helicopter).
1 Like
I suppose @jofemodo just means to mention if a certain instrument has several articulations or variants at all so indicate a certain level of complexity. I would rather mention each sample set once, assuming it might have one or several variants.
I assume we can leave that one out, because to all contenders right now this may apply: “has yml”: no, “should have yml”: yes.
Of course, let’s use variations instead.
And don’t need to fill every hole in the list. Step by step.
One further question to all involved here: What do you think about the matters of (in case we want to enhance sfz to our liking) instrument family dependend controls and general additional controls?
General:
For example having ADSR and Filter for any patch and connect these to usual midi cc (e.g. cutoff to cc74)
Instrument specific
E.g. all brass or bowed strings instruments get a common artificial vibrato control. Or all electric pianos get a tremolo control? Or: all brass instruments get an additional monophonic/polyphonic patch with artificial legato?
Having standarized ADSR & filter controls, modulators, etc is very cool stuff, but i wouldn’t worry about it in the current stage. Let’s proceed step by step.We have a lot of work just to sort, filter & ratioanalize the soundfont library. Let’s move this kind of improvements to the second round.
In spanish we use to say:
“El que mucho abarca, poco aprieta”
In english is something like:
“He who grasps at too much, holds nothing.”
Thanks!