PLUGIN AUTHORS: Help migrating existing plugins to Rack v1

@netboy3 Feel like helping out with tidying up southpole modules for 1.0 after well? i assume Gerrard Brandt won’t mind as he’s pulled someone else’s hose to make it ready for 1.0 at all. Would love the cornrows right click to crash Rack bug to go away.

2 Likes

Looks like there are a few folks working on stuff there (as recent as 3 days ago). I’m happy to join the party :tada: Will have some updates soon…

1 Like

Ah that must be what I was experiencing but haven’t managed to track down.

Anyone up for fixing MilkRack ? It builds for v1 but crashes Rack when I open the browser, every time. :frowning:

EDIT: Btw, I filed an issue on github on July 30.

Hi, I’m sure I’m not supposed to do this? But I’m repeating my request for some help here. I could use some help with porting the plugin I’ve developed for Rack v0.6.2c. It is a single plugin called Vocode-O-Matic (which you will find under the name Sculpt-O-Sound), so that should not be too much work to convert.
I’ve managed to create a working copy for v0.6.2c by looking at example code but since I’m not really fluent in C++ I have difficulties in understanding the changes needed for v1.x. I tried to follow the migration steps but am running into troubles after that (see branch here: https://github.com/josbouten/Sculpt-O-Sound/tree/v0.6_to_v1.1 ). Possibly it is best to start again but with the guidance of someone more experienced in C++. Can anybody help?

1 Like

opened a pull request for you.

1 Like

Thx. You are a life saver!

As requested, I’ve spent the last 10 days cleaning up Southpole. I believe we are ready for release. I’ve posted a pull-request for Gerrard that culminates all my work on the Southpole GitHub. I have also posted a comment on the Southpole V1 issue thread with binaries so the community can test the new build. I would appreciate if any discovered issues can be posted back (preferably to the GitHub issue tracker, but I’ll be monitoring this thread too). Please note, this build fixes an issue that was introduced during the initial v1 migration which broke 0.6 patch compatibility. This build is again compatible with the saved 0.6 patches. Unfortunately this means that if you have a patch you saved lately with the buggy version, it will not load. You can fix such broken patch files by opening the .vcv file with a text editor and replacing every instance of “southpole” with “Southpole”. If you want to build from sources, make sure to merge pull requests 41, 42, 43, 44 and 46.

7 Likes

Can I put a vote in for https://github.com/8Mode/8Mode-VCV_Modules to make into the latest version of Rack: If memory serves it was a fairly late addition to Rack 0.6 but I had a lot of fun with it while it was available.

1 Like

I actually started working on migrating 8Mode a few weeks ago and am almost done. I should have it ready in the next day or two.

4 Likes

Very great job. Thanks!

Awesome on Southpole and thanks for getting there with 8Mode.

Just completed migrating the 8Mode plugin to Rack V1. I’ve also posted a pull request for the original developer to merge my update into their code. I have also built the plugins and have them posted in the GitHub v1 migration thread for users to test out the new builds. Please let me know if you find any issues. I hope you enjoy the fun of the SoftSN Machine again. It’s a fun plugin that really strikes a cord with discrete electronics hobbyists.

4 Likes

This is fantastic, thank you. I didn’t really get a chance to play with it before I moved to v1 so it’s nice to have now to explore.

I’ve just tried your 21Khz fork, it’s working but it is not backwards compatible:

Old

  "plugin": "21kHz",
  "version": "0.6.1",
  "model": "kHzPalmLoop",

New

  "plugin": "21kHz",
  "version": "1.0.0",
  "model": "PalmLoop",
1 Like

Doesn’t solve for that in the short-term, but one of my VCV Rack Feature Requests would be fall-back tags for Plugin and Model. Something like:

"plugin": "21kHz",
"version": "1.0.0",
"model": "PalmLoop" or "kHzPalmLoop",

So if a tag happens to change like in your example, or you only have “Vult Modules” installed, but a preset was created with “Vult Modules (Free),” that Rack could still find the module in question and load the presets.

2 Likes

That would be really handy and sounds like a very sensible solution.

It’s possible I messed up :disappointed:… I’ll get it fixed and re-post new builds. Thanks for letting me know.

2 Likes

this is a great opportunity to open up an issue on the vcvrack GitHub.

perhaps note that in the parsing of plugin.json that model can be a string or an array.

maybe mention about how you’d store them (maybe a std::vector<std::string>).

could make for a great proposal if enough details are put in the issue, go for it!

Just opened a Feature Request. I actually thought I had opened one up for this issue before, but maybe I just mentioned it here in the past (couldn’t find it in my Github history).

Jerry, feel free to add to the new issue I just created. I’m just a dumb end-user and don’t know anything about coding:

3 Likes

@Vortico could @netboy3 get an answer to this question. Particularly what should he do if the original module developers are unresponsive.