PLUGIN AUTHORS: Help migrating existing plugins to Rack v1

using namespace whereveryourcomponents;

the components aren’t namespace'd, and they did not need to be for 0.6 - they likely shouldn’t need to be for 1.0 either.

the issue is occurring at load time, which should use pluginInstance as defined in each plugin’s init(), and thus load from their own resources directory. the resource directory itself seems to be getting confused.

editing to add:

when I add debugging to the Widget that loads the assets, it displays the incorrect Plugin:

  fprintf(stderr, "Path: %s, Slug: %s\n", pluginInstance->path.c_str(), pluginInstance->slug.c_str());
  setPanel(APP->window->loadSvg(asset::plugin(pluginInstance, "res/Mixer.svg")));

output is:

Path: ./plugins/SynthKit, Slug: SynthKit

but this module does not live in SynthKit. when I drop down to 2 plugins, by eliminating one of the two, the issue goes away:

Path: ./plugins/CharredDesert, Slug: CharredDesert

ah, I found the issue - pluginInstance was being overwritten, and was not being caught in clang++.

As of June 12, we have had 17 open-source plugins submitted to the library repository that feeds the v1 Plugin Manager.

See the current status here:

If you know of a plugin that has been ported, encourage the author to submit their v1 plugin to the library repository.


hi @cschol,

i just pushed the changes for our plugins for v1 :slight_smile:
branch: v1
version: 1.0.0
commit hash: 0d8d756d9af812a0b5d02dac1b936f4696697a7a

should i create a new issue in the tracker or is this one enough ?



Cool! Just reuse the existing 0.6 issue on Github and I will reopen it.

1 Like

Hi Everyone.

I’m having trouble migrating my plugins to 1.0. They compile fine, but they crash Rack. I thought this might have had to do with me having messed up something compiling the Rack beta, but using the 1.0 binaries Andrew provided the other day they’re still bonked.

I feel like I’m just starting to change random stuff, so if anyone can help I’d greatly appreciate it.

EDIT: @Coirt fixed my code and is now my hero.

(If it would help to have the 0.6 sources I can create a new branch on github or something.)


Was easier to fork. Issues should be fixed, I believe they were caused by the deprecated warnings.


struct PhaseCzarWidget : ModuleWidget {
	PhaseCzarWidget(PhaseCzar *module) : ModuleWidget(module) {

should be

struct PhaseCzarWidget : ModuleWidget {
	PhaseCzarWidget(PhaseCzar *module) {
1 Like

Found this thread today, I’ve started porting southpole-vcvrack in a forked v1 branch here based on the official migration guide. I don’t see it listed in the linked project page, what else needs to be done to start tracking this work?

Did you contact the author of SouthPole to see if he needs the help? In my experience it is a waste of time if the author will not accept a Pull Request of your changes.

I am adding the plugins that are being worked on to the Project Board manually.

Fair enough :slight_smile: I can try reaching out. If nothing else it’s useful to me!

Created an issue on the southpole tracker here.

1 Like

@Coirt, thank you!! I am totes in your debt for all the help you’ve provided me on this journey. :slight_smile:

1 Like

No worries!

Any chance some one can take a look at the PvC plugin?
I tried contacting the creator several times and asked if he was going to migrate to V1.
But no response.
Would be a waste of such a fine collection of logic modules.


@cschol looks like we’re all on board!

1 Like

Excellent! Thank you for the help.

gbrandt1 can let us know on Github when a new version of his plugin is available and we will integrate it.


I’ve submitted a PR for Southpole to move to the v1 API. If other plugin authors see this thread and are looking for help migrating I’d be happy to take a look, time permitting :slight_smile: otherwise I’ll pick off the next most interesting plugin to migrate!


The author of NonLinear Instruments has said he won’t be able to port to 1.0 but feel free to fork. So if anyone’s interested:

“Hi, thanks for your interest, but I’m afraid I’m much too busy in other things. Sorry … and feel free to fork !!“

I wasn’t here for the 0.5 to 0.6 migration. Were the changes significant?

0.6 to 1.0 migration felt like a lot of busywork for almost no benefit (on the plugin side.)

Not sure.

As to the busy work I feel like it’s unfortunate, but Andrew is responsible for the overall direction of Rack and if he feels the changes are necessary for the overall good of Rack I think we should give him a bit of slack. I’m fairly sure he didn’t change the API unnecessarily.

Having said that I am truly sympathetic for the amount of changes that plugin developers felt they had to make that didn’t help their plugin get any better and I’ve heard this from more than one developer so not discounting the assessment.