Midi2LR sends value back to rotary control again

[OffCornerDev]

Hi there, I've been watching this project for a while and I'm super excited. I still had some Arduino clones and potentiometers lying around so I decided to make my own MiDi controller. I have everything set up and using the absolute value setting it works great when sending a value between 0 and 127.

I want to use rotary encoders and set them up as a relative input.

I configured them as Binary offset, so when I turn the dial left, a 63 Signal is sent and when I turn them right a 65 signal is sent.

This also works really well; however, when I adjust the setting (let's say Exposure for example) in Lightroom using my Mouse Midi2LR also sends the new absolute value of the setting back to the Midi Input. So if I set an exposure of -1, it will send the value 40 back to Midi2LR as an input. This ends up in a loop and decreases the exposure until it reaches -5,00

This happens with all relative settings (Two's complement, Binary offset, Sign and magnitude). I can adjust how my MiDi controller behaves given the fact that it is an Arduino...

Midi2LR should not send the value back to the controller when the input is relative, otherwise it ends up in a loop and either goes all the way up or down.

I could later on attach a video. 

Anyways, the project is fantastic and I am already really excited!

[Rory Jaffe]

I'm traveling on business so can't run this on debugger, but that behavior shouldn't happen. The app sends and receives absolute values to/from the plugin, and translates the values internally to offsets, so the round trip behavior should be consistent.

With your setup, are you receiving values for Exposure on the same channel and control number as you are sending?

[OffCornerDev]

Thank you for responding even while you're traveling! 

Here's a quick video of what I was writing about: https://youtu.be/qe8jJkZsdyE

I hope it makes sense. At 00:35 you can see the error happening. Maybe it is my fault after all? The way I understood the binary offset is that it needs to send 63 to go down and 65 to go up. Is there anything in addition to that?

Even when the midi device is turned off completely and the type is set to binary offset, the error continues. When it's absolute, everything works.

Oh and I do receive the values on the same channel and control number as I am sending...

Cheers!

[Rory Jaffe]

You've got the definition of binary offset nearly correct. MIDI uses 4-bit binary offset, which is nicely explained here: https://en.wikipedia.org/wiki/Offset_binary . So 63 is -1 and 65 is +1. The other values have meaning as well. If X is the value you're trying to express, the binary offset value would be X+64. 

I do some work behind the scenes so that the actual adjustment range is anything you wish it to be--though each signal from the controller can be, at most -64 to +63 (or 0 and 127 in binary offset). You've left the range at 127, so there isn't any of that extended-range work going on, so that's not the issue. If you want to see how I'm handling this, look at the functions ChannelModel::OffsetResult_ and ChannelModel::ControllerToPlugin in ControlsModel.h and ControlsModel.cpp to show how things go from controller to plugin. OffsetResult_ may be hard to interpret, as it's doing a bunch of stuff to handle concurrent requests. ChannelModel::PluginToController shows the calculations going from plugin to controller.

I'm traveling a lot for the next 5 weeks, so it may be a bit before I can run some tests at home.

[OffCornerDev]

Thank you very much for your reply.

I had the chance to test a Midi (keyboard), although with a regular 0 to 127 control as well. It is interesting that the app keeps sending the values periodically... here's another screen recording: https://youtu.be/s7U0boNrjE4

It sends the values even when I do not touch the keyboard... I feel like there is some issue going on.

Cheers

[OffCornerDev]

Okay so I think I've found the error, but no way to fix it. The issue is directly connected to the tracking delay (in options -> Other...)

When I set the delay to 3 seconds, it will make those jumps every 3 seconds after leaving the dial. When it's set to 1 second, it will do it every second. 

Do I need the tracking? I would love to just disable it and only use relative controls...

[OffCornerDev]

Okay nevermind, found a solution (for me at least!). 

Opened the following file

~/Library/Application Support/Adobe/Lightroom/Modules/MIDI2LR.lrplugin/Client.lua

removed line 501:

501 | MIDI2LR.SERVER:send(string.format('%s %g\n', param, lrvalue))

This "fixed" the issue for me. It is not ideal... When I do edit a setting using my mouse and then the midi controller, it jumps. - but at least it is usable and works pretty well!

Thank you once again for the really quick support!

[Rory Jaffe]

Interesting. LR_IPC_In.cpp handles the messages from Lightroom, and it does translate the messages for the relative controllers. Perhaps I should just not send data back to the MIDI control surface--again, thanks for the info.

[Rory Jaffe]

You can try replacing MIDI2LR.exe with the file in this archive: https://www.dropbox.com/s/6gmxgie5jo31xi2/MIDI2LR.zip?dl=0 and restore Client.lua. The changed exe won't send values back to relative controllers.

[OffCornerDev]

There's one problem with that though: I am a Mac user, so exe files won't really help. I could try running it all in a virtual machine, but that'd take quite a while…

One issue i still have is that MIDI2LR does not read the values from lightroom when I change pictures or adjust the image manually. Maybe this has something to do with line 501 being commented out... 

[Rory Jaffe]

Yeah, commenting out that line prevents the app from responding to changes in LR. When I have the chance, I'll rebuild the Mac app with the edit I made--need access to a different machine for that. My edit keeps the app updated to changes in LR, but doesn't update the MIDI Control Surface when using a relative controller.

[OffCornerDev]

Okay pretty curious if this works. I've managed to build MIDI2LR using XCode on my mac, so maybe you could just send me the line that you've changed… 

I really didn't expect the whole build process to be so easy!

[OffCornerDev]

I am terribly sorry if I am spamming you to death. Since I am only using rotary encoders right now, I've decided to just comment all the midisending out (line 196-202) - and it WORKS! flawlessly! 

Thank you so much for your support! I guess there also has to be a more elegant solution (i.e. only send the midi information when an absolute controller is being used or something...) but it works really well with relative controllers now!

[Rory Jaffe]

you're being helpful, not spammy. Having a user experiment with the application helps development tremendously.

The git branch with the  specific fix is https://github.com/rsjaffe/MIDI2LR/tree/feature/fixrelativetracking . If you could try that, I'd appreciate it.

The only difference between that and the develop branch is the following, in which I've added an if condition to the case RSJ::kCCFlag. That tests for the control type and doesn't send back data if the control is relative.

  case RSJ::kCCFlag: 

                        if (controls_model_->getCCmethod(static_cast<size_t>(msg->channel - 1), 

                            static_cast<short>(msg->controller)) == RSJ::CCmethod::absolute) 

                            midi_sender_->sendCC(msg->channel, msg->controller, value); 

                        break; 

[OffCornerDev]

your fix works just as it should! I also tried setting the controller to absolute mode to see if it sends the value back to the controller and it does. So the regular functionality works and the relative controller works as well.

thank you so much!

[Fantomas]

Hello,

I've got the same pb as you're but the link fix is not reachable...

Can you post the file or where to put the if condition in the client.lua file.

Thanks.