Creating synth presets in Clojure

To speed up the creation of and maintenance of synth presets for rogue I created a little tool called rogue-presets. It is written in Clojure and provides a declarative way to write synth presets for the rogue synth.

The basic idea is that incremental changes to the synth defaults are stacked and merged and written out into LV2 preset files.

Here is a simple example

(def two_oscs
  (merge defaults
         (osc1 :level 1 :level_a 0.5)
         (osc2 :level 1 :level_a 0.5)))

(defpreset lead-pulse1 "Pulse Lead 1"
  (osc1 :type pulse :width 0.25 :fine -0.05)
  (osc2 :type pulse :width 0.75 :fine 0.05)
  (filter1 :freq 440 :type lp_12db :q 0.2 :level 1)
  (env1 :attack 0.01 :curve 0.7)
  (env2 :attack 0.1 :sustain 0.25 :curve 0.7)
  (modulations [mod_env2 mod_flt1_freq 0.6])

and here a more complex one

(defpreset pad-arctic "Arctic Pad"
  (osc1 :type fm1 :level 1)
  (osc2 :type saw :level 1 :coarse 12 :out_mod 2 :level_a 1) 
  (filter1 :type svf_lp :freq 220 :q 0.3 :level 1)
  (env1 :attack 0.3 :sustain 0.6 :release 1.2 :curve 0.7)
  (env2 :attack 1 :sustain 1 :release 1.22 :curve 0.7)
  (lfo1 :type lfo_tri :freq 2)
  (reverb-fx :bandwidth 0.75 :tail 1 :damping 0.25 :blend 0.75)
  (modulations [mod_lfo1 mod_osc1_pitch 0.2]
               [mod_lfo1 mod_flt1_freq 0.2]
               [mod_lfo1 mod_osc2_amp 0.2]
               [mod_env2 mod_flt1_freq 0.8]))

The general order is base settings, oscillators (osc1-4), filters (filter1-2), envelopes (env1-4), lfos (lfo1-4), effects and modulations.

The modulations section contains triples of source, target and amount. For example [mod_lfo1 mod_osc1_pitch 0.2] declares that lfo1 modulates the pitch of osc1 by 0.2.

I am still experimenting with this approach, but it feels promising.

rogue stabilizing

My current freetime project rogue is stabilizing. I converted the grid based UI into something more classical. The top bar copies a Minimoog style division and the lower level features tabs for common settings, envelopes, lfos, the modulation matrix and effects.

Screenshot from 2013-08-10 17:40:27

I am not yet very happy with the colours of the GUI, but the division makes IMHO more sense than a grid. Waldorf Largo uses a similar layout but with different knob sizes and lots of eye candy.

Featurewise osc sync and global lfo usage are still missing. Most of the other pieces are already there.

See the project page for usage instructions

Full visualizations

The component visualizations for oscillators, filters, envelopes and LFOs are now ready. The real DSP elements are used in the GUI to provide a realistic rendering of the component output. For oscillators and lfos a single wavecycle is shown and for envelopes a scaled envelope cycle from attack to finish is drawn.

For the filters fftw is used to calculate the FFT of the filter impulse response and a scaled version of the power spectrum is then drawn. I have yet to test if the FFT calculation is fast enough, but it looks quite decent.

In addition to the component visualizations, labels with knob values have been added. Now the exact values of all the ports are visible in the UI. It makes the UI a bit more crowded, but is hopefully more useful then the browser approach of ElectraX. The knob + name + value combination is also used in Curve.

Here is a screenshot


Sketching a new UI

After having worked out most of the lower level audio processing components in rogue I started to improve the GUI.

I wanted to customize the appearance of the Gtk GUI, but had some problems to apply theming so I considered looking at Qt as an alternative. I was quickly convinced by Qt and converted the full GUI to Qt.

All in all the advantages of Qt over Gtk are

  • easier theming, at least compared to Gtk 2.*
  • better designer tools
  • a dial widget to start from
  • C++ based programming model

Some disadvantages are

  • integer range for dial widget
  • build time metamodel and C++ syntax extensions

For the UI the main inspirations are ElectraX and Curve.

The UI is quite flat and I tried to make it usable and informative. Here is a sketch of the current state


I might still slim it down to something like this


The modulation part is not yet very usable and there is lots of empty space, but otherwise I am quite content with the current state.

Plotting waveforms

I am currently working on a new softsynth project and wanted to get some more immediate feedback of code changes to waveforms shapes, since most of the synthesis used in rogue are related to phase/waveform shaping.

Instead of plotting the waveforms via scripting tools like python or ruby, I decided to use Javascript for it. I set up a minimal table structure in the HTML document and plotted the waveforms via jquery, Flot and various phase to wave functions.

The HTML file is available here and it looks like this


The waveforms are categorized by synthesis types: VA for virtual analog, PD for Casio CZ style phase distortion, EL for various electronic waveforms and AS for additive synthesis.

The width controls the pulse width or distortion of the waveform and the tone field controls the brightness for additive synthesis. This combination gives me the possibility to try out new waveforms easily.

The functions used in the plot are referenced in the HTML document and take three arguments, the phase, the width and the tone. All parameters are from 0 to 1. The waveform plots are for 1.5 cycles.

Typed Lisp adventure

After having been inspired by overtone and extempore to try out a Lisp dialect for DSP coding I wondered if it would be possible to use a Lisp language directly in synth plugins without a host environment.

My second (or third) language in daytime programming is Clojure, which I am very content with, so I wanted to use something similar in my “freetime” for DSP programming. I initally tried some Scheme dialects such a Chicken, Gambit and Bigloo, but became a little annoyed by the verbose syntax and the lack of proper abstractions for collection like types.

On GitHub I stumbled upon a few statically typed Lisp dialects and was especially convinced by looking at extempore that writing a statically typed LISP was possible and for some programming domains even useful. So I decided to write something similar like extempore, but with Clojure syntax instead of Scheme and without a host environment but gcc based compilation instead. I named the exercise symbol.

I considered using LLVM as the compilation backend briefly, but found especially closure handling too difficult to handle, since I hadn’t any prior experience in compiler programming. I went with using C++11 as the target language since it has some nice features such as templates, closures, direct C bindings and fast compilers.

Next I began to sketch the architecture for my language compiler. After a few iterations and studying various Clojure/script compilation projects I went with

  • reading via a customized Clojure Lisp reader
  • macro expansion, using Clojure macros
  • form normalization via various function based rules
  • type inference using core.logic
  • serialization to C++
  • compilation via g++

The most challenging part was probably the type inference. Having used logic programming actively 10 years ago it was a little difficult to get into logic programming concepts again, but after a few core.logic performance issues, most things went quite smoothly.

I was able to infer variable types based on assignments and function argument and return types via body expressions using a simplified version of the type inference. In addition to Hindley-Milner type inference I also extended the set of literals of the syntax via a custom reader to support integer and float literals in addition to ones Clojure supports.

I was quite successful with porting simple extempore examples to symbol, but struggled with more complex programs. I also couldn’t decide whether to include garbage collection or not. Using smart C++ pointers might have been a good alternative, but might have been difficult for type inference, so I continued with raw pointers and without garbage collection.

I tried to use C++ bindings directly via gccxml which dumps the intermediate format of the gcc compilation via XML, but had some issues with it. gccxml doesn’t support templates and the XML format was difficult to transform into a form that was compatible with the types of the type inference.

Another difficult issue was to map both stack and heap allocation to the minimal syntax of symbol. After a while I gave up and began to use C++ directly for DSP programming. All in all this was a really interesting experience to sketch a new language, or better a compilation chain, since what I did could also be described as mapping a subset of Clojure syntax to C++. I might continue with symbol once I am more familiar with C++, but for now it’s suspended.

Various syntax examples are available here.

Diving into D

After having used C++ and Faust for a while to write Synth plugins I decided to try out some alternatives. My main requirements for the language were automatic memory management, easy to use bidirectional C interfacing for using and exposing C libraries and support for functional programming. I considered amongst others OCaml, Haskell, D and Vala as language options. After a small evaluation of the options I decided to focus on D. OCaml didn’t look like a proper evolution over Standard ML, Haskell too demanding to learn and Vala with too many Gnome dependencies.

D is a statically typed C-based language with the ambitious goal to provide a better C++. It feels more consistent than C++, but sits oddly between a system and application level language. As a small exercise I ported the STK library to D to get a better feel of the language features. I named the port synd.

What I liked were the module system, properties, type inference and integrated support for unit tests. What I found confusing were mutability of ranges, initialization of members and the quite heterogeneous community. Missing support for shared library creation in Linux is a showstopper for now.

I am still trying to figure out whether to use closures for lower level elements or Class based objects. The FP approach allows for more consistent types and composition of elements whereas the OOP approach offers better separation between configuration and other method calls.

Cascaded delegate construction would also work in D. And it works quite well for elements where only static and sample based configuration parameters are used. For configuration updates let’s say every 32 samples something else would need to be used.

Both extempore and Overtone look like good sources of inspiration for doing functional audio coding.

Soft synth plugins for Linux

Before starting with a new Soft synth project for Linux I decided to track what kind of synthesizers are already out there available. I focused on LV2 plugins, since LV2 is the plugin standard I want to use. LADSPA is outdated and DSSI doesn’t seem to be as widely used as LV2.

With the aim to provide a clear separation between the synthesis engine, the LV2 integration and the GUI I focused also on architectural aspects.

So here is a list of LV2 soft synths for Linux in no particular order.

Calf plugins

Calf plugins provides a set of plugins available as LV2, including a flanger, an organ synth, a phaser, a reverb, some filters, a chorus and a rotary speaker simulator.

Calf Monosynth

The Calf Monosynth is a monophonic subtractive soft synth.

Calf Organ

The Calf Organ is a mixture of a traditional drawbar organ and a subtractive synth.

Calf Fluidsynth

The Calf Fluidsynth is a frontend for the Fluidsynth Sampler engine.


The YC-20 is a divide-down combo organ designed in the late 60’s. The foo-yc20 emulation faithfully copies the features, sounds and flaws of the original organ.

Foo YC20


The Newtonator is a LV2 soft synth that produces some unpredictable sounds.



The LinuxSampler is a streaming capable open source pure software audio sampler with professional grade features.


The Minaton is a fat sounding mono subtractive software synthesizer.



ll-plugins provides several synth and utility plugins and a GUI-capable host.

Composite Sampler

Composite Sampler is a LV2 plugin that acts as a MIDI-controllable sampler.


lv2-mdaEPiano is a native LV2 port of the famous mdaEPiano VSTi.


mda-lv2 is an LV2 port of the popular VST mda plugins.

Russolo Suite

The Russolo Suite consists of the CrazySynth Synthesizer and the “the do-it-all effect” Omnifono.


So-synth-LV2 provides unofficial LV2 ports of 50m30n3’s synthesizers.


Zyn provides an LV2 port of Zynaddsubfx.


Qin is a LV2 synth plugin for plucking sounds


Minicomputer-LV2 is a softsynth for creating experimental electronic sounds


lv2_guitar is another String synth

This list has been assembled from the contents of the following two webpages:


Here is also an overview of the used programming languages and GUI toolkits in each plugin:

Name Languages GUI Remarks
Calf Plugins C++ GTK+ UI is defined in XML, knobs are created from SVG files and rendered via Cairo
foo-yc20 C/C++/Faust GTK+ Faust is a functional language for DSP design
Newtonator C++ GTK+ -
LinuxSampler C++ Qt4 Qt4 is only one GUI option, there is also a Java based UI
Minaton C++ FLTK -
ll-plugins C++ GTK+ ported from DSSI plugins
Composite Sampler C++ - part of bigger Composite audio system effort
lv2-mdaEPiano C++ - -
Russolo Suite C - -
So-synth-LV2 C - -
Zyn C/C++ - extracted Synth engines from ZynAddSubFx
Qin C - -
Minicomputer-LV2 C - -
lv2_guitar C - -

From this overview can be seen that most of the GUI-less plugins have been written in C++, whereas the plugins with GUIs have been mostly written in C++. GTK+ is prefered over Qt and FLTK as a GUI toolkit.

Popular Non-LV2 synths

As the LV2 plugin is still quite new, there are lots of great established soft synth projects that are not available in LV2 format.

Here are some of the more popular options:

Name Languages GUI Remarks
amSynth C++ GTK++ Subtractive synth with 2 Oscillators
Bristol Audio Synthesis C ? Emulation of various vintage keyboard synths
Qsynth C++ Qt4 Popular Qt based frontend for FluidSynth
ZynAddSubFx C++ FLTK Very popular synth with three different synth engines
Hydrogen C++ Qt4 Popular drum machine
hexter C GTK+ very good Yamaha DX7 synth emulation
WhySynth C GTK+ Versatile multi paradigm soft synth

Polyphonic Faust?

After my Physical Modeling Flute Faust experience I decided to try to model a virtual analog synthesizer in Faust. I looked at several synth structures and came up with this fairly standard wiring :

2 LFOS, 2 Oscillators, Noise generation, 2 Filters, 2 Amplifiers and 4 ADSR envelopes (integrated in Filters and Amplifiers).

Designing this in monophonic form was fairly easy, as no recursion in top level elements was needed like in many physical modeling designs. For oscillators, filters and envelopes standard components of the Faust libraries were used. Finishing a monophonic synth was easy.

Changing the monophonic synth into a polyphonic one was also quite straight forward. The single gate, gain and pitch controls for a single voice needed to be duplicated. I moved the original process declaration into a single voice with the following definition

voice(gate, gain, pitch) = (lfo1, lfo2) <: (_,_,osc1,osc2,noisegen)
  : (_,_,pre_filter_mix) // l1, l2, f1_in, f2_in
  // to filters
  <: ((_,_,!,_), ((_,!,_,!) : filter1)) // l1, l2, f2_in, filter1, filter1_to_f2
  <: ((_,!,!,_,!), (!,_,!,!,!), ((!,_,_,!,_) : (_,_+_) : filter2)) // l1,   f1_out, l2, f2_out
  // to amps
  : (amp1, amp2)
with {
    // ...
    // in : o11, o12, o21, o22, n1, n2
    // out : f1_in, f2_in
    pre_filter_mix = bus6 <: (((_,!,_,!,_,!) : _+_+_), ((!,_,!,_,!,_) : _+_+_));

The new process looks like this

process = par(i, 8, voice(i)) :> (_,_,_,_) : effects :> (main_out * _, main_out * _);

8 voices are run in parallel and are then mixed into a 4 channel signal which is fed to the effects section and then fed to Stereo out.

A problem with this design is that all the 8 voices are always on. And the resulting Faust structure is quite large and takes a long time to compile. With several compiler level optimizations this design can be made runnable.

Other performance issues are on a lower level with select2 and select3 constructs, which are Faust’s if-else equivalents. Non-active branches can only be skipped in Faust if they have no memory. Memory, or state, is involved if you use any kind of delays, either explicitly or via usage of recursion. The “always on” philosophy needs to be taken into account on every level, if low CPU usage is a goal.

I defined a single multi-waveform oscillator like this

oscillator(type, freq, width) = select5(type,
    squarewave(freq, width),

As all of these components use state internally to keep track of the current phase all of them are always run.

One way to fix this is to separate the phase which is stateful and needs to be memorized from the wave shape generation. This is another oscillator design which has stateless functions in the wave selection :

oscillator(type, freq, width) = phase(freq) : phase_to_osc(type, width);

phase(freq) = (+(q) : mod1) ~ _
with {
    q = float(freq)/float(SR);

phase_to_osc(type, width) = _ <: select5(type,

square(w) = select2(_ < w, -1.0, 1.0);

saw = bi;

tri = bi : fabs : bi;

bi = 2.0*_ - 1.0;

mod1 = fmod(_, 1.0);

phase is the phase generation and phase_to_osc is the wave shaper.

I will probably use this kind of phaseshaping oscillator structure also for my coming synth projects, Faust and non-Faust, because it is really flexible. More about this approach is explained in this paper : Phaseshaping Oscillator Algorithms for Musical Sound Synthesis

With the multi-mode filter there is a similar issue. My current naive form looks like this

reson_filter(type, freq, res) = _ <: select4(type,
    resonlp(freq, res, 1.0), // lowpass
    resonhp(freq, res, 1.0), // highpass
    resonbp(freq, res, 1.0), // bandpass
    resonbr(freq, res, 1.0)) // bandreject
with {
    resonbr(fc,Q,gain,x) = (gain * x) - resonbp(fc,Q,gain,x);

I have experienced a little bit with Moog ladder filter designs in Faust, but nothing really properly working has come out yet.

This synth is again wrapped as LV2 synth plugin with a GTK+ gui. I used Cairo to draw the knobs. Here is a screenshot :

The code is hosted at GitHub, so take a look if you are interested. I do not plan to maintain this project much, as I don’t see Faust in it’s current form the right tool for virtual analog synth design. Things I intended but didn’t manage to do are listed in the Issues section.

Polyphonic operation inside Faust is slow and I expect modulation matrices, alternative wirings and unison modes to be difficult to implement. Faust works quite well though for monophonic synths with a fairly static wiring, since the automatic SVG generation from Faust code makes such structures much more accessible than code.

Flauta is a project I am currently working on. It is a port of a STK based Flute model by Patricio de la Cuadra to Faust. Flauta is monophonic, uses a complex but static structure and most of the elements are mandatory, so Faust is a great match. I will write more about Flauta when we get some proper releases done.

Have you tried similar things with Faust? I am interested to hear more about Synth projects with Faust.

Concerning Virtual Analog in Faust, there is also the foo-yc20 project by Sampo Savolainen, which is a virtual model of the Yamaha YC-20 organ. It also uses a polyphonic design on the Faust level and has a much nicer GUI than mine ;)

Flute synthesis with Faust

A while ago I purchased an Akai EWI 4000s wind controller and as a Ubuntu user I tried to find suitable synthesizers to be used with my controller, since the built in sounds are fairly synthetic sounding.

After having searched for a while I decided that I could write my own. Java is my strongest programming language, but Java didn’t feel like a good tool to write a synthesizer, because of my fear that garbage collection cycles would cause lots of clicks and glitches in the audio output.

Now I delved a bit more into synth programming. I read some books on C and C++ programming and picked the LV2 audio plugin standard as the glue library between my DSP code and a synth host. LV2 is the successor to the LADSPA standard, and as we are talking about Linux standards here, it is not the only one, and seems to be competing at least with VST for Linux and DSSI.

The C API for LV2 is fairly understandable, but I picked the object oriented way, because I found the excellent LV2 C++ tools wrapper library. LV2 programming for the complete idiot is a very good tutorial for this library. Also the study of the lv2-mdaEPiano sources was helpful.

After I had mastered enough C++ and had picked the right libraries I was ready to get started. I was already before familiar with Physical modeling synthesis, and picked it as the synthesis paradigm. To be more exact, Waveguide synthesis.

I picked the STK library as another dependency, to get the proper building blocks for waveguide synthesis and some example models. While the STK source code is quite nice to read, the library is a little bit verbose and after some time I got frustrated and decided to replace the STK library with something more agile.

I searched around and found the stk-faust project, a port of the STK instruments to the Faust programming language. Faust is a functional programming realtime audio signal processing. I read some tutorials on Faust and decided that the compact syntax, the block diagram auto-generation and benchmarks were convincing enough to try it out.

After that I studied the Faust based STK instrument ports and tried to integrate the flute model into LV2 context. This proved to be quite easy, all I had to was connecting the audio buffers and sync the control parameters. But I wanted to try a little bit more expressive model of the Flute. I picked an improved Waveguide model of a Flute and began to port it into Faust.

This took some while as modeling feedback loops and crossing connections in Faust is well supported, but syntactically weird. Nevertheless I got it finished after some time and managed to play some Flute like sounds with it.

Here is the top level diagram for it :

The sources are accessible from GitHub

The model has several shortcomings though. I have not yet been able to model the involved lowpass filters properly, toneholes are not included in the model which makes pitch changes sound unnatural and the excitation is pure white noise.

Concerning using Faust for your DSP projects, I believe that it is a very good language for structurally unchanging models. If there lots of dynamic components in your model that can be added, removed and moved around than Faust is probably not the right tool. If your model is fairly static and C++ works for you as an integration language, then give it a try.

I was very convinced by the Faust syntax, block diagram generation, UI building approach and easy integration into various contexts.