TODO: Roadmap to baseline

[nathanjhood]

Chore

Describe the chore

Outstanding tasks before we can commit to incrementing the plugin version number to indicate an official baseline release version.

• TODO 1: Deps #147
  • WIP: Refactor codebase to seperate plugin, library, test, and external vendor code #15
  • WIP: dependency injection with vcpkg and CMake #21
  • cleanup VCVRack CMake install target directories #90
  • Make sub-targets for each dep; rack-sdk::dep::openssl, and so forth, each with their own FILESET and correct dep linkages #329
  • add more SDK versions to the vcpkg local filesystem registry
  • Make CMake API helper functions for creating VCV Rack plugin, modules, and more #121
  • vcpkg as a submodule with Makefile support #330
  • migrate local StoneyDSP to remote
  • migrate local vcpkg-registry to remote
• TODO 2: Tests #163
  • Add Catch2 for unit tests #165
  • Create Test Spec class or struct #166
  • WIP: Begin test coverage #167
    • instance constructs/deconstructs safely
    • REQUIRE_THAT(box.size.x, WithinRel(::rack::mm2px(5.08F))), etc... #327
    • box.size.y == ... as above #328
• TODO 3: Build system #164
  • CMake Presets #141
  • make dep #142
  • fix versioning
    • investigate pushing git tags to cut releases automatically #300
    • use STONEYVCV_VERSION <= 20001000.... instead of *_VERSION_MAJOR/MINOR/etc #385
    • use git rev-parse HEAD to generate STONEYVCV_BUILDNUMBER and/or STONEYVCV_VERSION_TWEAK #315
  • Better usage of 'EXPERIMENTAL' flag #134
  • create CMake Object Libraries with correct dependency order; link plugin target to them #89
  • CMakeRC for embedding some resources? #216
• TODO 4: Design system #168
  • fix correct sizes for HP1, HP2, HP4 (the modules are x3 too small on the x axis) #91
  • Create branch for component lib, panel and widget design, etc #162
  • WIP: Begin GUI globals, component library, design system #38
    • use global-scoped vars for module colours where possible/appropriate #264
    • learn how to subscribe to runtime-level "onThemeChanged" events, if possible, to mark framebuffer widgets as dirty() #263
    • themed panels #355
    • themed ports #356
    • themed knobs
  • Make component library shareable
  • Make design system templated and shareable
  • Add to CMake package
• TODO 5: Modules #169
  • GUI Modules #120
    • HP1 #116
    • HP2 #117
    • HP4 #118
  • Control modules
    • WIP: LFO #130
  • Audio modules
    • WIP: VCA #119
    • VCO
• TODO 6: Documentation #170
  • Doxygen for code documentation #177
  • add themed images of modules to docs #361
  • use configured headers to generate file version info (requires GNU coreutils) #380
  • Doxygen for module PDF generation?
• TODO 7: Deployment #171
  • Investigate and implement a process or pipeline which meets requirements for deploying StoneyVCV to the Rack User Library

[nathanjhood]

Some notes:

• Module/Widget/ModuleWidget struct initializer lists and deconstructors:

Tough call here. The rack structs Module/Widget/ModuleWidget all define virtual deconstructors, which iteratively call delete on certain resources. Overriding the deconstructor without a safe release pattern causes VCV Rack projects to crash when re-opening them with a faulty module instance pre-loaded. On the other hand, I'm not keen on the sight of calling new to assign to struct members in constructors. without seeing the delete. Problem: if we override deconstructors and call delete things will work as of Rack 2.5.2 - but since we'd not using the deconstructor from the API, we wouldn't know what we might be breaking in future Rack release compatibility by doing this. I don't doubt that the developers of VCV Rack are very well aware of safe release patterns, and their design choice has probably enabled more developers than it has hindered. I need to consider this one carefully - initializer lists in the constructors seems like a given though, can't see why this isn't the suggested pattern in the Rack docs?

• Module props (members):

There's a fine line here: we only need to test things which are specific to that module, such as box.size (seems a great idea to have this test residing over git branch protections), we do not need to test every available method and member since we trust these are tested by the VCV Rack devs before deploying. Our tests should not target "general" Module/Widget/ModuleWidget props and behaviours, but should target the specifics of our modules.

• Global design system/component library

This will need a feature branch. The eventual intention is to offer an open-sourced design system/component library that can be shared with others, separately from the plugin modules. Some aspects of this might end up in the StoneyDSP library, while rack-specific stuff would be in StoneyVCV.

I intend to use the contents of res/colors.json to populate some kind of templated struct or union data type, to carry aliases which I can use globally for visual theme, look and feel... there will be SVG-based widgets as well.

One thought I'm having is to use some custom data type to hold either RGB or hex color values (possibly in the StoneyDSP lib/namespace); then, in the StoneyVCV namespace, provide a function which accepts this data type as the input argument, and returns an NVGcolor to use in the Module/Widget/ModuleWidget....

auto black = {43, 43, 43, 255}; // RGBA

const NVGcolor bgBlack = createNVGcolor(black);

• Embedded resources/CMakeRC

I'll likely use CMakeRC or some hack on it to create char pointer arrays containing resource data encoded as bytes. This will enable me to re-use the tonnes of existing image resources I already have which are in other formats besides SVG. It isn't inconceivable to use this for other things too, like audio files...

[nathanjhood]

Ok.... I think this remote repo is finally up to date with my local, for the first time. All branched and versioned now.

I think it's time to figure out this GUI stuff.

[nathanjhood]

Problem

I don't like having so many different value ranges in the codebase. Specifically, voltages from 0 to 10, audio from -1 to 1, and parameters doing whatever ranges they like.

It tends for some very messy DSP with much more allocation and logic than necessary.

Idea

Use abstract classes to seperate DSP-based processing from VCV Rack SDK stuff

• The former shall process samples within an audio-like range of 0..1 or -1..+1
• The latter shall process, and convert where necessary, voltage standard ranges of 0..10 or -10..+10
• The DSP parts can be shareable and inheritable, as well as eligible for array/vector based processing, to allow for SIMD instructions
• The widget parts should be final as these pertain to our plugin, specifically

I propose everything on the panel should be viewed as analogous, as in, represents a real-world electrical voltage value. So, knobs as well as ports have a scale from 0 to 10, or from -10 to +10.

A lot of params will require scaling internally to behave as desired: all part of the plan, and a chance to do things like insert test points, clippers, scalars, and smoothers.

In terms of "safety" and headroom: clipping at 12v (including -12v) is an idea I like. It allows for "+12 above 0dBfs", with a "nominal" voltage of 10v (0dBfs)...

The actual limits may be hard-coded as a set of static, namespaced global variables which can be referenced in class methods. This saves some allocations. We may think of these as our plugin's "power supply".

[nathanjhood]

In terms of "safety" and headroom: clipping at 12v (including -12v) is an idea I like. It allows for "+12 above 0dBfs", with a "nominal" voltage of 10v (0dBfs)...

The actual limits may be hard-coded as a set of static, namespaced global variables which can be referenced in class methods. This saves some allocations. We may think of these as our plugin's "power supply".

It's far too expensive to do these comparisons on every audio tick. In the case of the VCA module, which is probably the most minimal audio processor I have planned, that's 4 calls to clamp() per tick, which is throwing the baby out with the bathwater 👶

There are certain things I do wish to clamp: unipolar inputs, particularly. Those are within reason. Vetoing the previous idea of clipping and clamping on the audio thread in any case which is not necessary.

[nathanjhood]

If knew then what I know now... this is what I would do differently

Sub-class basically all of the factory component library namespace into my own component library, and sub-class those to create my modules and module widgets.

Also wrap some of the factory functions in my own...

EDIT: ...and use more managed pointers-to-members with getter/setter functions...