That’s a good question. Whereas dealing with a zip file is conceptually trivial, I get tripped up on it almost every time when a build distribution is via zip.
The workflow creates regular vcvplugin files. What you can download in the workflow tab are just the build artifacts that are stored and can be reused in other workflow jobs and it contains the vcvplugin file in this case. A vcvplugin is attached to a release build, which means you need to create a git tag for this to happen or have a look at the Nightly publish step of the surge-rack workflow that always creates a vcvplugin on each push and reattaching it to a nightly release. Probably Latest would be a better name for this than Nighly.
2 Likes
Thanks everyone for your kind and helpful comments.
- I added a 2 HP version.
- Implemented ‘bypass’ correctly.
All I need now is a bug.
4 Likes
I was a bit surprised with this build. I have created quite a few Coerce patches of all types. After I updated, the first patch I loaded replaced the wide Coerce module with the narrow Coerce module and lost the In cable. So, I guess I have to carefully fix a dozen or so patches.
I suppose the wide module was originally named Coerce but is now Coerce6 and the narrow module is now Coerce, so the patch loader chose to disconnect the input cable since it could not uniquely determine how to map the old to the new module.
1 Like
Sorry about that. I had the same happen to my patches.
That’s precisely what happened. Won’t happen again.
1 Like
I’m in the process of fixing up my Coerce patches. I did just now get a crash that I think was due to my having connected more than one input on the original Coerce(6) module. I was able to continue and reload Rack and the patch was there with the narrow Coerce and I could attach the input cable. I may have lost some cables, but that is okay. In most cases I just had one input connected in my test patches.
Good to learn this lesson now rather than later after library release 
By the way, I am still loving Coerce.
Okay, all of my Coerce patches are working again. About half of them would crash on load, making it more difficult to fix them, but it is done.
I deleted my earlier post from a few days ago here where I included a Coerce patch as that will crash user’s Rack if loaded.
I think there is a general lesson here that there are things that can be done to a module that will break existing patches, included those that might be offered up from PatchStorage or in YouTube videos.
Sorry for all your trouble you had to go through.
Yes. It was during the switch from alpha to beta. Otherwise Coerce would still be Coerce and the 2 HP one perhaps something like Micro-coercion.
1 Like
Development is an ongoing learning curve for all of us; as is testing development builds.
I got a bit carried away with building patches on such an early release, but, Coerce opened up a tremendous number of possibilities for various types of CV meaningful-mangles. Everything I tried worked very well.
Thanks for this module.
Who can guess why Coerce and Coerce6 don’t appear in my module browser: Pictured: A patch containing the COERCE module, and module browser unable to find COERCE or COERCE6
Is there anything suspicious/interesting in your log.txt?
I remember I sent you the alpha version. The slugs have changed since then. (see discussion above). Maybe that has something to do with it.
If you delete the directory Rack2/plugins/SIM and reinstall from library, does that solve your problem?
1 Like
I don’t see anything fishy in the log!
I did this today, in fact - in order to get the update, I had to delete the old folder. I may try it again…
I have this happen to me quite often when using non-library builds. I usually never understand which sequence of steps fixed the issue, but something I do always does. I assume you have tried exiting Rack and relaunching it to see if the modules are visible?
I just set Rack to an empty patch, quit, deleted the plugin folder, loaded Rack again, updated the plugin, quit, opened Rack, checked the browser - no Coerce or Coerce6, just the blank, oddly enough. Here’s the log…
log.txt (103.2 KB)
Does the slug in your pugin.json file match the slug in the module code? Have you flagged the module as deprecated/hidden in the plugin.json file Have you added the model in your plugin init code?
Any of these can cause your module to not appear in the browser
2 Likes
I see in the log where the SIM-2.0.0. plugin was extracted
And the SIM 2.0.0 plugin was loaded.
Have you tried subscribing to the plugin in the library? That sometimes fixes this type of problem for me. Sometimes I have to “remove” the “modules” first from the library.
I am subscribed, let’s see what happens if I unsubscribe and resubscribe…