Parameter Feedback

8 posts / 0 new
Last post
electrofux's picture
Parameter Feedback


i am currently programming a Remote Codec For Reason for the BCR 2000 which is running fine. But i have some problems with parameter feedback. Reason sends the parameters values nicely and the LEDs on the BCR react according to it. BUT when i turn the knobs the BCR moves its LEDs by its own rules which doesnt line up with the feedback or overrides them.

I would very much like the BCRs LEDs ONLY react to Reasons parameterchanges but i don't know how to achieve that. Is there some kind of local off or something?



electrofux's picture

I found th "local" section in the PDF:

A .local statement is legal (i.e. accepted by the BCF and BCR) in $button and $encoder sections
(but not under $fader). Its function is unknown. The BC never includes it when it sends a preset dump,
so maybe it's not actually stored in the button or encoder.
One might think that .local off prevents the BC from sending MIDI messages when a
particular button or encoder is being moved (similar to the EXIT button’s local-off procedure described
in section 4.6 of the B-Control manual). However, this appears not to be the case. So...? ***
It also seems that neither .local off nor .local on blocks parameter feedback from the
computer to the BC.

Maybe this is not meant block outgoing or incoming Midi but to block LED changes by using the controls. Which would actually make perfect sense to me. Or am i on the wrong track? How can i use this command. I understand the editor very well but not how  the commands in the PDF are used.

I can send Sysex to the BCR on loadup of Reason though. How would a command look like that uses the local parameter?

Mark van den Berg
Mark van den Berg's picture

When I reverse-engineered BCL (in 2007 - ten years ago...), I tried pretty hard to discover what ".local" achieved, but never found anything, so I didn't implement it in BC Manager's button and encoder dialog boxes.
But maybe I missed something: your hunch that ".local" is related to the LEDs seems to make perfect sense, since (as I wrote) ".local" is not allowed for BCF faders, which have no LEDs.

Then again, ".local" may be one of those BCL elements that the Behringer engineer never fully implemented. For instance, section 20 of BC MIDI Implementation.pdf mentions a couple of BCL statements (".rangeon" and ".xref") that are even more obscure than ".local": these statements cause the BCF/R to return BCL error messages in any context that I tried. But again: maybe I missed something.

You can experiment with sending ".local" to a BCR from BC Manager's "BCL editor" window, accessible from the View pull-down menu of the B-Controls window. You should include it as a separate line in a button or encoder section.
(For explanation of the BCL editor window, see section 20 of the BC Manager manual. In particular, you may find Load -> Preset 0 useful.)
Let me know if you find anything!


electrofux's picture

Thx for the info, i will try and see.

Do you know of any other way to prevent that the leds get lit when turning an encoder locally and therefore only really react when Midi comes in? It is really weird, in the manual they speak of parameter feedback alot of times  but the way parameter feedback normally works is that the controller just waits for incoming midi and its LEDs react only to that. But on the BCR so far turning a knob allways means the LEDs also react to that local movement which they shouldnt (kindof hard to explain).


Mark van den Berg
Mark van den Berg's picture

If an encoder needs to respond to incoming MIDI messages, it needs a standard output definition, because with only a custom output definition, the encoder won't respond to incoming MIDI.

However, with any meaningful standard output definition (i.e. one in which Value1 and Value2 aren't equal), you can't prevent the LEDs from responding when you turn the encoder:
Unfortunately, if an encoder has a standard output definition, setting its resolution to 0 makes the BCR apply a "reasonable" (non-zero!) default resolution, as described in section 17.3 of BC MIDI Implementation.pdf.
So all I can think of is setting the encoder's resolution to 1: then a full rotation will only increase the value by 1.



electrofux's picture

Ok, so the only hope i have is that this .local works. I couldnt test it so far but i am positive about it since it makes sense. And there is an existing native Reason codec that seems to have this issue solved. Sadly it is not open source. But maybe i can monitor the sysex that runs bewtween Reason and the BCR on load and find soemthing out.

But first things first. Is the following script correct for checking the local function on encoder1? i am not sure what the first two parameter of easypar do (1 1 below)? CC# and Channel?

$rev F1 ; Firmware 1.10; BC Manager 3.1.0

.easypar CC 1 1 0 127 relative-1
.showvalue off
.mode 1dot
.resolution 128
.default 0
.local off


Mark van den Berg
Mark van den Berg's picture

As far as I know, Reason sets up the BCR's temporary preset when connecting to the BCR.
So if you wish to study this preset, you should be able to simply download it via "Receive preset 0" from the MIDI pull-down menu in BC Manager's BCL editor window.

From section 16.3 of BC MIDI Implementation.pdf:
.easypar CC Channel Controller Value1 Value2 Mode
So the channel comes before the CC#.

Do you really need to use "relative-1" and ".showvalue off" at this testing stage?
Personally I'd simply use "absolute" and ".showvalue on" for clarity.
I doubt that whatever ".local" does is affected by any of these settings - but who knows.

If ".local off" doesn't seem to do anything, try ".local on" too.

As described in BCMI section 14.1, ".easypar" has several side-effects, one of which is setting the Default parameter, so if you were to put a ".default" line above the ".easypar" line, that ".default" line would be meaningless.
So in theory the placing of ".local off/on" could matter too, so you may want to experiment with that too.

Good luck!

Anonymous (not verified)
Anonymous's picture

I just tried it out. The bad thing is, it doesnt work the way i thought. The good thing is by analyzing the codec i realized that the unit handles parameter feedback differently than other Midi Controllers.

All other encoder+LED Ring controllers i know totally separate the encoder from the led. If you turn the encoder the led will not move because it expects incoming midi and the encoder just sends out.

However the BCR, when it receives incoming Midi it uses this value to set the encoder IN ABSOLUTE MODE to that value in order to prevent value jumps. It doesnt really set the LEDs at all - then encoder sets the LED locally depending on its internal value.

Now in relative mode the encoder sends out increments depending on resolution and turnspeed at 96 1 or 2 at higher resolutions even more. However in my codec i just said if a value lower than 3 comes in decrement by 1 because i neither wanted a kind of acceleration nor did i know that this matters for the LEDs, i just thought the LEDs only depend on Reason sending the current value. The result were misaligned LEDs. When turnig fast i reached the last LED when in Reason the parameter was at half.

But all is good now and i use absolute mode.