BCR-2000 preset, beta

[azslow3]

The explanation for that is going to be a bit long, but if you are interested let me know

i´m interested, but don´t waste too much time - a few words would be nice.

There are "one packet" MIDI messages and "several packets" MIDI messages. Note, PB, 7bit CC and several other are all "one packet" messages. There are 14bit CC, composed from 2 packets and (N)RPNs, composed from up to 4 packets. The problem is that they all use the same set of CC messages... there is no "hint" in the packet itself either it is "self contained" or it is a part of something else.

Another problem is how to react on 14bit CC... according to standard, the system should react on both parts (lower and upper part of value) but that can produce unwanted "double trigger".

Simple controllers can send 7bit CC only and are able to ignore number assignments. So, some encoder can just send CC 6, while in 14bit "mode" it is most significant 7 bit from (Not)Registered Parameter Number. "Inc/Dec" is just jet another CC thought for (N)RPNs.

To avoid troubles, it is better avoid multi-packet messages when possible. AZ Controller support all types but not "violations" on the same MIDI channel, so it can not interpret CC1 as 7bit and CC2 as upper part of 14bit.

I think Mackie has made the decision to use PitchBend for hi resolution faders because that is the only 14bit single packet message. So, while using 14bit values, they could avoid (N)RPNS. In Control Surface world, unlike "real" MIDI world, original "interpretation" make no big sense. So any messages can be used for anything (in this case PB is used for Volume and other parameters control).

MIDI Controllers are called so because they can be used as controllers for MIDI hardware. And so they tend to support different message types, normally configurable. In that respect, BCR is more "smart" than MCU.

[MarKo]

Thanks for your explanations!
I tried some different endless-messages for BCR with mixed results.
Multiples from 128 produced lilttle jumps. While slow turning, i could see that it sometimes produced 2 steps instead in 1.
But the BC-Manager (utility for programming the BCR) defaults to 96, so i tried 96/192/384/768, this seems to give best results (accelerated).
Now i have to make some big changes to the BCR-preset...

[azslow3]

You can always switch off "HW Accel" in the Value Action setting so it is ignore the value and use direction only.
On my StudioMix encoders also produce "negative" values when I turn them fast.  In case you also notice some negative values during turning, there is a "fix" for that as well (but it skip one tick when you really start turning in other direction).

Sorry that I have not looked into BCR specification, I could give you the tip about endless encoders long time ago...