UI Feedback Loop Solutions

[Gavin Greenwalt]

I'm getting a feedback loop when changing values very very quickly.

E.G.

0.0ms | Set - shutter target - 1/200th

1.5ms | Set - shutter target - 1/288th

1.6ms | Current - shutter target- 1/200th

2.0ms | (1/288th != 1/200th) UI Callback: Set Shutter target 1/200th

2.6ms | Current - shutter target - 1/288th

2.7ms | (1/200th != 1/288th) Callback: Set Shutter target 1/288th.

Etc.

So that sets it into a loop. How are you guys solving this feedback loop? Should I have a rotating buffer and set a conditional to only use the latest as long as the latest is > 100ms old as a 'cooldown' period? How does the SDK Handle this situation?

 

[Gavin Greenwalt]

Here is a real snippet off wire shark:

ms | action | value
647.1 Current: 12000
648.1 Current: 9600
648.8 Set: 12000
650.8 Set: 9600
676.0 Current: 12000
693.4 Current: 12000
695.2 Set: 12000
722.4 Current 9600
723.3 Current 10000
724.4 Current 12000
726.3 Current 10000
727.5 Current 7200
728.0 Set: 9600

So it actually looks like it's taking a few ms for the value to change. Which is what's causing the feedback loop. Should I lock the UI from accepting changes until a Current is received from the camera as a confirmation?

 

[Gavin Greenwalt]

Or maybe do something like this and have a queue system. Where it only sends out new changes when it receives confirms?

struct paramQueueStruct
{
int QueuedTC;
int ConfirmedTC;
string packet;
}

Dictionary<string, paramQueueStruct> ParamQueue;

OnReceivedConfirm(string paramID, RDCPacket CurrentPacket) 
{
      if (ParamQueue[paramID].QueuedTC > ParamQueue[paramID].ConfirmedTC)
      {
          camera.send(ParamQueue[paramID].packet);
      }
      else
      {
           UI.update(CurrentPacket);
       }
}

 

[Gavin Greenwalt]

Bleh I'm an idiot. It's late at night. Time to sleep. The problem is obviously the fact that the Current changing the UI is also triggering a packet fired off at the RED. The UI should change "silently" when it changes due to currents. The camera already knows what the current is hence why it sent a current.

EDIT: No, I'm not too tired, it won't fix it. It will help it but it'll still result in a wonky UI where if you move the slider it'll jump back to its "old" position from 20ms ago. But it should prevent a loop. It'll just lock up the UI control.

EDIT EDIT: Ok in practice even with really really fast UI spinning it doesn't seem obnoxiously noticeable. If someone wants to really really change the shutter fast it might skip around a bit and I'm "ok" with that. But if there is an easy fix I'm all ears. Creating a queue event system seems like overkill for such a subtle flaw.

 

[Trent Lillehaugen]

A few comments/notes:
- Why is your UI sending out a SET in response to the camera's CURRENT message? You should really just send out SETs if the user manipulates a control, and update the control's position based on a CURRENT from the camera.
- There will inherently be latency when sending SETs to the camera and receiving the CURRENT. On top of that some parameters will take longer to process on the camera before sending out the CURRENT - your application should be prepared for that and designed to accommodate it.
- Our general approach for controls is this: If the user is manipulating a control we will ignore currents from the camera until some time after the user stops manipulating the control. At this time we will update the control with the last CURRENT we did receive. If you want to be lazier about it you could simply send out a GET after your timeout and the corresponding CURRENT will ensure you are in sync with the camera.
- I cannot stress enough how important using the API is. Although it doesn't address your UI problems directly (as it focuses on parsing, logic, string creation, dependencies, etc) it does offer quite a bit. Even something seemingly as simple as exposure time gets fairly complicated in our camera. For exposure time, the API takes into account: Frame processing mode, frame processing number of frames, motion mount mode, exposure assist mode and settings, playback state, user display settings, etc. If you don't implement the same logic as the API the user can potentially be presented with seemingly conflicting information.

 

[Gavin Greenwalt]

I hear you on the API but I'm not going to be offering full functionality. It's more of a barebones demo application and draining the swamp during porting and merging it over to WinRT was turning out to be more work than just directly communicating with the camera from a clean slate. It also gives, at least for me, a much easier to understand and use OO api.