I believe it’s @Vega. Maybe we need a list?
1 Like
It was me, but I don’t have time, life happened. I know someone else is doing it, but I forgot who (sorry!)
1 Like
I feel quite humble here, because I am not a developer. But as a long time member of this community, and user of Rack, I would hate to see those great plugins disappear. Because especially the unusual and, let’s say rebellious stuff are what made Rack so appealing, to me at least. So this is what I can do. Mentioning stuff that I think deserves being mentioned.
1 Like
alto777 and qwelk just need a plugin.json version change to 2.0.0, both build fine for initial testing.
1 Like
both LFSR(alto777) and qwelk were plugins I migrated to 1.0 and at that time alto777 and raincheque were attentive to PRs. I’ll test them and send PRs tomorrow with the hopes they are still around after two years. BTW, for V2 I’m testing plugins also as VST in DAW (I use bitwig on Windows). I’ve had plugins work fine in standalone and die in VST so it seems like a good step to add to my QA chain. Thanks for checking the build status on those - it brings back memories… 
4 Likes
No worries mate. Yeah quite a few migration memories or should that be flashbacks? LOL
2 Likes
Just building with updated plugin.json is not enough. Developers must do a runtime check also (load in module browser). This will flush out a good portion of potential issues.
The font caching problem must be checked with the VST. I have an additional integration step now that checks if fonts are used properly.
5 Likes
I would add to this, that a developer should do a patch load test as well. Not only loading a patch (with the module(s) under test) into Rack, but also exiting and relaunching Rack with the same patch in place i.e. an auto-saved patch. I had a user of Rainbow report this kind of issue to me earlier, which is why I bring it up.
1 Like
If you guys need any help, or testing or whatever, please let me know.
Would be great if one day those various checks you perform could be made available to developers so they can run the checks themselves and catch problems before they reach you.
1 Like
Load VST in DAW. Add modules. Save project and close DAW. Reopen DAW and load project. Crash?
I would need a daw for that.
If you don’t have a DAW (or anything that can load VSTs, save a project, and reload that project), you can’t do this test yourself. That’s what I do. Just for QA purposes, I would recommend all developers have a way to load the VST and test their plugin. There are probably free solutions.
Reaper has a 60 day free demo.
Reaper expects people to either pay or stop using the software after the 60-day trial period. However, there are no real consequences if you continue to use the software after the trial period ends. All you get is a message when you open the software that you can close after 5 seconds.
As someone noted, you can use reaper without a license. And there are several free daw around. There’s really no excuse not to get one you can test with.
Fwiw I bought Reaper, although I’ve never used it for anything other than testing. It’s about $70 iirc.
1 Like
None other than feelings of guilt! 
Hopefully before long you do the right thing and purchase a license if you continue to use it. Reaper is dirt cheap at $60 for personal / educational / non-profit use, or commercial use if annual gross revenue is <$20,000.
1 Like
Well, yes, but I wouldn’t feel guilty if I just used it to test VST. You are contributing to the ecosystem, after all.
Again, I have reaper, several free daws, and one or two that aren’t free but I got a license at no cost to me.
If you’re on Windows, for a free DAW try Cakewalk, it’s now available for free via BandLab and even though not state of the art should at least let you test out the VCV plugin.
1 Like
I’m a Bitwig man 
1 Like
Based on how much people are freaking out about these ones, I feel like if they started charging $5 for these babys it would probably cover the cost of hiring that intern as a FT software dev.