v0.0.1-rc

[nathanjhood]

What's Changed

• Merge 'production' v.0.0.1 into 'preview' by @nathanjhood in Merge 'production' v.0.0.1 into 'preview' #11
• Merge 'development' v.0.0.1 into 'preview' (Merge 'production' v.0.0.1 into 'preview' #11) (Merge 'preview' v.0.0.1 into 'development' (#11) #12) by @nathanjhood in Merge 'development' v.0.0.1 into 'preview' (#11) (#12) #13
• Development/v0.0.1-rc by @nathanjhood in Development/v0.0.1-rc #23

Full Changelog: v0.0.0...v0.0.1-rc

---

This discussion was created from the release v0.0.1-rc.

[nathanjhood]

What's this?

extras

I've ported some CLI tools from an existing project over to what will become stoneyhelper. This little app already accepts the standard --version/-v and --help/-h commands, which we might start using right away to validate all of our CI/CD build runs using CTest. Soon, this app needs to be reporting it's own name and version, ideally controlled by the CMake project that builds it, and by calling it's constituent parts from our StoneyDSP library, in the form of polymorphic classes (or pod structs, is also fine... I guess)!

examples

GUIApp is currently the actual JUCE GUIApp example, just borrowed here because we needed to validate that our graphical apps are building on all platforms. More CTest for CI/CD would be good here, but how?

modules:

stoneydsp_core

The beginning of what will be the centralized parts of our library; version numbers, crucial namespaces and typedesfs, linkage and include requirements, and so forth.

stoneydsp_audio

The beginning of a vanilla audio module, which will hold lots of audio utility classes - which may be derived from in other modules and classes, if desired, to create flavours non-vanilla.

stoneydsp_graphics

The beginnings of a module to hold some grahical utilities, helpers, and quirky ideas.