BMusic has some video tutorials on how to make LV2 plugins from scratch: BMusic - YouTube
But I’d also recommend looking into DPF and the plugins that use it to get started.
2 Likes
Not ideal (I know… ), but my strategy would be to ask ChatGPT for a working example and then modify it to suit your needs.
I spent some months for creating some compilable seeing other lv2 projects. I recommend you to see my GitHub project. I tried to make the most organized that my patience enabled.
The source code can be compiled using Docker. I used this way because my machine has some problem with the LV2 dev libraries. But you can use the makefile for compiling without docker if you want.
6 Likes
I feel your pain here. I am not that much of a c++ developer, except for doing arduino powered stuff, like a midi flute, and the learning curve for plugins was quite steep, somewhat like this picture.
I’ve found the youtube playlist below to be somewhat of use for me, while torturing because of the annoying background music.
By the moment when I created a plugin capable of playing midi files with midifile library I was exhausted as hell and switched to other hobbies, to cut losses for my self esteem.
For the second attempt I’ve taken DPF library quite recently, and it’s feels more simple to start, so it might be feasible to try it, depending on you task - as DPF is more limited than the plain lv2, as soon as it tries to be able to generate plugins in different formats, and functionality that it can provide is a roughly an intersection between capabilities of all these formats (for example even if you build a lv2 plugin with DPF - it would not provide multiple MIDI outputs, even if lv2 is capable of that - because non-lv2 format plugins cannot not do the same). At least that’s how I understood it:
It feels quite solid, for example sending and receiving MIDI messages is much more straightforward than dealing with lv2 low level atom messages forging. Also you had not to deal with a burden of writing TTL turtle files initially to get a working plugin.
However I have no clue how to debug the damn thing - lv2 has a way to send debug printouts to the host, and DPF seems not to provide access to this function.
(Probably debugging with printouts is a noob approach, but I am unlikely to be able to use gdb against a plugin, running in a realtime within context of the host app, on top of a stripped down embedded box)
There was a long FalkTX video introducing DPF -
Quite valuable bonus for DPF is that it’s developer is a part of the MOD team, and has a presence on this forum.
In both cases processing audio seems to be similar - you will have to implement a method within a class ( or in case of pure C lv2 it also could be also just a function), that receives a buffer of usually 128 or 256 audio amplitude data frames, you do something with them and return then back by writing into output buffer modified as you will. If you are only going for audio processing - it seems to me that it would be possible to port your processing code between DPF and plain LV2 quite in a straightforward way, as conception is the same.
Differences would be more noticeable for parameter ports and midi stuff.
To compare you can have a look into simple amp plugins implemented both with DPF and plain LV2:
10 Likes
Thanks for the info in here - I am also trying to get started on LV2 and it just seems really hard to start - tends to be ‘no use this’ ‘download 10tb of docker and docker images and do this’ everywhere. I have seen the ‘writing LV2 plugins’ site, and that stuff is really clear, just write some C++ code, stick it in a big library edit these files, but that is generic stuff, and maybe I am just missing some basics - what make file do I need, what do I compile it for for the mod devices, can I get away without having to use docker or any cross platform libraries?
Unfortunately there seems there is a lot of that info on videos, but sadly not written down, and going and transcribing a lot of videos so that I can get info from them will be very slow - videos are about the hardest way of imparting knowledge I know.
Is there a situation I can be in when on my mac, I can just write the code, in normal straight C++ for an LV2 device, hit make and get a plugin at the end of it I can stick on the mod?
3 Likes
Check out
I’ve got UTM running on my Macbook M1 and able to build plugins in a VM.
I’ve also managed to get the mod-ui & mod-host running on the VM (tho I’ve failed to get audio or midi to work)
I use VSCode in remote server mode to edit the code from my Macbook, iTerm2 to fire up the build and then Mmving the plugins over to the Dwarf is a matter of copying from the VM to my Macbook and then copying to the Dwarf.
2 Likes
I’d recommend to let most of the LV2 stuff handled by a plugin framework. DPF (that @falkTX develops) takes care of a lot of boilerplate, so then you can focus on writing your dsp code and connecting parameters to controls.
The Makefile structure for DPF is relatively simple. You mainly have to set some includes and build targets.
MOD Dwarf and DuoX have build targets in DPF already as well.
However building a plugin for the MOD system requires cross-compiling to a Linux ARM64 target. If you are on Windows (or MacOS) you may not be able to do that directly on the host machine. Together with the extensive Mod-Plugin-Builder requirements it therefore makes sense that people use Virtual Machine or Docker solutions to take care of the toolchain.
On Windows it might be possible to use https://www.mingw-w64.org/ ? but this would be extremely customized build environment that you’d need to fully maintain yourself.
1 Like
now I have spent a bit more time with docker and realise what it is doing, which was hampered by non functioning docker images and the fact that docker desktop on the mac no longer wants to play, (although docker is working fine), I see what is there and it is working.
Thanks for the info - now I have a functioning system, I will try and build a system from scratch. I see what you mean about the DPF, but that is exactly what I am trying to avoid at the moment. Maybe once I understand how things actual work, the idea of hiding the background will be great so I can get on with actual code, but for now I really want to know what the background is doing, that sort of thing has burned me so much in the past.
5 Likes
Also having got the docker image working on the mac for mod-plugin-builder, it kind of fails on the first step.
./bootstrap.sh moddwarf
cp: cannot create regular file ‘patches/gcc/4.9.3/0001-fixed-build-with-gcc-6.patch’: No such file or directory
builder@29dab4d3f8e6:~/mod-plugin-builder$ ./build moddwarf test
Package name ‘moddwarf’ does not exist
so maybe making my own image would be a better option anyway?
I think I will just write some LV2 plugins to get used to the structure, right now that seems the easy part, so when I have plugins working and tested how I want, I will come back to the dwarf and see if I can get any of the tools for it running - they certainly seem to put effort into making it hard work!
1 Like
Not sure what you mean by that. Cross-compiling for highly specific embedded environment (and targeting several systems at the same time) is never easy.
But if creating LV2 plugins from scratch seems that easy for you, show us then 
I have spent many years of my life cross compiling for highly specific embedded environments, mostly radar, but now sonar, although rarely targeting several systems at a time as they were custom hardware. These however started as expensive cross compiling systems, and even the later cheaper ones had very good documentation, which makes the difference and maybe I have just been spoiled by that. I know documentation is hard, and generally when it comes to open source projects, when you are doing things for fun / free then that is the bit that is likely to fall by the wayside.
Sorry if it came across as angry, or if you took it somehow as a slight, it wasn’t intended that way, but it is just frustration borne out of not being able to do something . Unfortunately, as a full time software engineer I really don’t get much time to ‘play’ with stuff that isn’t my day job, so its a shame when the bit of time I have got gets subsumed into trying to make some sort of functional environment. Unfortunately having got docker, got it to work, figured out what it was doing, follow the link from the mod wiki, installed it how it said and then failed running the first command it said, googled for a clue but not found it, I am at a loss what to do after that. Given time and calming down I will look into the error and try and find what is missing / not working, although this is what I said earlier about using other frameworks etc, the more abstracted you get from the process, the harder it is to fix things that go wrong.
The programming, as I said, that seems pretty simple - and I would like to show you if I could get the environment sorted, Its just a little frustrating - I absolutely love the dwarf, I have been gigging it extensively and told everyone who even comes near what a great device it is until they are sick of hearing about it, It has halved the size of my pedalboard, but there are just a few things missing that would make it so much better for me that I don’t have and it is just a shame I can’t currently make them.
6 Likes
True, I agree the documentation could be better across the board. With opensource more than other projects I suppose: the code is often the documentation.
the lack for details on the docker usage is mostly because the people that handle plugin building, me included, rarely use anything that is not Linux (and typically only for checking if things still work there), so for us the docker part is not needed.
at least the docker file in the mod-plugin-builder repo https://github.com/moddevices/mod-plugin-builder/blob/master/docker/Dockerfile I still try to keep up to date.
recently made it be able to build on both x64/intel and arm64 machines, as I needed to do some builds from a mac m1 machine.
the script in https://github.com/moddevices/mod-plugin-builder/blob/master/docker-mount.sh allows to directly mount the plugins folder inside the docker image instance, for quickly retrieving any built plugins/files.
but all this is targeting already existing plugins, not for doing development directly.
my personal recommendation on anything not linux (and even on linux systems where you dont want to setup jackd) is to just do regular development with hosts like Ardour, Carla and Reaper (all of which are cross-platform and support LV2) and then near the final phase of testing and optimization start doing MOD builds using docker.
if you go with DPF or JUCE you get a standalone build too which you can directly run and debug without the need of an external host.
8 Likes
Thanks for the info. Its the docker image I tried to use, but couldn’t get to work and today I tried a vmware image of arm64 ubuntu but again couldn’t get the bootstrap to work.
However, as you say, it seems I can build LV2 plugins just fine on the mac itself, and those are recognised in audacity, I wasn’t aware of the other hosts apart from reaper, so that gives me options for actually developing what I want, and maybe I can dig out another machine to put linux on to build it for the dwarf when its done.
2 Likes
But why? mod-plugin-builder is meant for x86_64 machines. It does cross compilation to ARM targets.
Many folks have machines based on ARM64 (In my case a Macbook with the Apple silicon M1 cpu … oh my does it fly!)
And whilst one can run a VM in ARM → AMD emulation, it is … S L O W!
1 Like
it supports arm64 machines since a fair bit. it used to be a separate docker file, now it is integrated into 1.
running fine here
$ uname -a
Linux falktx-macm1 6.3.0-asahi-00668-g1a9452fde941 #17 SMP Wed Jun 7 23:18:53 CEST 2023 aarch64 GNU/Linux
$ ./build moddwarf-new x42-midigen
/usr/bin/make -j1 O=/home/falktx/mod-workdir/moddwarf-new HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" silentoldconfig
make[1]: Entering directory '/home/falktx/mod-workdir/moddwarf-new/build/buildroot-2016.02'
GEN /home/falktx/mod-workdir/moddwarf-new/Makefile
BR2_DEFCONFIG='' KCONFIG_AUTOCONFIG=/home/falktx/mod-workdir/moddwarf-new/build/buildroot-config/auto.conf KCONFIG_AUTOHEADER=/home/falktx/mod-workdir/moddwarf-new/build/buildroot-config/autoconf.h KCONFIG_TRISTATE=/home/falktx/mod-workdir/moddwarf-new/build/buildroot-config/tristate.config BR2_CONFIG=/home/falktx/mod-workdir/moddwarf-new/.config BR2_EXTERNAL=/home/falktx/Source/MOD/mod-plugin-builder/plugins-dep HOST_GCC_VERSION="12" SKIP_LEGACY= /home/falktx/mod-workdir/moddwarf-new/build/buildroot-config/conf --silentoldconfig Config.in
make[1]: Leaving directory '/home/falktx/mod-workdir/moddwarf-new/build/buildroot-2016.02'
Finished copying midigen.lv2
Quite happy to be running linux directly on the M1, pretty much everything already works just some minor GPU/graphics issues from time to time
3 Likes
Hi Woodinblack
I know exactly how you feel. When I first attempted to do any lv2 plugins - what frustrated me was there were few simple examples to work from. (i.e examples with few tricksy unexplicit complexities. E.g makefiles which are obviously the result of years of a particular developer’s self-optimisations but which are bewilderingly opaque to a novice - the code for many of the midi utilities the mod system are a particularly good example of this). What is needed are more examples, which have just one c file and one ttl file.
This is a good place to start:
After following these up to (I think unit 7 - after which it becomes too complex) - I then attempted the plugins in the lv2 “book”
https://lv2plug.in/book/#_introduction
I found removing the makefiles there and attempting to compile with just the gcc command line used in the youtube course above (getting rid of the ttl.in files) did really help me understand the whole logic of how the ttl files connected with the c files.
I personally just coded on an old laptop with pure ubuntu on it rather than do the docker stuff. Compiling c files seems to be ridiculously fast - so you really dont need any power at all to do it.
6 Likes
How interesting!
My system (Macbook M1 with Ventura 13.4.1 on it) reports
❯ uname -a
Darwin M1s-MacBook-Pro 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:19 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T8103 arm64
1 Like