Easier publish flow to "beta in plugin store"?

Developers
#1

Hi guys,

There’s been an increase of offered plugins here, which is great!

I am concerned about these plugin reaching their potential audience though.
What if we could get more people to actually, test, give feedback and promote these community made plugins?

It is a Strength of the platform that we can but it is also a Threat when it is kept as such a black box to many people.

What if we can create a smoother process of these plugins to reach the beta plugins list in the plugin store? Easier access = more potential people to test it and yet again shorter path to 1.0 publish in the live, public plugin store?

I count myself in the part of the audience that is able to manually copy plugins (which a command line refresher to brush up on those skills though) but to be honest, I don’t feel much to grab source code from a git hun an try to get it working on my MOD Dwarf somehow…

It would be SO much easier if I could test plugins right out of the “beta” plugin store; or even some kind of “alpha” store, so I can download from my mod GUI, get it on my board and try it right away.
It could define the role and necessary skillset as “tester” a little better as well and we could create a clear workflow to widen that publishing funnel sooner

What is needed in order to achieve this?

  • more testing of the plugins?
  • Standardization and documentation of tihs process?
  • a “alpha” plugin store in the GUI for this purpose?
  • more support to get people to wrap their plugins with a basic gui to make the UX nicer?
  • more support for people to package to a format that is beta or alpha store ready?
  • A designated “go to market” person acting as catalyst to help people get their plugins through the publishing funnel?
    …?
8 Likes
#2

I kind of feel responsible for the current influx of plugins. :sweat_smile:

I have prepared everything to go into beta though. But the bottleneck here is; the build script pull requests need to be approved by someone from MOD. I think this is a good quality checkpoint, but it takes a while before a new admission is checked. Which is why I decided to drop plugins on the forum before they’re even in the beta store. It would definitely help if reviewing pull requests were more of a priority for the MOD team. But that might be due to limited resources…

For me, it was a learning curve to set up the build scripts to get plugins into the store. But I think it’s fine and inevitable for that process to be technical. The documentation is clear enough. And I think there’s a knowledgable community of people here to help a developer out when they’re stuck.

6 Likes
#3

Yeah, You have a big stake in my impulse; once again thank you foor all of that!

What you mention is exactly what I care about;
a portion of the success of this tech and community ARE exactly these community plugins.

In all transparency; I’m trying to ignite the obviousness of the issue at hand:
How to get YOUR plugins to people like ME in the most fluent way.

As you mentioned; the MOD moderation is a crucial point in the critical path of the process.

2 Likes
#4

I agree, if we can find a way to make it easy for interested volunteers to test plugins, this could act as a pre-filter for the MOD team sign off for beta. Perhaps if there were some semi-formal test procedure/guidelines and a way for volunteers to register go/no-go results the community could be (seen as) a useful resource rather than a drain on MOD resources.

#5

Given the current state of MOD I think the best bet is to create something that doesn’t need the teams input.

My suggestion: Build a tool/website/storefront with all the plugins, rating system etc. that installs the plugins easy enough via ssh but without all the technical stuff.

patchstorage.com essentially was on board to integrate stuff but @gianfranco isn’t really a fan of that.

1 Like
#6

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.

#7

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.

#8

There is no way to reliably know that the binaries are what they say they are. The risk remains.

#9

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
#10

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
#11

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 :sweat_smile:

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:

  1. Push code somewhere accessible online
  2. Create a “mk” file describing how the code is built (just like any other in mod-plugin-builder)
  3. Go to builder.mod.audio, pick “custom build”, upload mk file and press build
  4. After build completes, press the “generate persistent build” button (name TBD)
  5. Get a link after the persistent build finishes (it will build for the other MOD units)
  6. Share this link with any user interested on trying out the plugin
9 Likes
Reboot Phase 2 updates
#12

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?

#13

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
#14

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” ?

#15

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:

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.

#16

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. :slightly_smiling_face:

#17

We hope for the opposite :slight_smile:

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
#18

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.

#19

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.

#20

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