Chore

Describe the chore

• StoneyDSP::stoneydsp_core
• StoneyDSP::stoneydsphelper
• CI/CD artefact caching
• vcpkg integration

Additional context

#14

Chore

Describe the chore

Currently establishing a set of validation rules for our project v0.1 baseline.

Command-line tools are easy enough to test on CI/CD. However, this is an audio library catering for vst3 and other plugin formats. Testing these on CI/CD therefore requires a slightly different approach.

Fortunately, we have pluginval for that.

Need to implement a pluginval step for each platform. Ideally, the command shall be as identical as possible for all workflow runs, so that we can re-consolidate all platform runs into a single workflow file later on.

Additional context

Pamplejuce implementation

Chore

Describe the chore

The project root folder has become quite expansive, meaning new visitors are immediately faced with a lot of various content without much context or direction.

One root cause of the issue is that there are mixed traces of differing project layouts; in part, we have followed the Unix-y C-like approach of having things like /lib and share, which is a current personal preference due to it's universal frame of reference.

However, the underlying tooling such as JUCE and vcpkg take much more customary approaches: JUCE's C++ module support via CMake does not actually allow splitting C++ units between seperate /src and /include paths - the headers and sources must instead be co-located on disk. Their suggestion to use a /modules dir makes sense in this context, not to mention that it has been adopted by many users already.

I am happy to move all CMake into extras/Build/CMake/ as per the JUCE project layout, thus ensuring a single source of truth for our CMake module requirements, consumptions, and distributions. That will eradicate the /share dir.

I am happy to actually open a new /tests dir for our StoneyDSP CI/CD and CTest stuff, as this is a good reference for our users, just like JUCE's tests are a good reference for us. The naming is clear enough as to actually have some merit in it's existence, rather than it's removal.

Not sure what to do about the Typescript/Javascript/NodeJS interface under /lib, particularly since this is not likely to progress further in the current development cycle. At time of writing, I suggest probably leaving this alone for the moment, but once implemented it will probably likewise want to become a new CMake target and also be placed where it can be bundled safely for distro, a la the CMake modules.

The above also applied to our /public and /_layouts folders, and some various NodeJS-related files lingering around the root folder. These are probably all causing the most clutter and obfuscation, to my mind; perhaps, then, we should enhance the priority level of getting these pieces in play, rather than trying to ignore them until later on? There is a fair bit of documentation, not to mention CI/CD, intended to go along with that stuff... and also the question mark which is both cmake-js and the stoneydsp_web module. Quite a blocker...

I am 50/50 about the /.vscode stuff - it's not supposed to be some sort of requirement, just more of a helper. Could be pushed to one side and referenced in the docs as some helper files... maybe. Certainly it makes more sense to implement much of that stuff as CMake presets instead...

Strategy

Perhaps, then, we should make the initial changes which have no blockers, ensure the CI/CD is passing with this configuration, and then make another assessment of the condition of this task at that point.

If necessary, we can either:

• choose to enhance the priority of the entire web/NodeJS interface
• choose to move those files to one side for the moment
• choose to proceed to other tasks without changing anything else here, for the time being

Chore

Describe the chore

Bit of a nightmare trying to get just v.0.01 off the ground for osx platforms. A summary of some issues:

• The runner for 'macOS' seems to be an ARM-based architecture, and PampleJuce's workflow sets CMAKE_OSX_ARCHITECTURES=arm64;x86_64; accordingly. This seems to be no issue for JUCE projects by themselves.
• The vcpkg workflow action step fails when target triplet is x64-osx - using arm64-osx seems to correct things and the build succeeds
• The linker step fails on all osx builds when trying to link our stoneydsp_web module's CURL-based functions to libcurl, with output suggesting that the linked libcurl is - frustratingly, always - the wrong architecture for osx triplets.
• target_link_libraries(stoneydsp_web INTERFACE CURL::libcurl) picks up the x64-osx libcurl, fails, and the output suggests that we need the arm64-osx variant. Directly linking to the arm64-osx lib using various hacky tricks and/or linker flags allows us to force the previously-requested library variant, but this also fails, with the output here countering the previous advice by requesting the x64-osx library instead! So, it seems to be impossible to satisfy this
• I had considered playing even more dirty by trying just a #pragma comment (lib, "curl") and seeing if the linker can just intelligently suss things out; however, the windows workflow is capable of taking close to one hour to fully complete (aghh...)
• Since the intended CURL functionality is not necessarily critical to proving that the utmost essential parts of StoneyDSP are building, I have decided to sacrifice the stoneydsp_web module and the CurlConsoleApp example by removing it from this initial release, and will place it on a new wip or feature branch for later merging, pending further discovery and development
• Having removed the above for the time being, the entire yaml file is now passing validation successfully; however, the macOS workflow is failing to cache it's build using sccache, producing the following output:

Non-cacheable reasons:
multiple different -arch, and SCCACHE_CACHE_MULTIARCH not set      47

• This is clearly because of this mis-mash of architectures on osx, the same thing causing the libcurl linkage issues.
• The macOS workflow is forgivingly fast enough in it's work that I am happy raising sperate issues for resolving the multi-arch handling of osx triplets and the setting of SCCACHE_CACHE_MULTIARCH, and the concurrent creation of the stoneydsp_web and CurlConsoleApp parts of the project

Additional context

This issue will be linked to PR's for resolving the multi-arch handling of osx triplets and the setting of SCCACHE_CACHE_MULTIARCH.