nathanjhood / orfanidisbiquad Goto Github PK

The entire calculation and conversion of GUI parameters -> Processor parameters is very poorly coded, being taken almost line for line from a Matlab library (link in Readme credits).

Issues:

• Very heavy amount of memory allocations
• Indeterminate initialization order of the above
• Near impossible to debug any numbers due to long strings of calculations in places...
• Order of operations not respected at all (for seemingly any platform) in original codebase. Output is correct, at least!

Suggestions:

• Re-create the parameter calculations in another workbench with easier/instantaneous debugging capabilities to validate the actual order of operations
• Once the above is known, the various calculations may be broken out into separate functions and methods (for example; "DCBA()", "Numerator()", "Denominator()" etc...)
• Calculations which are repeated very often (for example, "abs(a/b)") may also be split into small functions that simply return the input value with the algorithm applied, thus saving memory allocations in doing so (keep in mind that "return" may make a copy, research needed)
• Once all of the above is in place and the filter is operating correctly (i.e., the same behaviour as v1.0.3b), the operational numbers can be observed closer with a view to breaking down how the calculations are applied, and further filter types might be possible branching off from here.

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 a target_link_libraries(Biquads PRIVATE stoneydsp::stoneydsp_audio stoneydsp::stoneydsp_graphics), and then only require the standard ProcessBlock() and MainComponent 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.