Components EffectUnit rework

[Be-ing]

This is a work in progress to rethink the EffectUnit UX for components. I'll be experimenting with different ways of focusing effects and showing that on the controller.

For now, the first commit just fixes a bug wherein the EffectUnit wasn't unfocused when show_parameters was set to 0.

Merge requirements:

• introduce ControllerEngine::makeConnection and deprecate ControllerEngine::connectControl #1218
• create [Master], num_effectsavailable ControlObject #1235

[Be-ing]

The issue I am trying to address is that there is no visual indication on the controller of whether an effect is focused, and if so, which effect. Presently, the user must look at the skin to see this information, so it is easy to get confused about what turning the effect knobs will do without checking the screen first. Here's a rough idea of how to map this differently:

• Change name of showParametersButton to effectFocusButton.
• When effectFocusButton is pressed and show_parameters is 0, set show_parameters to 1.
• When show_parameters is 1, holding effectFocusButton and pressing an enableButton focuses that effect.
• When effectFocusButton is held down and show_parameters is 1, light the LED of the effectFocusButton indicating the focused effect. When effectFocusButton is released, revert the effectFocusButton LEDs to indicate the enabled state of the effects.
• While holding effectFocusButton, pressing the focused effectEnableButton resets show_focus to 0, but keeps show_parameters as 1.
• When any effect is focused, light the LED of effectFocusButton to provide a visual indication on the controller that the knobs are controlling individual parameters and not metaknobs. When show_parameters is 1 (regardless of whether an effect is focused) press shift+effectFocusButton to unfocus and set show_parameters back to 0.

The biggest issue I imagine with this is that pressing effectFocusButton behaves differently depending on the state of show_parameters. If a user presses effectFocusButton and sees the effect unit expand in the skin, the logical assumption of how to go back to the previous collapsed state would be to press the same button again. Having to press shift+effectFocusButton to go back to the previous state is a discoverability issue.

Suggestions welcome.

[Be-ing]

The biggest issue I imagine with this is that pressing effectFocusButton behaves differently depending on the state of show_parameters. If a user presses effectFocusButton and sees the effect unit expand in the skin, the logical assumption of how to go back to the previous collapsed state would be to press the same button again. Having to press shift+effectFocusButton to go back to the previous state is a discoverability issue.

Perhaps alternate actions for short and long presses of effectFocusButton could overcome this:

• When show_parameters is 1, short pressing effectFocusButton resets both focused_effect and show_parameters to 0.
• When show_parameters is 1, holding effectFocusButton switches to the mode for choosing the focused effect as described in the previous comment.

This is going to get really complicated to implement. I'm glad I have a library to help out...

[ronso0]

I just got used to Component JS for FX units and I like it. There's show_parameters, with Shift there's un/focus. And if -in minimal view- it's also possible to focus an effect without a forced expansion of the unit, that's perfect!

Presently, the user must look at the skin to see this information, so it is easy to get confused about what turning the effect knobs will do.

Indeed, and there's no timed behaviour for physical buttons yet like there is for the virtual ones (long-press & release enables effect temporarily).

Perhaps alternate actions for short and long presses of effectFocusButton

So, if timers enter the game, it could be sufficient to also apply them to LEDs, maybe an unobtrusive 'negative blink' like this:
Effect enabled, not focused = LED is On
Effect enabled and focused = LED is On, goes of for .1sec every second
I think, having to press a button to know which effect is focused, is equally intricate as looking at the screen. As I mentioned, I like how focus, highlight & show_parameters currently work. Because it's simple. Visual feedback about focus would make it pretty solid, I'd say.

When show_parameters is 1, short pressing effectFocusButton resets both focused_effect and show_parameters to 0.

Make it a long-press and you got my vote :)

[Be-ing]

And if -in minimal view- it's also possible to focus an effect without a forced expansion of the unit, that's perfect!

Why do you want this? I think it would be confusing because the values the knobs would be controlling are not on screen. Isn't this what you were just confused about?

negative blink

I think blinking is annoying and I will not be implementing it.

I think, having to press a button to know which effect is focused, is equally intricate as looking at the screen.

True, but presently there is no indication whether or not an effect is focused, so when looking at the controller, it's a guessing game as to what turning the knobs will do. Even if a single LED can't indicate which effect is focused, I think a hint that any effect is focused will be a helpful change.

Make it a long-press and you got my vote :)

That would make it too easy to accidentally unfocus and switch to collapsed mode. With your suggestion, if effectFocusButton was pressed to display the focused effect on the controller buttons' LEDs, there would be a very short window of opportunity (probably around a few hundred milliseconds) to let go of effectFocusButton without an unintended side effect.

Thanks for your input.

[ronso0]

Why do you want this? I think it would be confusing because the values the knobs would be controlling are not on screen.

Because it should be up to the user if he/she wants exanded view. For example, I got used to control Echo (delay & feedback independently) and Filter (HPF & resonance independently) blindly and I wouldn't want that expanded FX units squeeze my playlist.

I think blinking is annoying and I will not be implementing it.

I think so too, but I would accept here if there's a subtle solution not a "LOOK AT ME" flash, if you know what I mean. Something like a pulse

That would make it too easy to accidentally unfocus and switch to collapsed mode. With your suggestion, if effectFocusButton was pressed to display the focused effect on the controller buttons' LEDs

Hm, I meant short-press to mini/maximize like now, long-press to minimize and unfocus.

In general I feel, you already have a very precise idea, and that complex behaviour -if it would be fixed- would cut other options, other users' personal preferences. No offence, I very much respect your commitment on this issue

[ronso0]

Ẁhile your working on this anyway, I have another idea/wish/hint:
Instead of a shifted enable button cycling through the effects list in one direction in minimal view, shifted knobs could do that way better. I had this (and timers) in my script solution (low-level code admittedly, but only multiple timers for long-press would interfere now&then).
I decreased the shifted knobs' resolution so they would change to next/prev effect every +-10 steps of their actual value. Was pretty comfortable.

[Be-ing]

That's a good idea. I'll keep it in mind for after the focusing rework. We'll need a new CO to indicate the number of effects available so a finite knob's range can be divided in a way that can select every effect... or a new ControlPotmeter specifically for this purpose.

[Be-ing]

Hm, I meant short-press to mini/maximize like now, long-press to minimize and unfocus.

Yeah, that's what I was thinking. Also I think long pressing effectFocusButton when show_parameters is 0 should both set show_parameters to 1 and switch the buttons to focus selection mode. That way, focusing an effect from collapsed mode will only require one long button press instead of one button press then another long button press.

[ronso0]

Also I think long pressing effectFocusButton when show_parameters is 0 should both set show_parameters to 1 and switch the buttons to focus selection mode. That way, focusing an effect from collapsed mode will only require one long button press instead of one button press then another long button press.

In addition to that: while show_focus=1, enabling an effect could automatically focus it.

[Be-ing]

In addition to that: while show_focus=1, enabling an effect could automatically focus it.

I disagree. Enabling an effect and focusing should remain separate.

[Be-ing]

Okay, I have implemented the focusing changes discussed above. I also added a new aspect to it. When hiding parameters, show_focus is reset to 0, but its value is stored and the focused effect is refocused when parameters are shown again. This seems to work as planned, but I haven't yet tried to actually mix with it. Please test.

I have removed the premade enableOnChannelButtons. They can still be made easily with enableOnChannelButtons.addButton('CHANNEL_NAME'), but I think they should only be used if the assignment buttons are in the effect unit like the Denon MC6000Mk2 (ping @uklotzde). Otherwise, I have added a new type of Button called EffectAssignmentButton that is separate from the EffectUnit object. The options object to the constructor of this requires a group option as the deck to enable and effectUnit as the number of the effect unit. I added a special case to Deck.setCurrentDeck so it will switch the deck of any EffectAssignmentButtons in the deck.

[Be-ing]

Wow this is really fun! :D

[uklotzde]

This is one of my tasks for 2.1, remap the effects unit for the MC6000MK2. Thanks for reminder ;)

[Be-ing]

I have temporarily removed effect selection from this. I'll add it back to shift + knob turn after making a ControlObject to map to a knob.

[Be-ing]

After discussing with @MelGrubb how to map the M-Audio Xponent, I realized there is some desire to switch physical EffectUnits on a controller between Mixxx's EffectUnits. I have implemented support for this as shift + effectFocusButton. To use it, pass an array of effect unit numbers to toggle between to the EffectUnit constructor, just like toggling between Decks: new components.EffectUnit([1, 3]);

[Be-ing]

I have updated the wiki to explain the new behavior and how to map it.

[daschuer]

Thank you for working on this. The plain text on the wiki is hard to understand. Could you replace the term briefly by short and mention the 275 ms, this is more obvious for a non native speaker.
A kind of truth table would also be very helpful.

Is it now still possible to focus an effect without showing the buttons in the GUI?
I think not, because a short press already sets show_parameters = 1.
I think this is a valid requirement, because in a controller only scenario, all GUI space should be
available for the library.

Idea:
Would it more natural if we do it like that?

• Hold effectFocusButton
• Short Press effectEanbleButton: Toggle the focus
• Long Press effectEnableButton: Toggle the focus and show_parameters

[Be-ing]

I will continue to work on the language on the wiki. It is complicated to explain, but it is actually quite intuitive to use.

Is it now still possible to focus an effect without showing the buttons in the GUI?
I think not, because a short press already sets show_parameters = 1.
I think this is a valid requirement, because in a controller only scenario, all GUI space should be
available for the library.

As discussed above, no, it is not possible to have an effect focused without the parameters showing, both to save screen space and because it would be confusing to manipulate a focused effect without being able to see the values being manipulated.

Would it more natural if we do it like that?
Hold effectFocusButton
Short Press effectEanbleButton: Toggle the focus
Long Press effectEnableButton: Toggle the focus and show_parameters

I don't think so. The way it is currently, I can see whether an effect is focused from the LED of the effectFocusButton being lit. If I want to unfocus, it only requires one short press of the effectFocusButton. If I am setting up custom metaknob linkings, I can unfocus by long pressing effectFocusButton then pressing the focused enableButton without causing show_parameters to be set to 0.

[ronso0]

Is it now still possible to focus an effect without showing the buttons in the GUI?
I think not, because a short press already sets show_parameters = 1.
I think this is a valid requirement, because in a controller only scenario, all GUI space should be
available for the library.

As I explained above, I'd like this to be possible, too (for me Filter & Echo are easy to use without GUI knobs). I understand that you try to build this for an expected majority of users for whom it's probably better to keep the interface simple/intuitive.
I would be glad if you leave easy to find comments in the code where to manually revert that automatic unfocussing behaviour and the knob behaviour for onHideParameters.

[Be-ing]

Sure, I could even make a boolean argument to the EffectUnit constructor to control that behavior.

[ronso0]

That would be great!

[Be-ing]

Ready for merge?

[Be-ing]

Please merge. This is holding up controller mappings.

[daschuer]

OK I will merge now.
@ronso0: It would be nice to get a LGTM from you nevertheless to make this PR complete .. or if there are remaining issues a according comment. In the later case we can open a new PR or file a bug. Thank you.

[daschuer]

Thank you for working on this.

[ronso0]

Yeah, the parts of this I've been using work great: effect toggling, focus toggle, parameter control, meta control, expand/collapse, switching between effect units. Though, I can't judge the code, at all.

I can test again next week to see if the bugs are still present (LED of focused effect only lights up if this effect is ON)
Once I experienced the bug @Be-ing described, about a (meta) knob losing contact to GUI knob. Caused an awkward moment during a live gig but when I noticed I could catch it with softTakeover.

For the Components wishlist: Temporarily de/activating an effect with longpress (like in GUI & like with previous effect mappping) would a nice feature, it's fun to use with beatlooproll!

[Be-ing]

Once I experienced the bug @Be-ing described, about a (meta) knob losing contact to GUI knob. Caused an awkward moment during a live gig but when I noticed I could catch it with softTakeover.

If you figure out how to reproduce this, please share.

For the Components wishlist: Temporarily de/activating an effect with longpress (like in GUI & like with previous effect mappping) would a nice feature, it's fun to use with beatlooproll!

Interesting idea. I'll play with that :)

[Be-ing]

I wrote a wiki page targeted at users explaining how this works. Feel free to edit it if you think the language could be clearer.

[Be-ing]

@ferranpujolcamins have you made any progress updating the Xone K2 mapping with this? This PR changed the public API a little bit.

[ferranlala]

No, I'm sorry. I won't be able to work on this until next month.

…

On 12 May 2017 5:41 a.m., "Be" ***@***.***> wrote: @ferranpujolcamins <https://github.com/ferranpujolcamins> have you made any progress updating the Xone K2 mapping with this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1211 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGIcT5yvAcooI2ytmPyP6AzWKpHE0Q0cks5r49TPgaJpZM4MXIZi> .

[ronso0]

Just tested: working great, like it did so far!
Thanks to your other fix, effect toggling while fully dry now works reliably.

The issue with unlit Focus button after restart is due to this snippet in controller script (here):

// Extinguish all LEDs
for (var i=0; i<=3; i++) {  // 4 decks
	for (var j=1; j<=120; j++) {
		midi.sendShortMsg(0x90+i,j,0x00); 
	}
}

So it's kinda solved, I guess.

The other issue I found persists...
Press Focus button > focused effects LED should light up > only does so if this effect is enabled
...but this is not a problem for me anymore since I got used to look at the screen for parameter adjustment due to softTakeover.

[Be-ing]

The other issue I found persists...
Press Focus button > focused effects LED should light up > only does so if this effect is enabled
...but this is not a problem for me anymore since I got used to look at the screen for parameter adjustment due to softTakeover.

Maybe you're misunderstanding how it is meant to work. Regardless of the state of show_parameters, you need to press and hold effectFocusButton to show which effect is focused. Short pressing effectFocusButton will toggle show_parameters.

[Be-ing]

@ronso0 does commit fb79a04 from PR #1233 fix the issue you had with the LEDs showing the focused effect?

[ronso0]

@Be-ing Yes, now it works: focus led lights up no matter if effect is enbaled.
Thanks!

[Be-ing]

Thank @DJMaxergy for fixing that.

[Be-ing]

I am thinking of making the buttons control the first 3 button parameters when an effect is focused. When I was first working on this, I found it helpful to retain access to the enable buttons of all the effects in the chain when an effect is focused, but I haven't actually been making use of that much. #1256 made it clear to me that button parameters are actually useful and it would be nice to have access to them on controllers. It would also get rid of the awkwardness of having the knobs control parameters of the focused effect while the buttons control other effects. What do you think? @ronso0, @DJMaxergy? I think it could be fun to use the Triplet parameter of Echo with a power window button.

[ronso0]

I understand the Triplet example.
Shift + effect buttons could be mapped to mixxx effect enable buttons.
Because it's good to always have a reliable way to quickly switch effects on or off, without any modifier key. For example when something goes wrong (see 1). Also using the effect enable switch in power window mode together with loop roll buttons is very interesting > press both buttons simultaneously, optionally turn Meta knob

1. i.e. feedback goes through the ceiling with Echo or Reverb, or when Meta knob loses grip on a linked effect knob (happened to me twice with Moog filter and I can't tell if the reason was Components or the knob sending faulty values)

[Be-ing]

Good point, having that access is helpful sometimes. How about when an effect is focused, the buttons control the focused effect's button parameters and the LEDs show the state of the button parameters. With shift and an effect focused, the buttons could be used to toggle the enable switches of all the effects in the chain without showing the state of the enable switches on the buttons' LEDs.

Meta knob loses grip on a linked effect knob

Does this happen after loading an effect? If so, that's because of #1148.

[ronso0]

Hm, you mean the exact opposite of my proposal..
For my loop roll example you'd have to press three buttons at once then (while pressing Shift and loop roll buttons might do sometime completely different).
I admit using effect toggle + loop roll while an effect is focused seems to be a rare use case.
But more importantly I consider effect toggles to be basic controls like Play button and volume fader, which should work the same way under all circumstances, whereas IMO single effect parameter knobs and buttons are on a special level and could require modifiers like Shift.

[Be-ing]

I admit using effect toggle + loop roll while an effect is focused seems to be a rare use case.

What about using effects with loop rolling would require the effect being focused? Why not use the enable switch together with a rolling loop without the effect focused?

Regardless of what the buttons are doing, the dry/wet knob is always there as an emergency brake.

[ronso0]

Does this happen after loading an effect?

No, it happened somewhere during a session, the effect was in use since the beginning.
when turned quickly the physical knob sometimes sends values like 56-57-01-80-62-63, though IIRC the meta knob only lost the low pass knob.

[ronso0]

What about using effects with loop rolling would require the effect being focused?

How to switch on an effect then?
I use loop roll very spontaneous. It's quite the opposite having to focus an effect in advance to enable that feature.

Why not use the enable switch together with a rolling loop without the effect focused?

Sure, that's how I do in most cases, I wanted to point you to other valid use cases.
These are just my 2 cents..

[DJMaxergy]

I agree with @ronso0:

But more importantly I consider effect toggles to be basic controls like Play button and volume fader, which should work the same way under all circumstances, whereas IMO single effect parameter knobs and buttons are on a special level and could require modifiers like Shift.

Someone who gets in touch with a controller and it's effect buttons would be very confused, I think, if he cannot activate effects with the concerning buttons on the controller. It's a key feature at the currently available controllers. Yes, you can read the documentation and get into it, but it's not very intuitive. I sometimes forget or doesn't see immediately which effect I have focused and then I would wonder why I cannot activate the other effects.

[Be-ing]

Please give #1353 a try. I am finding it more intuitive than the old way where the knobs controlled the focused effect and the buttons controlled the chain. Now both the knobs and the buttons control the focused effect.

@DJMaxergy, I have done usability testing with this and confirmed that it is unlikely that anyone would focus an effect on accident and get confused about what is going on. I intentionally designed the focus switching in a way that the user needs to know it is there to activate it.

The focus button's LED shows whether an effect is focused. If it is lit, you can know that touching the knobs (and with #1353, the buttons too) will control the focused effect. If you forget which effect you have focused, you can either look at the screen or hold down the focus button which will show which effect is focused on the buttons' LEDs until you release the focus button.

I should really make a video demonstrating all this.