Looking through the code for the ports that have already been done, it looks like there’s two basic structures for porting a VCV module:
(1) fork the VCV module code and add a directory called /metamodule with all the additional stuff the MetaModule build needs;
(2) create a new repository and add the original code as a submodule.
I can see that @danngreen and @etcetc have each used both approaches in various cases. I’m curious what the circumstances are that call for one approach rather than the other.
I prefer (2) , I like to keep my vcv module ‘vanilla’
then have a separate module MetaModule project which just has it as a submodule.
Im writing my own modules, so I just do this as a preference.
for porting , my main criteria would be, Id not want to fork the original vcv repo, unless I was having to change code , so the submodule works better.
if I forked… then Id probably still want to have the fork containing minimal changes (so still submodule), as Id like to make changes in such a way they could be pushed back upstream.
… so again, probably not want metamodule stuff in their as original author might be less likely to merge it back in.
the other consideration is if you start doing ports of different modules from different repos.
then in make sense to have one ‘meta module’ repo, bringing in multiple submodules (from different sources) … which is how 4ms have done their 3rd party/porting repo.
Yeah, basically this ^^. Ideally there are no changes to the VCV plugin code at all, so at first it made more sense to create a new “wrapper” repo with the metamodule build stuff, and adding the original code as a submodule . It’s easier to pull in upstream changes or push improvements that benefit all versions. So initially I took this approach.
But over time, almost all the ports have had at least one change to the original source, so the submodules ended up becoming forks anyways. Then there are two repos to manage and keep in sync, so I’ve started converting them all to forks with the metamodule stuff in its own dir (#1), as it means there is only one repo to manage.
Got it! Seems like the dream of keeping the VCV plugin code unchanged is generally unrealistic, so when we’re porting a VCV module we might as well start out with a fork rather than a submodule.
(1) Is there a way to automatically append the version number to the .mmplugin filename? I’ve been manually adding it, and that seems to work fine, but you’d think there would be a way to have CMake do it. I tried editing the plugin name in CMake and that didn’t work because it broke the connection to the VCV plugin.
(2) When I convert the svg to a png (using Acorn on Mac, or svgtopng.com), the png looks fine, but it displays misshapen on the MetaModule — it’s about 30% wider than it should be for some reason. The original svg is here, the png is here.
Id not say ‘unrealistic’ , it depends on plugin - as the MM vcv wrapper is really good.
so sometimes, it depends if you as a dev, want to ‘enhance’ the MM experience.
there are a few things that need custom mm code.
that said, I think its a moot point really…
from what Ive seen, vcv plugins (so repos) are rarely under ‘active development’ / being updated frequently - so unless you are managing a lot of them, from different devs, you’re probably not going to need to ‘pull the fork’ that often.
so ‘fork away’
however.,
it’s also trivial to initially use their repo, then change to using a fork.
even once you’ve started making changes…
so you can do it when you need… as ‘tidying up’
I think its “manual”
my GitHub action, I see cd metamodule-plugins && for f in *.mmplugin; do mv $f ${f%.mmplugin}-${{ env.CI_REF_NAME }}.mmplugin; done;
however, “my GitHub action” is the key here…
the intended process is:
you develop without a release number.
then you use GitHub action to actually make the release
the GitHub action uses a git tag to fetch the right code version, build it, and then use that for the release.
this ties into how dann/4ms can grab your build , and share it.
(at least thats my understanding, from what I see of code etc)
one related bit to this, that I need to double check…
vcv
plugin.json does have a version number, not sure if/how that gets updated - I’ve a suspicion thier GitHub action updates it via tag but Id need to check.
I thought also it somehow tags the vcv version compatibility, but that may be code check? as you build again a specific rackSDK
mm
I dont think pluginmm.json has a version, but Id need to double check, its not mandatory.
probably you should be using the metamodule script
metamodule-plugin-sdk/scripts/SvgToPng.py
its in the metamodule sdk docs - id def give these a read, even if just to get an overview of the process and what’s possible.there is so much useful info in there - its truly excellent.
(the VCV SDK docs are also excellent !)
