See subject. All I’ve found so far is instructions on creating a single plugin (and uploading to a MOD device) or disparate github repos for a single plugin or a family of plugins. Ideally I’d like to:
$ git clone https://github.com/moddevices/one_repo_with_all_plugins.git
$ cd one_repo_with_all_plugins
$ ./configure
$ ./make
Congratulations, all the stock MOD DUO plugins can now be found within this directory!
Surely this exists. Either I’m blind and haven’t found it yet or it’s not public. A little help?
This is quite developer oriented though, not for end-users.
mod-plugin-builder can build for both MOD Duo and MOD Duo X units. (it does not build for “native”)
The plugins used in MOD are made in LV2 format, which not all DAWs support (specially commercial ones).
If you are looking for VSTs, you won’t find them in the MOD ecosystem.
Ok I actually attempted to compile mod-plugin-builder some months ago but got stuck with a compilation error I never resolved. But, just to be clear, you are confirming this repo does contain all the plugins you’d find on the MOD DUOs?
(it does not build for “native”)
Could you clarify this? Do you have to have a MOD Duo or Duo X to even compile? Or are you saying it only compiles for the arduino arch (or whatever it is). In either case, is it possible to compile these LV2 plugins to run on amd64 or arm or whatever? (I assume the GUIs are all incompatible… luckily ardour has a default plugin gui you can use instead.)
The open-source ones, yes. @BramGiesen is working to get the last remaining ones there.
mod-plugin-builder is a tool to build plugins (from source).
If the source is not available, it is quite pointless to have them in there.
You don’t need a Duo/X to build anything, the mod-plugin-builder will cross-compile the plugins.
For Duo it is armv7 binaries, and aarch64 for Duo X. These binaries do not run on regular PCs.
Yes, why not. But it is not within the scope of mod-plugin-builder (at least not right now).
You can use it as a guide to see where the plugins are located, which patches we apply and how we build them. But you won’t be producing binaries that you can run in your DAW out of mod-plugin-builder.
I just meant that “mod-plugin-builder” could mean “the tool for building MOD plugins which aren’t necessarily contained in this repo”. I mean it’s not like the linux kernel repo is called “kernel builder”. The build scripts are implied.
Wait one more thing. Let’s say you’re running a DAW on arm7? Why wouldn’t you be able to use the resulting LV2 plugins in that DAW? What’s the blocker?
Also, (from the github readme)
To build a plugin, run: ./build <platform> <plugin-package>
What’s “platform”? “duo” or “arm7” or what? The instructions don’t say, as far as I can tell.
And is there a way to compile all the plugins at once without running this command 150 times for each one?
No real blocker, but one has to watch out for the optimizations.
The Duo binaries are specially tailored for its CPU. It might trigger a segfault if you run it in a completely different CPU.
The Duo X binaries are a lot more generic, since 64bit ARM implies the use of neon and other things.
(you cannot change the FPU type in 64bit ARM compilers for example)
They do now
hmm some small bash scripting can do it:
for p in $(ls plugins/package); do ./build modduox $p; done
Thing is, we also place plugins that are not fully ready in mod-plugin-builder, so building them all is not advised.
As I mentioned in the beginning, this is a developer oriented tool.
We intend it to be for developers that want to make their own plugins.
Using it to build things for the unit skips the stable/beta tagging, so it will be impossible to tell which ones have been flagged by us as “good and ready to use”.
Having some success, some trouble. Am able to compile plugin families like CAPS and Guitarix but each time, the build fails along the way. Sometimes the resulting plugins end up recognized by Ardour, sometimes not. Here’s an example.
None of these plugins from this particular family become available to Ardour after this build, even the ones that appear to build successfully (like harmonizer). Not sure what the difference is because I see most of the CAPS and gx plugins there. Any thoughts?
Everything is building properly so far and almost everything is usable, as-is in my DAW. mod-pitchshifter gives me issues when scanned in, though. The DAW gives an error “[WARNING]: Unsupported required LV2 feature: ‘http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength’ in ‘Super Capo’.”
One of the first lines in the plugin ttl is “lv2:requiredFeature bsize:fixedBlockLength, bsize:powerOf2BlockLength;”
So the error I’m seeing means the DAW (ardour) can’t support the feature the LV2 plugin needs?
That is correct. Ardour does not support plugins which require fixed-block-size buffers, as looping and a few other things make the audio cycle “split” in half (half at end of loop, the rest at the beginning, in order to align samples)
The power-of-2-size is a requirement on top of the previous one, and as the name says it requires the buffer size to always be a power of 2.
Since MOD only runs at 128 or 256 samples, the plugin works fine there.
The reason for the requirements is due to how an FFT works. If you want to NOT have it delay audio for 1 cycle (in order to fill in buffers to process), you put the fixed-block-size as a requirement in your plugin
The plugins that do not have such requirement (and use FFT) very often do so at the expense of 1 audio cycle latency.
you can remove the lines from the ttl, and then hope (or pray, whatever you prefer) that ardour will keep the buffer cycle constant.
If you use looping or automation, well, expect bad things very quickly
jack buffer size can be changed at anytime, to any arbitrary number (within a few limits).
so just because jack starts at 128, does not mean that during the playback of the session it wont suddenly change to 42 or even 1337. these plugins were not made to work under such conditions.
What I’d really like to see is a ‘MOD Shell’ of sorts for the desktop/DAW, similar to NI Guitar Rig. This to me would make a complete ecosystem. The benefits are pretty obvious; we’d have studio & stage within one system.
My biggest trouble with MOD is that I like the results I get for live performance, but for studio use the device becomes a problem.
a) The things I want to do, demand too much power from the unit and so isn’t possible
b) I use studio DIs & converters and so again, the device isn’t possible/preferable
c) The things I want to do require many instances of MOD
I see MOD as an effect suite and it’s one I’d very much like to have on my desktop!
