jd-13 / we-core Goto Github PK

This feature is pretty common now on many plugins. Some of the changes will be in the plugins themselves rather than core, but this issue can track the investigation and common changes.

Most of the changes may be required in the plugins rather than core, but this issue will be used to track the investigation and any common changes across multiple plugins.

Create an abstract class EffectsProcessor (or a better name) which provides abstract member function signatures for basic processing.

The mid-side processing in MONSTRBand can then be moved out, and MONSTRBand made to accept any EffectsProcessor.

All other effects should also be refactored to use this API.

The class should be restructured so that it can contain a variable number of bands rather than the fixed 3 bands it currently has.

This issue is to track double precision support across plugins:
jd-13/Richter-Tremolo#6
jd-13/MONSTR-Stereo-Imaging#13
jd-13/Songbird-Formant-Filter#5
jd-13/Carve-Distortion#15

Currently it appears only VST2/VST3 supports double precision, this doesn't seem to be a particularly important feature right now.

https://forum.juce.com/t/audio-plugins-64-bit-processing-double-precision-dsp-in-audiounits/28173/5

This test fails on VST3 for all plugins, passes on Audiounit

The modulation source is currently only checked once per buffer, this should be checked for each sample to reduce artefacts.

I've found that this library is a little less performant that the TPTSVFilter and potential the new JUCE filters, so the possibility of reducing the usage of this library should be investigated.

Add functionality so that plugins can check for (but not download) updates.

The basis for this has already been added, but needs to be thoroughly tested.

Carve currently has the poorest coverage of all the modules. This should be improved to over 90%.

The method CoreAudioProcessor::registerParameter() requires a setter be specified for each parameter. For most plugins this setter just uses setParameterValueInternal() to set the parameter value, so this could be defaulted.

MONSTR is currently the only plugin which requires the ability to override this setter.

Hello,

on GCC11, WE-Core 0.2.0 does not compile properly because of some instances of this error:

error: 'size_t' has not been declared

This I think happens because GCC11 explicitly requires #include <cstddef> in order to use size_t.

You can view the full build log here. Thank you!

Fast changes for certain parameters sometimes causes an audible click, usually on volume or gain controls. Theoretically affects all plugins but is only noticable on a handful of parameters.

The plugins have not been build for some time it seems:

$ ldd ~/.vst/Songbird.so | grep "not found"
	libidn.so.11 => not found
	libgcrypt.so.11 => not found
	librtmp.so.0 => not found
 $ ldd ~/.vst/Carve.so | grep "not found"
	libidn.so.11 => not found
	libgcrypt.so.11 => not found
	librtmp.so.0 => not found

I have:

/usr/lib64/libidn.so.12.6.0
/usr/lib64/libgcrypt.so.20.2.5
/usr/lib64/librtmp.so.1

I have cloned the git modules, but there are no Makefiles and no instructions to build them.

Tests should be stored in a sub directory of the components that they relate to rather than in all in one central location. This will make them easier to manage as new ones are added.

Currently various classes which perform processing implicitly rely on their associated parameter objects to enforce parameter limits and set defaults.

There is no way for a user of one of these processing classes to change the defaults or the limits, it should be made possible for the user to pass a parameter object to the constructor of a processing class which the object then uses, otherwise default to the one it already has defined in its namespace.