It seems that there is a bug in Ardour. Maybe add it to the tracker so we don’t forget. I expect Ardour does not make 64 a no movement, but rather just does a split anything above a value goes up anything below goes down. So turning one way will probably go in double steps and the other way looks to Ardour like one step each way with a net result of 0. I expect that will be fixed in Version 6… but until then in linux you should be able to use an external midi filter like qmidiroute to pass everything but 64.
Is that really a bug? There are 128 possible values between 0 and 127 inclusive. 0-63 (64 values) are considered to indicate one direction, 64-127 (64 values) are considered to indicate the other. How else would we break this down? Just change the “split” point to 63 ? If we consider 64 as “no movement”, it will likely break some other encoder … It would need a new encoder type, I think, which explicitly marks 64 as “no movement”.
Right, so far as I know this is the first use of this kind. In our manual we say: 64+ and 64- which does mean 64 is zero movement. As this is based on the documentation of the BCF2000, I expect that leaving 64 as zero is intentional. All of the other enc-* do have a zero position. The first two have -0 and +0 (like the mackie). Having a zero movement is actually quite important for use as a jogwheel or speed setting. This is why I suspect my math is wrong currently. Here is a snip from documentation:
This is from documentation of someone who actually looked at what the output was. Documentation has changed each time the company has been bought by someone else or maybe because of firmware upgrades. I have two user manuals (a new one today) that are both different.
Thank you for information, and for mentioning qmidirouter, I will explore its possibilities.
I do not know if this information will be useful, but I have already seen the “relative-1,2,3” from your screenshot in the application that configures my midi controller. I can send the sequences events that the controller generates for each type of “relative” if it comes in handy.
Actually, only relative #1 (default settings) generate pair of midi events, other two generates one event. Below events for different types of “relative”, counter clockwise first and then clockwise.
So maybe your quick fix is to use relative 2 or 3… though rel 2 looks like enc-2, rel 3 looks odd I would have expected 01 for one direction and 41 for the other.
Unfortunately, the problem is that 1) the program in which the settings are made, works only under Windows 2) the settings made are not saved when the keyboard is turned off
Thus, only the default settings (relative #1, paired events) enabled under Linux, and encoder type suitable for Ardour (relative # 2) cannot be set.
Acceptable workaround, thank you again - to use qmidiroute (I have already tested it) and skip the first event for relative # 1, then Ardour works fine with encoder type enc-b and checked option Enable Feedback.
Just FYI. I tried relative #2 type of encoders, it is works as enc-2 in Ardour, BUT value 127 is not recognized as “-1” and Ardour is not reacts if I turns knob gently counter clockwise. 126 recognized as “-1”, 125 as “-2” and so on.
