@cosmoproductions Here ya go 
Imagine and Info panels, both with Light theme and their “Bright xxx in a dark room” settings on. Info noting the Imagine settings in play.
1 Like
The Sierpinski Carpet and Cantor set will get you simple rhythms. This is a type of image where a larger read head area could be very useful, with options to take max/min/average values. At the moment, I’ve gone the other way, where it’s reading only a single interpolated sub-pixel value at the read head. But then, if you crank up the speed, it will start skipping over pixels. Results can be very dependent on the size of the image because we scan at a constant pixels/time velocity. And, if you want smooth varying voltage out, you have to use a smoothed image or turn up the Slew.
1 Like
Some modules have had “hidden” ports, like the geodesic blank panel.
Done – you can now plug into the panel’s logo and get a pulsing glow. – I like it!
1 Like
Update:
Rack doesn’t have a color picker widget. Most modules just stick a hex edit field in the menu, which is ok, but I 'd like something better, so I started working on a color picker. I guess I’m enjoying doing the UI work, and resisting the final DSP work needed for Imagine. To start off, designing a menu widget seemed like another level of complexity, so another module is born:
Copper
Not only works great as a color picker, but you can modulate the chosen color with CV and send component values elsewhere. It also works as an extender for the Null module to set its color, animated by modulation, and all. Pretty cool when Null is set to glow in the dark with something plugged into it’s secret Input port hidden behind the #d logo.
Info now lets you pick a font, change the size, set all the colors, and stay lit in a dark room.
I’ve also started some drafts of a large version of Imagine where the image is full module height, with all the controls and ports on the right, with plenty of room for full-size knobs and maybe a second read head.
I’m running out of excuses to do that DSP work for Imagine. As soon as that’s done, I might need a hand from the community to get builds working for Mac and Linux.
I have the basic requirements for doing Linux builds – WSL on my main box, and I have old machines that are falling out of Windows support, so good candidates to live on with Linux and force me to learn more about living in that world, but haven’t explored that yet. I don’t have ready access to a Mac, though. I’m wishing someday someone loves my software so much, they’ll gift me with a decent Mac Mini so I can do x-plat development.
Of course, I’ll also need to see how others have set up CI on GitHub, and publish private releases before we reach the library.
Anyone interested in helping out?
1 Like
Updates
I’ve added a passel of factory presets. Glad I did that: I discovered bugs that only happen when applying a preset. There is no message or established protocol to tell the UI that new settings have been loaded. It sure would be nice if Rack sent a notification event to the module widget after a preset has been loaded. Not hard to cook up your own, but it would be nice to have all significant lifecycle events as events.
I’ve made further adjustments ot the UI layout, and added some neat features (no labels option, save head reset position, single gesture image reload for iterative image design, paste text to Info, pallette color picker menu for Null and Copper, etc.)
I’ve opened the issue to add the pachde-one plugin to the library, but I’d love to have people able to build it to build try it out in their environment (Mac especially).
I’ve revitalized an old laptop with Ubuntu and tested building and running on Linux. Before i got that set up, I built and ran Rack under valgrind in WSL2, which is a bit painful but found a couple of small issues to fix.
I have a demo patch on patchstorage: VCV Rack | Patchstorage | pachde-One
How much trouble and expense is it to use GitHub actions to build for all three platforms? (or 4 if Mac M1 is even an option on GH). Never done that before. At the moment, the only option is to build from source.
1 Like
Many folks use github actions (and yes, it also builds arm64 mac builds). SurgeXT (@baconpaul) comes to mind, seen others but too lazy to check now. ah yes, @cosinekitty also does
Qno set up latest version but yeah I’ve been auto building forever.
There’s the action. Mentions surge once or twice but will just work.
1 Like
@cosinekitty popped up on my library submission issue and got me straightened out on getting the GitHub actions working! Thank you so much for that! Happy to see that this builds the ARM Mac too!
I’ve fixed all my cross-compile issues: very, very annoying differences in math functions across platforms (no sincosf on Mac), and some warnings that only occur on the Mac builds (not annoying: they were good things to fix).
I did notice this warning pop up in the Mac ARM build:
ld: warning: ignoring file /Users/runner/Rack-SDK/libRack.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
I bumped the Rack SDK version in the build script to 2.3 to see if this has been fixed, but then I get
Run export RACK_DIR=$HOME/Rack-SDK
/Users/runner/Rack-SDK/arch.mk:17: *** Could not determine CPU architecture of arm64. Stop.
Error: Process completed with exit code 2.
Are these build issues bug-report-worthy?
1 Like
Those just look like you are configured improperly.
Did you set your cross compile flags in your action?
https://github.com/surge-synthesizer/surge-rack/blob/4afa7bbb9fa4aafdeea087b2664e00e520803e32/.github/workflows/build-plugin.yml#L87 There’s the line where surge sets them
Excellent - this C++ build config stuff is basically new to me – this project is the getting back to C++ for the first time in 16 years.
I’m just using the same build YAML that @cosinekitty is using. So, Don, it looks like you might want to fix yours.
The surge version includes:
echo "Plugin architecture '$(lipo -archs plugin*.dylib)'"
and cosinekitty’s has
lipo -archs plugin.dylib
What does lipo do? In my MINGW64 bash console, it doesn’t find a lipo command, so not sure what to do there.
(I really appreciate all the help, BTW – what great community!).
Lipo runs on macos to show you the architectures supported by a fat binary. It is informational only and only on mac. But if you leave it in your action you can see thst the arm build is arm and the Intel is Intel in yout logs
1 Like
Oh and dons looks like it is from before the arm Dylib had a differentiated name. Rack uses plugin-arch.blah as the binary name except on x86_64
2 Likes
Thanks, Paul! I have a clean build now. which makes me happy.
I see the build uploads “artifacts”, but I don’t see where I can download them. I assume “artifacts” includes the built product, and not just the build logs and a copy of the build config. Or, do I have to make Releases to get downloadable builds?
Make a tag and release called “Nightly” once and then push a new commit to main and the Nightly will get updated
If you add a tag “v2.3.1” it will automatically create a release but for the nightly you need that additional first step.
Ah, the artifacts are right there on the page with the action result. Of course, these expire, but 90 days should be good enough for preview builds.
What you’re describing looks like it requires that Release portion of your GitHub Actions script that isn’t present in the one I am using from cosinekitty. Not sure i actually need this until I get a pool of users who want preview builds.
Time to dig deeper into these things to tune when builds run (e.g. I’d want to avoid building when I’ve only updated the README or other docs).
I don’t understand the significance of this. Should I update my GitHub Actions yml file? It still seems to be working, but perhaps my build coverage isn’t as complete as it could be?
If you upgrade it to the surge one, you will build both an ARM and X86 mac version of your plugin with 2.3.0. I haven’t actually looked at yours but from the fragment shared it looks like a 2.2 era arm check.
1 Like
That was helpful… I diffed mine against yours and updated accordingly. Mine is a bit trimmed down, without the nightly-build, etc. Thank you!