From faust to mod plugin


I’m learning faust right now. Now I’m wondering what the best way is to get from faust to a mod plugin. Is there a nice way to get a DPFied plugin out of a faust dsp? Or should I just export a lv2?


probably better to just export lv2.

here’s a project that uses faust for lv2 plugins. I made those makefiles…

copy&paste as needed, it’s GPL :slight_smile:


Nearly any of the Gx plugins been written in faust, I use a script-set and a skeleton package to generate the LV2 bundles from the faust source. This is currently limited to audio effect plugins with equal in and output ports. On advance in it is, that it allow oversampling, even oversampling of just the parts which would benefit from oversampling.
A other advance is, that it allow to generate LV2 plugins directly from schematics, by generate the faust code (IIR Filter) from the schematic file.
The scripts and the skeleton packages been part of the guitarix project.

My work-flow when building lv2 plugins from faust source is like this:

./ -p faust mysource.dsp -n MySource
cd ./MySource.lv2
make && make install


I heard of the tool ampsim by you. That’s really cool. I thought about a orange tiny terror. That’s too much for the beginning.

Maybe I could start with a bass overdrive. I think there is no special bass overdrive in the mod yet.
I found that one:
That looks simple. But when I put the transistors in the schematics what informations does your script need?


@brummer Is there any effect pedal with JFETs in the guitarix repository? I couldn’t find any and so I don’t know how to include them in my schematics.


Anything has drawbacks, and so has the ampsimtoolkit. There is currently no support for JFETs inbuilt.
In the current stage, we are bounded to PHP transistors.
A overdrive witch will work in the ampsim will be this one for example:
ColorSound OverDriver

Changing the input and output capacitors will make it a BASS overdrive.

But, one more drawback, we are only able to generate linear filters (IIR), so, the clipping needs to be added by hand in the faust source. For most of my plugs I’ve generated interpolated tables from some diode/transistor calculations with some python scripts, to implement the non-linear clipping.
The ampsim toolkit is also able to generate C** source, for non-linear filters, but, that is a real advanced task, where the build scripts needs to be created carefully.
For getting started with the ampsim toolkit, I’ve included a gschem file “Startset.sch” which include all supported elements.
For different transistor type’s, the needed values could be researched in the net, Check out for spice values of transistors.
Often, I use the ampsim toolkit for partial emulations, and calculate the other parts old school like direct in faust.


I made a schematics and found some values for the BC169C (aka BC547C).

What is Vt? There is Is=7.59E-15, Bf=500 and Br=5. I don’t find Vt.


Vt is the thermal voltage.
For most PNP’s you can just leave it as it is,


Script and schematic is finished. Now I have to package slicot for Fedora -.-



When you’ve resolved the slicot package, you may wont to update your guitarix checkout.
I’ve added now a new directory to ampsim/DK buildlv2
I contain the sceleton bundle and build scripts, which allow to build the lv2 plugin direct from the gschem file.
Just need to run now

python ./ -i mygschemfile.sch

this will create the lv2 bundle and save the .dsp file in /buildlv2 for later rework.


I got this:

Traceback (most recent call last): File "./", line 109, in <module> subprocess.check_call(['./ -p ./ %s' % dspfile], shell=True) File "/usr/lib64/python2.7/", line 541, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['./ -p ./ colorsoundoverdriver.dsp']' returned non-zero exit status 4

The files are there. So now I’m looking what it did.



So we come straight to the next drawback. :relaxed:
The dk resolver sucks on to much variable resistors.
This could be solved by splitting the circuit into partial emulations.
The Colorsoundoverdriver.sch could be split into 2 parts, right after C9.
In part 2 you need also to remove P4 and put the output direct into C6.
Both parts will build then. A remark to the treble control, it needs to be inverted, this could be done by adding “inv=1” to the value list. The same is true for the “gain” (which will better called drive here).

Now you could build both parts, you didn’t need to write a script for any sch file , just use the script like this:

python ./ -i ColorsoundOverdriverp1.sch -m cod1 -n ‘COD1’ -c 'Fuzz’
python ./ -i ColorsoundOverdriverp2.sch -m cod2 -n ‘COD2’ -c ‘Fuzz’

the dsp files will be created in /tmp, and guitarix plugs will be installed. You could try your plugs straight in guitarix.
Now, to stick the parts together, you could open the dsp files in /tmp with your editor, and copy the process part from p1 to p2, rename the process to p1 / p2 and add a new line on bottom

process = p1 : p2 ;

This will represent the Filter Response of the hole circuit, but still missing is the non-linear part.
For the colorsound overdrive, a clipping function is missing, one nice one is this

clip(x) = atan(x)/PI;

add it to the dsp file and change the process line to

process = p1 : clip : p2 ;

This will insert the clipping directly behind the input stage, before the tone control and the output buffer.
Now, still missing is the output volume control, this could be added by add a declaration line on top, after the other declarations.

declare volume_p “Volume”;

Save the dsp file as colorsoundoverdriver.dsp to the buildlv2 directory and run
(from the buildlv2 directory)

./ -p ./ colorsoundoverdriver.dsp -n ColorsoundOverdrive

(remark the space between ./ and colorsoundoverdriver.dsp!!)
This will create the lv2 bundle. You could build and install it (as user) by
make install

Now to make a MOD plugin out of it, you need to follow the advices for the modstk.


Thank you for this detailed description!

How do I have to split the schematics? When I put a 9V battery in the second one, COD1 works fine but when I turn on COD2 it starts with some “noise” and then silence.

I pushed the splitted schematics to github.


I tried it nonetheless.

[nils@linux gx_colorsoundoverdriver.lv2]$ make install g++ -I. -fPIC -DPIC -O2 -Wall -funroll-loops -ffast-math -fomit-frame-pointer -fstrength-reduce -msse2 -mfpmath=sse gx_sceleton.cpp -I. -shared -lm -o gx_sceleton.cpp:68:68: schwerwiegender Fehler: No such file or directory #include "" // dsp class generated by faust -> dsp2cc ^ Kompilierung beendet. Makefile:57: die Regel für Ziel „gx_sceleton“ scheiterte make: *** [gx_sceleton] Fehler 1


Looks good so far, I’ve downloaded your schematics and build them here without issues. I’ve run them in guitarix, also without issues.
However, first noise (is it like ssscchhhsscchheeet?) and then silence, mostly indicate a DC-overload in the transistor.
Maybe a dcblocker as pre filter in COD2 would help.

For reference I’ve uploaded the 2 faust files here:
COD2 with added dcblocker

and the final complete faust file (without dcblocker, maybe you need to add it):

This means that the generation of the cc file from the dsp file is failed beforehand in
Don’t you get a error during that?


I get no error during Maybe it’s the faust version? It’s 0.9.46.


Oh, yea, this is to old for our set. You need version 0.9.73


Okay. Next thing to package. If somebody else misses SLICOT on Fedora here it is:


I thought I give it a try. I now use faust 0.9.95. That doesn’t work too.

Plugin type DistortionPlugin generate and copy to gx_colorsoundoverdriver.lv2 filter.lib:2100: ERROR: undefined symbol BoxIdent[SR] Traceback (most recent call last): File "../../..//dsp2cc", line 2060, in <module> main() File "../../..//dsp2cc", line 2040, in main options) File "../../..//dsp2cc", line 496, in __init__ self.headvers = self.skip_until(r"\s*//\s*(Code generated with Faust.*)").group(1) AttributeError: 'NoneType' object has no attribute 'group'

Is it a parsing error?


Well, faust 0.9.95 is to new for our dsp2cc script. Faust introduced a new library inclusion in v 0.9.95 which we haven’t port our internal scripts to. Hence the undefined symbol ERROR.
You really need to use v 0.9.73 with our build system, to get best results. Hopefully I’ve found some time this year to port our system to v 0.9.95, but I can’t promise.