Make the effect On button be a input on/off button

[Ferran Pujol]

Right now when I turn an effect off, the signal goes straight to dry. Instead, we could make the On/Off button control whether the effect receives input or not. This way, when turning a delay off, the effect would fade out nicely for a short time.

This has the side benefit that we could remove the extra send knob in the delay effect :)

Traktor takes this approach.

[Daniel Schürmann (daschuer)]

This might be hard since the user might want to control when the effect consumes CPU.
Which such a approach the effect will always require CPU, unless it is able to reside to switch of itself.

Traktor should have the same issue, how it is solved there?

I am also struggling with our Mix (D/W) Knob. It is useless for many effects, but consumes always screen.
Maybe we have to rethink it and replace it with something more usable.

[Ferran Pujol (ferranpujol)]

I have no idea how Traktor handles this, but we could just monitor the effect volume and stop the processing once it is below some threshold.

Well, our effects are weak right now. Once we got powerful effects we will surely need the D/W to tame them.

[Be (be.ing)]

> Which such a approach the effect will always require CPU, unless it is able to reside to switch of itself.

What would be a use case for keeping an effect enabled if the user doesn't want to use it in that moment?

[Daniel Schürmann (daschuer)]

This an issue about the "settled" state of an effect. If an effect deals with infinity, it needs infinity samples to be settled and produce the desired sound. When switching off. It will produce infinity samples after it is switching off.

The EQ filters are such effects. We have also this issue when changing parameters like in https://bugs.launchpad.net/mixxx/+bug/1486863
A solution is to fade new the effect signal into the old signal once the effect is almost settled.
For the EQs I use just on callback buffer for this fade.

[Owen Williams (ywwg)]

In many cases I think Daniel's suggestion is ok, waiting for a settled case and then disabling. However, some effects, like a distortion processor, produce sound even with no input -- there's a constant hum of the distorter being active. It has to be up to the user to fade from wet to dry themselves and disable it manually.

In general toggling the on/off state of the effect should instantly disable processing of the effect. But turning the effect off for a particular channel should keep processing the effect, but just cut the input completely. This doesn't solve the question of the distort effect, though, because by this logic either all channels always have the distortion hum if that effect is enabled.

This leads me to conclude that the effect-enabled buttons in the skins should be three-state: process both input and output, process output only (mute input), and off. Click the button once turns it on, clicking it again cuts input but keeps output going, and clicking again disables it for that channel. I think that covers all the use cases and then we don't need to code a possibly-flaky "settling" algorithm.

[Daniel Schürmann (daschuer)]

Once an effect produces sound independent from the input signal it can safely be stopped and continued afterwards. So here is no settling issue. There might be only an settling issue issue for the first start if there are internal filter need to setup.

From the technical point of view a three state button will work, but I am afraid a three state button will not fit to the way people are using effects and it might be hard to visualize the third state with a single LED.

[Ferran Pujol (ferranpujol)]

I think two buttons is way better than a three state one: one button to open/close input signal and another one to enable/disable the output processing (effect on/off). This way we can add the input on/off button as an effect parameter only to those effects for which it makes sense (e.g. it makes sense in a reverb, but for a bitcrusher there's no difference between closing the input or the output).

Another idea: what if we make something similar to release effects in pioneer rmx devices? Users have several ways to disable the effect:
-Cut: simply stop processing the effect, what Mixxx does now.
-Spinach
-Echo / reverb
-Whatever...

This would work by disabling the effect unit but enabling an internal effect unit for a predetermined amount of time.

[Owen Williams (ywwg)]

Daniel I don't understand what you are saying. When input is cut off, an echo will continue to produce sound momentarily because it is echoing, and a distort will continue to produce sound indefinitely because it has a driver. How can something be both stopped and continued?

As for adding buttons, the trick is making everything work with controllers to which we can't just add buttons.

And, spinach?

[Ferran Pujol (ferranpujol)]

Spinback*

If the on/off button is for the input signal as proposed, the user can:
-Let the effect gently fade-out by toggling the effect off.
-Completly cut the effect by setting dry/wet to 0.

This is what Traktor does. I think this is more convenient than the three state button, which I think will confuse users.

[Daniel Schürmann (daschuer)]

Yes, right, those effects can't be stopped and continued because their sounds are not independent form the input.

@Ferran: How does the user decide what happens if he disables an effect on the pioneer RMX?
How is an effect disabled if he presses an effect button on the disc again?

[Ferran Pujol (ferranpujol)]

A three state switch. I'm not sure what happens when an effect is switched I don't own any.

Anyway, release effects is a complex feature. Let me focus on the specific request of this bug.

We could let the user either

1) turn off the effect completely (cut the output)

Or

2) cut the effect input signal and let the fx continue generating output. Mixxx monitors the effect output level and turns de effect off automatically when it is inaudible. If the effect output levels don't decrease enough after a certain amount of time, then Mixxx automatically performs a fade out and turns the effect off afterwards.

How to map this to the UI (after some thought, Owen's idea was not that bad! My apologies): just one button
Use it to enable the effect, the button lits.
Left click it to turn the effect off as described in 1), the button indicator turns off.
Right click it to turn off the effect as described in 2), while the effect still has audible output the button blinks.

For controllers we just need to map 2) to the controller fx on/off button with a shift modifier.

Do you like this approach?

[Daniel Schürmann (daschuer)]

I have found a hint that shows how Pioneer thinks about it:
http://djtechtools.com/2015/07/08/creative-tips-for-pioneer-fx-spiral-effect/

"
The effect on/off button is your release button – use it when you want to release the effect and let the spiral fade out. This sounds way better than just turning down the dry/wet knob.
"

So it looks like Ferran's right click proposal heads in a good direction. I would suggest to put the new "input_enabled" (2) on the left button since it looks like this is the industrial standard.
Cutting the output (the current "enabled" control) can goto the right.

For the technical implementation we have to consider 3 different enable controls, that can be all used on the controllers and are already used on the skins and are mappable for the different effect layouts on controllers:
* [EffectRack1_EffectUnit1], enabled
* [EffectRackX_EffectUnitX_EffectX], enabled
* [EffectRackX_EffectUnitX], group_[XXX]_enable

Which one needs the fade out feature? It looks like all of them because all are
The new control can be named like "input_enabled" once it is pressed, it enables the normal "enabled" control as well.
If it is disabled, it actually only disables the input, while the effect is still processed and may produce output samples.

The blinking indicator for the idle state will work for me. For this, we need a new "enabled_indicator" control.

A silence detection for each effect in Mixxx will take also an amount of CPU and it is hard to do it "Right" without knowing the effect (I think of external LV2 effects). So maybe a cooperative approach works better. Mixxx can tell the effect that its input is disabled and the effect can decide what to do.

The extra CPU for an idling effect might be no issue, since the user has used the effect before and there was enough CPU.
So in most cases there is still enough CPU. If that is an issue, the user can still disable processing by right click.

The user is also able to re-map the controller back to the current behavior.

What do you think? Will this work?

[Ferran Pujol (ferranpujol)]

Looks good to me.

We still need a timeout to progressively turn the effect output off, just in case an effect ignores the "your input is off" signal Mixxx sends to it. This is also needed for external effects for which Mixxx can't send such a signal.

[Daniel Schürmann (daschuer)]

An extreme example that not work, is an loop or ambient effect, that feet by ab input signal and then cycles infinity time. To allow this, the auto fade out schould be configurable.

Is this worth to have a configuration option, or could we just rely on the user that he disables the "blinking" button. Manually?

[Owen Williams (ywwg)]

I think we're converging on a good design. Maybe we can have a per-effect boolean flag that determines how it is cut -- something like a reverb can be "until mostly silent for 1 second" and a distort can be "absolute fadeout period".

I'm *extremely* reluctant to add yet another preference for this. Let's start by hardcoding something simple, like 4 beats / 3 seconds, and test. If the default fadeout time is not desirable, a user can just use the dry/wet knob instead. For now let's do this without any new preferences.

[Ferran Pujol (ferranpujol)]

I agree, I would hardcode a long fadeout time and let the user use dry/wet to shorten it. (Keep in mind not every effect needs to take that long to fade out, it an upper bound)

Daniel's approach of sending a signal to the effect is better than just reading the effect's flag and cutting input and fading output. If we tell the effect it has to fade out, the effect can adjust itself to try to fade out on time, thus avoiding the hard fadeout. For example, an echo effect could automatically decrease it's feedback parameter if it is too high.

[Daniel Schürmann (daschuer)]

Why is there a strong reason that we need a hard coded fade out limit at all?

If, like in your example, a user set up an echo with a feedback value of 1 he probably knows what he is doing and he want have an echo to entreaty. Any automatic decreasing of the feedback after a hard coded time, will limit the use cases and might be an unwanted behavior.

The user can always right click to cut an never ending the effect or the effect can disable itself.

[Ferran Pujol (ferranpujol)]

If the user doesn't want the effect to fade out why does he/she turns the effect off in the first place?
The point of all this is to offer a way to turn an effect with an automatic gentle fade out. Either using the natural fade out of effects like echo (with feedback < 1) or by artificially lowering de output volume for effects that don't fade out by themselves.

[Ferran Pujol (ferranpujol)]

This made me think that we actually need the flag that Owen said. Because we have three types of effects:

1) For some effects we want to cut the input and let the effect naturally fade out (reverb)

2) For some other effects, we need to keep the input open and progressively lower the output volume (bitcrusher).

3) For some other effects we need to cut the input but also progressively lower the output (echo with feedback = 1).

Problem is this can't be a static flag, because echo can be of type 1) or 3) depending on the feedback parameter.

[Daniel Schürmann (daschuer)]

> If the user doesn't want the effect to fade out why does he/she turns the effect off in the first place?

Without any auto fade out the user has the full control, he can left click to disable the input and let the effect do what is should do without any input, or he can right click to stop the effect mediately. In case of echo, the user can also use the feedback knob and the dry/wet knob to control how the effect fades out.

For 1) this seams to be the default for implementation on competitor devices.

For 2) this is already possible with the dry/wet knob. Once the effect is fully dry, the user can right or left click the enable button.
For a bit crusher, the result will be the same since it has no internal buffer.

For 3) I understand the demand, but do not see how this will work without an additional preference option.
I cannot think about a way to predict the fade out behavior for any type of effect or use case.
It makes sense to add a preference or a parameter to set the fade out time individual.
The echo already has such an parameter (= feedback)

Has Traktor such a parameter?

How about postpone the decision, until we have merged the general "input_enabled" control and Nicus LV2 branch.
This way we have the chance to play with it before doing to much work.

[Ferran Pujol (ferranpujol)]

I understand your point. We could add a button for "input_enabled" to let users manually perform this actions if they prefer to do it themselves.

However, the automatic approach is a great feature IMHO. I see how we might need to offer a config option for each effect fade out time. Can this be placed in the effects section in preferences? Right now it only lists effects but no tweaking option is available.

[Owen Williams (ywwg)]

Before anyone goes to start coding, I must insist that they write up a design document describing the final design, including internal changes and planned external UI. We've talked about a ton of different approaches and I don't really know what to expect in a PR any more.

[Daniel Schürmann (daschuer)]

Yes, the "automatic" way will be finally the best way. A preference option for every effect will work for me.
This will also work for external effects, great!

I think we should also we should keep a single button with right and left click to keep th interface easy
The button may becomes then an "input_enabled" + a "start_fade_out" once the fade out parameter is set.

Do we actually need the to target the fade out for an effect like bit crusher, or can we rely on the dry/wet button?

[Ferran Pujol (ferranpujol)]

> Do we actually need the to target the fade out for an effect like bit crusher, or can we rely on the dry/wet button?

For me it is not important. But it might offer a more consistent user experience.

[Daniel Schürmann (daschuer)]

Ok, what will be the "right" name for the control object?

[Ferran Pujol (ferranpujol)]

I don't know, "Effect active"?
By the way, are you going to implement this soon? Otherwise I think we can postpone further discussion.
I might take this once I start my holidays.

[Owen Williams (ywwg)]

we can bikeshed control names in a design doc -- I suggest starting one in Google Drive and then sharing it with the mixxx-devel group.

[Daniel Schürmann (daschuer)]

Ok.

No, I have not planed to to implement this.
In any case, I would like to merge my jack branch and Nicos LV2 branch first.

[Ferran Pujol (ferranpujol)]

I can write the design document.

Daniel, what related changes do these branches introduce?

[Daniel Schürmann (daschuer)]

The jack branch is not related jet, but it will allow to route the deck stream to a jack effect and capture it by Aux.
For now there is no reason to adopt this "auto fading" to this approach, but it cant hurt to think about it.
Maybe there is a nice idea to improve it.

The LV2 branch will effect this discussion here, because it introduces "unknown effects of any kind"
You may watch the branch here: https://github.com/mixxxdj/mixxx/pull/359

[RJ Skerry-Ryan (rryan)]

Daniel do you have any details on your design to share?

It would be a bummer if we ended up with an effectively Linux-audio-expert
route to aux send/receive effects.

Is your design abstract enough to support multiple different transports?
For example, SoundFlower on OS X or Virtual Audio Cable on Windows?

This sounds like a potentially very complicated change to Mixxx and it
would be ideal if we could discuss the design first before you spend time
on it.

Thanks,
RJ

On Tue, May 3, 2016, 2:55 PM Daniel Schürmann <email address hidden>
wrote:

> The jack branch is not related jet, but it will allow to route the deck
> stream to a jack effect and capture it by Aux.
> For now there is no reason to adopt this "auto fading" to this approach,
> but it cant hurt to think about it.
> Maybe there is a nice idea to improve it.
>
> The LV2 branch will effect this discussion here, because it introduces
> "unknown effects of any kind"
> You may watch the branch here: https://github.com/mixxxdj/mixxx/pull/359
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1481170
>
> Title:
> Make the effect On button be a input on/off button
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1481170/+subscriptions
>

[Daniel Schürmann (daschuer)]

Hi RJ,
there are no design changes of the audio routing involved right now. I am working "only" on a native Jack integration.
The Hardware preference window will not change, but you will be able to edit the connections nicely using third party tools like QJackCtrl. It is mainly a fix for Bug #839562 and Bug #1172299
With some patience, you can already route the deck output to Jack and put it back via Aux.
This should be a no-brainer after the change.

[Be (be.ing)]

It seems clear from the prior discussion that there cannot be a good one-size-fits-all solution for every effect. I don't think any new COs (at least COs for skins and controllers to interact with) are necessary. Modify the current enabled/disabled COs to signal to the effect to do whatever it needs to do to turn off. Provide effects with an interface to cut off their input and output separately, and leave it to each effect to use these as appropriate when they get the signal to turn off.

[Daniel Schürmann (daschuer)]

Sounds good. Do you have already an idea how this new effect interface will look like?

[Be (be.ing)]

Hmm, actually it looks like that system is already in place through the const EffectProcessor::EnableState enableState argument to EffectProcessor::process(), but only the EQ, filter, and Moog filter effects make use of it currently.

[Be (be.ing)]

Reviewing the above discussion and thinking about this more, I think the original proposal to cut off input when the enable switch is turned off and stop processing when the output gets below a threshold is the best approach. Depending on each effect to implement its own way of shutting itself off cannot work for external effects, but this approach will. I don't think it's necessary for Mixxx to automatically fade out effects like the Bitcrusher that stop producing output when their input is cut off. Suddenly switching those kinds of effects on and off can be used in a musical way. If Mixxx automatically faded out such effects, there would need to be an additional parameter to control how long that takes, but the chain dry/wet knob can already serve that purpose.

I will implement this by moving the enable state onto the GroupFeatureState. For effects that would keep producing output indefinitely, it would be up to the effect to set the enable state to fully disabled from the intermediate disabling state.

Any approach that complicates the user experience with more COs or preference options is a non-starter for me.

[Be (be.ing)]

Ack, it doesn't look like moving the enable state onto GroupFeatureState will work without extensive refactoring. The enable state needs to persist across each engine callback, but a new GroupFeatureState is constructed for each engine callback.

[Be (be.ing)]

I'll add a private QMap to EngineEffect to store the enable state of each effect on each channel.

[Daniel Schürmann (daschuer)]

I am afraid the outlined solution will not work for any effect.
A extreme case is a Synthesizer effect that does not take any input. Like a Metronome click or something. We do not have them yet, but we should be prepared.

See also https://bugs.launchpad.net/mixxx/+bug/1481170/comments/5

I would be also happy if we find a solution that works without any additional controls.

I am curious to see how Traktor solves this problem?

[Be (be.ing)]

For effects that continue to produce output without any input, a pointer to the per-group enable state for the effect can be passed to the effect's process() function, which would allow the effect to turn itself off. To handle external effects like that, we'd need a preference option for the effect and ship Mixxx with a list of popular external effects that work that way so they can be shut off immediately when going into the intermediate disabling state.

[Be (be.ing)]

https://github.com/mixxxdj/mixxx/pull/1252

[Daniel Schürmann (daschuer)]

I think if we go for the post fader solution Bug #1370837, we should not implement this.
The enable button should mediately go to dry in this case and this hard to solve bug is gone.
Right?

[Be (be.ing)]

I agree. I am closing this bug as Invalid.

[Be (be.ing)]

For the record, after I implemented this in https://github.com/mixxxdj/mixxx/pull/1252 I realized it isn't very useful. It does prevent temporal effects from cutting out suddenly, but when the deck is playing and the dry signal is mixed in with the wet, it doesn't matter much.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8188