Real life got in the way a few times, but I finally reached the point where I could publish the plugin on GitHub.
So if anyone is interested in trying it out, you can find it here:
Although I’ve only been able to test it on Windows, the plugin should also work on macOS and Linux, as it is built using the standard VCV Rack toolchain.
I’ve also written a complete user manual covering every module, so hopefully everything you need to get started is there. If you run into any issues or have suggestions for improvements, I’d love to hear your feedback.
Thanks for the report, and thanks for trying to build it for MacOS. I’ll report back when I have a fix
It seams to be a clash between the MAX_INPUT I define (id for an input port) and the MAX_INPUT that is defined as the value 1024 in syslimits.h for the MacOS build. As I recall I use MAX_INPUT and MIN_INPUT in several modules, so I better rename them all to someting different. The M_PI is at least “just a warning”, but I’ll have a look at it as well.
Perfect, builds fine now and even the warnings were sorted out. Nice one. I will report back if I find anything amiss, but that is a lots of modules to go through .
I’ve just submitted a request to have the plugin added to the VCV Library, so time will tell whether it’s smooth sailing from here.
Since fixing the issues pointed out by @fractalgee the source code hasn’t changed. I have, however, gone through the module documentation, corrected a number of issues, and added a few more screenshots.
It turned out it wasn’t completely “smooth sailing” after all. Apparently, I had used an unsupported (unknown) tag in the manifest file. Also, while all of my dark-themed panel files are suffixed with “_dark”, one of them was accidentally named “_Dark”. That wasn’t an issue on Windows because of its case-insensitive file system, but it naturally caused problems on platforms with case-sensitive file systems. Finally, I received a cppcheck report from VCV that flagged a few warnings. These warnings are now fixed, so I just need a last test before pushing it for the VCV Library again.
In any case, I now have a release script in place that checks for all the issues identified during this release—including validating the manifest, checking file naming, running cppcheck, and performing several other release checks I wanted to automate. So, hopefully, future releases really will be smooth sailing.
There is a script that VCV uses to check your manifest file. I asked for a copy and received it. I use it to check my own manifest file on every build. Here it is for you to use also: rack-manifest-validator.py.
Sometimes it glitches out from network errors, so I call it in a retry loop like this from my bash script for building my plugin:
RETRY_SECONDS=5
for attempt in $(seq 1 3); do
if python3 rack-manifest-validator.py ../.. -p sapphire; then
break
else
if [[ $attempt < 3 ]]; then
echo "Retrying in ${RETRY_SECONDS} seconds..."
sleep ${RETRY_SECONDS}
else
echo "Exhausted retries."
exit 1
fi
fi
done
This is just one more way you can check your own homework before turning it in!
Thanks @cosinekitty . I ended up writing (or at least instructed Cursor’s AI to write) a script, where I now perform all kinds of checks. So hopefully next time I hand in my homework, it will be more smooth
If anyone is interested I don’t mind sharing this script, however it is very specialized to how I do things, and which files/folders I have:
=== panels-pairs ===
PASS: 76 light / 76 dark panel pairs OK
=== plugin-json-bom ===
PASS: No BOM; starts with '{'
=== plugin-json-parse ===
PASS: Parsed OK; version=2.0.2; 76 modules
=== version-changelog ===
PASS: version 2.0.2 matches CHANGELOG.md
=== manifest-panels ===
PASS: All 76 modules have light+dark panels (exact slug casing)
=== manifest-tags ===
PASS: All tags allowed (77 aliases from Tags.txt)
=== orphan-panels ===
PASS: No orphan panel bases
=== panel-layers ===
PASS: No multi-layer panels in res/ (152 SVGs checked)
=== status-modules ===
PASS: All 76 modules listed in Status.md; no orphans; none In Development / Needs Testing
=== manual-modules ===
PASS: All 76 modules linked in manual.md Modules section
=== model-class-slug ===
PASS: All 76 modules: Model* / Module / ModuleWidget names match slug
=== model-extern ===
PASS: All 76 modules have extern Model* in plugin.hpp
=== model-addModel ===
PASS: All 76 modules have p->addModel(...) in plugin.cpp
=== md-links ===
PASS: All relative .md links in doc/ resolve (25 file(s))
=== changelog-md-links ===
PASS: All doc links in CHANGELOG.md resolve
=== manifest-manualUrl ===
PASS: All 76 module manualUrl targets resolve in doc/
=== cppcheck ===
PASS: cppcheck clean (C:\Program Files\Cppcheck\cppcheck.exe)
=== Summary ===
PASS
I think I got all my ducks in a row some 5 days ago, as I haven’t got any Issues raised, and it appears to have reached the “Build update” stage, so I guess it will be implemented next time the Library is updated.
Anyhow I decided to have a go at GitHub Actions (of which I know nothing), in order to have Nightly builds (basically a new build, each time I push changes). These builds are both for Windows, Mac and Linux,
Getting this working was a lot more simple than I had initially expected, thanks to the work done by @Pachde and @Bloodbat. Paul’s Generic Template had the yml I needed (just had to replace “main” by “master”) and it relies on the container @Bloodbat have made. Then it was just a matter of creating the “Nightly” tag and release.
.
