Multi-instance Remote Control

[dionzand]

Is your feature request related to a problem or a limitation? Please describe...
The limitation is that I want to remotely control the teleprompter.

Describe the solution you'd prefer
I see a nice solution by implementing a websocket to connect multiple clients to a certain master control. For instance as in Eyevinn's teleprompter. Of as in dreamteamprod's DigiScript. There you have one master that controls the teleprompter and multiple clients can connect to the master via websockets. This way all clients are always in sync with the master.

Describe alternatives you've considered
Another option I like, as has been opted before, is remote control via an API. But this does not directly solve the problem of keeping multiple (remote) clients in sync.

Provide use examples
For instance i want to place multiple teleprompters around the stage for all presenters to be able to walk around and see the screens from all over the stage. But I want to do this wireless, eg not connecting the screens to the control computer via HDMI.

[Cuperino]

I see teleprompter transmission, screen duplication, and remote control as three separate features. I'm cataloging this under transmission, since the goal is to be able to have the prompter being presented across multiple devices. This could be accomplished either by synchronizing multiple instances or by broadcasting a video feed that all instances can pick up.

When creating QPrompt I decided to not go the synchronization route because it leads to inevitable de-synchronizations and the act of re-synchronizing, however subtle, results in jerks that people notice. Said jerk was the most reported bug of all in my previous teleprompter app, Imaginary Teleprompter. For QPrompt I will take the video transmission approach. My plan was to accomplish this using the NDI protocol, but I don't see why we couldn't also use WebSockets for this.

Video transmission is more expensive in terms of hardware utilization, but it yields more consistent results. I don't think that it would scale-up enough to work inside of a stadium, but multiple screens should be achievable through multi-casting.

Referenced:

• NDI output ticket, NDI Output #41

[dionzand]

Thanks for the quick reply :). I really like the NDI protocol, but I believe it is proprietary, not open source? Besides, it seems a bit of overkill to first create a video stream for something that is only text/string data... To me it sounds more logical to only send the current scroll state of the teleprompter over network to multi clients. I can see how this could result in "jerks", but it think that could be solved more easily (i.e. slow slide to last updated/received location), than a bandwidth-intensive video stream.

But I agree that an NDI stream is also nice to incorporate in different media systems.

Best,
Dion

[Cuperino]

NDI is proprietary protocol, but the headers to use this library are open source, meaning QPrompt's license wouldn't have to be changed to accommodate NDI. However, the NDI library used by QPrompt would have to be licensed to users using a separate license agreement, so anyone wanting to use QPrompt with NDI would have to agree to that. That said, I plan on adding other streaming options, so people aren't limited to agreeing to a proprietary protocol if they want to stream the prompter as a video over the network.

To me it sounds more logical to only send the current scroll state of the teleprompter over network to multi clients. I can see how this could result in "jerks".

A slow slide could work, but that alone is not enough. All teleprompters would have to present at the exact same resolution. Any discrepancy would result in different font sizes being used, which often use different glyphs, leading to line breaks happening at different words, which would cause the prompters to go crazy or very out of sync because they are no longer able to sync.

If you don't want display resolutions to be exactly the same, everything about the contents being prompted: aspect ratio, glyphs, images, text formatting, margins to the edges of the screens, etc, would have to be perfectly proportional, which is impossible to accomplish using system fonts because of the very nature of fonts.

You're welcome to implement multi-instance synchronization if you like. I'll gladly help you avoid all the pitfalls I fell into over 5 years, trying to get Imaginary Teleprompter to synchronize its screens using inter-process communications. That said, this requires a strong foundation. The following changes, or more, would have to be done for this to work:

• Add means to fix teleprompter viewport resolution across all instances.
• Fix an unnoticeable imperfection that causes prompter's destination to vary by 1 pixel with every velocity change would also need to be fixed.
• To mix resolutions, the instances on the receiving end would have to allow for scaling their teleprompter instances.
• Remote control API would have to be developed, which would be used as the back-end to enable this functionality.
• Means for the leading instance to act as a remote control would also have to be implemented.
• Lastly, the program would have to prohibit anything from being modified on secondary instances when the multi-instance remote control is in use.

[dionzand]

Thanks for taking the time to discuss this topic in depth :) much appreciated. I can certainly see now how al these things make it hard to synchronize over different clients if they have different resolutions, fonts, font size; word, letter, and paragraph spacing...

I have not looked into your backend yet on how the "scrolling" works, but you mentioned that problems can already arise when there is a 1 pixel difference, so I imagine that scrolling takes place based on the position in the "image" of the script (ie "I am now at this exact y-position, when using this set of font, spacing, etc.")? And not based on the line position in the script (eg. "I'm now at line 182 of the script"). For multi-instance syncing it would be beneficial to do use the latter. Just communicate over the network "master control is now at line 182 with this velocity..." (and maybe other metadata) and scroll all clients to that exact line. I agree that velocity for instance should then be converted/recalculated for that specific client, based on that clients settings - and then still it could be that it is not always very fluent. But I don't know if that is a problem. If the idea is just to have the script at the same position at all clients at all times, it could work to just communicate the line positions.

Let me know what you think.
Best,
Dion

[Cuperino]

The text itself has no concept of a line. It's words separated by spaces, and every now and there, a special character or separator splits them into blocks called paragraphs. These "paragraphs" can have 0 or more things inside of them, including images. Each time that you press Enter/Return on a keyboard, a new paragraph is created.

The lines you see on screen are the product of word-wrapping. These are, therefore, a local graphical representation of said text. The prompter engine concerns itself solely with coordinates in pixels. If we want the prompter to go someplace different then we must compute the desired position into a y coordinate and compute the time that the prompter should take to reach said coordinate.

There are ways to go from pixel coordinate to character cursor position and from character cursor position back to pixel coordinates.

[dionzand]

Ah I see! You described it very clearly, thanks. Then communicating only the "paragraph" position is not enough.

You mention that a "line" is the the local graphical representation of a word-wrapped product of the underlying text. This makes a lot of sense! And I can see that word-wrapping can be different between clients and therefore hard to sync.

Then indeed a "line" could have a starting and ending character cursor position, than could be communicated to clients. But then still it would be difficult to calculate that back to a given y coordinate and velocity...

I am starting to understand why you opted for a video stream. Although I still think that is a bit of overkill. Would it otherwise be possible to do force the exact same layout and word-wrapping in the clients, so communicating only the scroll state is sufficient to guarantee synchronization?