We need a marketplace for module developers

Feature Requests
1

Dan,
Plugin development is kinda slow. People work for money. Making a quick little market website or something a VA could pop out for you in a week or two. Let’s get a market going so developers can sell their modules and feel like they are not doing it for free to 4ms can get more value.

I would, no problem, buy modules for Meta that I’ve already bought in VCV rack. If someone complained on that they’re not the type of person who matters because that complainer doesn’t care about developers time and paying them for it, so screw that person.

Let’s get a plugin market going sooner than later. have someone else make it for you.

2

Dan has said he has no interest in maintaining any sort of marketplace for this, so I think you may be barking up the wrong tree here.

3

There are two things I care about here: 1) not having a big burden on 4ms to maintain another commerce site, and 2) not having 4ms be a barrier to plugin developers by regulating what can and can’t be in the store (thinking of some App stores where it takes some work to get your product in it).
That’s why I’ve said I would prefer not to run a marketplace because of the additional customer support and because I want people to be able to sell their work however they like.

But, as I hear it, the point you’re bringing up is that NOT having a official store is backfiring against my wish #2 by making it less convenient for developers to sell plugins.

So, maybe there is a quick-and-easy commerce platform that can be a solution? Ideally payments could go directly to the developers (not pass through 4ms). I wonder if there’s a platform that works like that?

Does anyone here have suggestions/experience for quick, easy platforms for digital downloads?

Right now I’m focusing on getting the current base of modules stable and bug-free on the new v2.0 API, so I don’t want to push to attract new plugins until the new stuff is stable. But if we’re going to have a marketplace, then it would be the right time to start setting it up.

2 Likes
4

one idea: gumroad? that seems to be working for the independent sellers within the maxforlive community. new mm plugins for sale could be announced here in announcements section(or a brand new commercial plugins section?) with a link to the gumroad page in each post

5

I don’t think the lack of a marketplace is a big issue for developers
there are other ways for developers to get donations etc (ko-fi/patreon)

(on percussa, I had voluntarily ‘tips’ via ko-fi for modules, and it was fine)

also it might create a nasty ‘edge case’ e…g encouraging someone to charge for the ‘port’ of an existing module (by another developer) , which id think is ‘suspect’.

ofc, I think, for vcv, the main purpose of the marketplace is to have one place to easily download modules . the commercial side is secondary.
(and I do think its great for users !)

in fact, many (majority?) of developers for vcv are not charging for modules.

I think @CountModula made some good points in another topic

so why are we not having an influx of developers?

vcv is a good hobbyist developer platform because its pretty easy to develop for, and has a pretty large user base.
the MM is always going to be a bit more niche, you have to have the hardware… and as developer its a little more complicated (cross compiling etc)

however, for me as a developer, the reason Ive being holding off is due to some of the limitations the MM api currently has. (midi, native draw, files access)

ofc, these are not needed for all modules, but they are needed for ideas I had. ( * )

also, I personally, have found the UI/UX challenging.
when I create modules I want them to be fun to use, and stepping thru parameters is not that… and it also means things like step sequencers just ‘dont work’ (imho)

BUT, none of this is bad… rather its saying, things will get better !

the limitation I mentioned above, @danngreen is already working on.
the less restrictive the api is, the more creativity it will give to us developers.

also the expanders (in particular buttons) may open up the UI a bit.
the nice thing about buttons , is that they are not modal like pots… ie… as you switch module there state can switch with it.
(Id kind of like/wish there were more encoders so this would be possible for parameter values too)

( * ) more generally, Id point out vcv doesn’t really have any limitations, you can pretty much do what you want… e.g. accessing other hardware devices as I have done. this is not a criticism of MM, its just the nature of moving to hardware that doesn’t have an OS.

6

another idea(but unlikely): would be interesting if there was some way developers could somehow just nest the .mmplugin file within the .vcvplugin file. so when we update commercial modules inside vcv, the .mmplugin appears in that brand’s folder after unpack. imo that would make it easier for dev’s to not have to host the modules in 2 different places. they could just lean on the preexisting commerce system available already with vcv. but obviously this would not be possible unless ben or whoever maintains the commerce side of the vcv site makes some kind of update to allow for this. i guess if enough devs with commercial plugins brought up and echo’d the idea on the vcv forum, perhaps it could happen.

edit: but i guess there will certainly be some devs who would maybe want to eventually sell only the .mmplugin (hardware ones like instruo) so probably the above idea makes even less sense ha scratch that idea

7

Huh, I was just looking at that site, I even made a test account. It looks like each seller has their own account and just posts their software and updates them as needed. That would work well as far as I’m concerned.

I’m happy to make a new section on the Plugins page for commercial plugins, and clicking on them would take you to the gumroad page (or any page: ko-fi, personal homepage, etc) instead of downloading. We’re all setup to do that already. And making a new category on the forum for new plugins and updates is a good idea.

My hunch is the same. It’s that the API still needs some more features, and the docs could be beefed up a bit, and debugging on hardware requires some specialized equipment.

I’ve intentionally been putting energy into getting the current set of plugins stable, instead of porting more (or reaching to help other devs port more).
Now as some new features in v2.0 are materializing (text screens, MIDI streams, right-click menus, better parameter behavior) I’m starting to turn back to plugin porting (e.g. we’re releasing some Sapphire modules today).

2 Likes
8

yeah, its all going in a great direction … so I’m confident.
I will say, I think direct draw is v. important… ( I know it’s tricky).
look at the vcv store, and you’ll see an abundance of modules that are doing thier own graphics, it kind of makes the a bit more fun/creative - rather than just a bunch of knobs/buttons which are ‘functional’. its that extra bit of ‘spice’ ( * )

I don’t think hardware debugging is that important, IF the underlying framework ensures difference (to desktop) are minimised.

overall, though, development is a ‘slow burn’…
buying a module as a user is immediate - turn it on, off you go.
but dev, is different, you want to play with it a bit, get a feel, decide what you’d like to do.
its not just dev effort, its also the fact, later we have to support et, its a ‘commitment’.
only fools rush in (as they say)

anyway, Im confident, its all going in the right direction - I never expected plugins to be ported at great speed. rather, many will wait n’ see.
I think the constant updates you are doing, inspire confidence that its worth looking into, that its going to be around a while :slight_smile:

( * ) Im doing something in advance of this, but mid term, it’s important,
(also file access also opens up quite a lot of options… not just samples ;))

9

I had some ideas for this, kind of excited to try it.

Well… the problem I keep coming across as I go through plugins is that porting code from one architecture to another exposes hidden bugs. Most common one is uninitialized variables, I think I’ve run into that one on a dozen or more modules. On a modern computer, these kind of bugs just lurk under the surface, but on a small system they pop up and it’s hard to track down. I’m not pointing fingers at all – I just spent all of this morning tracking down my own bug I created when porting Fundamental Quantizer due to not initializing some variables. Another one I see from time to time is using new/delete in the audio loop. If the allocation is small, a modern computer will probably handle it, but on the MetaModule this is a big deal and is the cause of many of the “spikes” in CPU usage we saw back in the v1.1/v1.2 days.

thanks! Yes this will definitely be around for a while!

1 Like
10

yeah, this can crop up,
sometimes its caused by non-zero initialisation (not guaranteed in release builds, but sometimes these days it is done ! )
or some other oddities in particular compilers. (I had an odd one with static initialisers)

actually, Ive come across a few oddities due to compiler differences, when doing cross compiling.

so yeah, remote debugging is for sure useful for some edge cases :slight_smile:
(but fortunately, its not so common)

yeah, thats a no-no, even on a desktop… I approach this by design, rather than try to catch it later.
however, if you are porting code, you never know what you might find :wink: