Great to see so much activity and porting going on! Just a quick note, before going too far with porting anything however, I’d at least encourage contact with the VCV maintainer - especially in the case of hardware plugins. I do a lot of work on VCV plugins and always have a conversation about MM versions. Two recent examples are Bastl and Black Noise, where at least at the time they didn’t want to persue MM versions (yet!). If they do I was happy to help port the modules, and generally it makes sense for the VCV maintainer to be MM maintainer (know the codebase, can add new modules etc, don’t want to be responsible for MM bugs etc).
Some manufacturers are less keen to port (e.g. for commerical reasons), and it’d be nice if ports weren’t performed unilaterally. From a licensing perspective it can’t be stopped I suppose, but then it makes open source VCV plugins less appealing from a manufacturer perspective.
Finally I don’t want to come across to negative, it’s great to see so much progress and effort put into this, just suggesting that it’s good form to check with the VCV developer (and manufacturer if relevant) first!
Strongly agree with Hemmer’s sentiments. Best to ask first in these kind of situations. While there are guidelines around what people can do with open source - it’s actually a complex arena, and so it’s best to adopt as reasonable a position as possible.
Thank you, I appreciate that! The same advice probably goes for non-hardware modules too, although there I think it’s much less likely there would be an issue.
I’ll also reach out to Black Noise again, just in case they’re interested - it’d be a shame to not use your hard work!
Also strongly agree here – I always send an email out to the original developer before getting too far with porting and it’s always been a positive response. I’ve even made some nice connections this way!
Besides just courtesy it’s also good to check if sometimes a developer might want to help in porting or even take it over themselves. Or maybe they even have started porting themselves, you never know. If they happen to have a MM they probably would want to try it before it’s distributed
And mea culpa for not putting this in the SDK docs! We probably could use a “best practices” section.
That sounds great, maybe could be part of the “adding newly ported modules” submission process. A headling like: “if not developer, have you reached out to them” section maybe?
Yeah I have Kompas running here locally on MM, but haven’t pushed because at the time at least we decided not to port (will check in again).
Also just a slightly broader point about when there are hardware brands behind these (or even if there aren’t) is that these plugins represent the brand, and could influence whether people buy the module. In the case of Black Noise COSMOS, we thought quite carefully about oversampling/aliasing because it’s great to use on audio rate material, but I see in the recent port that oversampling is disabled by default, so there’s a risk people use COSMOS, hear horrible aliasing and decide not to buy. Just as equally, I could port Pizza but it ends up in the “red column” for CPU performance (which I suspect it would) and then we either compromise (make it sound worse to save CPU, see above) or don’t (you start to see comment like “too bad Pizza is a CPU hog ” etc which also has negative connotations).
But again I don’t want this to sound like a pile-on / too much of a rant, and I’m super grateful for all the hard work going on here, I’m just explaining why it’s complicated and just that we all should be a little careful, me included, in the rush to port as much as we can to MM (which ultimately, as a user, I want to see as much as possible here!).
Finally just to share my experience on the other side of this, I made emulations of the Mannequins suite for VCV a while back and proudly emailed Trent saying look how awesome this is. He was really great about it, and we had a good email exchange but ultimately he didn’t want to see digital versions released and I really respected why, I hope he doesn’t mind me sharing this snippet!
I’ve actually built out a few of these modules into VCV Rack myself, but in the end decided it didn’t make sense for our business to release them publicly. So much of what makes the Mannequins modules unique is peculiarities of the analog domain, and the ability for self-patching to exploit those. I was never convinced that the digital emulations captured the essence of the modules, and felt it prudent to avoid watering down their magic with a less-than-perfect emulation.
this is a really great doc, containing really valuable information.
Id like to make a couple of suggestions…
I think the initially readme for the SDK, could perhaps point to this somehow?
it feels like some of this info should be read before someone starts a port etc.
whereas, it’d be temptingto read a releasing doc, only at the point you want to release it.
GPL code and license file.
generally something like GPL requires you on release of a binary to :
a) include the license file, and make it accessible (as part of your release)
b) provide reference to the source code used to build the binary.
I think this could be covered by 4ms, if your plugin page requires author to specify the license (as you do already, though this could link to a license file) , but also source url, where this is applicable.
as you rightly mention, whilst some treat this all a bit ‘lightly’ there are legal ramifications, and also as you say a lot of open source developers to this out of passion so its important to respect and acknowledge their work.
” etc which also has negative connotations).