So here is a first preset for BCR2000.
This is still a work in progress, but i was asked by another BCR-user, so i´ll provide this as a starting point.
It may have bugs and is not complete, so feedback is welcome.
I assume you have installed and configured AZ-plugin and had a look at the documentation.
First thing to do is to load the matching preset into the BCR, because i have reprogrammed my BCR, so that ALL buttons can be used for Midi-Ctrl (normally there are 4 reserved buttons, and 2 for preset-switching).
This also means that you will not be able to switch between BCR-presets directly from the unit!
To switch to a different BCR-preset, you´ll have to send Program-changes or use a preset-manager.
I´m using the BC-Manager (http://mountainutilities.eu/bcmanager (http://mountainutilities.eu/bcmanager)) which i strongly recommend also for backing up the current state/presets of your BCR (see BC-Manager-Docs).
But the BCR-preset is just a SysEx-file, so you can use whatever you like (the attachement must be renamed to .sxy because that´s not allowed).
If you load this preset "BCR2000 for AZCtrl (all Btns).syx" into your BCR, it sends the MIDI-Controllers needed for this AZ-preset.
If you don´t like to reprogram your BCR, you could think about a different layout and reassign the controls inside AZ (Hardware-Tab).
Ok, now a short description:
I hope the attached picture helps, but don´t look at the current labels :o as said, this is work in progress.
It has 3 main modes:
- Track (can be toggled between Track/Bus)
- ProChannel/Selected Track-Mode
- ACT
The states are indicated with corresponding Led´s.
In Track-mode, the Tracks can be shifted in groups of 8 (preset buttons < >), and the WAI-position is also shown (2 Led´s, so currently up to Track 32).
The 8 Track-controls are (top-down):
Level meter (timing adjust see Sonar-Preferences), Solo, Mute, Send1, Pan, Vol
Pushing the first encoder (level meter) switches this Track to:
"ProChannel-Mode", indicated with a flashing Solo-Led of this channel (solo-function of button still works).
In Channel-mode you have:
the left group of 4 encoders is EQ - the layout exactly as on the screen.
the other group of encoders shares HiPass, LoPass, Compressor and Console Emu (i hope you can identify it on the picture)
mute-buttons are: EQ-band 1-4 enabled, then HiPass, LoPass, EQ-active, Compressor active.
I hope the global buttons and transport can be to guessed from the picture.
Not all buttons have shift/ctrl functions yet, but some.
As said, it´s in still progress and i´m not sure about some details.
E.g. i have a problem with: level-meters must be top row (only this can be switched to "meter-style"), while i want my fader to be in the first(bottom) row. i would really appreciate ideas of other BCR-users too.
But i hope it helps to get started.
@Alexey: if you have time, please take a look at the "flash selected channel" - logic (S1 Sel & Feedback). I think this could be done more efficiently, but at least it´s working now ;)
Great work!
I hope someone with BCR2000 join you, at least with testing and ideas if not with help in configuration. May be post on OF to make it more visible? Unfortunately, search of OF (event with google) does not work well. I have tried to find Faderport preset post and the result was all set of problems with Sonar and Faderport during many years, but not the link to working modern preset...
I have a question: in S1v, I see "s_SEL:1 - Undefined". Do you have something else here?
In Sx Sel:
* you can "Strip WAI Current" as the first action, "Select Strip" will work with that (since it defines the strip) and so you can remove second "Strip WAI Current". That will not change what that list is doing, but there will be one action less
* "Set engine state" in the next action does nothing (since it is after monitor declaration, this action is not executed in Monitor mode)
* I think Parameter Value Monitor should be periodic, not once (it does not react on focus changed by mouse otherwise)
* I do not understand why you reset Solo indicator from there
* I have not completely understood your s_SEL logic. Can you explain what you try to achieve?
In Solo action:
Parameter Name/Value Monitor has "Double" flag set. I can imagine that is coming from bug in some of my examples/preset. Do you remember where you have seen that? It will be nice to fix.
In _ModeChanged:
I have recently found always working way to use "Move Input focus to Track/Bus":
1) define another state set s_CurrentTrMode with Track/Bus
2) do "Save/Recall" "Recall" "focused" strip type to s_CurrentTrMode. That way you get currently focused strip type
3) ignore where it is already correct "s_CurrentTrMode: Track s_TrMode: Track - Undefined final", "s_CurrentTrMode: Bus s_TrMode: Bus - Undefined final"
4) for switching from Track to Bus, use 2 commands: "Move Input Focus to Track Pane" and then "Move Input Focus to Bus Pane". For Bus to Track switch reversed. The first command (move input focus where it already is) makes the second one always work. Do not ask me why...
Sorry, it is the first time I try to understand preset written by someone else. And I must admit that is not an easy task... ;)
Thanks for your comments and suggestions!
i will need some time in the evening to give you detailed answers, but i think most of the mentionend points are just "historic" from experimenting and/or lack of knowledge.
But i remember that "double" flag was created by startup-preset.
what do you mean with "OF"?
QuoteSorry, it is the first time I try to understand preset written by someone else. And I must admit that is not an easy task...
really? ;) i know...
Quote from: MarKo on May 27, 2015, 08:32:08 AM
But i remember that "double" flag was created by startup-preset.
I see it is still there. Thanks for reminding.
Quote
what do you mean with "OF"?
Official Forum
Quote
QuoteSorry, it is the first time I try to understand preset written by someone else. And I must admit that is not an easy task...
really? ;) i know...
That is why I put lengthy texts in may examples/tutorials.
But I am not asking for detailed explanation, at the end in case someone can interpret presets that is (should be) me ;)
I have already understood that you use s_SEL as "Mode" for Selected/Not selected and the same LED for Select/Solo ( CC:65 for the first strip ). But you have coupled all things together. In case you have selected Strip 1 and it is blinking and then have changed focus by mouse, does everything still work as you except? For me it looks like LED1 can "stuck" in On state in that case. What I mean is that I do not see you are tracing "external" focus changes in respect to mode.
Ok, now more detailed answers (the very long story ::)).
As i said before, the preset is not finished and must be cleaned up too.
I started with a startup-preset, and then i played with many different layouts/logic, so i´m sure there are errors left over, or things which i have changed in the meantime.
Some things are not implemented yet (thats where you see "Undefined"), but i just uploaded the preset as a start because i was asked from other forum-user (i hope he get´s it working).
But i have to say that i nearly gave up with my "flash selected track"-logic, and i was about to ask you for help. So what´s currently there, is the result of hours of fiddling around - in the end more trial&error. And i really spent time reading your explanations.
So somehow i got a first version a little bit working, but with all problems like you mention: wrong states after bank-switching, sometimes needing 2 button-presses, and so on. The craziest bug was once that when toggling solo from Sonar side, the solo-led was sometimes flashing shortly. I still have no concrete idea from where that came. But i had a version where i tried using one "global" flash-timer, which was always running. i know that´s not optimal, but i tried if it makes it easier. With a global "blink-state", the logic for solo-led was pretty simple, to flash in selected mode.
But then i had some other bugs - i restarted the Sel-logic from scratch several times >:(
Some trys later, i was quite happy - it seemed to work. At that time it was following mouse-selection correctly (Value Monitor was periodic, like you said it should).
Then i copied this logic to the other track-strips (testing first 1 strip).
Ok, then the real problems began: if first S1 was selected with S1v, but not deselected with the same button - so directly pressing e.g. S2v, the logic was not working. After some more trials, i thought found the problem: directly after "select track" action, the check for current track was not working as expected, because it referred to the previous selected track! It looked like Sonar needed time to first update it´s state and "current" track will be correct only after the next cycle.
And then it got really weird when i tried to check this "later" ::)
I admit that after some hours, i started planless moving things around, playing with priorities and cycles and i think that i also changed the monitor to once while testing.
It was late night and through planless trials (i was just about to write you), i somehow got to this puzzled solution, which is the first one working correctly (when used from surface). I did not re-check that following mouse-focus was broken, and it has another little drawback: i can not switch directly from selected stip1 to selected strip2, because s_Sel is toggled off with first the press of S2v. Anyway i was happy to get it working so far.
i changed the monitor now to periodic again, which follows mouse-focus correctly, but of course you are right - it has exactly the problem you mentioned (it leaves Led´s stuck in one state).
It would be very nice if you could show (and explain) an example of how you would code that perfectly (and why). It´s enough to have 2 buttons and 2 Led´s to get the principle.
The Led´s should show in track-mode the solo state of 2 tracks, and button-press should make this track the current and selected (s_Sel:1). In selected track mode, the corresponding solo-Led should blink.
if track1 is selected, pressing button 2 could switch directly to state SelTrack 2, but that´s not so important.
I will check the other points you mentioned later.
And of course i will propose that on "OF", but i´d like to have it a bit more finished than today (also the description). Currently i´m not really often in OF, it has become very strange (i need a perfect staff-view blabla :o )
Quote from: MarKo on May 27, 2015, 09:08:16 PM
It would be very nice if you could show (and explain) an example of how you would code that perfectly (and why). It´s enough to have 2 buttons and 2 Led´s to get the principle.
The Led´s should show in track-mode the solo state of 2 tracks, and button-press should make this track the current and selected (s_Sel:1). In selected track mode, the corresponding solo-Led should blink.
if track1 is selected, pressing button 2 could switch directly to state SelTrack 2, but that´s not so important.
I have no much time left... So, shot.
In AZ Controller you first have to try strait way.
* I have defined 2 controls Sel1 and Sel2 (your buttons with LEDs). I have also created one "System" control "Mode monitor".
* I have created 3 Sets: for Mode, for Blink and for current Selected strip (with required number of states).
* Mode monitor show current mode in the Column 1
* Column 2 and Column 3 are your LEDs
* Sel1/2 are identical, the difference is in track. So, the explanation is just for Sel1.
* We have 2 modes, so I select WAI Track Solo when in mode Track, and WAI Track Selected when in mode Selected
* We need a monitor for value in both cases (so, no condition)
* You do not use the button for solo, if I understand correctly. So it just select the track/switch the mode (if it was already selected).
* Select track (in both modes!).
* I also add Monitor trigger, as I remember you need that to update LED after it was changed by hardware during button operation.
* In track mode: switch to Selected mode. Final! Otherwise next action will satisfy (we switch Selected STATE, so the effect IS immediate)
* In Selected mode: in case the strip was selected, switch mode to Track. (you are right, changes are not immediate. So, "Selecting" the strip does not change the Selected state, that will be done in the Monitor later. And so, we can use its "old" status here).
And now the monitor:
* for Value 0 (does not matter either it is "Track not selected" or "Solo is off"), we turn off LED (I display '-'). Final action.
* for Value 127 in Track mode we just turn on LED (+)
* for Selected mode value 127:
- we turn off/on led according to the Blink state
- change the Blink state
- remember Selected (value 127, we ARE selected!)
- trigger ourself in 2 cycles (blinking)
* I have to update display with prepared text, you do not really (and you can set Value: 0 Action as final and avoid Value:127 condition in all other actions).
Thats it... :)
You can test it with "play" button, or assign some controls to them. Blink,Solo, focus changed by mouse - everything should work.
There is one problem... If you select some track outside your controlled range, Selected state will not be updated, and so "Select" button on the last controller strip with turn mode to Track instead of keeping it in Selected. Nothing is perfect, but I do not think that is a huge issue.
QuoteI have no much time left... So, shot.
sorry, i forgot - somewhere i read something about sea&sun - have a nice time!
meantime i´ll try to understand/implement what you wrote. Although a short reading leaves me partly clueless on what you mean. But maybe it becomes clearer, when i start working on it...
thanks for your ideas.
OH - thank you!!!
i did´nt see the attachement first, i read it just as explanation!
have to try that now...
many thanks again!
I have finished packing quick... I do not like "not perfect" programs.
I attach modified preset, without the problem mentioned :)
The trick in modification: I also have "Undefined" state in the "Selected" Set. In case monitor see that the current Selected is our, but Value is 0, it set it to "Undefined". Note that all conditions are important: other monitors (from other channels) could be executed before or after. So, in case we unconditionally set "Undefined" on zero, it will be always undefined (all strips except may be one are not selected all the time). "Mode: Selected" is also important. In "Track" mode "Value: 0" means "not soloed".
I think in addition to "Selected" Set concept, the only one you have not see so far is several parameter selection before Monitor. I guess you can understand after all my explanations before, that Monitor work with the parameter selected as last, even in case there was several (working) Strip/Fx/etc. actions before. They are evaluated every time before monitor, so that works correctly with conditions.
Related note: Value Monitor also auto triggered on Parameter change. I mean in case your Track has Solo (Value 127) and is switched to Selected mode (also Value 127). The monitor will be auto triggered since it worked with parameter "Solo" and it is parameter "Selected" now.
It is good practice to put all actions not required for Monitor environment setup after monitor. Both "Strip" actions are essential for Monitor (they define what is monitored). While the rest is just the reaction on button press, not relevant for Monitor.
Quote from: MarKo on May 27, 2015, 09:08:16 PM
But i have to say that i nearly gave up with my "flash selected track"-logic, and i was about to ask you for help. So what´s currently there, is the result of hours of fiddling around - in the end more trial&error. And i really spent time reading your explanations.
Please do not do that again... If you need an example for something you do not get within 5-10 minutes, just let me know. You are always welcome. Normally, in case I can not get it within 5-10 minutes, I start planing modification in plug-in to make it quick. So you will not waste you time, I get new idea and all other can use the result!
QuoteI have finished packing quick... I do not like "not perfect" programs.
It could be that your latest explanations were really important for me...
Have a nice trip!
Hi Martin
Thanks for posting your preset I have installed as per your instructions and with a bit of adjustment have it running as expected
Having looked at the program and documentation you have done an excellent job to get it to this stage, no way I could do that!
The compressor button filter type was set to other once set to the compressor it turned on and off
Then I just had to assign the filter types to the compressor encoders
Took a while to figure out but compared EQ settings that were working to compressor settings that were not and got there eventually
A good learning experience for a beginner like me
Your instructions and picture worked well, I have not given it a real workout yet so I have not found any problems
I can see that the transport controls with the shift looping option will be handy
This is my first post so I must thank Alexey for his excellent program, I own an alphatrack (now working very well) a BCR2000 (well on its way to working well) and 2 X BCF2000 hopefully working well in the near future
I can see some more flowers on there way soon :) and I hope you are enjoying your break
So a big thanks to you both keep up the good work anything I can do to assist let me know
Regards
Stevie
Hi Stevie,
Welcome here!
About my plans.
I have realized that I have to implement plug-in management. Including scanning for particular parameter resolution and mapping to user defined "categories". I mean selecting EQ parameters in each preset by numbers is a nightmare, especially if you want control more than one plug-in. So my current thoughts: if we can define category "EQ" ("Dyn", "Strip", "Reverb", I mean arbitrary) plus some set of parameters in that category ("HF Freq", "Cut-off", "Wet",...) and then say "ProChannel EQ" IS "EQ", its parameter 16 is "EQ HF Freq" (and the same for any other FX plug-ins), then in the configuration for some knob we just say "EQ HF Freq" and it controls HF Freq of whatever plug-in we have selected... that sounds like a good idea for me :)
That is quite some work, so please do not expect it is done soon.
BSF2000 has some similarity with MCU, but may be more with StudioMix (not touch sensitive faders, no channel display). I have StudioMix now, so there will be good preset for it. My MCU preset is in "frozen" state since there was no big interest from community after it was published while it requires enormous amount of work for testing. With 2 active users we have managed to make Alphatrack working in several weeks, and Alphatrack is much simpler.
Regards,
Alexey.
Hi Stevie,
Fine that you got it working!
I´m currently finishing my layout and optimizing some details, then i will post the next (complete?) version.
So if you have some suggestions, they are welcome.
Which Sonar-version are you using? Could there be a difference?
I´m on X3 - and for me the compressor is working with filter:other.
i do not even have a filter:compressor - strange.
martin
Quote from: MarKo on May 28, 2015, 12:27:32 AM
It could be that your latest explanations were really important for me...
They were!
Alexey, for me this was the best example until now, really wonderful for understanding.
Along with your descriptions, i finally think that i understand it now (mostly).
While transferring your SoloSelected-solution into my preset, some little questions came up.
But i don´t want to bother you now with that.
Hi,
I do not think I develop something this week, but I can answer you question. It is too hot in the middle of the day ;)
Thanks Alexey for welcoming me on board, happy to be here
Does your mind ever stop working? The ideas and work arounds you come up with are amazing!
I hope they don't all come to you in your dreams otherwise you will get no rest at all
Quote from: MarKo on May 31, 2015, 01:24:07 PM
QuoteWhich Sonar-version are you using? Could there be a difference?
Martin I am running platinum so that may make a difference
QuoteSo if you have some suggestions, they are welcome.
One thing that would really help my workflow would be control over horizontal and vertical zoom
Regards
Stevie
AZ Controller is my hobby project. So, I think/modify/comment it when I am NOT working ;)
About zoom (for MarKo, that is NOT ready BCR preset): all zooming operations are done as "Commands".
There are many which can/should be mapped on buttons ("Fit whole project", "Fit selection", etc) while other are good for encoders (Zoom In/Out Horizontally/Vertically All tracks/Selected track).
I do not want you spend sleepless night in attempt to understand how to map commands to encoders. So I attach an example with such mapping, one for "normal" knob and another for endless encoder. Both are for horizontal zoom, but I think that you can change yourself.
Thanks for the Zoom-example, i´ll look into that and try to find a useful layout.
(i´m currently busy with other things too)
@Stevie: if you now know about the possibilities of AZ - do you have an idea for zoom-handling?
i mean which commands/buttons/encoders...
thinking about a separate "zoom-mode" with all zoom-commands (e.g. Shift-ACT?)
Hi Martin
The main zoom items I use continually are zoom in & out vertical, zoom in and out horizontal, fit all vertical and fit all horizontal
I will have a look this week at Alexey's zoom preset and see if I can get an idea of how it works
for example one endless encoder zoom in and out or one encoder zoom in and another encoder zoom out, this way I can make a better judgement of how we might set it up
I am not sure if we would need another mode for zoom or if we can work it in with what we have got
It would be good to get other peoples ideas as the way I work is not necessarily the only and best way to do it and it may make for a better tool to use
Also please do not feel any pressure from me to get this done I am just grateful for the effort you guys are putting in and hope I can contribute in some way
Regards
Stevie
Quote from: azslow3 on May 31, 2015, 04:00:16 PM
So I attach an example with such mapping, one for "normal" knob and another for endless encoder.
Yesterday i had a quick look at ZoomExample, but i´m not sure if it´s behaviour is as expected.
It does zoom out for controllers <64 and zoom in >64.
but when i zoom out one direction (e.g. left until 50), and then want to zoom in, i have the values coming up from 50 to 64, which further zoom out - which is the wrong direction. It does correctly not before reaching 64.
Maybe it was plannend for some other midi-messages (endless?), but the BCR-preset sends normal Controller-values.
I could change it to 2 Controls, so that one does zoom in, the other out - that works, but i´m not sure if there is a better way...
That is why I have included 2 controls! One is "Endless", other is for normal "Knob". Have you tried "Knob" one ? It uses different option for state mapping from value, called "Step". The same option exists also for "Value" (just in case you want to try), together with "Instant" and "Direct" it is for normal knobs.
Of course i´ve seen and tried both controls, but there was no difference in behaviour.
I have to check it again, but this will be tomorrow.
Oh sorry, my fault... I forgot to re-export final version before attaching the file :-[
I have exported the version you could see, have decided to test it with controller, have observed exactly what you write and have modified it. And so I was surprised it does not work for you.
I have updated now as replacement for the original attachment, so no one try to use buggy one.
Thanks, the corrected version works.
Now i had a bit time to proceed with my preset.
The Zoomexample was ok, but it still had this "dead range" when changing direction (then you had to reach 64 before it worked).
So i had the idea of sending values back to the BCR.
Turning left does zoom out and sends Ctrl 65 back, and turning right does zoom in and sends Ctrl 64 back.
_InOut with just 2 Values, so _InOut from StepValue always works directly, regardless which direction and there is no dead range.
But trying something more, i found that _InOut (with 2 states) from Ribbon-change works even better!
There´s no need for above workaround, plus the Led-ring shows a useful value. The only limitation is the range of 127 values, while the above solution works really endless.
But 127 is much more then needed for zooming, even for shuttle this is enough, so i prefer this one now.
What do you think?
I do not have BCR, but from this and your other thread, I understand that in hardware the encoders are endless. But they send 1-127 range and also "set" current value to specified. In this case, Ribbon with value sending it the way to go.
But is it possible to switch BCR into "native" mode, where it is just send hardware +-1 directly? That can solve many problems, inclusive metering/volume one.
Yes, the BCR encoders are endless, but are currently setup to send normal controllers.
They can be programmed for other modes too, and i tried a mode called "inc/dec", but with this i got no midi input at all, so i stayed with "absolute". But perhaps i did something wrong, i´ll have to check again.
So you mean such a mode would be generally be better? does it work for all other scenarios too (PC, ACT,...)?
Then i´ll have to find the correct mode for the BCR. Reprogramming and transferring the preset is not done so fast, so i can not just quickly try all modes through. Could you guess from the screenshot?
Quote from: MarKo on June 08, 2015, 12:00:15 PM
Yes, the BCR encoders are endless, but are currently setup to send normal controllers.
They can be programmed for other modes too, and i tried a mode called "inc/dec", but with this i got no midi input at all, so i stayed with "absolute". But perhaps i did something wrong, i´ll have to check again.
So you mean such a mode would be generally be better? does it work for all other scenarios too (PC, ACT,...)?
If there is an endless encoder, it is better to use it as endless encoder! Everything else is "compatibility", implementer in the BCR firmware. It can be simpler to dial with that at the beginning, but you get such "troubles" as with level/monitor.
AZ Controller is able to process native signals, for all operations. You just has to set "Value" mode to "Endless" (from "Direct") and adjust sensitivity to your taste. You can also define "Shift+Encoder" more sensitive (Fine) then "normal" (coarse).
Quote
Then i´ll have to find the correct mode for the BCR. Reprogramming and transferring the preset is not done so fast, so i can not just quickly try all modes through. Could you guess from the screenshot?
My guess is that any from first 3 "Relative" will work for you (other "Relative" are also supported, inclusive "Inc/Dec", but you do not want them. The explanation for that is going to be a bit long, but if you are interested let me know).
It is hard to guess what is what, so it is better to try all 3 and find which one produce the following result in the "Last MIDI event":
* slow turning right produce value 128, fast turning produce 128/256/384/... depending on speed. It can be that in one mode it produce 128 or 0 independent from the speed (my guess in "sign in MS bit"). It can be that there is no such mode, "second best" is when it produce 128 independent from the speed
* slow turning left produce value 16256, fast turning some another "big" values.
In can be that the result is "reversed", so turning left produce "128". Also not a problem ("Alternative endless encoders" in the Options tab).
Quote from: azslow3 on June 08, 2015, 01:07:18 PM
If there is an endless encoder, it is better to use it as endless encoder!
ok, i understand that (now).
QuoteMy guess is that any from first 3 "Relative" will work for you
the first one gave strange results, but it seems as "Relative (sign in MS-bit)" works.
Initially i had no idea about the different messages. And the BCR can be programmed to send about anything.
But it´s quite some work, i´ve seen now that i can adjust different messages for 4 speed-levels and set values for each.
i´ve got the principle working for 1 control with 2 speed-levels, so i think this is the way.
Maybe it should be noted somewhere, which messages have their advantages.
QuoteThe 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.
Quote from: MarKo on June 08, 2015, 11:48:52 PM
QuoteThe 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.
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...
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...