Fx by @jnonis

[probonopd]

Do not merge this PR. We need a PR against master that has no conflicts.

Looks like @jnonis has done a great job with effects. Unfortunately it was not opened as a pull request back then and our code has deviated since, to his changes don't cleanly apply to master. Hence, applying them against an old baseline to get builds for testing in this PR.

This has:

• A Juno style chorus (Chorus I, Chorus II,...)
• Delay
• LP Filter
• DS1
• Big Muff
• TalRvrb3
• Reverb
• MVerb
• 3Band EQ
• Phaser
• A Phaser
• Flanger
• Saving effects in performance files (@banana71 might like this)

Aapparently one effect can be active at a time for each TG ("insert effect") and one global ("send effect").

Every TG also has MIDI effects, currently a simple "Arp". It also has a new global "Tempo" option, which is used by the Arp.

[github-actions[bot]]

Build for testing: MiniDexed_2024-11-17-062671a Use at your own risk.

[probonopd]

@diyelectromusic maybe you'd like to have a look at this?

[diyelectromusic]

@diyelectromusic maybe you'd like to have a look at this?

I'm not sure what you want me to say. That is an awful lot of code changes with implications it is almost impossible to anticipate.

Considering how many times in the past you've resisted some of my changes on the basis of not making the code too complex, seeing this and all the network additions - well, to be honest, I just think they will make the codebase significant less maintainable than it already is - and maintaining it as it is right now is already pretty tough.

Will these people be responsible for maintaining these huge changes if accepted? There is certainly no way I can get my head around the code that is being proposed and it is almost impossible to anticipate the impact on the real-time performance of the system across all Pis with so much additional processing being added as part of the run-time scheduling itself.

In short, I'm afraid I just don't know where to start thinking about the ramifications of all this new code...

Kevin

[jnonis]

Hi, I've started that branch trying to add a chorus and a delay effects to Minidexed, but then I tried to port other LV2 effects and make them to load dynamically. My main testing platform is Raspberry Pi Zero 2w so I think it should worked fine in RPi 3, 4 and 5. I've also enabled these effects for only one TG in an original Raspberry Pi model B and it works fine using the chorus and the massive TAL reverb 3. If you have some stress test that I can use to check performance, like a particular patch or midi file, let me know. The only effect that is given some problems is the MVerb port.

Now the FXs and Mix structure looks like this:

But I'm planing to change it to something like this:

I think the main issue with the current base code is related with the 8 output support, because the insert FXs are stereo, if I change the insert FXs to be Mono I guess all the changes will fit.

[probonopd]

Hi @jnonis welcome to MiniDexed. I tried your branch and I really like it. And to address @diyelectromusic's concerns, we need to

• Make it possible via an option in minidexed.ini to entirely disable the FX feature, so that the signal chain stays unchanged when disabled (needed for testing and debugging)
• Heavily stress test it on various Pi models (I don't have a systematic MIDI file for this yet but really anything with fast-playing notes and heavy polyphony should do)

Thanks for the diagrams, these are really helpful. One could think that the insert FX should be mono since the TGs are mono. But don't some FX take mono as an input and produce audible stereo on the output? Or would you move all such FX to chain FX?

Maybe another option would be to just disable FX altogether when an 8 outputs configuration is detected. My assumption is that the (likely very small) user group who uses 8 outputs is clearly doing so in order to do further postprocessing outside of MiniDexed, and hence probably is not interested in built-in FX. So personally I'd not worry about this use case in the context of FX. @diyelectromusic what do you think?

My line of thinking is that if I have 2 instruments, say E. Piano and Bass, and I want to have a (stereo) chorus on only one of them (E. Piano but not Bass). Isn't that a typical application?

I know that some of our users really like the idea of sends, but I am unsure how this is done for chain FX without overboarding complexity and on the low-spec CPUs we are dealing with.

And wouldn't the Arp typically come after the seq/loop?

All of this is not exactly my area of expertise. Maybe @Banana71 would like to add to this discussion?

[diyelectromusic]

Maybe another option would be to just disable FX altogether when an 8 outputs configuration is detected. My assumption is that the (likely very small) user group who uses 8 outputs is clearly doing so in order to do further postprocessing outside of MiniDexed, and hence probably is not interested in built-in FX. So personally I'd not worry about this use case in the context of FX. @diyelectromusic what do you think?

That is essentially the assumption when I implemented it - yes. IIRC if 8-output mode is selected then all the existing stereo, pan, FX processing is skipped, so I'd say do the same here - basically just add to what is already there fx wise and not worry about 8-ch output.

Kevin

[Banana71]

Build for testing: MiniDexed_2024-11-17-062671a Use at your own risk.

My Raspberry Pi 4 doesn't work at all. The display remains dark and no sound is produced. Since I can't easily access my HDMI port, I can't see the log. When I find time, I'll try a different Raspberry Pi.