As a test I have been attempting to get “plugins/package/eg-amp-lv2” built and deployed to the mod.
I have managed to shoehorn in a ui as well using mod-sdk to generate the files and using ssh and scp to update the files on the mod, pretty sure this isn’t the recommended way but:
Any changes I make to the files in “~/ModDuo/mod-plugin-builder/plugins/package/eg-amp-lv2/source” are just ignored when I do a “./build eg-amp-lv2”, it looks like it is using a cache somewhere of the original files I have mooched through the build system trying to see how it worked but it gave me a headache and I needed a beer!
Is there some documentation somewhere about how to use mod-plugin-builder?
I found I had to delete the build from the workdirectory or else it wouldn’t actually build. from mod-workdir IIRC its in /plugins/package/eg-amp-lv2. Delete that and try again. I agree that could use some mention in the docs, I’ve been trying to update it myself as I learn these things, but I haven’t quite figured out for sure if this is the best way yet, but its been working for me.
the buildroot system wasn’t designed to do this kind of local development.
but I can give some tips.
use ./build <pkgname>-dirclean to remove the old build of a package
the cached content is under ~/mod-workdir/plugins-dep/build/<pkgname>-<version>
remove the .stamp_built file inside the folder above to build the package again without having to remove the entire folder
Because of weirdness of buildroot, for quick&dirty local development I usually do:
start a build with ./build …
go to ~/mod-workdir/plugins-dep/build/… and initialize a git repo inside the package build folder
do random changes, remove stamp_built, build and deploy for testing on mod
when changes are confirmed to work, do a git diff out of current folder and apply it to the main repository.
I agree it’s not optimal.
But mod-host is not the only LV2 host out there, and it runs on the desktop too if you really need it.
I heavily recommend doing local development first (ie, build natively and test on your own pc), then only do the final adjustments and optimizations using mod-plugin-builder.
Thanks for the info, from my meandering through the build system even with my very limited understanding of these things it is obvious it does way more than building the plugins!
I’m knocking together a project using eclipse to build a simple LV2 plugin for local/mod use including mod-app, when I get it all working I will stick it on github and can maybe write some text about how it all hangs together. Might be useful for other people…
as an absolute beginner I have to ask a few basic questions. If the docker environment isn’t for the local development of plugins, what is it for then?
I just cloned the stepseq.lv2 from http://gareus.org/gitweb/?p=stepseq.lv2.git;a=summary as a starting point locally and tried to mount it in the docker image with: docker run -ti --name mpb -p 9000:9000 -v ~/bin/workspaces/stepseq.lv2:/tmp/myproject moddevices/mod-plugin-builder
But after executing docker start -i mpb the folder /tmp/myproject does not exist. What am I doing wrong?
the ‘docker run’ creates the image, if you had run it before the mpb image name already exists.
I think in this case it will be named mpb-2 or similar.
you should only run docker run ... once, with a common folder for all plugins. docker ps -a will tell you the current image instances you have, names at the end of the table.
I mentioned before that buildroot is not designed for local development, docker is a different thing.
docker is a container for linux “images”/snapshots.
the docker-engine toolbox uses a very minimal VM to allow to run the linux binaries on mac os and windows.
OK, I managed to mount the folder. If it is usefull for anyone: I just deleted the container with docker rm mpb and recreated it with the above mentioned docker start command. docker inspect mpb helped to see that the folder was really mounted.
But now the next problem lies ahead. The stepseq.lv2 project from gareus.org does not seem to have a proper mk file. Seems like it does not use buildroot at all.
I looked at the eg-amp-lv2 but I did not see any GUI-code. Any suggestions which way to go?
The stepseq.lv2 is a mod plugin. This is written in the README file of the project: “simple step sequencer for moddevices.com”. It even has a “modgui” folder. But its .mk file is called “git2lv2.mk”. And a few lines under it, it says: “Compiling stepseq requires the LV2 SDK, bash, gnu-make, and a c-compiler.”. So it seems it does not use the mod-plugin-builder at all.
What exactly are you trying to do?
In the very short term: I just want to compile a plugin an load it to the MOD, to see how the workflow is.
In the short term: I want to modify a Midi plugin and load it to the MOD.
In the long term: I want to build a realtime Midi sequencer.
The mk file extension is used for makefile extensions.
The stepseq.lv2 source code has a ‘git2lv2.mk’, but it’s used internally for building rules of its own.
As you noticed it does not have any buildroot stuff.
Buildroot files are also *.mk, but with a different target usage.
The stepseq.lv2 project was initially created for MOD, but later on the author added a regular desktop interface as well.
For you, the fast way to modify the stepseq.lv2 project is:
copy/clone the code of it locally, somewhere that docker can access
adjust the plugins/package/x42-stepseq/x42-stepseq.mk file to build from that folder (ie, local build)
remove the custom rules for building variants of x42-stepseq, just do the normal build (which is 8x8 grid)
build with “./build x42-stepseq” using mod-plugin-builder
The x42-stepseq project might not be the best one to start learning though.
Because it has a desktop interface, it includes cairo, opengl and other code that is never used on MOD.
It also has some automated rules to be able to build any grid size.
As always, for the initial test and development, I recommend to do it natively, running on your own audio card locally.
You can get mod-host and mod-ui running on your own pc to simulate a MOD, or alternatively use a regular desktop plugin host similar to mod-host/ui, like Carla or Ingen.
Having issues right at the start (like not being able to build things) can be a motivation killer.
So better to start slow to test native at first, I think.
