Using XMAP to modify midi CC?

[kriskeyman]

I have an I2C/Multi track successfully triggering 16 channels of Machinedrum. However, I’m trying to use XMAP in FX lanes to modify decay of bass drum (MIDI CC dec 17).

Machinedrum is using base channel 10.

I’d like XMAP 000D to have short decay (30)
I’d like XMAP 000E to have long decay (127)

In mapping screen, how do I set source & destination in the 0D & 0E rows to change the decay when XMAP in FX row is triggered?

I can assign an I2C slider as source to change the decay value, which works fine. But how can I use the mapping screen to assign a specific decay value when the mapping row is triggered?

[blofeld]

I can assign an I2C slider as source to change the decay value, which works fine. But how can I use the mapping screen to assign a specific decay value when the mapping row is triggered?

Something like this for mapping rows:

Code:

000  SKIP 02<> 00=2
001  VAR  # A  #030        MCON  TC10  # 17
002  VAR  # A  #127        MCON  TC10  # 17

SKIP will make the rows never execute by itself, or you will only have a loop that simply sets these value every x ms.
VAR is easier to set specific values. The "#030" or "#127" is your value, change it to whatever you need. The "TC10" is your device/channel, set it accordingly. "# 17" at the end is the number of the MIDI CC. The value will be passed from the VAR to the MCON CC.

There are other mapping commands, but I think thats the easiest way. Then you can XMAP 0001 or XMAP 0002 depending which value you want. Hope it helps.

[kriskeyman]

Thanks! This is working great for what I need. Though I was able to delete the skip command and it’s still doing what I need… not sure why.

[XORadmin]

Thanks! This is working great for what I need. Though I was able to delete the skip command and it’s still doing what I need… not sure why.

I know why. Because only changes in the row are being send to the destinations for most of the mapping commands. And since you do a VAR #A 030 the row will stay 30 forever.
It will be executed once at startup though so the skip command is not obsolete here.

XMAP is different and will always execute the row and update the destination, regardless of if it has been the same.

136: Mapping explanation: "The updates of most of the values is happening ‘on change’. That means if the source
value doesn’t change then the destination will not be updated. They are some exceptions for it which will be described with the dedicated mapping destinations."

38: XMAP explanation: "Be aware that the selected row will be completely executed, regardless if the source changed or not."

I got to admit that it can use a bit more detail here.

[blofeld]

Thanks! This is working great for what I need. Though I was able to delete the skip command and it’s still doing what I need… not sure why.

I know why. Because only changes in the row are being send to the destinations for most of the mapping commands. And since you do a VAR #A 030 the row will stay 30 forever.
It will be executed once at startup though so the skip command is not obsolete here.

XMAP is different and will always execute the row and update the destination, regardless of if it has been the same.

136: Mapping explanation: "The updates of most of the values is happening ‘on change’. That means if the source
value doesn’t change then the destination will not be updated. They are some exceptions for it which will be described with the dedicated mapping destinations."

38: XMAP explanation: "Be aware that the selected row will be completely executed, regardless if the source changed or not."

I got to admit that it can use a bit more detail here.

I am confused...
So, the row gets processed once and if the source doesnt change, the dest will not be updated in future runs? These lines will be skipped without specific command to exec them!?
I can set the value of the MCON CC with other lines and it will not interfere with these two constants, they will only execute when I target them specifically!?

You are begging for misinterpretations here I think...


But glad it helped the author.

[XORadmin]

One MCON CC doesn't know anything about another one. It is just a destination.

Values are saved per row and if the source value (as in source result) didn't change then there will be no output to the destination. If the source stays 5 then the destination will be updated to 5 once but not anymore after that. If the source changes to 6 then the destination will be changed to 6 once. Other rows can have the same destination and will update on other occasions.

The exceptions are the XMAP command which will ALWAYS update the destination also if it never changed. Also some special trigger commands and some others.
This saves processor time and it takes care that you are not having for example a MCON update every millisecond (which is not possible with Midi anyways, the amount of bytes takes already longer than that).

And indeed if you don't care about the fact that they will be executed once in the begin then you can save the skip command.