FX Rack proposition

[abscisys]

Proposition of FX Rack providing a new set of Audio FX:

• Tube saturation simulator
• Chorus Adding chorus FX #77
• Flanger
• Orbitone ( = Ensemble)
• Phaser
• Delay Adding delay FX #78
• Shimmer Reverb

All parameters are global and saved as Performance data

[probonopd]

Very exciting @abscisys. And great remarks @BobanSpasic.
A build for testing is available at MiniDexed_2023-01-05-d72e204. Let's play with it a bit.

Since I am not an audio pro myself, I had to look this up:

Source: https://cecm.indiana.edu/361/rsn-sendeffects.html

[probonopd]

@abscisys, during testing the following questions came up:

• Which RPi models did you test this on, and with which kind of audio output? On a RPI 3 with i2s DAC, I get lots of noise, distortion, and what seems like audio clipping. I tested this in the default configuration, without changing any parameters. Can you reproduce this? Switching off FXChain makes the noise, distortion, and clipping go away
• Are FXChain settings saved in performance.ini?
• Reverb should be "just another" effect, not a separate menu entry

[BobanSpasic]

@probonopd
Insert effects would be ideal, but that would need an extreme amount of processing power from the RPi.
You need a separate instance of every insertion. Every instance with its own settings. If you decide to have two FX slots for every TG, you need 16 instances of the various effects.

Using Send effects needs less power. If you decide to have 2 Global FX slots in MiniDexed (where you can select any of the effects from the palette and put it in a slot) and just two FXSends for every TG - it is less complicated, and you need just two effect instances.
In the code, FXSend need to be before any Volume attenuation (per TG). That way, you can have dry-only, and wet-only signals.

As I can see in @abscisys repository/fork, he is already working on another implementation. Let's wait a bit and see what goes up there.

[abscisys]

@abscisys, during testing the following questions came up:

• Which RPi models did you test this on, and with which kind of audio output? On a RPI 3 with i2s DAC, I get lots of noise, distortion, and what seems like audio clipping. I tested this in the default configuration, without changing any parameters. Can you reproduce this? Switching off FXChain makes the noise, distortion, and clipping go away
• Are FXChain settings saved in performance.ini?
• Reverb should be "just another" effect, not a separate menu entry

@probonopd happy to answer:

• I used RPI4b which is the only model I have unfortunately. I should buy a 3 but they are even more expensive than 4 are nowadays! I quickly recorded a short audio under Cubase with different FX activated that I post here (the sound is pure from Minidexed -> no additional effect applied except the DAC from my Steinberg UR44 soundcard). If you listen you'll hear (Preset 1=Brass 1 with the plate reverb deactivated and with the following FX arrangement (as you can hear I am not a performer. link to the audio file: https://drive.google.com/file/d/1-r0dvei2NfwFTlTkjIudeUeTQ-BgpHL-/view?usp=sharing)
  • Dry
  • Shimmer Reverb
  • Tube > Shimmer Reverb
  • Orbitone > Shimmer Reverb
  • Tube > Chorus > Delay
• Yes FX params are loaded & saved as part of the PerformanceConfig.
• I fully agree, I just wanted to avoid to be too much impactful as all the FX follow the same structure
  
  However I have just completed the migration of the AudioEffectPlateReverb so it implements the reset and processSample methods while keeping the doReverb one so it enables the following design (I am almost almost done the audio part, the UI integration is a pain)
  

[abscisys]

Send need to be before any Volume attenuation (

@BobanSpasic the design I propose allows:

• to send a part of the signal to each indivual FX in parallel
• each FX returns and can send a part of the return to another FX (except it self)
• all TGs and FX return can send part of the signal to the main output

I implement a Dry FX that is the actual MainOutput and that allows to have a pretty simple code for processing this logic of course there will be 1 sample delay between the TG inputs and the FX returns:

template<size_t nb_inputs>
void MixingConsole<nb_inputs>::process(float32_t& outL, float32_t& outR)
{
    float32_t fx_inputs_[Ouputs::kNbFX][StereoChannels::kNumChannels];
    float32_t fx_outputs_[Ouputs::kNbFX][StereoChannels::kNumChannels];

    for(size_t i = 0; i < Ouputs::kNbFX; ++i)
    {
        // Compute the samples that will feed the Ouputs and process Ouputs
        fx_inputs_[i][StereoChannels::Left ] = arm_weighted_sum_f32(this->inputs_[StereoChannels::Left ], this->levels_[i], nb_inputs + Ouputs::kNbFX - 1);
        fx_inputs_[i][StereoChannels::Right] = arm_weighted_sum_f32(this->inputs_[StereoChannels::Right], this->levels_[i], nb_inputs + Ouputs::kNbFX - 1);

        // Process the FX
        this->fx_[i]->processSample(
            fx_inputs_[i][StereoChannels::Left],
            fx_inputs_[i][StereoChannels::Right],
            fx_outputs_[i][StereoChannels::Left],
            fx_outputs_[i][StereoChannels::Right]
        );

        if(i != Ouputs::MainOutput)
        {
            // Feedback the resulting samples except for the main output
            this->setReturnSample(
                static_cast<Ouputs>(i), 
                fx_outputs_[i][StereoChannels::Left],
                fx_outputs_[i][StereoChannels::Right]
            );
        }
    }

    // Return this main output sample
    outL = fx_inputs_[Ouputs::MainOutput][StereoChannels::Left];
    outR = fx_inputs_[Ouputs::MainOutput][StereoChannels::Right];
}

[abscisys]

@probonopd I forgot to mention that my RPI4 is equiped with the RaspiAudio+ v2 interface https://raspiaudio.com/produit/audio

May I ask you how you debug on RPI? Do you have a mean to attach a debugger? Did you manage to virtualize the RPI with Qemu for instance. My attempts do not let boot the VM. I try to pass most of the code through valgrind to chase memory leaks.

[BobanSpasic]

Man, that is a lot of sliders.
Each TG has 9 FXSends (incl. Dry output). Each FX has 8 ReturnSends. Every FX is active the whole time.
How does this impact the CPU? Does the polyphony for the TGs on the same RPI core suffers?

[BobanSpasic]

https://drive.google.com/file/d/1-r0dvei2NfwFTlTkjIudeUeTQ-BgpHL-/view?usp=sharing
  
  Dry
  Shimmer Reverb
  Tube > Shimmer Reverb
  Orbitone > Shimmer Reverb
  Tube > Chorus > Delay

This is evil, pure evil, buhahahaha
I love it 🥇

[Banana71]

Very impressive what you @abscisys have created here 🥇 , it takes the project another step forward.

I tested version MiniDexed_2023-01-07-000daae and noticed the following things:

• The switch-on pulse from the FX Rack is quite loud. Or is the resulting tinnitus a deliberate effect. :-)
• Performances in which the FX Rack parameters are missing should have the effects disabled.
• The Shimer FX only works on the left audio output.
• Delay FX only works on the right audio output.
• The Chorus FX produces some crackling. The FX probably needs too much computing power!?
• Tube FX: The setting on the overdrive only makes the effect loud but otherwise has no effect.
• PhasR, FlangR and Orb works fine.

The use of these effects brings a clear added value. For example Strings with Phaser FX or E.Piano's with phaser and overdrive are excellent.

It is my joy

On my Raspberry Pi 2 Model B I mostly had a "BitCrusher" Effect :-(

[abscisys]

Thanks @Banana71 !
There are few optimization opportunities that I am looking. Almost done but it will have to wait for the week end I am afraid. The problem I have is that I only have a RPI4b to test and the current version without an audio crack. I agree that there are level differences depending on the FX.

You right about the phaser effects (2 to 24 stages) on ep or strings renders quite nice sounds but my taste goes to the orbitone and the shimmer like reverb.

[probonopd]

Hi @rsta2, asking for your advice: We have a great contribution here which greatly increases the value of MiniDexed; however the author only has access to a RPi 4. On that model it is working nicely but not on other models. Hence we would like to find out:

• Is this PR indeed requiring so much computational power that it is not possible to use this on lower models?
• Or do we need to do something to utilize the different cores more evenly?
  How could we go about testing/experimenting/debugging this?

(RPi 1 and 0 are out of the equation, they certainly don't have enough horsepower, which is OK. We are not offering effects on those models.)

[probonopd]

Closing in favor of

• Fx3 beta1 #499