Encoder initial value when a session is loaded


(Zor) #1

Hi,
I’m building my own midi device based on a Teensy 3.2 micro-controller board. My goal is to be able to tweak track fader gains, filter frequencies, etc…
My first version was using potentiometers and it was working, however the problem is that if I want to work on a new session and change the potentiometers positions, all my settings for the first projects will be lost.
I did a new version of my device using encoders, so that when I save a project, all my values are saved and are restored when I reopen the project. I finally found out how to make it work, by creating a midi binding file to deal with encoders.
The problem is that when I open my project, values are well restored, but when I turn an encoder, the value is reinitialized at zero instead of keeping the initial value and adding to it the encoder +1 or -1 control. I tried with the 4 version of encoder coding (enc-r / enc-l / enc-2 and enc-b).
I’m not sure if it’s a bug or if there’s something to configure to get it right.
I don’t have the problem in other applications (VoiceMeeter for example).
Another approach would be to have Ardour send midi messages to my device when a project is loaded with the initial values, so I can initialize my device with the correct values and send absolute values instead of incremental (this would also allow me to display values on my device). I managed to catch these messages when I change a value in Ardour with the mouse, but I don’t know how to get the initial value when a project is loaded.


(Len) #2

It would be helpful to know:
what MIDI events do you send for +1 or -1?
what line do you use in your binding file?
Also check that you do not have more than one binding for the same control. I have tested all four types of math and gotten the value to move from where it was to a relative position. Having Ardour send a value is not really the right way to do things in this case (unless you also have light rings around the encoder).

Ardour does have a midi tracer (in the window menu) so you can see what Ardour sees. Use the drop down at the top to choose MIDI control in.


(Zor) #3

Thanks
For the enc-b type, the events that is sent for +1 and -1 are for example :
+1 : Controller chn 1 07 41 (07 is MainVolume code)
-1 : Controller chn 1 07 3F

Only one binding is assigned to this control. Is does the same with the code 70 (which stands for Sound Controller 1). I use a different channel for each track, but the same control code. I just tried using a unique control code but got the same issue.
I agree that having Ardour sending the value is not the right way to solve this problem, although later I would like to have a feedback on my device (leds or a 7 seg display or a small oled screen).


(Len) #4

Ok so I am assuming a binding like:
<Binding channel=“1” enc-b=“07” uri="/route/gain 1"/>
or:
<Binding channel=“1” enc-b=“07” uri="/route/gain Master"/>

Ardour’s feedback in generic MIDI is kind of patchy. There are some things that work (mostly route based stuff) but a lot that does not. There does not seem to be anyone who has an itch right now to play with it either. If you can fit your particular control surface into a well known protocol such as the Mackie control protocol, the support is much better. That is what I did with this simple controller: http://www.ovenwerks.net/hardware/3dollarcontrolsurface.html It follows the MCP standard except only 5 strips instead of 8. I take two keys to make an encoder, one for +1 and the other for -1 (using enc-l style signals) For the faders, the controller keeps it’s own register and adds/subtracts from that. The feedback can set it to a value for bank changes etc.

The other thing to do is dig into Ardour’s generic MIDI code and make fixes yourself. Beyond that, The OSC code is probably better supported than most, so you could switch to that if you have a network connection or use one of the MIDI2OSC or OSC2MIDI utilities around… though I do not know if either of those are easy to get/use with Windows.


(Len) #5

Hmm, the manual really should include some examples…


(Zor) #6

I have tried these kind of bindings :

and

I have not tried all possible bindings, but they all seem to behave the same way, whatever the kind of encoder message type I use, and whatever the value I’m changing in Ardour.
I’ve looked for some examples and found a few about encoders with midi, but none with Ardour, and no information regarding this problem.
I could save all my encoders value internally in the device, but they would then just behave like potentiometers which is not what I want. I want these values to be saved in the session. And ideally if I add a graphical feedback of any kind, or if I build motorized faders, I would love to have them initialized correctly.

I asked for help to find out if it’s a bug (if someone has faced the same problem or if the developers are aware of it), or if I’m not doing it as expected.
I’ll have a look at osc if it works better, but the advantage of the current approach is that I can have a wired or wireless midi device very easily with the Teensy and the expansion board I’ve made. Adding a network layer is more complex, it would either mean to add an ethernet or wifi expansion to the Teensy, or to implement some kind of USB/UDP gateway.
I feel it’s not in the way de device communicates with Ardour that is the problem, especially looking at the midi messages received, but sometimes in complex software some weird things happen :slight_smile:
I wanted to avoid to recompile Ardour if possible. Especially considering I need it on Windows…


(Len) #7

To be honest, it has been some time since I have played with generic MIDI. I was the one who added the enc-* part of the code and it did work at the time at least with my controller. However, I think that was Ardour 4.* if I remember right, though it could be early 5.*. I have been working on OSC code for quite a while since. I will have to make something that gives me some encoder like data to play with.


(Len) #8

It has been a while since I used my little controller… I needed to redo the sw to give my user permission to grab a keyboard. I used a very simple map with only one line:
<Binding channel=“1” enc-l=“16” uri="/route/gain master"/>
My encoders are set up to enc-l to mimic the mackie. In Ardour 5.12 the first event sent by the encoder sets the control to zero after which it performs normally. So yes you have found a bug. In Ardour 6 pre-alpha it appears that bug has been fixed however, there is another bug in that if I use the encoder to raise the fader to the top… I can no longer move it down. However this bug does not seem to be there in 5.12 (good). Then I tried turning on feedback… and now the fader does not jump when first touched. So maybe this will work for you too. My encoders send 01 for +1 and 41 for -1 (for enc-l) So try slecting “Enable Feedback”


(Zor) #9

Enabling Feedback fixed it ! (tried with enc-b type)
Thank you soooo much Len :+1::raised_hands::clap:
Thank you very much for adding generic midi and encoders support as well.


(Zor) #10

BTW, what’s the difference between “enable feedback” and “motorized” ?


(Robin Gareus) #11
  • enable-feedback A message is sent to the device when a mapped value changes
  • motorized A physical knob’s position is assumed to always matche the control value

If motorized is disabled, Ardour ignores all control events from the hardware until the knob’s position is close to the internal control-value. The “smoothing” control allows to configure this.

e.g. If a Fader in Ardour is at -inf dB but your physical knob is all the way up, moving the knob will do nothing at first. There will not be an immediate jump in volume. You have to sweep the knob until it is sufficiently close to the actual value and then Ardour will start following.

If motorized is enabled, the smoothing parameter does nothing and Ardour will always follow the knob’s value as-is, potentially allowing discontinuous jumps.


(Len) #12

Well I added encoders… but generic midi was already there before I came. Your welcome though