14 bit CCs with higher resolution

6 posts / 0 new
Last post
Pistor
Pistor's picture
14 bit CCs with higher resolution

The BCR's default encoder speed is kinda slow, and but luckily it can be set to higher. I was using the resolution values recomended here:

https://forum.ableton.com/viewtopic.php?f=1&t=56878

E.g.

$encoder 55
  .easypar CC 1 55 0 127 absolute
  .showvalue on
  .mode 1dot
  .resolution 96 192 384 768
  .default 0

Note: 96=128*0.75; 192=96*2; 384=192*2; 768=384*2;

Now I want to do the same but with all encoders sending 14 bit CCs:

0.75*16384=12288; with the above calculations I get 12288 24576 49152 98304 but the resolution can be 65535 max (2 bytes) so I had to scale it back:

So I'm using these values now: 8192 16384 32768 65535 (they still double the previous, but starts with 0.5*16384):

$encoder 56
  .easypar CC 1 0 0 16383 absolute/14
  .showvalue on
  .mode 1dot
  .resolution 8192 16384 32768 65535
  .default 0

I sent this to the BCR but now when I turn the knob, it behaves unexpectedly: When I turn it slowly, it works, but when I turn it fast, it turns very very slow and even sometimes jumps back one LED.

Is this because of internal overflow in the BCR, when it adds 65535 to the current value and it's over 16383?

How can I get this working? According to the manual this should work, right?

 

Pistor
Pistor's picture

Btw, I just tested this with a 14 bit NRPN, same behavior!

$encoder 52
  .easypar NRPN 1 154 0 16383 absolute/14
  .showvalue on
  .mode 1dot
  .resolution 8192 16384 32768 65535
  .default 0

Pistor
Pistor's picture

I tested this a little more, this behavior is the most obvious with the following resolution values:

$encoder 52
  .easypar CC 1 2 0 16383 absolute/14
  .showvalue on
  .mode 1dot
  .resolution 12288 24576 36864 49152
  .default 0

This causes the knob values to decrease when turning the knob to the right fast (and increase when turning it to the left fast).

So this looks like an overflow, probably because the BCR is using 16 bit integers to do the addition of the current value and the resolution step?

But then how is one supposed to use 14 bit CCs with higher encoder resolution?

 

(Btw, in my testing I found out that the maximum difference between subsequent CC values sent from the BCR (with the resolutions 96 192 384 768 in a 7bit CC) is 32, if I turn the knob really fast.)

Mark van den Berg
Mark van den Berg's picture

At first I couldn't see the strange behavior you're reporting: it doesn't help that the BCR's display only has four characters!
But when I started monitoring the BCR's output in BC Manager's "MIDI controllers" window (from the main window: View -> MIDI -> Controllers; press Record), I noticed that controller #0 (the MSB of the 14-bit value) indeed showed strange jumps when I turned the knob quickly.

I then tested at which value these strange jumps started occurring in the simple situation in which all four resolution parameters have the same value, so ".resolution R R R R" (equivalent to simply ".resolution R").
It seems that (at least in this situation) everything goes fine if R is 32673 or lower, and that things go wrong for 32674 and higher.
E.g. if R is 32674: when the value is at its minimum of 0 and I turn the knob counterclockwise, the value should simply stay at 0, but actually jumps to 341. Similarly, when the display value is at its maximum of [1]6383, it jumps back to [1]6042 when I turn the knob clockwise.
With R = 32767, things are really horrible: I can't raise the value higher than 832 at all!
And with R = 40000, the direction of the whole knob is reversed?!
I don't know what's going on here exactly, but it's probably related to the fact that to 215 = 32768. Maybe because 32768 - 96 = 32672; something like that.

In any case it seems to have nothing to do with BC Manager: when I make BC Manager retrieve the encoder definition back from the BCR, it's identical to what BC Manager originally sent to the BCR. So the fault seems to be just in the way the BCR treats these high values.

To be fair, Behringer never claimed that the resolution parameters went all the way up to 65535. They just never published any specs for BCL!
When I reverse-engineered the .resolution statement (around 2007), I determined that 65535 was the maximum that the BCF and BCR accepted and returned, but I didn't study the actual behavior at these high values in depth.
But if 32673 is indeed the "soft" limit in all circumstances, it might be an idea to make BC Manager warn the user that higher values lead to erratic behavior.

Mark.

Pistor
Pistor's picture

Thanks, I guess I'll just use 7-bit CCs then..

Btw, I noticed that it makes a lot of sense to have the value at constant resolution so you can more easily operate it without looking at it, with muscle memory..

Do you know what resolution (one value for all speeds) is equivalent to the actual angular knob velocity, so that you could (in theory) draw a mark on a knob and it would always point to the LED that's on? I thought it should be 127*16/15=135 because the range of the knobs is 15 leds in a circle that has space for 16 leds, and those 15 leds should cover the whole range of 127 increments. But that resolution seems to be too slow, and if I multiply that again by 16/15 it seems to fit, but why is that? I thought the resolution represents the increments for 360 degrees. So if 127 increments should map to 360*15/16=337.5 degrees, shouldn't 127*16/15 be the correct resolution?

Mark van den Berg
Mark van den Berg's picture

There is no direct correspondence between the LED(s) that is/are lit and the angular position of the knob:

The 15 LEDs are mapped to the full range of the encoder's parameter.
For instance, if the .mode parameter ("LEDs" in BC Manager) is 1dot, each LED (except the first and the last) covers roughly 1/14 of the encoder's total range, so roughly (MaxValue - MinValue + 1) / 14. The first LED covers roughly 1/28 of the total range, as does the last LED.
E.g. for a normal (7-bit) Control Change parameter with MinValue = 0 and MaxValue = 127:

LED # Range Number of values in range
1 0-4 5
2 5-13 9
3 14-22 9
4 23-31 9
5 32-40 9
6 41-49 9
7 50-58 9
8 59-68 10
9 69-77 9
10 78-86 9
11 87-95 9
12 96-104 9
13 105-113 9
14 114-122 9
15 123-127 5

By contrast, the angular velocity of the knob is exclusively determined by the currently applicable parameter RN in the .resolution statement, where "the currently applicable parameter" is the one associated with the speed at which you're currently turning the knob.
So with the BCF/R's default R of 96, a full rotation corresponds with a difference of 96 values, and a standard CC range with MinValue = 0 and MaxValue = 127 requires 127/96 turns to go from 0 to 127, which amounts to almost one and a third turns (476.25 degrees to be exact).
And, with R still being 96, a 14-bit value ranging from 0 to 16383 spans 16383/96 = 170.65625 turns. However, the 15 LEDs cover the full range from 0 to 16383, so each LED except the first and last covers about 16384/14 = 1170 values, which amounts to 1170/14 turns, i.e. over 12 full turns.

Hope this helps,
   Mark.