I am beginning to think that it could be a worthwhile contribution to the community to publish a common Github Action for managing a VCV Rack plugin to the GitHub marketplace, with docs to show how to use it in various scenarios:
don’t build if only readme/docs/designs/internal notes change. I just added this to my script, where I have docs, dev-notes, and design folders for documentation, develop notes, and SVG design sketches, respectively – none of which require a build to run when pushed to.
checkin validation (build all platforms)
generate a release with version bump (possibly also open your tracking issue in the library for the new release).
I use this pattern to segregate stuff that ends up in the distrbution zip from things that don’t, Builds only happen when you change something that effects the built package. Particularly good for doc maintenance, as you don’t get a lot of CI traffic in your github just for doc updates.
I take care to move stale assets like SVGs or fonts I don’t use anymore out of res but want to keep for later or for design reference. I like to keep my dist package neat and as small as necessary. Some modules ship assets they don’t use (anymore), probably because the stock makefile includes everything under res.
Hooray! The pachde One plugin has been accepted to the library, to appear in the next library update.
When it arrives, you can check out a couple of simple demo patches on patchstorage, linked from the module and plugin docs. I’m eager to hear what you make of it!
Given the discussions on this thread, and that the plugin is being published, I’m thinking of moving this thread to Development, to avoid conflicts with a new thread here in Plugins and Modules for the released plugin.
It is customary for plugin developers post one thread per new module to Announcements. Once you post, you have to wait for moderation by an admin. This lets everyone know the post is legit. Also, many people subscribe to Announcements because they want to hear about all the new stuff coming out, so it’s the perfect place for this.
Thanks for the tips! I was planning on posting to Announcements once I verify that my plugin has hit the library page (should be in the next couple of days).
I’ve always found address sanitizer to be less painful than valgrind. You might try that. I run them both under Ubuntu in VMWare Player. Should be the same in WSL…
Interesting! I have used Valgrind before, but I had never heard of AddressSanitizer. I’m reading about it now, and very interested that it comes built-in as options to gcc and clang.
Valgrind does make code run really slow, but one of the things I like about it is how it very reliably detects and reports any access to uninitialized memory. Does AddressSanitizer do this also?
I’m not sure - I think it does? but you can run much faster – I’m sure it finds less, but it’s super good. At work I used to work on something with a lot of native XCode. In xcode it’s just one button to turn it on (for their make files). Same in windows now with Visual Studio. All my code I care about I can build in visual studio anyway, so that’s pretty cool.
There’s also an amazing thread sanitizer, which finds lots of subtle stuff. But not so much use in VCV.
I just found this that says AddressSanitizer does not detect accesses to uninitialized memory, but there is something else called MemorySanitizer that does.
I have just tried your pachde demo 1 and I’m loving how versatile it is and it’s only a relatively simple patch. Congratulations on making these modules and no glitches either!
Thanks for the nice words on the demo patch. You can try swapping in different images, and it can be surprising the different results you get from a different image – certainly the evolution that happens as an image is scanned… The speed, slew, and g/t that work best depends very much on the image and what you’re driving with it. I’ve often found that the output voltage usually needs taming with quantization, attenuation, scaling, or slew. I haven’t run it through S&H yet, but that could be interesting as well.
