Well no not really. Patchstorage hosts non-reproducible LV2 binaries for raspberry pi.
It would be quite risky to upload such plugins to your MOD unit and more than likely things won’t work or might even break.
of course you have to have the DWARF added as a platform, add the plugins compiled for the Dwarf, done. Then its just create a tool that talks to the api.
There is no way to reliably know that the binaries are what they say they are. The risk remains.
I like the idea of having a simple web tool doing the ssh operations. But including a rating system and other stuff related to beta testing seems a bit much to me (Although nice!). Because I think we shouldn’t want a second, workaround BETA store.
Thinking a bit further, wouldn’t it also be a requirement to be able to get the plugin out? Why not use WinSCP or a similar tool instead of building a custom solution?
1 Like
I’m not sure how the beta plugin review process works exactly.
But I expect the review process to be mostly technical. I expect that once the plugin passes technical requirements (code quality of the build scripts) the plugin goes to BETA. So I don’t think this really helps the MOD team to sign off on beta quicker. But I might be wrong…
Hopefully someone from MOD can chip in.
Not to say that a test procedure wouldn’t be beneficial anyway. If there’s enthusiasm for that, that would be great!
1 Like
I am writing here instead of creating a new topic, I want to share the current plans to make it easier for developers to give plugins for others to try.
And please note we still plan to add more plugins to the store, while we want to make it easier for developers to get beta testers and users in general to try their plugins, it would be a shame if this results in no more plugins making it to the store. It is best to let community decide on what plugins they want to see in the store, so we will monitor these forums for that. Giving a chance for users to easily try plugins helps with gathering feedback, so yeah let’s make that a process that does not need anyone from the MOD team to be involved.
As some of you may know, we host a service on http://builder.mod.audio/ that allows MOD users to build plugins based on existing technologies. At the moment it supports faust, puredata/hvcc and max-gen~ (with puredata still being quite limited, work in progress).
The first step here is to allow developers to upload an “mk” file in the same fashion as used for mod-plugin-builder. This way the online builder is able to compile generic code and not just projects from faust, max-gen, etc.
This needs to be done carefully because this “mk” file allows for any arbitrary instructions to be placed in there. We will trust the community to not try to break things on purpose 
After this is done, the obvious 2nd step is to allow persistent builds, and have them build for Duo, Duo X and Dwarf at the same time. After the build completes for all 3, the developer is presented with a special page link. This will be a dedicated page for that specific build that has the “deploy” button accessible.
This link can then be shared with other people and they will be able to simply press a button to install that particular plugin on their MOD unit.
So in short, from the developer’s perspective:
- Push code somewhere accessible online
- Create a “mk” file describing how the code is built (just like any other in mod-plugin-builder)
- Go to builder.mod.audio, pick “custom build”, upload mk file and press build
- After build completes, press the “generate persistent build” button (name TBD)
- Get a link after the persistent build finishes (it will build for the other MOD units)
- Share this link with any user interested on trying out the plugin
9 Likes
Hi FalkTX, nice to read from you again. A plugin built with Max’s gen files very often requires additional work in the .ttl file. When can these changes occur in this process?
no, that cant be added.
but it is preferred to create a git repo with all the resources for that anyhow, we do not want a mess of “you manually need to input this file, then copy this file over, and change this 1 thing here” kinda steps. builds should be reproducible and automatic, if a build needs manual tweaking then it is not a good build and also does not scale.
3 Likes
Ok, so does it mean that this workflow will not be usable for Max users since the plugin thus generated will not be a “good build” ?
for max we have the dedicated repo for packaging plugins as we were doing before.
that being GitHub - mod-audio/max-gen-plugins: Collection of MAX gen~ based audio plugins used in MOD Audio
if that is still too much work let’s figure out where the bottlenecks are.
in theory you would be able to do these steps:
- fork the max-gen-plugins repo and add your custom files there
- update the mk file from mod-plugin-builder/plugins/package/max-gen-zwabo/max-gen-zwabo.mk at master · mod-audio/mod-plugin-builder · GitHub to point to your repo and commit hash
- give this mk file to the soon-to-be-released online builder
The persistent plugin builds need to use a mk file, which means having a git repo or source tarball somewhere, so we always need to have a git repo in the end anyway.
Do I understand correctly that this would then be a sort of pre-beta stage (alpha if you will)? I’m a little worried that it will be hard to get a plugin upgraded to the beta stage. My guess here is that the beta store will have a bigger reach and therefore more testing and overall engagement. But I might be wrong there. What would be the procedure to offer something for the beta store? Would that remain the same, e.g. open a PR at the mod-plugin-builder repo immediately after creating the “persistent build link”?
Nonetheless I think it sounds like a good idea @falkTX. I understand it’s better to be less reliant on you and others from the MOD team. And this would be a user-friendly way to share plugins. These are just concerns I have about getting plugins that might be a good addition into beta. 
We hope for the opposite 
There are two bottlenecks in the beta plugin store.
1 - publishing either for the first time or as an update requires action from the MOD team, so any action requires time from the team
2 - the store does not receive binaries. It compiles the plugins for the multiple devices. In order to do so, the code must be structured accordingly, so that it can be built by the mod-plugin-builder.
None will change without significant changes of the architecture of the entire platform.
With the flow we are proposing, developers will not need to worry about setting up toolchains and can focus on making code that can be built by the online builder (that uses mod-plugin-builder).
Once the developer can build a plugin he is satisfied with and wants to have people testing, he can open a topic here in the forum, share the link provided by the online builder, and allow other users to easily try the plugin. They just need to click and the plugin will be installed in their units.
All the testing and improvement can happen inside this topic, with the many links of the builds being shared direclty here. We expect that in this phase a proper UI, presetting and a manual are also produced.
Technically, these plugins are considered “local” and pedalboards with these plugins cannot be shared to the online feed, so they are still quite contained in terms of audience.
Once the plugin is ready to be tested by a wider audience, we publish it in beta, making it available to all device owners via the Web UI, and able to be included in shared pedalboards.
In this flow we want to put in place, developers will be able to reach the the last step in a totally unattended manner.
The time consumed for this last step is very small and can be handled by the team.
There is a whole different angle that also needs to be also tacled, that is the gigantic mess of the beta plugin store. It currently contains hundreds of plugins, ranging from total crap to raw diamonds.
We have plans to “reset” it, sending all plugins to a website from where they can be installed, but outside of the Web UI.
We then can start populating it again with plugins that are actually being maintained and taken care of.
5 Likes
Sounds good. And good to hear you’re planning on doing maintenance on the beta store.
I have one suggestion. It might be helpful to have just one download link per plugin or a link to a latest version instead of a link per build. I think it gets confusing quickly when you have multiple builds in a forum topic. Or annoying when you have to search for the latest version.
And is this complete?
I don’t see a gui in there as a requirement for example. If the requirements are clear we can probably get more plugins beta store ready.
Can’t wait for this “reset” since it will really help to put focus on testing those plugins that are almost ready to move to the main collection.
There are definitely a hand full of rough diamonds that just need that little push and I think this proposal for the “day-to-day” testing of new plugins will make it much easier for users to start playing with new things without devs having to wait for the team to step in.
2 Likes
That is to be seen by the people coding the Online Builder. It is open source: GitHub - mod-audio/mod-cloud-builder
1 Like
Yes, definitely. By no means I want to impose anything. Just an idea. I know it’s easy to wish for things, time consuming and harder to implement them
Indeed
One of the changes we want to bring with all these measures is to allow this constructive cycle within community members and without a constant burden on the team.
2 Likes
c’mon @brummer
help us get the Cloud builder - GitHub - mod-audio/mod-cloud-builder - updated to support the mod-plugin-builder so we can see more plugins emerging here in the forum
5 Likes