New Tape Emulation on the block

just found this with the new surge release:

made by:

quite decent, might be open for addition into the mod plugin collection…


It’s opensource (gplv3), so why not.

There are quite a lot of options to put into the UI though, but if a similar design could be used that would be great.


Glad you like the plugin!

I had actually spent some time a couple months ago looking at porting some of my plugins for MOD. Unfortuntely, it was not particularly straightforward, as the build system that I use (JUCE + CMake) seemed to have some issues when I tried running it in the MOD plugin builder environment (I don’t remember all the details off the top of my head). I ended up putting the MOD ports on the back-burner while I worked on some other things, but I am hoping to get back to it at some point. In the meantime, if other folks out there would be interested in helping with the porting process, that would be very helpful!


Join #lad and #moddevices on - lets bring chowd to the mod family!


To be clear, a few steps are needed:

  1. Building as LV2 (which is done now)
  2. Special patching for a JUCE linux-embed/nogui build (I need to adjust this from my old JUCE version to the new one)
  3. Patch chowdsp plugins to fully disable the UI stuff

I should import that cmake support in DISTRHO/JUCE repo now that it seems to work well…
Will make this much easier for other devs to build stuff.

Anyway, lets talk more on IRC then.


Great! Yeah, having the steps spelled out like this definitely makes it a little less scary :slight_smile:. I believe Konstantin has made some updates to his JUCE fork based on some conversations with the Surge Synth Team, so I may want to look at editing my Pull Request to DISTRHO to include some of his more recent changes.

Also, it seems like the irc link above is broken?


ah yes, works, though I can say it is a lot better using a desktop client instead of connecting through the browser.
IRC is old stuff, so there are plenty of clients by now :sweat_smile:
We hang out at #moddevices on the server. We are very few, so everyone is welcome.

1 Like

Just wanted to add my :arrow_up: vote to this. Would love to see @chowdsp 's plugins make it to MOD. I’m particularly psyched for his Klon clone.

I’m currently trying to fire up the plugin builder to see how far I can get building that. I’m a software engineer but I’m pretty removed from C and have no experience working with LV2 or JUCE so we’ll see if I can be any help here.


Thanks! Sorry I’ve been super busy with some work and family stuff, and haven’t followed up with building my plugins for MOD. Hopefully in the next few weeks my schedule will open up a bit, but until then definitely keep me posted with any progress or problems you might find!



Thanks for the reply.

I haven’t yet made much progress. I did get cmake upgraded in my build environment, but cmake is pretty foreign to me. I’m getting hung up as to where to define the DBUILD_CENTAUR_HEADLESS macro. Even after that, I imagine I’ll end up getting stuck where you did in this github issue: CMake Version Issue · Issue #111 · moddevices/mod-plugin-builder · GitHub

Anyway, I appreciate the response and no pressure to move this along – but I am looking forward to when we can get it working on MOD

There is progress on this.

JUCE really doesnt like being built without graphics, plus their cmake support is quite special…
Luckily X11 and related things are a build-time dependency.
With some manual setup it is possible to build stuff.
I did some quick testing and the plugin does work!

Now… having a bunch of new dependencies that are never used is not good.
But this being the first step, we can now focus on getting things running better, right?

There is some documentation on JUCE/Linux at master · juce-framework/JUCE · GitHub for things that can be disabled.
We need to disable all of them.

We can track the current code changes here:

and for a little proof I guess…

Going to try the AnalogTapeModel plugin next.

EDIT: tapemodel fails to build in xsimd::batch<double, 2>::batch()


Amazing @falkTX!! How does it sound on Mod? Now we can start to look at NeuralPi too potentially :grin: that would be one of the coolest plugins for guitarists!


I never used the desktop version, so cant compare. Sounds like a distortion to me :sweat_smile:
CPU usage was okay, you can kinda see it in the screenshot too, I have the plugin loaded and around 21% cpu load.
It is not the lightest of plugins, but it does work.


I’m assuming this was built with modduox or moddwarf in mod-plugin-builder? Doesn’t seem to build with modduo…

no, you cant build it on the duo.

I built for dwarf and it worked.
for duo and duox we need to update its whole toolchain because gcc4.9 is now too old and cant build C++14 codebases.
currently doing an experiment as we speak, building the entire duox OS image with the new toolchain (matching dwarf), will later see if the plugins can then work with it or not.

as nice bonus, this should make it possible to run pianoteq on the duox.


NeuralPI does not have LV2 builds yet, I opened this issue about this last month: LV2 builds? · Issue #2 · GuitarML/NeuralPi · GitHub - although I see that they are already pulling distrho-juce into the project from .gitmodules

I realize that branch isn’t fully supported or anything. I tried building it locally for the dwarf and I get the following error:

  [100%] Linking CXX executable juceaide_artefacts/Debug/juceaide

  error adding symbols: File in wrong format
                                                                                                                     collect2: error: ld returned 1 exit status
                                                                                                                     extras/Build/juceaide/CMakeFiles/juceaide.dir/build.make:177: recipe for
  target 'extras/Build/juceaide/juceaide_artefacts/Debug/juceaide' failed

I’m building it in docker - I updated the docker image to use the above branch. Did I miss anything obvious?

hmm perhaps a re-run of the bootstrap is needed?
I had this issue before I changed the mk file, fixed by not using buildroot built-in cmake commands but writing custom ones.

Some news on this.

After various tests and experiments, decided to go with brand new toolchain for duo/duox but only with the essentials and building a few things statically.
Idea is that we keep everything as-is, but add a special build option for duo/duox to be able to use gcc-7.5 (same as dwarf).

mod-plugin-builder has been updated with modduo-static and modduox-static targets, and chow-centaur tested to build and run on both the duo and duox.

Only issue is xrun when changing mono mode, and perhaps parameters taking a little bit to apply (seems issues with the engine)
If left untouched, there are no xruns and dsp load is mostly consistent
Takes 20-25% cpu on the duo, which is not great, but not horrible either

next steps…

  • its self bypass needs to be integrated properly.
  • mode and mono made into boolean (easy change, just a ttl property)
  • a modgui, but we can do that on the MOD side

And some more, the AnalogTapeModel plugin now building and running too …on the duox.
Unusable on the duo.

The 1st non-default preset cant run properly, the others can
DSP load varies greatly, some presets 20% some 96%
(Why does it take so much cpu to make a “LoFi” sound? :joy:)

I could get it to build with the optimized xsimd, some double-math operations seem to not be implemented for ARM. So the high CPU usage seems normal for now.