Refactor effect superknob linking

[mixxxbot]

Reported by: daschuer
Date: 2014-03-28T07:07:16Z
Status: Fix Released
Importance: Low
Launchpad Issue: lp1298813
Tags: effects

---

This bug is to continue the discussion at
#207

rryan:
Ah, can't we call setParameter(chainParameter) now instead of this log vs. linear logic?

rryan:
Ah, now I see. To get rid of this logic the superknob parameter linking should flow from EffectChainSlot -> EffectSlot -> EffectParameterSlot -> value CO instead of from EffectChainSlot -> EffectChain -> Effect -> EffectParameter::onChainParameterChanged(...).

[mixxxbot]

Commented by: daschuer
Date: 2014-03-28T07:54:42Z

---

To be honest, I have not managed to get the new signal and control flow entirely.
A drawing will be really helpful here Bug #⁠1298817

But as far es I get, I got the impression that there is still something weak.
So we should tweak the super knob a little bit.

Controlling two parameter with the superknob feels wrong, because for the desired effect you need a special, probably different scale for the controlled parameters. This is a desired feature, but lets move it to 2.0 to keep things simple.

Idea: (maybe some things are already in place)

SuperKnob:

• One SuperKnob for the each EffectUnit. This is connected to the first parameter of the fist Effect in the Chain.
• Once you work with two effects in a chain, the superknob moves (is focussed) on the last enabled effect
• Add a read only "superknob_focus" CO to reflect this in the GUI
• the superknop linking should be moved one layer up and actually use "setParameter()" of the parameter CO
• For use cases with two or more parameter knobs per effect unit we map the knops in consecutive order to the first parameter of each effects in the effect chain.
• When defining the effect, it is possible to setup an an artificial parameter as first one. In case of the bitchrusher, we may introduce a "LowFi" control, which acts on the bit_dephs and downsampling parameter, in a way that it sounds as desired.

D/W:

• replace the "Mix" control with a "D/W" control on the EffectUnit Layer. Full Stop.
• If a Effect like delay, needs a own "Mix" control to be an end effect "echo" in this case, it should be introduced inside the effect as normal parameter. Preferred: Parameter 2". We may add it in general to all Effects, but introduce correct labeled as "D/W" for Insert effects or "Level" for Send effects.

http://www.reasonexperts.com/video-tutorials/getting-started-with-reason/Send-effects-vs-Insert-Effects.html

Link to the original PL #180

This concept can resist even if we introduce 2.0. We only need a Wrapping effect for external VST effect. Which introduces the probably missing Parameter1 and Parameter2 for configurable Superknob mapping with desired scales and "Mix" control.

[mixxxbot]

Commented by: rryan
Date: 2014-03-28T14:51:40Z

---

Hi Daniel -- the whole idea behind the superknob is effect parameter linking and this terminology is also found in other software.

I think what you are proposing is virtual parameters or a built-in feature for focus selection with a MIDI Controller. I think that's a separate use case from superknobs.

It will be confusing if we claim something is a superknob and really it's something else.

Focus for MIDI controllers is a problem we face in multiple areas so we should come up with a common solution.

Also, I think I lost you once you started talking about dry/wet. It also sounds like a different bug than this one. Can you clarify what you mean there?

RE: per-effect D/W. Dry/wet calculation is expensive and prevents in-place processing of the buffers. If we really need d/w per effect then it should default to wet. I'm not convinced we need it though. Again this is a separate bug though -- please file?

[mixxxbot]

Commented by: rryan
Date: 2014-03-28T15:27:32Z

---

Fix is here:
aecd024

Much better!

[mixxxbot]

Commented by: daschuer
Date: 2014-03-28T20:52:27Z

---

I have created Bug #⁠1299215 for the remaining issue

[mixxxbot]

Commented by: daschuer
Date: 2014-03-28T21:52:32Z

---

Also, I think I lost you once you started talking about dry/wet. It also sounds like a different bug than this one. Can you clarify what you mean

Wasn't there a version where the insert type was set from the effect? Just read the Insert code again and it is fine like it is. Sorry.

[mixxxbot]

Issue closed with status Fix Released.