Hi everyone. I found a new open source LV2 synth wich, in my opinion, sounds great. The name is Sunset Circuits, by Dusk Audio. It has a lot of features like a mod matrix, sequencer/arp, chorus, delay, reverb and so on. The filter sounds great to my ears. The most important feature is that there are six modes. Each of them is basically a different synth. I installed the plugin via webconf without any problems. All the parameters are in the interface, and it works in VNC.
Furthermore, Dusk Audio produced some open source great FXs. Just try Tape Echo 2 and DuskVerb…
The links to the synth page and to all the plugins:
Thanks for sharing—six distinct modes plus a mod matrix is a nice combination, and running it in VNC makes it easy to audition parameter changes before committing them. For a clean comparison I’d keep the synth patch fixed, bypass one effect at a time, and record the same short MIDI phrase; Tape Echo and reverb can otherwise make a filter change seem larger than it is. I sometimes use the free KYMA369 Frequency App alongside synth work to browse audible tone ranges; its frequency reference is handy for checking the musical context without treating a number as a claim about what a plugin or effect does. I’ll give Dusk a try.
Well, It worked as expected!!
Now we have a chord analyzer that fully integrates with zynthian UI. Simply add the “chord_analyzer-headless” MIDI processor on any synth or MIDI chain:
I must say I have mixed feelings about these. Starting with the positive: You can get pretty sounds out of these.
(It’s Pianoteq felt patch with the 4K EQ, Multicomp, Tape, Tape Delay and the Reverb on it)
On the other hand, they really tick all the boxes of vibe coded plugins: zipping noises on parameter changes. Really loud pops on model changes. Plus that these multi-mode plugins are maybe not that much suited for headless.
By the way, worth noting I changed the eq’s default oversampling to 1x, because I think it makes sense on a raspberry. Think about changing it for the others as well.
Just a little bit the Sunset Circuits and i find some presets really good, like the “Init Mono”.
But my favorite piece from this collection is probably the “Chord Analyzer” because it’s unique. We don’t have a replacement for this! It’s been programmed with “LV2 spirit in mind” and it fully integrates with zynthian UI.
Indeed, i like a lot that most of these plugins use DAF (a DPF fork) instead of Juce.
I really appreciate this, specially because most plugin developers have jumped to JUCE, but JUCE is a trap for several reasons. First, it lacks some important features we need for full integration with zynthian UI (or any embedded device). DPF is LV2 native and it does support the LV2 way: full DSP/UI separation.
Also, JUCE is boring. It has a increasingly growing DSP library that more and more developers use for their plugins. Newer plugins have less custom DSP code because they use this library. The DSP code is what gives the “sound character” of any plugin. If most plugins use the same code for oscillators, filters, envelopes, LFOs, compressors, etc. then most plugins are boring from a sound perspective.
In the other side, DPF is a plugin framework that doesn’t include DSP code at all. Developers have to fight the DSP code. Take from here or from there, write custom code, use the IA, whatever! Any of these options is better than “every plugin sharing the same DSP code”.
So I want more plugins using DPF and less using JUCE
I agree with you in most of your statements. When it comes to this topic of DSP code in frameworks, I’d say that when it comes to basic DSP building blocks, you shouldn’t reinvent the wheel all the time. So it might be better to have some basic “analog” filter abstractions (I mean, a one pole filter or a biquad or state variable filter is simply what it is) which are coded well, including parameter smoothing than ask some artificial friend to slop something down or try to write that other unique ine pole lowpass filter that nobody coded before. It’s rather the arrangement of basic blocks that can create individual sound as well.
Apart from that I think plugin coders used third party DSP code from huge code libraries before no matter what JUCE is now offering.
Of course. I don’t think DSP code must be written from scratch all the time. But having everybody using the same DSP library all the time can result boring. I think it’s more interesting when developers take from here and from there, etc. Tiny implementation differences do matter. Also, sometimes “DSP bugs” can be interesting from a sound perspective and “add character”
