Logic Modifier input mapping and others

[FigDJ]

While we were still in 2.4 I had made several mappings for

UMCP-1 4 decks + 8 locators + 8 pads + Video
UMCP-2 4 decks + 8 locators + 8 pads + Video
UMCP-2 2 decks + 8 locators + 8 pads + Video

These mappings all worked in 2.4 and broke in 2.5

After much testing and experimentation
I used a duplicate of the 2.5 mapping that you provided and added just 2 Logic modifier maps

I found that any modifier mapping completely disrupts the LED on the UMCP-2. It doesn't matter if the Logic modifier has also been mapped an LED output.

A way to reproduce the problem
1. Take the UMCP-2 V2.5 with video supplied with 2.5 and reproduce a copy of it.
2. Pick any button in the UMCP-2 and map a Logic modifier to it as a toggler button.
3. Load track in deck A and B.
4. Press play twice on each deck. The Cue LED should be blinking for both decks.
5. Now press the button that was map as a logic modifier and watch the lights.

Perhaps this is a result of the addition of Logic Modifiers to output mappings in version 2.5. Perhaps a work around is to add mappings with the logic modifier to the output mappings of all the lights so it will work when the a Logic Modifier set and also when is not set.

However, in mapping output, my assumption was (taken from the logic to set input mapping) that an output mapping without a Logic Modifier should work regardless if the Logic Modifier is set or not. While and output mapping that contains a Logic Modifier should only work when the associated modifier is active.

This could potentialy be a big problem. Say you just got a controller and do all the inout and output mapping without using any logic modifiers. it is all set up and ready to go. then you find yourself wanting to map a special fuction using a logic modifier, tou map it using a toggling action. it will break the mapping for all the LEDs already mapped.

Some advise please. Keep in mind that all of this works perfectly and as expected in 2.4, it only break in 2.5.

Also from the GUI if you press input mode for sampler C it switches input mode for sampler D
conversely if you press input mode for sampler D it switches input mode for sampler C. that is regardless if there is a controller connected or not just using the GUI.

The 1st issue I might be doing something wrong so I may need assistance.
The second issue I know is wrong and it should be on the to do list.

[FigDJ]

I guest I am talking to myself in this respect.

I asked for Logic Modifiers on output mapping and I so got it.
1st thing thank you Mixvibes team.

A little note and as I suspected the default logic for output mapping seems reversed.

Here is what I mean.

When doing input mapping any command without a logic modifier will be executed regardless of the state of any of the logic modifiers. These are default mappings.

Any command with a logic modifier will only execute when the logic modifier is active and only for those modifiers for which it has been mapped.

Base on that I thought that output mapping would follow the same convention, no modifier execute all the time, modifier attach to it only execute when modifier is active.

The current actual logic for output mapping will not execute command that do not have a logic modifier attached if a logic modifier condition is set.

In laymans terms this "reversed logic" broke all the output mapping as I was using logic modifiers for multiple functions.

Mind you all my mappings work perfectly in 2.4 and they are broke in 2.5 with the addition of logic modifiers to output mapping (but a reversed logic from input mapping).

Anyway I updated and tested my UMCP-2 4 deck 8 locators and 8 pads and this confirmed my theory. I will be updating and posting all the Quneo mappings with the 2.5 logic at a later date.

For now I will be posting the new map for UMCP-2 in General chat in a few moments. oh and now the issues with correct indication of LEDs is resolved with the output modifier. Lots of work ahead.

[sylMV]

Hi, you're completely right concerning the modifier conditions on output mappings. If you use, for instance, 2 modifiers and want a led to light whatever the modifiers, you need 4 'mappings':
- one without modifiers
- one with ML1
- one with ML2
- one with ML1 + ML2

Since output mappings still needs manual xml editing, I agree it's quite a pity...
By the way, we can't make a line without modifiers just ignore modifiers. In this case you wouldn't be able to emulate several layers on your controller.

Thanks a lot for your feedback!

[FigDJ]

Hi, you're completely right concerning the modifier conditions on output mappings. If you use, for instance, 2 modifiers and want a led to light whatever the modifiers, you need 4 'mappings':
- one without modifiers
- one with ML1
- one with ML2
- one with ML1 + ML2

Since output mappings still needs manual xml editing, I agree it's quite a pity...
By the way, we can't make a line without modifiers just ignore modifiers. In this case you wouldn't be able to emulate several layers on your controller.

Thanks a lot for your feedback!

I understand about the layering using modifiers but in any mapping there is always a set of commands and lights outputs that are the base (you could call those defaults) everything else can be managed by using a layer with modifiers.

Right now for inputs

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active

for outputs

command+ no modifier= execute only when no modifier is active
command+ modifier= execute only when modifier is active.

I am saying that (at least tome it will make more sense to have output behave as follow

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active
thus following the same convention as input mapping. Then all command without modifier are the components of layer 0 and everything else becomes a layer that follow modifier commands.

[FigDJ]

Hi, you're completely right concerning the modifier conditions on output mappings. If you use, for instance, 2 modifiers and want a led to light whatever the modifiers, you need 4 'mappings':
- one without modifiers
- one with ML1
- one with ML2
- one with ML1 + ML2

Since output mappings still needs manual xml editing, I agree it's quite a pity...
By the way, we can't make a line without modifiers just ignore modifiers. In this case you wouldn't be able to emulate several layers on your controller.

Thanks a lot for your feedback!

I understand about the layering using modifiers but in any mapping there is always a set of commands and lights outputs that are the base (you could call those defaults) everything else can be managed by using a layer with modifiers.

Right now for inputs

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active

for outputs

command+ no modifier= execute only when no modifier is active
command+ modifier= execute only when modifier is active.

I am saying that (at least tome it will make more sense to have output behave as follow

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active
thus following the same convention as input mapping. Then all command without modifier are the components of layer 0 and everything else becomes a layer that follow modifier commands.

[FigDJ]

Hi, you're completely right concerning the modifier conditions on output mappings. If you use, for instance, 2 modifiers and want a led to light whatever the modifiers, you need 4 'mappings':
- one without modifiers
- one with ML1
- one with ML2
- one with ML1 + ML2

Since output mappings still needs manual xml editing, I agree it's quite a pity...
By the way, we can't make a line without modifiers just ignore modifiers. In this case you wouldn't be able to emulate several layers on your controller.

Thanks a lot for your feedback!

[sylMV]

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active
thus following the same convention as input mapping. Then all command without modifier are the components of layer 0 and everything else becomes a layer that follow modifier commands.

I hope you don't believe we haven't thought about it.
Cause, basically, this doesn't work.

Example:
You want a led to light when looping and no modifier.
You want the same led to light when synced and ML1.

The "looping" state will always change the led even if ML1 is active.



The modifiers system needs a massive rework to differentiate "no modifiers" from "any modifiers". We already start thinking about it but nothing's planned right now.

[FigDJ]

command + no modifiers= execute all the time
command +modifier= execute only when modifier is active
thus following the same convention as input mapping. Then all command without modifier are the components of layer 0 and everything else becomes a layer that follow modifier commands.

I hope you don't believe we haven't thought about it.
Cause, basically, this doesn't work.

Example:
You want a led to light when looping and no modifier.
You want the same led to light when synced and ML1.

The "looping" state will always change the led even if ML1 is active.



The modifiers system needs a massive rework to differentiate "no modifiers" from "any modifiers". We already start thinking about it but nothing's planned right now.

Thanks for the feedback. As always it is very nice to know that you guys (Mixvibes Team) are on top of the issues an thinking ahead.
For now I can work with the logic as I understand it.

On another subject there has been many updates, please keep them coming. I just think that perhaps is time to update the manual to account for the updates and include a brief section about mapping, some of the logic used and a more descriptive explanation of the available command for mapping. I understand most of them but some are still obscure to me. Knowing more about the command will empower me to get more creative with mappings specially with powerful and flexible controllers like the Quneo.