Hi @dwek, have you guys considered letting developers setup their own plugin repositories? Then the users could decide whose repositories they want to enable or disable based on their needs and craving for (in)stability. Admittedly, this idea is slightly off-topic but pedalboard sharing with some extended set of plugins would apply to different repositories, too.
I would love if I could share pedalboard’s at all. But on my MOD I’ve a couple of community plugins, so the share button ain’t exist any-more.
Also, from the developers view, it would be great if it was possible to upload a pedalboard which show, what the new plug do. I guess that would be more helpful then 1000 words in a description. (and more easy to done for me )
+100
I suspect devs (myself included) may get a bit lazy in maintaining this though. Then they’d all be mixed bags. I think its better for MOD to groom the categories and therefore help keep the user experience consistent.
Thank you all for contributing to this discussion.
We’re working on our roadmap and all I can say is that pedalboard (and all things around it) is huge!
I’ll definitely bring this suggestion up to discussion. As @ssj71 already mentioned it’s a bit problematic supporting pedalboards with community plugins since buggy ones are bound to happen. It’s a difficult trade-off to say the least.
On one hand, if we put too many barriers / warnings / pop-ups, we simply kill the user experience and end up penalizing those particular pedalboards and associated community plugins. If we go easy on the warnings then users might get a bad experience without fully understanding the benefits.
Imagine how frustrating it would be having your brand new Duo and then you happen to try the one unlucky pedalboard with an unstable plugin. No matter what we do, it becomes our fault.
Maybe we can call them “community pedalboards” with some big bad warnings. But ultimately I think the typical user experience must be done in such a way to avoid those by default.
A possible solution could be:
Allow sharing of Pedalboards with unstable/community plugins.
If, a user have enabled the community store on his/her board, he/she could download and try the pedalboard. In that case you could assume that he/she know the risk, as he/she has enabled the unstable store active by him/herself.
Otherwise, if the community store isn’t enabled, refuse the download of the pedalboard with a popup info, that this pedalboard contain community plugins which are not supported on his/her board.
Advance of it is, that users could hear a example of a new plug and could vote for it if they like the sound, without the need to enable “unstable” plugs on his/her board.
I think this is a pretty good solution. I think perhaps the best way is to have 2 pedalboard categories that reflect the 2 plugin groups: community pedalboards and official pedalboards. The default when you go to the pedalboards page would be to show only official pedalboards, then if you select community pedalboards you can browse them and hear them, but can’t download them until you have enabled community plugins. This is a one time opt-in with some reading required so they know what they’re enabling. I think it would actually be best if pedalboards could become official through testing without all the plugins needing to become official though. That can be added later. With just sharing pedalboards with community plugins I think it can really aid developers to get their plugins tested and promoted.
Its great to see some discussion on this. Thanks all and keep the ideas coming.
I like where this is heading. A solution around those specs are more reasonable and probably the right compromise.
I think the community pedalboard sounds like a great idea.
Maybe there should be some kind of reporting system for plugins and pedalboards that cause crashes.
That sounds like a good idea to me. A simple like/dislike button might not convey enough information. But what happens if we report a broken pedalboard? Is there a process to delete them?
That makes me think of Debian’s stable/testing/unstable model.
There might be a way to add a bit more granularity, and depending on advanced user’s feedback/vote on plugins belonging to a particular category, the plugins could be promoted from one category to the next.
Let’s say we have 6 categories :
-
Rock solid
-
Usually fine, with exceptional glinch
-
Occasional glinch that is easily fixed
-
Frequent problems that can result in annoying consequences
-
Difficult to use, with potential bad consequences. You must have a very good reason to run this
-
Totally experimental. For development use. Expect to have to hard reset your mod.
Users could then set their mod to allow for a particular level of (in)stability.
I think getting granular will take away from the user experience.
I’m not a developer so I may be totally off base on this…
But I think any plugin that makes it into the “community/unstable” list is already at some level of stability. So the chance it will crash a system seems low to me.
If there isn’t some initial level of screening then there should be one.
I think a more simple approach is good where if a specific plugin is causing a crash or has some bug, it’s flagged. When flagged any pedalboard using that plugin can not be shared until the issue is resolved.
My two cents…
I feel like this is something that would be best improved via people rather than process. The MOD team, despite their best intentions and enthusiasm, won’t be able to manage this process effectively with their current team size and roadmap anytime soon.
I propose that MOD selects a few of the longtime contributors and community members to form a special admin group that has the ability to manage the review and promotion process. There’s a at least a few active and knowledgeable community members who are regularly performing and/or recording with unstable
plugins. That seems like a pretty good endorsement to me
I do understand the MOD team’s position that they don’t want new users to have a bad experience; and that the stability of the system is critical in user’s perception. That said, I encourage the MOD team not to fall into the common startup fallacy of making decisions for a mythical user base that doesn’t exist yet. For what it’s worth, my $1000 smartphone, made by a decades-old tech company with a market cap high in the billions, is not glitch-free.
I guess you misunderstood the topic, it isn’t about getting community plugs in the official store, it’s about Pedalboard sharing.
If, you could share a Pedalboard with plugins from the unstable store, developers could present there plugins in action.
That will allow all users to vote for a plug, without the need to enable unstable plugs on there unit.
Users could present Plugins from the unstable store, which they love, but, for example they miss a UI. This may catch a developer to work out a UI for this special Plug.
Truly that needs some kind of mechanism to prevent the download of a Pedalboard, when unstable plugs been detected in it, but the user ain’t have enabled the unstable section.
Sorry I wasn’t very clear. I’m suggesting that these two things are my take on reality:
- The MOD team doesn’t have the resources to manage the plugin review and promotion process. Many ‘unstable’ plugins are are seeing real-world use but there is little to no movement on getting them to stable.
- Given the numerous feature requests, usability bugs, some rumored new kind of plugin store, long awaited hardware extensions, and many months of almost complete silence, I’m not optimistic that the team will be able to put attention toward modifying the code to support a change in how the boards can be shared.
isn’t about getting community plugs in the official store, it’s about Pedalboard sharing.
Most of this thread has been discussing the problem of not being able to share many Pedalboards because they contain unstable plugins. I’m proposing that one solution - rather than addressing this via code and UI changes to allow more boards to be shared - is that a group of smart people could work together to start moving the best and most widely used unstable plugins to stable. By moving about 10 or so plugins to stable I bet a bunch of people’s totally awesome boards would be newly shareable to the community.
I agree that this does not address the specific case of ‘share board with unstable plugin to the community’, and I’m sorry if I’ve gotten off track here, just trying to offer different perspectives. For what it’s worth, as a software consultant I’ve found that some ‘technical’ problems can be solved without writing any code at all!
Jesse has been quite responsive in the last few weeks. I think if we can get some momentum in the community, all that needs to happen is some user to make a plugin:promotion thread for one they have tested, then a few other users try it and chime in. I think that would work today.
So while you are right some community culture shift toward trying to find and vet the best plugins in the community store will make it easier for devs, I think this is only a workaround. It specifically doesn’t address the issue of perfectly stable plugins that are only subtly different from those already in the official store (the hypothetical 200 fuzzes). Sure we could all work harder to achieve roughly the same results, but allowing users to share boards with community plugins will make this same process easier for everyone by increasing plugin discoverability.
I think this is only a workaround
It is a workaround.
some user to make a plugin:promotion thread for one they have tested, then a few other users try it and chime in. I think that would work today.
I think that would be great and is basically what I have in mind. It’s really up to MOD team of course, but I feel like if you and a few other distinguished members give your approval to a plugin, that should be good enough endorsement for promoting. If I were on the MOD team I would probably give more weight to some people’s votes (like yours) based on exhibited knowledge and expertise.
but allowing users to share boards with community plugins will make this same process easier for everyone by increasing plugin discoverability.
It seems like everyone here is on agreement on that, but nobody knows how/when that will be able to happen. Hence, one person’s desire to poke around at other possibilities.
But, your “other possibility” is exactly how it is right now. Developers could publish plugins in the Publishing section, @jesse add then the plugs to the unstable store. Then, a promotion thread could be opened and waiting for response of established users.
Unfortunately that step fail.
So the idea is, that a sound/use-case example will help to fetch some attention.
As far as I can see the changes in code to allow that are simple, just remove the mod-hidden from line 344 (and the other parts of the share process) in mod-ui/index.html and enable the unstable store on the mod server.
Hmm, I’m proposing that a few community members be given the ability to promote plugins at their own behest in addition to, or instead of the current documented process. That somehow feels like a notable difference to me.
A different type of solution could be setting up a third-party pedalboard repository. I haven’t investigated the technical and security end yet, but something like this could work without modification to the Duo. You’d have a browser bookmarklet or extension that would post a pedalboard to the third party site. In this way any pedalboard could be shared on and used from community sites. This way the MOD site continues hosting stable-only pedalboards as they’d prefer, and member’s boards with non-stable can still be available.