Behringer XR18 optimization request - Bome Forums Archive 2005

nottooloud

2015-08-20 21:23:24

Behringer's new XR18 mixer has a handful of parameters available as MIDI CCs, but it's fully controllable via OSC. They've given us a workaround, in that it can read OSC text embedded in MIDI SysEx.

This is a patch that reads CC 0-15 on MIDI ch 1, and builds the correct string to control Effect Send 4 for all 16 channels. I'm running it from a Novation LaunchControl, although it should work from any 16 channel controller.

It has functional limitations that don't bother me. It only does Effect 4, with no bank switching, but that's fine because my default set up is one reverb. It doesn't do controller feedback, which is fine because the controller's knobs aren't motorized, and is also fine because I never leave reverb up, so recalling levels isn't important to me. The resolution is limited to 1dB steps. It's pretty laggy, which doesn't bother me for most reverb applications. No way I could do dub effects with it, though. I don't know if the lag is at my end, or in the "SysEx to text evaluation to OSC to data" mess that's happening at the other end.

It works, and does what I want. My question is, how can I make it more efficient? I'm looking for any pointers I can get either. More efficient methods, ways to prune the data, places I'm being sloppy and making things hard for BMTP, or whatever.

Code: Select all

Project: XR18 Novation FX6
 Author:   Dan Richardson
 Contact:  tech@nottooloud.com
 Comments:
Novation Launch Control to Behringer XR18
16 knobs control channels to effects send 4
4 buttons mute aux sends 1-4, 4 buttons mute FX sends 1-4
Novation knobs MIDI ch 1 CC# 0-15, captured and altered here
Novation buttons MIDI ch 2 CC#  21-24 & 27-30, toggle, pass through
patch also passes through MIDI Fighter Twister unchanged.

 Project MIDI IN ports:   Launch Control, X18/XR18, Midi Fighter Twister
 Project MIDI OUT ports:  X18/XR18, Launch Control, Midi Fighter Twister
_____________________________________________________________
[x] Preset 0: New Preset

[x] Translator 0.0: all channels FX4 send
Options: swallow
Incoming: LaunchControl, on port Launch Control
Rules:
  // qq is incoming CC#, using 0-15 on MIDI ch1
  if qq>15 then exit rules, skip Outgoing Action
  // rr is incoming MIDI CC value
  // OSC send level range is -90 to +10
  rr=rr*100
  rr=rr/127
  rr=rr-90
  // rr has been converted to outgoing OSC level
  // generate OSC text hex string from rr
  // uu is pos/neg place
  // 45 is 0x2d is "-", 48 is 0x30 is "0"
  uu=45
  if rr>=0 then uu=48
  // absolute value
  if rr<0 then rr=rr*-1
  // tt is 10s place
  tt=rr/10
  // ss is 1s place
  vv=tt*10
  ss=rr-vv
  // convert to hex
  ss=ss+48
  tt=tt+48
  // qq is CC#, 0-15
  // convert to inputchannel #, 1-16
  qq=qq+1
  // generate OSC text, yy is 10s place, 48 is 0x30 is "0"
  yy=48
  if qq>9 then yy=49
  //zz is 1s place, oo is rounded to 10
  oo=qq/10
  oo=oo*10
  zz=qq-oo
  // convert to hex
  zz=zz+48
Outgoing: OSC: /ch/yy zz/mix/10/level uu tt ss, to port X18/XR18
F0 00 20 32 32 2F 63 68 2F yy zz 2F 6D 69 78 2F 31 30 2F 6C 65 76 65 6C 20 uu tt ss F7

nottooloud

2015-08-20 22:57:53

I just realized I should be doing this with global values and one shot timers to clear the old data, shouldn't I? You guys helped me with one like this a while back.

nottooloud

2015-08-21 00:37:11

Can I use a local variable in the name of a timer Outgoing action?

nottooloud

2015-08-21 03:11:24

Well, I did the whole thing again with timers, and no change. The lag is at the XR18 end. Buffer clears immediately in BMTP, and hangs out quite a while over on the XR18 if you really rack a bunch of knobs. So back to the posted version, because it's much more compact.

Still, anything in there I should be doing differently?

florian

2015-08-21 12:11:58

Hi, I've checked out your Rules, looks good to me! There are a few other optimization techniques explained in the user's manual. Here, you may be overflowing the MIDI pipe -- or the incoming buffer on the X18R is slow, causing the lag. A way to fix this is to try to send fewer messages to the X18R. Some controllers also send control change messages if the value hasn't changed. In that case, don't send the message to the X18R.

Here's a way to do this with the global variable g0:

Code: Select all

 // rr is incoming MIDI CC value
  // OSC send level range is -90 to +10
  rr=rr*100
  rr=rr/127
  rr=rr-90
  if rr==g0 then exit rules, skip Outgoing Action
  g0=rr

Also, I cannot see the MIDI INPUT action, but I assume you're assigning the channel to qq. Then it is guaranteed that qq is always in the range 0 to 15 and you don't need to double check this at the beginning of your rules. But performance wise it should not matter a few lines more or less in the Rules section.
Florian

nottooloud

2015-08-21 13:57:58

The lag is definitely on the XR18. I can see the buffer empty in MTP, and then there can be as much as several seconds of activity on the mixer if I've really twisted a bunch of knobs. It's OK for this application, though. At least until you implement OSC.

Input is only from the specific controller, and only on MIDI channel 1. qq is set to the CC number. The controller has other buttons, and this translator calculates the output rather than using an if/then tree, so if some button is set to change a different CC, this would happily send messages to some arbitrary parameter on the mixer. Hence the range check.

Thanks for the help. MTP continues to rule.