I was thinking about this from time to time in the past. Before just hammering another issue into the tracker I wanted to ask how you might feel about that:
What if we bring together the processor and preset selection under one menu and be able to change processors on the fly through the preset menu without the route of “replacing” the processor in the chain menu? It would mean that the processor would be replaced automatically depending on the chosen preset.
Some assumptions:
In another thread it was discussed to incorporate the function of other rotary encoders to approach multiple levels on the controller screen. These thoughts could apply here.
In soundfonts you would choose a processor named “Soundfonts”, and depending on the file format the respective processor would be choosen (sf2/sfz/gig ↔ Linuxsampler/Sfizz/Fluid). It would result in having a common preset list.
In synths it wouldn’t work like that. The preset menu could have two levels, first for synth (processor), second for their presets. Of course it may be desirable to have all synth presets ordered by categories, but that is unrealistic.
Possible problems/reasons against:
Might conflict with the “prelistening preset on note on” function. Otherwise I guess that loading a processor (a plugin) might take less time than preset loading (at least in soundfonts).
Mixing different “ontological entities” might be not suitable for an open software project. Keeping the processor as the plugin shaped sound source separated from it’s presets of control parameters in order to be transparent to the user what is what might be desirable.
To be fair, changing the processor might also only take 4 to 5 user inputs.
Reasons:
My main focus is on my own uploaded sfz files, so I always load sfizz. After month of using the zynthian now I lately “discovered” that there are some really usable sf2 presets. But switching back and forth requires some serious UI menu diving.
Some of your ideas are in our (developers) minds from time ago. My thoughts:
Unifying/merging all presets from all synth engines would be difficult to manage in a reasonable way and probably undesirable for many users. I mean, if i want setBfree, i know what i want. I don’t want to browse a 10000 presets collection to load a sample-based drawbar organ patch by accident. Same would happen with a lot of engines. Not to talk of bank classification, ordering, tagging, etc.
An optional text-based “preset search” could have sense, but it wouldn’t replace the current engine/preset selection. You type a search string and you get a list of matching engine//preset pairs. Of course, it would be inaccurate and limited, but it would be positive anyway. It’s something we could just implement as it is and improve later by implementing a tagging system, etc.
In the other side, unifying all soundfonts and leave the zynthian to choose the rompler engine has a lot of sense and it’s definitely something we want to implement. The only stopper for this is having 2 engines for SFZs and the fact that they offer different set of opcodes, what means some SFZs perform better with one or the other, but it’s difficult to automatically decide what it the best suited engine for a given SFZ file. We could add some heuristics and/or add a “prefered engine” option in the recently added YAML config file. We would have sfizz as default, but we would need a list of the SFZs that perform worst (or fail!) in sfizz.
Please, open a feature request for the 2 last points and we would start moving in this direction ASAP, specially the unifyed soundfonts feature.
Thanks for considering this. I will open a feature request.
Mentioning SetBfree could lead to the assumption that this behaviour might be desirable to distiguish between the top level categories (synth/sampler/organ/keys/percussion)
If one would not unify all synth presets under one list but putting the processor choice as the top level preset choice would not lead into browsing 10000 presets.
I would prefer some kind of user option to state the preferred soundfont player.
I never ran into any major problem with sfizz up to now. There are some cc modifier opcodes that are still not implemented there, but none of them lead to real misfunction of the instrument for me. On the other hand there are some major problems with linuxsampler (flac?, folder structure) that lead to not playing back samples in really straight forward written scripts.
I would bet that users would like to have a default/preferred SFZ engine abut still choose a the other one for specific SFZs.
If all SFZs we know run decently in sfizz, we could start moving right now. I would like to read what other users have to say about this. Could someone tell about specific SFZs that doesn’t work properly with sfizz? Could we identify the critical opcodes that we should detect to force loading with linuxsampler?
Just for completion, i would like to mention the different treatment we make of SFZs and SF2s:
We consider SF2 files as “banks” of instruments. Each instrument inside a SF2 file is shown as a preset. This has sense because there are lot of multi-instrument SF2 files, some of them with many instruments inside, like GM sets.
In the other side, SFZ and GIG files are organized in folder-banks. Each SFZ file is show as a preset. it’s worth noting that some SFZ files include several “instruments” or “articulations” that you can choose using key-switches. Each GIG instrument inside a GIG file is shown as a preset.
Then there is this thread mentioning Salamander Piano being linuxsampler optimized. In the same thread finally users reported that it worked good meanwhile, and the repo now states that the piano is now Sforzando optimized. There is also this NoctSalamander which I can say works great on sfizz.
Reading through the (un)supported opcodes in sfizz: Regarding only opcodes which are widely used in real world examples, unsupported are mostly modifiers (CC/random → parameter, like filters, effects, veltrack and so on) and curve shapes. In most cases the instrument would be usable anyway. I did not find that in real world, but a problematic case would be eg. if someone would use the cutoff2 filter (set_cc74=127 cutoff2=100 cutoff2_cc74=9600), so the cutoff will be fixed to an unusable value. But: cutoff2_onccN works, cutoff works with all opcodes, and the most common cc modifiers (–> ADSR/filter ADSR/filter/LFO/pitch/volume/offset etc.) work.
But I’d be really interested in practical problems with sfizz.