-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor - StoneyDSP Library #69
Comments
On reflection (been a while), I know that the existing OS implementation is quite hacky; It is not a requirement for the base DSP to work, but rather an extension that further demonstrates some points made in the analysis/write up. Since both open issues are related to the OS implementation, and it is this implementation which is holding back progress somewhat, I've moved that implementation over to a backup branch for visitors to continue referencing, and have updated the main branch to reflect the other latest changes - because I wanted to get multi-platform CI/CD off the ground, above and beyond just oversampling on a Windows-only plugin. I will "circle back" around to the oversampling at a slightly later date - readers, if curious about this, please check the backup branch for the meantime. |
I have merged a v1.2.0 which rolls back the GUI and the oversampling, in favour of multi-platform builds validated with Tracktion Pluginval via CTest, over GitHub Actions. Now, this project can be deployed for all platorms. However, in the context of this ticket, I consider only half of the work to be complete: I moved some of the codebase into the StoneyDSP library modules, which are currently still local to the project - these should obviously be centralized, perhaps delivered over a CDN or package manager, sourced from the StoneyDSP library repo - and much of the implementation is still sitting in the Biquads unit files. Ideally, those unit files (i.ie., everything under It may be possible to do some kind of aliasing, like In regards to this Biquads implementation, I have moved the atomic coefficient object and a general Biquads class (not used - just for reference for the moment) into the In continuation, I would ideally like to have the transforms be placed into the The various distinct pieces would be filed under The namespace StoneyDSP {
namespace Biquads {
using AudioPluginAudioProcessor = Biquads;
}
} ...before it includes the other unit files. Then, the I am not sure how well this might work, but I will investigate it while continuing with this task. Still to be done, then:
With the above complete, and the "genericizing" of the project files a secondary goal, I will re-evaluate the status of this ticket. |
EDIT: I guess I'm sort-of thinking about trying a PIMPL-like way of connecting a predefined set of interfaces using a compile-time variable... |
This concludes on half of the refactoring task at hand - the moving of our class from outside of the project files, and into an external library/module. The other half which still persists, is to now move
I've been making improvements to the audio processor structure while de-coupling the DSP from it. I have realized some redundant areas in the previous design and removed/refactored quite a lot of that away already, but I'm not totally happy with a few of the design decisions with regards to ownership, and initialization. Which class owns which, and then which class initializes which? I've de-tangled several looping idioms in the constructors that started to look very dodgy when looking at them a bit closer. However, I've done only about half of the work involved in what I've discovered along those lines. (currently I'm quite unhappy about all the un-managed pointers to the main Audio Processor class being passed in to initialize-construct it's own members... in some cases, quite redundandtly...) I am thinking that the APVTS and the entire parameter layout should all be defined and looked after in our Parameters unit, which may pass a couple of methods to the Audio Processor which instantiates it, allowing the Audio Processor to access the APVTS (and vice versa), while providing a level of indirection between our parameter pointers and the audio processor class. The parameters class/object can then also be made accessible to the audio processor wrapper, where the parameter values can be exchanged atomically with the audio-thread class instances. It will be necessary to consider carefully how this is done, as we can potentially reduce complexity quite a bit by simply considering the chain of dependencies between each of these class objects, and which shall need to be defined first. It should not be at all necessary to pass multiple un-managed Regarding the Biquads Audio Processor: There are sketchy aspects of this design which I think are valid concerns, not least because this was my first ever serious coding project and I'd held on to lots of things I'd learned at the time, but probably misunderstood, or over-used, or can now think of solutions which are more aligned to the way I have done things elsewhere within the codebase and/or want to pursue as I move forward. Regarding the Biquads DSP: It is very hard for me to validate the Biquads class as a whole, from top to bottom, even using unit tests and a debugger. The data structure is much too large and it's members too inter-related. I aim to continue refactoring the DSP such that the coefficient calculations will become a set of namespaced math functions, templated, and that the blinear transformations will be something like a DSP class, defined seperately. Ideally, both shall hold and manage array-based containers of coefficients (instead of unique declarations per coefficient), and the Biquads DSP class will define a method which passes the calculated coefficient array to the bilinear transform array, possibly atomically. Looking at both concerns above, what actually happens is, the Biquads Audio Processor is defined here in the Biquads project, and so those concerns will remain associated with this project; if I am not finished with that part of the work by the time I have vcpkg (or something else) serving and fetching our modules from the library, then I will make future epics here in this repo for fulfilling those tasks. The concerns relating to the DSP library shall not really be applicable to the management this repository - even if this is where we discover them, and figure out how to fix them. Instead, since the DSP library shall be fetched remotely from the StoneyDSP project, those concerns shall become epics and issues over on the StoneyDSP repository, instead. I am also looking at the potential idea of having each StoneyDSP module exist as a submodule, such that the StoneyDSP org holds the StoneyDSP repo, plus a repo each for In either case, I find the most interesting element in the work to be the nature of the provider/consumer relationship in this coding project. As I de-couple the DSP from the plugin files, I will need to be mindful not to break the interface that I have defined for the Biquads class, including as I dive deeper into de-coupling parts of the DSP from itself internally. This Biquads project, being the consumer, must not be broken by upstream changes in the StoneyDSP library. |
The existing implementation is still a little messy; previous attempts at improving things within the codebase have lead to some complexity that is probably not necessary, given that the project is mostly just academic in nature.
Moreover, I've gotten to grips with making API's and modules with C++ and CMake in graceful ways that should now allow me to build my own library/extension for JUCE.
My intention therefore is to begin parting out the relevant source code for modularisation. This is already somewhat considered in some of the design aspects of the C++ used code, but there is currently no larger library or framework supplying these files to (potential) consumers.
The C++ module code shall be supported by a possibly optional CMake API, designed to provide consumers with easy CMake targets to link with in their projects, allowing them to easily pull in the C++ modules from various sources such as vcpkg, or even have system installations of the library, with which to build.
Furthermore, the proposed work would also allow some scope for the creation, development, and testing of a custom vcpkg registry from which the modules could be supplied.
Ideally, this external project should be able to do a CMake
find_package(StoneyDSP 1.0.0 CONFIG REQUIRED)
and then atarget_link_libraries(Biquads PRIVATE stoneydsp::stoneydsp_audio stoneydsp::stoneydsp_graphics)
, and then only require the standardProcessBlock()
andMainComponent
from the JUCE audio plugin template.I have begun work on the library itself, and will be using this project as a test/example of the library.
The text was updated successfully, but these errors were encountered: