PLUGIN AUTHORS: Help migrating existing plugins to Rack v1

During the migration phase from Rack 0.5 to Rack 0.6, the community assisted authors of open-source Rack plugins with migration in the form of GitHub Pull Requests.

This worked great and allowed a very efficient transition and successful launch of Rack 0.6 with the majority of open-source plugins available in the Plugin Manager upon release.

For Rack 1.0, the Rack Library Team is again coordinating the open-source plugin migration effort on GitHub.

Here is a few ways that the migration can work:

  • Plugin author migrates plugin herself, then submits an issue in the Library Repository. The Library Team will review the plugin code and integrate into the Library Repository if the acceptance criteria are met.
  • Plugin author needs help migrating plugin. A community member volunteer will provide a GitHub Pull Request to the author with the necessary changes to update to v1 of the Rack API. The author then submits an issue in the Library Repository. The Library Team will review the plugin code and integrate into the Library Repository if the acceptance criteria are met.

General Notes: The migration of all plugins will be tracked in a GitHub Project Board. This project board page contains an overview of the Acceptance Criteria the plugin has to meet to move through the different stages of the process. Every plugin must have 1 (one) issue in the Library Repository on GitHub that is used for communicating plugin status to the Library Team. Notify the Library Team that your plugin is ready for migration to Rack 1.0 in that issue on GitHub and the team will update the Project Board status of the plugin.

Plugin Authors: If you need help from the community migrating your plugin to the v1 API, please let me know in this topic. I will update the GitHub Project Board to reflect the need for help and community members can volunteer and work with you to provide a PR against your plugin.

Community Members: If you are willing to help migrating plugins to the v1 API, please also let me know in this topic. The Library Team will provide a list of plugins that need migration help on GitHub and will assign one to you. You will then work with the plugin author via their GitHub repository to get the plugin updated to the v1 API.

IMPORTANT: Please do NOT just start randomly updating other people’s plugins to the v1 API. We had a lot of success last time around with a coordinated effort that eliminated a lot of duplication of work. If the authors want help, they are encouraged to ask for it here. Otherwise we assume that she is updating the plugin herself.

For reference, here is a link to the official v1 migration guide.

Let me know if you have any questions.

(This will be cross-posted in the Facebook Plugin Developer group).

4 Likes

I can help with modules with ridiculous custom widgets. Some of this migration work could be inspiration for last-minute changes to the v1 framework, such as addition of classes.

@cschol, if you see plugins that have nontrivial code, assign them to me. I’ll have a few days within the 3-week period between v1 API stabilization and v1 release to work on random projects, and I’ve gotten fairly efficient at porting plugins.

2 Likes

I’m not familiar with that github stuff - but here I am - let me know :wink:

It might be better to open “signs of life” tickets than assuming everyone silent is doing an upgrade. Some developers pinged weren’t aware the API was even being stabilized yet.

Yes. That’s what I did last time. I first want to see the response we get from this messaging.

you should make a post in VCV the facebook group too,
or I can link it there

@Vortico Can we pin this post to the top until migration is done?

@Vortico regarding ridiculous custom widgets. I frequently refer to Fundamental, Befaco, AudibleInstruments, etc. for examples of best practices. What plugin/module has a good example of custom widgets handling NULL gracefully and not blowing up the module browser. The custom widget I am working to migrate is a display based on TransparentWidget, in MrLumps SEQEuclid. Thanks!

SkJACK had such a ridiculous widget; there wasn’t an easy way to change the font/color of a text field or be notified of its update (0.6), which required creating a subclass and copying the draw code just to insert two calls. The 1.0 port still does this for now.

It would be miles more convenient if:

  • Font and gradient colors were just properties of the (LED)? text controls, as with usual widget toolkits and
  • There was a message handler of some sort.

Having to subclass a text control just to turn around and tell a module that a text control changed is a little :thinking:

Absolute lowest effort message handler would be an onWidgetMessage(int32 reason, basetype_t sender), while setting the messages is just a recipient_basetype_t weak ref and the type code.

When you say text field, do you mean ui::TextField? I haven’t really made a public API for that, but you’re always welcome to open feature requests on GitHub.
If that’s what you used, why not use TextField::onChange?

I had/have a lot of ridiculous custom widgets
and they are thousands and thousands lines of code

I had 2 solutions (to avoid crashes in module browser)
a) going in all the ridiculous custom widgets (custom for every module) and check for the integrity of the “MODULE” inner member

b) during the widget creation, avoid the creation of any ridiculous custom widget if MODULE dependent

I choose b, because was easier
of course in the module browser the nysthi modules appear like a green desert :slight_smile:

The LCD Text Edit field, a la the one used by the Notes module (although the single line variant.)

I’ve already patched my code, what I’m saying is having to do a subclass just to catch the change event is junky coding.

Wut

In all seriousness, if you require a feature such as changing the font in certain classes, open a feature request because that’s why they exist. Nearly every feature in Rack began with a feature request.

Your modules aren’t open source, but if you want to give me access to a git repository, I can send some updates.

I just draw placeholder graphics for the widget on the panel in inkscape (box/font) which renders in the browser which is then covered by the actual widget when in the rack.

1 Like

As of June 2, 9 open-source plugins have been ported and integrated in the repository, which will feed the v1 Plugin Manager.

See the current status here: https://github.com/VCVRack/library/projects/1

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

2 Likes

I’ve managed to port my “ridiculous widgets” without too much pain.

the issue that I am seeing, though, is patch compatibility due to the difference isSlugValid() has. for instance, I had 3 modules with what are now considered invalid slugs:

  • Oscar^2
  • CV Sequencer
  • Mixer CV

note that these were the slug names in 0.6 that will not be registered in 1.0 - since patches and autosave use the slug field, and not the name field, no patches from 0.6 that use these modules will be compatible.

is this an oversight, or something that we should expect will not work?

Remove invalid characters “^” and " " from your module slugs, and Rack will “normalize” module slugs to “Oscar2”, “CVSequencer”, “MixerCV”, etc. upon patch load.

I’m seeing some weird resource “crosstalk” when loading multiple modules that have been ported, and would love a few pointers on how to better track down the issue.

status:

  • 3 plugins ported to 1.0 with minimal deprecation warnings (due to components using setSVG(APP->window->loadSvg(asset::plugin(pluginInstance, "res/...")))
  • when only loading 2 plugins, everything works without issue
  • when loading 3 plugins, run-time errors about panel SVG’s and other assets not loading with incorrect path (Plugin 1 panels trying to be loaded with Plugin 3 paths)

this gets manifested as panels for Plugin 3 not existing, and the following log entries:

[3.531 info src/window.cpp:72] Loaded SVG ./plugins/SynthKit/res/1x8.svg
[3.531 warn src/window.cpp:75] Failed to load SVG ./plugins/SynthKit/res/Pan.svg
[3.531 warn src/window.cpp:75] Failed to load SVG ./plugins/SynthKit/res/Port.svg
[...]
[3.165 warn src/window.cpp:75] Failed to load SVG ./plugins/SynthKit/res/Noise.svg

note that Pan.svg and Port.svg are part of another plugin (Plugin 1), as is Noise.svg.

All plugins are using asset::plugin(pluginInstance for loading assets, such as setPanel(APP->window->loadSvg(asset::plugin(pluginInstance, "res/Pan.svg")));

Plugin 2 shows correct assets, Plugin 3 shows correct assets, but all assets are missing for Plugin 1.

any help would be appreciated.