this doesn’t need to be hard - also imho not necessarily unrelated to the thread. it has been at the back of our minds for a while.
at present the AUX and INS effect parameters are hardcoded into multiple layers of the norns ecosystem. so it would be easy to add a light abstraction layer to the processing, and switch out different DSP implementations using the same parameter sets.
the compressor and reverb algos are basically off-the-shelf Faust programs, so if people wanted to use Faust to roll their own implementations then that is trivial to provide a general Faust build script, and a means of switching between any number of static instances of AuxEffectChain and InsertEffectChain or whatever. (i suppose we could even make all the parameters work with abstract unit ranges, or something.) (same applies of course if people want to implement algos in C/C++.)
on the other hand, allowing crone to instance arbitrary FX chains with arbitrary parameters, is a different proposition. still doesn’t need to be very hard on the crone side - a simple stereo chain is easy to manage, and the OSC/IPC interface [*] can be dynamically regenerated without too much trouble.
but requiring dynamic parameter management means that these arbitrary AUX and INS chains start to look exactly like engines. and in that case i suppose i would simply implement them as such - two additional “engine slots” that take the aux and output busses as their inputs, instead of the ADC bus, but otherwise function identically to other engines in 3.0 proposal: correspond to arbitrary DSP processes and present their parameter metadata as lua files. doesn’t matter if they are supercollider patches, pd patches, mod-host instances, or something else.
[*] side note: i’ve been meaning to replace OSC as the matron -> crone IPC layer, for many reasons. assuming this can get done, the resulting efficiency improvement might be an argument for keeping the effect chain DSP within the crone process.
