1 Topic by Chris_G

  • Chris_G
  • Member
  • Offline

Hi Joan,

I would like to control the recording using a USB remote control. We want to start recording from the camera to SD-Card with one press of a button and at the same time start recording from Kinovea via USB. I have already built a Lanc remote control for our Sony camcorder on an Arduino and would expand it.

My planned functionality includes:

  • Green LED indicating that there is a connection to Kinovea (with some kind of ping)

  • RED LED indicating that a recording is in progress in Kinovea

  • Red LED that flashes when an error occurred during recording

  • Button for changing the recording status

It would be important for us that the remote control definitely speaks to Kinovea, even if the program does not have focus or is in the background. This means we don't have to constantly look at the computer screen to see that the recording is running in Kinovea. Therefore, I want to integrate the remote control control into Kinovea.

What would be your recommendation as to how and where I could integrate the code into Kinovea?

For the remote control hardware I use an Arduino Nano Every and this project https://github.com/Novgorod/LANC-USB-GUI/tree/main as the basis. I will then publish the code for the remote control on github so that anyone can build the remote control. I think there will be two versions: one with just one button for recording with Kinovea and a remote control with two buttons, as we need it.

Best regards, Christian

2 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

To start the discussion there are two existing trigger mechanisms.
1. The audio-based recording trigger. The Arduino could send a signal directly on the mic input of the PC to trigger the recording.
2. Software based trigger. This goes through Windows messaging system and can trigger all the commands covered by keyboard shortcuts.

Both these mechanisms work even if the Kinovea window is in the background. These are only actions though, for the heart beat I don't remember if the Windows Messaging system is enough for back and forth comms. Ideally we can add another message to ask for status and get a response.

I haven't touched Arduino in a long time, is there a piece of software running on the PC side, in what language?

3 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

I'm not against adding a different control interface if the windows messaging system is not adequate. Maybe having a little HTTP server would make it simpler on both ends. Something in the vein of VLC HTTP requests https://wiki.videolan.org/VLC_HTTP_requests/

4 Reply by Chris_G

  • Chris_G
  • Member
  • Offline

Thanks for your quick answers. I think a web server API is too complex for the use case.

I have also used Windows messaging system in LabView to start the recording in Dartfish and it worked well. Unfortunately, I don't get any confirmation that recording has started.

Therefore, I thought about whether it would be possible to integrate this directly into Kinovea, as I found this project https://github.com/Novgorod/LANC-USB-GUI/tree/main and this tutorial https://hmojicag.github.io/hmi/hmi-4-Do … dPractices. My plan so far is to run a background service after starting Kinovea that takes care of the serial communication. This could be easily solved with a state machine. From what I've studied your code so far, I need a reference to CaptureScreen.cs and then I can start/stop recording and respond to the events for RecordingStarted and RecordingStopped.

What do you think about that?

5 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Yes I'm thinking about a slightly more general use-case because it would make a lot of people happy that have been requesting this in one way or another over the years.

At minimum I think you should consider that there can be two capture screens with their own status so ideally we want to get information about both and control both. With that in mind and the similar requests for control from other applications, I think it should be as high as possible in the hierarchy so it has the option to control everything and return the most information.

The top level has ways to get information about the screen supervisor and individual screens rather easily. If you would consider getting back a formatted string and extracting the information from it instead of directly getting a data structure it would be super general and most useful for every other use-case. The capture screen can be in several states: empty, connected, grabbing, recording.

So I think there should be an internal API to grab the global status from the top and then one or more entry points to expose this information to interested callers based on communication tech. The advantage of using an HTTPListener is that it would be super easy to test queries for other interested applications. Example applications: controlling via a Stream Deck, interfacing with record keeping software for competitions, advanced multi-cameras record/playback setups.

6 Reply by Chris_G

  • Chris_G
  • Member
  • Offline

Ok, I didn't know that other people had already requested this feature. Then I think an http API makes sense I guess. This would be the most flexible and you could pack the specific settings for the remote control into a small external application. The disadvantage, however, would be a certain latency in communication. However, I don't know if it's that significant.

The best solution would then be a real-time technology such as SSE or websockets so that you have a bidirectional connection and no polling is required. I have only used SSE from ServiceStack so far and have been very happy with it. The ServiceStack project also has a free SSE client.

Do you want to use a lib for the server or program it yourself?

7 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

External library is fine as long as it's open source. I think this might be common enough that the classes included in .NET could go a long way though. Ideally it would handle all the server aspect and we only have to declare some routes/requests to handle and implement the corresponding functions. Probably one thing to be careful about is the threading aspect, whatever is listening to the commands/status requests will likely run in its own thread, it may or may not have to communicate with the main thread to do its job.