I played around with them quite a bit and I must say, while most of them are pretty awesome, some of them seem to be not as robust as the originals. E.g. Baxandall just cuts heights if you raise the treble knob.
However, there are quite some additions which work great. If you’re overwhelmed by the number of plugins, try these first:
I’ve added the airwindows plugin collection to zynthian vangelis.
I have re-categorized a bunch of them, but still not sure of having every plugin in the right category.
Perhaps we need to extend the category tree. I’m open to proposals.
Also, you can contribute adjustments to the engines DB:
/zynthian/config/engine_config.json
Re-categorization, description improvement, ranking scores, or “enable-by default” proposals.
@hannesmenzel , i’m still testing the huge amount of plugins that compose this collection. Some of them are really sutile and some are quite esoteric,
But it’s a really amazing collection and the best is they have very few parameters, what is perfect for zynthian.
There are a few plugins we may not want to include or at least not enable by default. We can definitely leave out the “Console” (and PurestConsole) range completely as they are an esoteric (but good) channel-bus summing plugin not so suitable for zynthian (at least if we don’t want to include it under the hood). Then there are dithers, nice but not so suitable for zynthian maybe. Then we might consider keeping one version per plugin, since Chris from Airwindows tends to not update plugins, but add newer versions next to the old ones.
I’m actually searching for a way to script a vst to lv2 conversion that we can have theoretically every airwindows plugin and then chose the right ones (there are +500 at the moment).
Do you think I should delete my compiled plugins before performing an update?
Legend: - Yes! Activate by default. - Probably yes, but not (fully) tested - Don’t activate - Bad, to esoteric or not suitable for zynthian workflow - More recent version available (what must at Airwindows not always mean it’s better but sometimes different)
Any problems with line endings when I edit the engine config on a windows machine?
@jofemodo I looked over all the categories, see PR.
By the way, I had some problems with the categories, so we might want do define, what a simulator is, diverse the category of distortion (add saturation?) and ask if spatial and panning might be merged into one.
Well, in theory it would be any plugin that simulate a real device, but it’s confusing, also for me.
The problem is that the criteria is not unique. Most categories are defined by the “functionality” or the “type of process” the plugin does, but simulator doesn’t.
In practice, we normally use it for amp simulators, reverb / cabinet simulators (IR convolvers) and things like that. Anyway, a bunch of airwindows use this category.
The line between distortion and saturation could be really blur. Perhaps it’s better to change the name to “Distortion & Saturation”.
Well, conceptually, panning is part of spatial. Merging both categories seems logic.
Let’s see what other zynthianers think about it.
I think we would have plenty of guitar amp and pedal related, which could form another category. Well, more for the amps, the pedals might fall in functional ones (like distortion perhaps).
I agree about the blurryness of distortion and saturation, but a tape simulation or a mixer input stage in distortion seems odd. I think we recognize a distortion when we see it, which might be ProCo Rat clones as well as hard clipping waveshapers.
I’d put Convolution to an extra category, because it can do cabs and reverbs alike, and you might want to find it explicitly if you want to load a reverb IR against an algorithmic.
By the way, wouldn’t it be fine if the UI just generated the categories from the present one in the engine list?
