Vary speed dynamically based off lines/words per minute and characters per second

Is your feature request related to a problem or a limitation? Please describe...

To be honest, we do not understand the logic of all those speed settings. So we set everything on 1 (Base Speed, Curve, line height) and the start velocity. And at the top of each file we show the velocity settings, just by writing it down.

We use a teleprompter for videos that have a certain length. For instance, 2:50 minutes. The text is made by an editor.
If it is longer, the editor remove words and sentences, until it fits in 2:50 minutes.

Now we instruct the speaker carefully what settings to use.
Our speakers want to adapt the font, and other layout features to his/her own monitor and distance to the monitor. But we cannot allow that because that influence the speed. We think that the interdependency of speed and layout is a usability error. But an error we can live with because we can simply forbid the speakers to use those values

Describe the solution you'd prefer

In the Start Velocity, you have can set a value. We would like to add two other values at that point:
- speed per line, in lines per minute.
- characters per second. It is of course not perfect, but good enough.
Dynamic speed Each new line is interpreted for speed, depended on the two parameters.
Store parameters in the file To store the speed parameters in the file. So we can be sure the speaker will use those parameters
Make the speed parameters visible in the file. And the speaker cannot change it.

Describe alternatives you've considered Use powerpoint. In combination with OBS studio for flipping the monitor screen.

Provide use examples All videos that are made by copywriters follow this workflow. ...

Explaining velocity settings

When text is close to still, changes in velocity are more perceptible to readers than when it is going faster. Ideally, velocity should increase following an exponential curvature that matches the reader's perceptibility of changes in velocity. Unfortunately, perceptability varies across individuals and properties like text size and words per line.

"Base speed" is a constant that gets multiplied to obtain greater velocity with each "velocity" step.
"Acceleration curvature" alters that constant so that it has a greater effect the faster the text is going.

An acceleration curve of 1 means velocity will increase linearly with each step. An acceleration curve of more than 1 follows an exponential curve where velocity grows by more with each velocity step that is taken.

On the interdependence of speed and layout

I agree that the interdependence of speed and layout is a usability error. Most of the philosophy behind Imaginary Teleprompter and QPrompt's design was around making all settings have consistent outputs across screens of all resolutions. Extending this treatment to the individual properties of rich formatted text is the next logical step.

The countdown in QPrompt is a simple function of time and velocity. To make the ETA remain constant, all lines should have the same height at all times or speed should vary relative to font size and line height. It is inconceivable for all lines to have the same height if QPrompt is to support multi-language scripts because there may be a need to combine different fonts for the different languages. On the other hand, varying speed to compensate may do the job, but it could have a negative impact in usability, as operators might expect the text to move at a certain speed when velocity is set to x steps, but it would move faster or slower as a result of formatting differences.

I do think ETA should remain constant or not vary by much irregardless of formatting. But this is a complex issue that needs thoughtful consideration. Let's continue this discussion at issue #21.

Feature request: Dynamic speed (speed in lines per minute and characters per second)

This idea sounds good, but the proposed implementation wouldn't work across all languages. A symbol in a logographic writing system could be a word of any length, thus a model with comprehension of the symbol's phonemes would be necessary to correctly change dynamic prompting speeds.

Nevertheless, this is not a reason not to implement what you propose. The program could hold multiple implementations of dynamic speed, and switch between them according to the language of the paragraph currently being read. Characters per second works very well for German because of komposita, while other languages could better benefit from words per line.

Because of these differences, I've already begun work on a more complex, more universal, machine learning implementation that analyzes properties like word bounding box geometry, paragraph language, user inputs, and prompter settings to create a model of the speed that each line should be given.

This particular feature would only be available in paid versions of the program. It also won't come out any time soon, as first I must finish implementing telemetry functionality in way that meets my high privacy standards, and collect user data for an extended period of time, enough to create the necessary models.

The main takeaway here is parameters such as desired lines/words per minute, and character per line, should be taken into account by the model as well for it to be suitable for productions that must fit strict time slots.

Feature request: Store velocity parameters in the file.

I had thought about doing this but haven't gotten around to it. Duly noted as a separate feature request at #23.

A professional presenter will never follow exactly the speed of the teleprompter. If he/she does that, it sounds very unnatural. Some sentences (question type, slight emphasis) need to a slight delay, other sentences must be speeded up. Quite often the presenter is a few lines ahead, of a few lines later.
That is the reason two parameters are, in our experience, good enough. And maybe, you can do it a little more precise, but I doubt it is a real improvement.

About the paid version: If you could export subtitles, or have a version with this parameters, for us it is reason enough to switch the paid version. (And be aware, we checked and sometimes purchased >10 different applications, none of them has this features)

In order for speed variations not to result in jerky motion, speed changes should be interpolated between lines. This would prevent the prompter from being in perfect sync, but it should be easier to read than if it were.

Interpolation could be added with either implementation. I'll add your proposed solution to the list of goals.

I'm copying this excerpt from an email conversation I had with another QPrompt user here, because it'll be relevant once I start developing this functionality. The emails date May 7, 2022 and are stored in my main account (in case I wish to look them up).

Steve M.

.. if you could see each character, you could double count for comma and triple for period, building a char table for any other equivalents (different tables for different languages).

@Cuperino

.. If I were to iterate through the characters and count them, this could cover punctuation marks for Roman, Cyrillic and Asian character sets. In fact, I already have a list of those somewhere…

The challenge is in parsing the text quick enough for real time changes not to slow the prompting on large documents. The Qt framework provides me with two different data structures to navigate text, for its textual and visual representations respectively. I’d have to test the performance impact of traversing these to update the ETA when changes occur. Alternatively, the ETA could be determined and cashed on a separate thread, and we only use the lines in front of us to determine animation speed the block of text ahead.

Cuperino / QPrompt-Teleprompter