Relative control with sysex?

Per previous topic I am aware there is an upcoming firmware release which will improve/correct behaviour of the ‘relative’ control type with relative MIDI CCs.

Is there also intention to add support for sysex? Currently if message type = ‘sysex’ for this control it doesn’t seem to output anything.

Ok, so having upgraded to v3.5, this still doesn’t help as I’m trying to send the relative control data as the data bit within a sysex string.

It’s to mimic the front panel encoders on a Yamaha A5000 sampler. These are notoriously crappy encoders that jump all over the place and are practically unusable. However it is possible to use sysex parameter changes to emulate all the front-panel switch and encoder data. This was implemented some years ago in a freeware app called A5000 Remote.

The A5000 service manual says this:

image

So using electra I can get the A5000 to respond to the above-formatted sysex for the ‘knob encoders’ using a normal fader control type, but without the ‘relative’ behaviour which makes it next to unusable.

Is it possible to use LUA to somehow inject a relative data bit value into the sysex string as a workaround?

You should test : if you send a positive value (anything above 64) to a fader via one Sysex message: Does the parameter on the sampler change accordingly and only once? Or does it continue increasing its value until you send a sysex message with a value of 64?

Take a quick look at this small preset: a5000 test

The first control sends the full range of MIDI values and the second control only sends 63 - 65
Does either/both do what you want?

I did try this, but the behaviour was that I had to keep changing values ‘above’ 64 to get it to keep incrementing positive, and in the range ‘below’ 64 to get it to keep going the other way. This is because once the continuous fader control passes through the data value range from roughly 63-65, the A5000 stops responding.

Thanks so much - yes this works! The second control (‘+1/-1 ONLY’) is the one I want as it is limited to only the useful range of 63-65, so the parameter scrolling responds as desired on the A5000.

Now if only there was a way to implement acceleration…

Thanks again, and I will study your preset some more as there are several things to learn from it… :+1:

acceleration as in – the faster you turn, the more +1 (or -1) are sent?

OK, take a look at the second row, switch 125. There’s probably optimizations that can be done, but this might do the trick for you.

a5000 take 2

Note that the barrage of sysex messages could overwhelm/confuse the a5000…

Thanks, yeah this one just lead to a ‘midi buffer is full’ message on the A5000. I wonder if a clue to the acceleration might be in the cryptic phrase from the service manual:

‘…a value of 64 less than the data specifies the number of pulses which correspond to rotation (30 pulses per rotation).’

Perhaps there is a useful range slightly wider than 63-65, perhaps 61-67, in which repeatedly getting to 66 or 67 doubles the tick rate…? I’m guessing though :slight_smile:

You can simply mess with the original control (switch 123).
Go into the web editor. click on that control, then change both the Min/Max value and the Min/Max MIDI value ranges from 0-127 to 61-67 and see.

The

events.subscribe (POTS)

function events.onPotTouch(potId, controlId, touched)
   if (touched == true) or (controlId == 0) then return end

   local ctlId = controls.get(controlId)
   local pNum = ctlId:getValue("value"):getMessage():getParameterNumber()
   parameterMap.set(1, PT_VIRTUAL, pNum, 64)
end

LUA code is what “snaps” the control back to 64. It is called every time you touch and release a control. If you wanted to emulate a jog/shuttle wheel that would take a lot more thought.

  • So, the 1st control (123) is a traditional approach - turn it a lot to the right and it will send bigger and bigger numbers. If you can see the A5000 screen update in real time, you can turn that control a bit or a lot and see what happens.
  • The 124 control simply sends a +1 or -1.
  • The 125 control sees how big of a step you want and then fires off a series of +1 or series of -1 to get to that number. That is why there is a sendDelta() and sendDelta2() function - they do slightly different things.

There’s all kinds of variations you can do - like if the delta is greater than 5, send out a series of +2 or -2, if it’s greater than 20, send out a series of +5, -5. It really depends on what the A5000 can handle.

The other thing to pay attention to is that the controls are defined as virtual (PT_VIRTUAL) because we’re doing a lot of non-standard data manipulation. As such, you need to make the parameter number (as seen in the web editor for the control) match the parameter number in the Yamaha docs (so 123-127).

1 Like

ok, I had 20 minutes and had a thought.

I added another control to kind of simulate a jog wheel. Small movement away from center sends sysex increments slowly. Moving farther away sends them faster. There’s also a debug counter on screen to see if the number of increments/decrements kind of matches what the target device is seeing.

If folks find this fun or useful, I’ll clean it up, add some comments to the LUA and make it public this weekend.

1 Like