Patching: Map incoming Sysex-Value to Midi Range

Developers
1

Hi There

I have a Fader configured with 4 Values A,B,C,D (0-3) and Midi-Range 0-127. So the outgoing Midi Values are 0 for “A”, 42 for “B” , 85 for “C” & 127 for “D”. The corresponding Sysex-Value consists only of 2 Bits to represent the 4 Values. If i Patch them with JSON, i only get Values 0-3 → “A”, as all Sysex-Values fall into the Range 0-42 which is “A”.

Is there a easy way to map the parsed Sysex Value to the Midi Value? Something like
“mappRange:” 0,3,0,127

thx

Busa

2

Can you clarify a bit more?
Are you sending or receiving sysex on the E1?
Sometimes sysex is used for patch parsing (thus inbound into the E1), while real time changes are transferred via MIDI Cc. Is this the case here, or are all time changes also done via SysEx?

And what do you lean with “ If i Patch them with JSON” ?

→ For each inbound message, please give the values that are transmitted and the formats ( Sysex or Cc), same for the outbound message.

3

Couldn’t you just create a list for that fader with 4 items and assign the values 0,42,85,127 to them?
When you parse the incoming sysex and get the 0-3, that should cause the fader to jump to the correct entry.

(I hate not having an Electra One here at work so I can work the answers in real-time, but I think people might question how it applies to my day job …)

1 Like
4

Thanks for the fast reply!
Unfortunately, it does not work.
If i configure it like in the Screenshot, the Control sends the right Midi Values over CC73 to the Synth (0,43,86) and also shows the right Labels, if i receive the Midi Values over CC73 from the Synth (0-> Val1, 43->Val2, 86->Val3. But if i load the Preset over Sysex, the two Sysex-Bits for this Parameter are “0b10” for VAL3 = 2. This Value is then placed in the ParameterMap under the Position of CC73. But the Control interprets them as “Midi Value” and “2” is in the Range of 0-42-> “VAL1”. But it would need to be 86 to show the “VAL3” Label.
Hope you understand what i try to describe :slight_smile:

image
image241×940 22.5 KB

5

I’m trying to understand, but it’s a bit hard. Why do you need two CC’s ? CC37 and CC73 ?

Please share your preset. I may have a solution , but don’t want to to try to “guess” the issue.

6

Sorry, Typo. its CC73.

1 Like
7

There are always more ways to resolve issues like that. This is what I would do:

  1. create an extra virtual parameter that would keep value parsed out of the sysex
  2. add a parameterMap.onChange() that would facilitate the conversion parsed value (0 - 3) to desired CC value and that would then update the CC parameter of the fader.

I hope you catch my drift. And yeah, an arduino style map() function would be very handy in those situations. I will add that to the Lua todo list.

8

Here is one way to resolve this:

  1. add a virtual control, I called it “EG Trigger VT”, which parses the inbound SysEx (instead of parsing it directly into the CC parameter). In this case the virtual parameter number is exactly 1000 above its CC partner.

image
image706×512 22.3 KB

  1. Make that virtual control hidden, with the following characteristics:
    image
    image769×795 27.7 KB

Let’s compare it against its CC partner:
image

  1. At the end of each parsing round, I added a command: finishParsing() (especially here, there are numerous other ways to resolve this, it’s just an example)
function finishParsing()
  local parameterNumber={85,73,108,107,91,92,86} -- parameters with option values spread amongst 0..127
  local multiplier =   {22,43,16,16,43,43,6}
  local value = 0 
  for i = 1,7 do
     value = multiplier[i] * parameterMap.get (deviceId , PT_VIRTUAL, 1000+parameterNumber[i])
     if parameterNumber[i] == 86 and value <= 64 then value = value + 1 end-- small CC map for LFO clock division has offset of 1
     if parameterNumber[i] == 86 and value >= 65 then value = value + 2 end-- large CC map for LFO clock division has offset of 2
     parameterMap.set(deviceId, PT_CC7,parameterNumber[i],value)
  end
end

In other words , CC 73 is being dealt with when i = 2. It takes the parsed value of virtual parameter 1073, multiplies it with 43 and then assigns the result to CC 73

As you see, the solution was needed for 7 controls in this example.
image

In the case of the Minitaur, from which the example is taken, there was some specific behaviour to CC86 ‘LFO clock division’ as well in the code.

9

Hi

Thanks a lot Martin & NewIgnis for your detailed responses and ideas! I had a similar solution in my Mind but directly altering the CC73 Value. But using a separate VT makes absolutely sense - nice idea!
But yes, at the end, i thought there should be a easier way as it is quiet a common case to use that with Systex Parsing. So really happy to here that it makes its way on the todo list :slight_smile: Btw: Congrats on the Sysex Parser Martin! It’s it super handy and a mighty tool for Sysex parsing!

BR

Busa

2 Likes