Page 1 of 1

DR TCP Transport Control - behavior issues

PostPosted: Mon May 17, 2021 8:28 am
by Max Paperno

I'm working on a basic client for the Resolve TCP Transport Control, v1.2 as described in the DR manual, Chapter 121 (of the v17 edition). Although it's mostly working "as advertised," I've run into a couple issues so far.

DR Studio v17.2 Build 11 (same issues with 17.1), Win 10 (20H2 19042.985, latest updates as of this post). Using Python's socket implementation. Client and DR "server" are on same machine.

  1. When sending play command, all the forward play speeds work as expected. Eg. sending:
    Code: Select all
    [04:00:00:00] [70:6c:61:79] [00:00:80:3e]
    [cmnd length] ["play"]      [0.25 (little-endian)]

    will play forward at 1/4 speed, 0.5 at half speed, 1.0 at full, etc. However, doing the same thing with a negative play speed seems to confuse DR.

    If I send -0.25 (00:00:80:be), Resolve just crashes, with this in the debug log:
    Assertion failed: m_PlaySpeed > 0.0f, file C:\jenkins\workspace\resolve\Resolve\Cyclone\UI\Player\UiPlayerModel.cpp, line 5943

    But, if I send -0.5 (00:00:00:bf), then it plays backwards w/out crashing... at 1/4 speed. I have to send -0.75 (40:bf) for -1/2 speed, -1.0 (80:bf) for -3/4 speed, and -1.5 (c0:bf) for -x1 speed. After that, -2.0 (00:c0), -4 (80:co), -8 (00:c1) all work as expected.

    Either I'm missing something, or something is a bit off :P in the DR code?
  2. On the Fairlight page, the play speed values are interpreted in some other bizarre way... sending 0.25 starts 1x playback, going up to x16 when sending 8.0, but then when going back down, from, say 8.0 to 4.0, the playback speed actually increases to x64, like the 4.0 is being treated as relative instead of absolute. Pretty hard to describe, but clearly not working like on all the other pages.
  3. The goto command also acts strangely. It doesn't actually move the playhead (or change the preview), except on the Color and Deliver pages. On the other pages the command seems to be ignored... but it's more complicated than that.

    When on any UI page, after sending a goto, a subsequent gettc reports the same timecode which was just set with goto, as if the command worked (which on Color & Deliver, it does).

    If the UI is on the Cut or Edit pages, the goto is ignored but gettc keeps reporting incorrect position until the playhead is manually moved.

    If the UI is on Media or Fairlight, the goto appears to be ignored, unless you switch to any other page after that (w/out moving the playhead)... where you'll find that the position has actually changed to the TC specified in goto.

    Maybe I'm not understanding what goto is supposed to do?

Does anyone actually use this protocol? I can find zero information on it, except what is in the manual (and one old thread on this forum regarding the "advanced" setting to enable remote control).

I can't find any other/better (and inexpensive) way to smoothly control forward/reverse playback speeds ([Shift]J/K/L are too "chunky"]. So I got a Python script which reads from a HID and sends playback commands to DR via TCP socket. Seemed like it should be easy. The playback speeds work great, except as mentioned above. I would like to use goto for quick scrubbing/jumps per x frames/seconds (after gettc/getframerate). I plan to publish the code once I know what works or not (but I could post it sooner if anyone wants to play/test).

Let me know if I can provide any further information. I tried to keep this as brief as possible for now. :?


Re: DR TCP Transport Control - behavior issues

PostPosted: Mon May 24, 2021 5:54 pm
by Max Paperno
Code: Select all
> ping BMD

Pinging BMD with 3,545 bytes of data:
Reply from Destination unreachable

Re: DR TCP Transport Control - behavior issues

PostPosted: Mon Aug 09, 2021 6:14 pm
by ambustion
Hey Max,

I found same as you, I just think it only works properly in full integers. What's more is some commands only work in color page, and some in edit. Would be very interested in seeing what you have working so far if you are interested in sharing. I have everything working you mentioned with python, but first time trying tcp so would love to compare.

It's super handy for grabbing stills or jumping to notes from a treelist if you are making guis at all though. Seems pretty solid in the color page.

Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Aug 14, 2021 8:56 pm
by Max Paperno
Hi Brendon,

FWIW, I submitted a support ticket regarding this issue to BMD, and eventually that led to this reply on June 10th (2021), but I haven't heard anything since then.

I was advised that a developer was assigned to look into the case. This limits our current visibility in the progress of this case, but I will let you know if we get any specific responses or follow-ups.

For this and other similar reasons (lack of support, constant bugs, proprietary everything) I've decided not to invest any more resources into DR or BMD at this time.

Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Aug 21, 2021 1:27 am
by ambustion
Too bad. I agree it'd be great to have a line of communication with the developers. They add things I want every update for API and I just use it to increase productivity in my own workflow so understand if you are not using it to just poke around as a bonus it would be frustrating.

If I get any headway I'll share with you as well.