Hi @ToFF
Could you share the link?
I can’t find it in the wiki.
Thanks
I have it all messed up on my PC. I don’t have access to the wiki.
Good idea @riban. I went ahead and grabbed some screenshots from the UI and updated the page to display a gallery of UI images.
After I started, I realised it would be cool to use the gallery as the basis for the entire page. You can link the images direct to the page (whether internal docs or a link direct to the synth/effect creator’s docs directly). The gallery shows a description on mouse hover. I like the idea that someone who is exploring the wiki can click the synth engines link and see a wall of UI images, that should get people more curious and remind them of all the stuff sitting under the hood.
2 Likes
After looking at this more, I decided to update the list of synths on the wiki page into a sortable table. I copied the full list from webconf then added more headings to provide an almost complete list of descriptions and categories for the synths with a space for notes and guides. It’s possible to click the headers (e.g. sub-category or author/project headers) and sort the list the way you want to help discover what’s available. Suggestions on column headings are welcome.
I referred to threads such as below and many websites on a process of Zynthian synth discovery to make descriptions and categories for everything. I hope it is helpful for people. It was quite a bit of work, and I wondered whether people don’t use half of them? Maybe now they will? Along the way I found interesting things such as the physical modellers, PC soundcard chip emulators (MiniOPL3, reMID), OS-251 digital Juno style synth and the drum synths that @ToFF has been putting lots of work into.
One thing I would ask @riban or @jofemodo is if it’s possible to install a table editor extension for the wiki? This table is pretty big and it’s a pain to make changes if others want to edit it going forward (such as adding more guides).
I have another table saved on my computer for the effects list. These are probably more self-explanatory than the synths with their sometimes obscure names. I think adding the sub-category and author/project can help to see what effects are less common (e.g. granular). This list is a monster though and I won’t be filling it all out. There are sites such as below which I used to create the table (import from spreadsheet) but something built into the wiki editor would be best to make updates easier.
4 Likes
Hi @LFO!
Great work!! We really need to put some order in the synth & effects collection and we need to coordinate the efforts to take profit of everyone who want to help with this. The wiki is a great collaborative tool, but far from perfect. The risk of collisions will increase when several collaborators start editing this table and this will lead to frustration and wasting of time and resources.
Luckily, developers have been doing some work in the shadows and we are really close to having a good solution. Let me explain myself:
Those of you already using Oram-Bookworm version probably have noted some important changes regarding engines:
-
engines are categorized in the UI and you have to browse across the different categories to find the engine you want. The separation between LV2 plugins and the rest of engines doesn’t exist anymore. Engines are engines.
-
when browsing engines in the UI, some extra info is shown. Currently this info is only available for users using the “4-rotaries-at-right” layout (V5), but we are looking for the best way of making it available for “classic layout” users:
- Quality (1-5 stars) => How good/remarkable/special is the engine
- Complexity (1-5 knobs) => How complex to use is the engine
- Description => 100 first chars or 2-3 sentences aprox.
- in webconf, “LV2” tab is now called “Engines”, and the table allows editing the category and the extra info:
All this engine info is stored in a json file at:
/zynthian/config/engine_config.json
The description is not limited in length, although only the first 100 chars. (aprox.) are shown in the UI because of the limited space.
So, we have a comfortable, fast, coherent and decentralized way of editing engine info.
What we need now is a good procedure for “collecting & merging” the distributed work of all zynthianers that want to contribute seriously to improve this data base. Collecting is almost trivial, but merging can be challenging, specially if we don’t have a good ruleset that enforce coherence as much as possible.
This is my proposal for next steps:
-
Close category lists: We have implemented a “flat” category system for each engine type (synth, audio processors, MIDI processors, etc.). We have avoided nested categorization because of browsing simplicity. The category list for each engine type SHOULD be closed ASAP to avoid wasting resources in re-categorization processes. Currently we have a decent proposal for Audio Processors (the hardest type!) and draft proposals for the rest. Of course, we are open to any proposals regarding category lists, but once we close them, we should try to stick to our decission and avoid an endless discussion about this subject. There are infinite ways of categorizing the engines and each user will have his preferences regarding this and it’s very dependent of user likes and workflows. My personal vision regarding categories is:
- The less, the better
- I prefer a functional criteria: what the engine does (instead of, for instance, how it does it)
-
Extra fields: We should consider if it’s useful to add extra fields for the wiki or other documentation, but not used by the UI. I mean, project/documentation URLs, author, etc. I personally wouldn’t add too many fields to what we currently have. Remember that this table is loaded and kept in memory by zynthian UI.
-
Decentralized DB Collecting: Those wanting to collaborate on this effort to generate the zynthian engine info DB should use the webconf to edit the table. This will enforce the format and stablished rules, so we will have a coherent collection of files to merge.
Regarding the editing/collecting process itself, initially all engines would have Quality and Complexity set to 0. Only engines with Quality and Complexity set to a value > 0 will be considered for merging. I mean, collaborators should truly test the engines they edit and evaluate category and complexity for them. When editing an engine, collaborators must choose the best category for it and write a short description that fits UI. Description can be longer, but it’s important to have a short description intro that can be displayed in the UI and it’s compact and descriptive enough. We should avoid redundant info. For instance, we would avoid saying it’s an “excellent emulation” because excellence is already expressed in the “quality” field
-
Merging: Automatic except when collisions. Someone would have to manually merge collisions. The latest DB file would be published on zynthian repositories so normal users would get the latest version when updating their zynthians. Also, wiki table could be updated automatically from the repository version, etc.
NOTE: I would kindly ask collaborators to avoid evaluating engines they don’t understand or are not qualified to evaluate. Indeed, collaborators should have some background related to the engine type/category they are evaluating. I mean, if you are evaluating a plate reverb, you should know what a plate reverb is, so some sound engineering or music production background would be desired for evaluating this. And please, don’t think i’m being “elitist”. I’m simply trying to get valuable scores for the engines. For instance, i’m not going to evaluate any audio processor because i don’t think i’m qualified for it. I could evaluate some synth engines because i play piano/keyboards and have some experience with them. I have played a real DX7 or a Fender Rhodes for a time, so perhaps i could evaluate dexed or ePiano, but it would be better if someone who has played a real Oberheim could evaluate OBx.
Only proposals!
Let’s brainstorm about all this, please
The best!
3 Likes
OK! Let’s start with the category lists:
Synth Engines:
- Analog / VAS / Virtual Analog => What is better?
- Drums => This is purely functional
- FM => This is NOT functional
- Modeler
- Soundfont
- Wavetable
- Others
I’m not too convinced about this list. Criteria is not coherent. Please, help
Audio FXs
- Analyzer
- Delay
- Distortion
- Dynamics
- EQ
- Filter
- Looper
- Modulation
- Panning
- Pitch
- Reverb
- Simulator => This “mostly” refers to amplifier simulator. Very “guitar player oriented”, but functional
- Other
This list is not perfect, but i’m quite satisfied with it. Of course, open to improvements.
MIDI processors
- Arpeggiator
- Automation
- Chorder
- Filter
- Mapper
- Sequencer
- Other
Not very sure. Some advice will be welcome!
Audio Generators
- Oscillator
- Other
Not very sure. Not very important. I’ve not thought about this too much
Regards
2 Likes
Damn, I wish I had checked out Oram before 
but I only have one sdcard available and not keen to go experimental right now.
This taxonomy problem can be a bit thorny. When adding the descriptions I was thinking: what is a useful way to describe each synth? I went with a sub-category to add things like wavetable or FM to the main synth category or author/project because maybe you found an author’s plugin interesting so you want to try more. But yes, KISS is best.
Could tags be one solution? I was wishing for tags while I was combining these descriptions, sometimes devices combine multiple qualities that aren’t just ‘virtual analog’ or whatever. It can become crowd-sourced categorisation. Not sure if that would be useful inside the zynth UI though (maybe it could with touch capability?). Or is this just adding unwanted complexity? I don’t know.
Regarding the descriptions, I noticed the ones that provide a description of the types of sounds it can achieve were helpful. I mostly picked them up from github or the project pages but the quality varies. Here some better examples of technical and/or functional descriptions:
- Triceratops Triceratops is a virtual subtractive synthesizer plugin with 3 oscillators, 3 ADSR envelopes and 3 LFOs. Oscillators have unison mode, filter has three modes low pass resonant 24db, high pass and band pass. Oscillator sync, inertia (portamento) and basic FM is implemented.
Very descriptive but what kind of sounds does it make or what is it good for? If you are more experienced you may see this list and understand what types of sounds it can achieve
- SO-666 Feedback Synthesizer SO-666 is a feedback based drone synthesizer building upon the SO-KL5 synth. It creates haunting cacophonic howls and drones. It’s a bit hard to play but making good use of the modwheel will help keep the sound in control.
A bit more ‘what can it do’ and how to use it. When I read this description I want to try it!
- OS-251 OS-251 is a “JUNO” style digital subtractive synthesizer with a simple yet powerful DSP algorithm. Unlike other plugins that use analogue simulation, OS-251 uses digital algorithms to give warm, lo-fi sounds.
This one is a bit technical description but also gives a sense of what sounds it can make e.g. ‘Juno’, "lof-fi’, again I want to try it
1 Like
The categories should be ordered to match workflow, e.g. currently they are ordered alphabetically so “Analyzer” is first but I seldom want an analyser but often want reverb.
Similarly we may want to use the quality value to sort processors. Do we want the best ones at the bottom because they start with, “Z”?
“Modelling” is better than “Modeller”.
“Percussion” is better than “Drums”.
“Analogue” is better! “VSA” means nothing without context and “virtual” seems superfluous. (Analogueish?) I wonder if this is too restrictive? We probably think of most analogue synths as using subtractive synthesis. Maybe:
- Subtractive
- Additive
- Mixed
- Sample
- Percussion
- Modelling
We could categorise by era, e.g. 1980’s, 1990’s. Of course this doesn’t give much info and I probably think it’s a bad idea but… blue-sky thinking!
We have talked about tags before and I think they may be appropriate here. It does add a little complexity to the design but I don’t think too much. It allows a processor to appear in multiple categories. That may be confusing/ undesirable but Zynaddsubfx, Surge, etc. are complex synths with multiple synthesis mechanisms. It feels wrong to put them in “Other”, especially if they are significant flag-ship modules.
EQ and Filter are effectively the same thing. We shouldn’t separate these.
“Simulator” confuses me. We could use “Modelling”. Modelling seems to be the more common description.
“Panning” is a form of modulation. I think we should lose “Panning”.
“Chorder” (isn’t a word!!!) is like “Mapper”. We don’t want / need lots (more than one) chord plugin so it probably doesn’t need it’s own category.
Description should avoid repeating anything that is obvious or superfluous. Avoid using superlatives or other qualitative descriptions, e.g. “A good monophonic virtual analogue synth with excellent filters” has to many adjectives and to little useful description.
Are there any technical authors out there?
We can use upstream descriptions as a basis but we want a consistent language style. And we should avoid references to manufacturers or specific devices that may be protected by copyright. Such comparisons are the domain of the independent reviews.
I would add * Vintage for setBfree, combo organs, string machine, Mellotrons etc,
.
or Emulator
1 Like
Complex / cumulative / compendious
1 Like
I think the modelling catagory should be about modelling real sounds, like Pianoteq. We can have a catagory for Organs. I don’t think it advantageous to have a catagory to group together engines that emulate other electronic devices (like setBfree). It does not have a functional purpose - only a historical interest which, although interesting is not useful. (Again - something for the docs / reviews.)
Synth Engines:
- Subtractive
- Additive
- Complex
- Sample
- Percussion
- Modelling
- Granular
- Frequency modulation
- Vector
- Wavetable
it’s from a synthesis-type point of view, but then the percussions stand out for me
I would suggest that Wavetable could be included in Sample. Would "Vector fit in “Complex”? (I am not sure the quantity of vector synthesis engines we have. We don’t really want catagories with single entries.
I feel a big difference between wavetable and sample when I look at the classic representatives:
Vital - wavetable
Sfizz - sample
And yet another synonym for COMPLEX
Surge - he defines himself as a hybrid synth
Fantastic! Here my 2 cents. I will be pragmatic, forget purism and think only in user experience. As @riban said above, we should avoid categories with 2 engines.
First, i think that “soundfont player” should be a category by itself. The 3 soundfont players deserves a special place where you can fin them easily. In the other hand, we have a lot of hardcoded-soundfont plugins. Could we have a separated “soundfont” or “sampled” category? I reckon to use “sample” derivative words because some people associate “sample” with “sampler” and this create confussion.
Perhaps we should simply put the 3 generic soundfont players the first positions, separated with a line from the rest of hardcoded-soundfont plugins.
I would remove granular, as we don’t have any granular synth and they would fit in the “complex” category. Regarding additive, AFAIK, “Aeolus” and is the only one in this category. setBfree could be there too, but it include some extra processing like vibrato and lessly, so probably would be better in complex. Anyway, i would prefer a “Emulator” category for engines that emulate a physical device. Regarding modelling, we have only Pianoteq, so perhaps we could put Pianoteq inside “Emulators” and remove this. Vector engines should be in “complex” too. Frequency Modulation is too long. FM is shorter and everybody understand it. Anyway, this category will be quite “empty”. Why not moving Dexed to “Emulators” and remove FM category?
My revised proposal for “Synth Engine Categories”:
- Analogue => NoizeMaker, helm, synthv1, triceratops, calf monosynth, etc.
- Complex / Hybrid => ZynAddSubFX, surge, string machine, padthv1, etc.
- Emulator => Pianoteq, setBfree, aeolus, dexed, OBxD, JX10, ePiano, FooYC20, etc.
- Percussion => DrumGizmo, fabla, geonkick, drumsynth, etc. This is purely functional. Should drum-soundfont plugins be here?
- Soundfont Player => FluidSynth, LinuxSampler, Sfizz
- Soundfont => The hardcoded-soundfont plugins. We have a lot of them.
- Wavetable / Sample => Those engines allowing to load separated samples. Like samplev1, DrMr Sampler, Calf Wavetable, etc. We still lack a mechanism to load samples from the zynthian UI, so they have to be operated from the native GUI via VNC.
- Other => Do we need this?
I’ve been tempted to add a “Piano” category to the list. It’s purely functional, like percussions and pianos deserves a relevant place. But then, perhaps we should add “Organs” too, etc. This way is tempting, but it also have its limitations. Opinions?
Let’s follow this interesting journey, but i would like to add a rule. Following proposals must include examples for every category and they should be >= 3. Preferably more!
Regards!
1 Like
In my opinion, yes
Very cleverly divided, I agree
Away with this vague and saying nothing
I am also in favor of having this category. Pianoteq, MDA Piano, MDA ePiano, Fluid Pianos …
If we have three or more representatives in the Organ category, we can have it too. Representatives of this category: aeolus, setBfree, Fluid Organs, Foo YC20 Organ. Oops, I think I found them
1 Like
Hi @riban !
I also thought about this. You are right in theory, but remember the “functional” approach we want to adopt. EQs are filters that you use to equalize, but not all filters are used for this. IMHO, EQ process is important enough to deserve a separated category.
Indeed, a good amount of these “simulators” are convolvers that simulate amplifier cabinets, so they work mostly like many reverb plugins, but reverb process is important enough to deserve a separated category and we don’t want to have reverb plugins mixed with amplifier simulators. Perhaps we should change the category name to “amplifier simulator” or simply “amplifier”.
You are right again, but modulation category is quite overloaded. Perhaps we should split “modulation” category instead of adding more to it. Anyway, “panning” is quite functional and important. I would check how many panning plugins do we have to see if it justifies a separated category.
Agreed. Let’s remove chorder and move them to mapper.
Regards,
1 Like
He he! I was pleased to see @jofemodo say what was in my head as I read his proposal…
People want to find instruments based on the sound they make, not necessarily what tech is used to make them. I agree with having Piano & Organ. I see that @ToFF responded similarly with good suggestion for populating these.
I don’t like “Emulator”. We may move many of its content out, e.g. Pianoteq, setBfree, aeouls, ePiano. Also I think that OBxD & JX10 fit better in the “Analogue” catagory.
I have often wondered why we have all those soundfont LV2 plugins. They make it simpler to get to what you want but you have to have lots of them to do this. They are all available within fluidsynth and it makes for a much simpler to understand system if you have one soundfont player which can load all available soundfonts. It is also more efficient on resources due to how we manager standalone Fluidsynth. I would be happy to see the soundfont LV2’s removed. (Of course we may want a migration that automatically replaces them with Flusidsynth instances.)
I also wonder why we have three different soundfont players. (I know the answer but it would be good to have just one to rule them all!)
I prefer “Hybrid” to “Complex”. It is explicit what it means. Complex could mean all sorts of things.
Wavetable is a form of sample player. It is clever simultaneous use of multiple samples but at essence it is a sample player. I see this as very similar to soundfont players. Both of these are what we would have called a Rompler back in the day, playing pre-recorded samples with some processing. Samplers had the enhancement that they could record as well as playback. Most of our sample based modules do not implement recording so fit in the rompler heading. I think these can all go in a Sample type catagory.
“Other” should be avoided but it could be a catch-all that only appears if there are any non-catagorised plugins. This might happen during development when adding a new module that we haven’t catagorised yet. It can be easy to add LV2 but we need to manually catagorise all plugins. So I think we should aspire to not normally see “Other” but it should be there in the background.
The audio player is actually a sampler. It sits in “Special” at the moment but doesn’t really belong there. (There is some history around this. Audio Player has evolved a lot since.)
I would be suprised if there were many panner plugins. (And if so - there shouldn’t be! How many ways are the to pan a signal?) Remember that users can disable plugins and are unlikely to have many of any of these plugins enabled. If they find a panner they want then they will enable it and disable the others, resulting in a single plugin in the catagory. Although there may be many modulator plugins, a user is likely to disable most and just have the most useful ones showing. We can use subcatagories within each list if it is useful.
If the simulator / modelling plugins are only amplifiers then let’s have an amp catagory. Indeed there are other plugins that are not simulators that would fit that catagory, e.g. Amplifier Gain LV2.
In that case I propose the category "Weird Shit”
Also we can have “Cursed Instruments” category for the Banjo.
2 Likes