Discussion about the specification of a new "official" client

Thanks @dan. @7sorkr you can just remove that line in inside gui/label.cpp. I am no longer using any literals, but forgot to take it out. D-mo

1 Like

New official client:

I would define (or not) for each channel a preview channel.
I would add in settings “show preview” checkbox.
I would add in GUI a “preview” button.
Whenever is pressed next things should happen in the pre-defined preview channel if this is configured.

Show preview checkbox will still keep the actual look of the GUI or add preview button
(not to interfere to those accustomed with the actual GUI look)

Making things a little bit complicated I would add a 2nd checkbox in settings
something like “1 preview”.
If checked to switch back automatically to program after 1st play command in preview mode.

To understand that: When you navigate to another item in the list of events, the preview would automatically fire? What about scrolling trough the list?

What will switch back? You would kill the preview of the item, when you play it? What would be the point here? The preview channel will anyway be verwirrten by the next event.

In general: Interesting ideas, at lest the ones I understand, but why is having a preview that important for you? What is your intended workflow?

@didikunz
On 2nd thought I think you’re right.

Today we have preview on F8 and we can define preview on another channel/consumer.
My idea was to multiplex somehow the F2 play command between preview and program but indeed that would add an extra step.

Not multiplexing command we can keep the direct access to both program and preview and not one at a time depending upon button status.

As of the importance of preview is when airing a news bulletin and last minute changes are made by CG operator.
PVW is at least useful to check whether the text exceeds or not the field on the lower third, not to say to check the misspellings for example by someone else which doesn’t see the CasparCG GUI but can see the CCG PVW out on the multiviewer.

For sure on productions which happen as planned (like talkshows) the need for preview is not so required. Even for sports is not so critical since the score generally is incremental, there are rules to play, and probably sometimes you have some sort of data connection with scoreboard or data from referee tablet.

On news there are no rules and the data are sometimes entered manually especially on live hot events.

So briefly my idea is a bad one at least in terms of speed of operation. F2 and F8 should suffice.

Returning to bad things which sometime happens there is the minimum time a lower third
should stay on screen. The rule is worst case 3 seconds but not less than someone should be able to read it at least once (if not twice). But that I dont know how can be implemented other than counting the number of characters to be displayed on a lower 3rd.
I often see, even at the station I’m working with, extra long text staying 1-2 second and then replaced by another one. (but this is another story) And that’s annoying for the TV viewer.

I do that by building the templates so, that the text get squeezed, when too long. As HTML (and Flash) allows programming inside the template, that is very easy.

I don’t think your idea is bad, but I wanted to know your workflow. I think it is worth thinking about ways to speed up thing and make it save for operators. I sometimes also need somebody to check spelling in situations were everything is done “free flying”. But would not go for a preview for each individual channel, as I think a common preview for all channels is a better solution, as it does not demand that many channels and monitors.

I usually read it two times before taking it out and I do that by hand. But you could add code to your templates easy to count the numbers of characters sent to it, multiplied by a factor for the average reading time and doing an auto-out after that. I would not want that to be in a client, as it is hard to figure out, if a text variable sent to a template is actually something the viewer will read or simply a filename of an image etc. So putting the code into the template would make it easy to distinguish these cases.

@didikunz . I know about squeezing text
and it is okay as long they do not abuse.

You say " I sometimes also need somebody to check spelling"

How is that somebody else checking:
sitting next to you and looking at your GUI
or he has some other kind of access for preview?

It depends on the setup. Last time I had one looking at the GUI as this studio had no preview, but sometimes I have a preview and the director or producer checks it from there.

Sending OSC commands would be great feature ! it would help in many circountances

It would be nice to be able to know which video is loaded on wich channel and layer in the server osc train.

It would be nice to be able to edit video input time using TC instead of frames mesurement. Also be able to set output time instead of length.

The current layout is quite effective with a few major problems as discussed above. The method of data input in the UI definitely needs to change along with the implementation of how the preview and live windows are populated. A few improvements could also be made for the rundown entries.

Important features:

  • Default client is able to run on any platform including arm single board computers and tablets.
    This is the real reason to change programming languages. Qt/c++ is already extremely cross platform, but setting up compile environments for each destination is cumbersome and limiting.
  • Plugin architecture for tools to allow customization for specific templates.
  • Required function for HTML templates that returns template title, data variable names and other info. (another method could also be used if better)
  • Rundown entry shows template title field along with important data fields.
  • Template input data shown in rundown item entry allows click to edit…
    The majority of templates only a have a few fields that change often.
  • Other data can be input with inspector field, drop down, or some other method.
    Whatever fields the template author wants to expose, but rarely need modified.
  • Plugin interfaces to allow customization of data input portions of the client
  • Preview shows template layer over generic background.
    The current method of creating preview channels, setting up streaming, etc is complicated for new users to set up. A preview solution should be built in and functional by default regardless of architecture.
  • An option to have a preview state that only shows thumbnail versions of templates, graphics, or other tools. The thumbnail displays a snapshot of how the item will appear at a specific point in time using input data from the selected rundown entry. For lower third templates this would be the fully displayed state for example. Rundown items that are not loaded in the server will display a not loaded thumbnail when selected. Streaming takes processing and network resources, and the default option should use as few resources as possible.
  • Allow custom naming of output channels, layers, etc.
    The graphics operator should not need to have all the layer, channel, and server numbers memorized. Names are for operators, numbers are for engineering.

Many of us, including me, would like to see a web based default client. Will this interfere with the ability to use keyboard shortcuts or custom input panels and devices?

I would really like to make a CasperCG console with a small single board computer with a keyboard, mouse, monitors, and a few hardware buttons for common shortcuts and macros. I would hate to see us go down a development path that made it difficult to have keyboard shortcuts and custom buttons. That said, a solution that allows the client app to be run on a device without having to install software would be awesome.

Are there any opinions on reusing Sofie’s timeline-state-resolver to control CasparCG in such a client, and abstracting the actual ACMP commands? Or would a potential client have to have raw ACMP control of the server? Would it make sense to include both options in a single client?
I can see several advantages in using Sofie’s existing timeline tech, as we would be able to fairly trivially restart both server and client without losing any state (at least I think so :P).
In addition, we save a bunch of work by basically writing an user interface that outputs a timeline for the TSR library, instead of controlling the server manually.
Any thoughts?

The bad thing about this tread is, that I had the intention to build something, when I started it in May 2020, but never had time to do anything.

The basic idea was to have something similar to the current official client, written in a language for the rest of us (not c++). It would be a list oriented thing. The problem with a timeline oriented rundown is, that everything needs to be in sequence. That is true for news shows and the like, but not for anything else, like sports, games, not even talk shows, so this would not be use full as a replacement to the official client.

For all, that look for a universal Caspar client, that has a list and also a lot of extra functionality to query for external data etc. I can recommend my Excel AddIn. It makes Excel (under Windows) a CasparCG client.

I’m actually toying with picking up an old personal project again, which is why I asked. Originally, I was going to go in the direction of controlling template data elegantly, but having this integrated with an entire client would be quite useful.

Is it though? The official client is a list of cues, yes, but as far as I know the client doesn’t even offer some kind of automatic step through the entire rundown. QLab, for example features a similar layout but is clearly oriented towards sequential playback. I think the client just happens to use a list to display all cues. I see no issue with simply having the layout toggleable to a grid view, for example.
How would you have cues organized for a non-linear show setup like a live event?
I’m quite open to ideas here, though I don’t know if I will actually have the time to build something.

This is an important question in my opinion, as I personally think having an abstract concept of playback would be quite practical in a client. I’m interested to hear if other people think having the client directly send AMCP commands from “cues” is important.

I see no reason why that should not be an option. But it should always be possible to skip out of the sequence to play something else.

I usually to something like a sequence somehow (I seldom use the official client in production), but then I just point an click a list entry to play that graphic. If you do for instance a talk show you would have a few lower thirds for each of the participants, probably ordered by participants. Durring the show you choose one, that fits what he or she is talking about and play it. So it’s totally random.

I would think it needs to send AMCP commands directly, as the way Sophie does it, with states, is based on a sequential model. For a random “click and shot” workflow that is not usable, I guess.

That’s not entirely true, it depends on how the state gets defined. The most simple way of using timeline-state-resolver would be to have a running ‘current state’ object that gets added to and removed from when things are run. In this mode, the only things that I can see TSR helping with is an overview of what casparcg is doing (assuming nothing else is controlling casparcg), and with delaying things happening.

I’ll admit I don’t do many productions, but I do often use the official client for knowing what is needed is not known until onsite. Its always been possible to make things work, although often in a pretty horrible fashion (groups of lots of manually written commands). I will probably try using just companion instead next time.

Do you have an opinion if it would be sensible to use TSR in a universal CasparCG client? I’d imagine you have a deeper insight into the limitations of the TSR library. Are there many CasparCG features that are not exposed through a TSR connection? I’ve played around a bit with TSR a few months ago, and as far as I can see this is completely separated from the media management aspect of Sofie, which means we would still need a separate connection to CasparCG to get the available media files, correct?

A potential advantage I see in using TSR is easy support for all kinds of other playback devices, such as ATEMs, or other vision mixers, by just writing a very simple wrapper and the corresponding UI. Though, the general consensus in this thread seems to be that control of external devices should not be in scope for a Caspar CG client.

Sounds pretty interesting. I never had think about that. That could indeed be a way to go.

The current official client has also a few external devices, that it can control. If we could use, what Sophie offers, why not do that?

In the studios I work with, control of external devices like ATEM switcher macros is critical to how we use the CasparCG official client. This is how we fire program start graphics, start the recordings, and talent program clocks. I think implementing the full existing client feature set is critical to actually replacing it instead of forking development resources.

We run multiple CasparCG channels to fulfill several different purposes in the facility all from one default client. These channels also handle overlays for various monitors.

If a state based resolver was used, it would need to be able to be restricted to specific channels and time periods. The current group/delay method is extremely primitive and doesn’t always work properly.

Mini timeline style events would be awesome for program start and credit roll events that involve multiple templates and channels. Asynchronous or out of order template usage is also important though. It could proove useful to be able to arm a template to fire on an external signal from an ATEM or other device also.

I know many are already doing things like this using custom clients or template variants. My normal graphics operators are not programmers though, and creating a custom client is not feasible. I would much rather focus any development efforts I can offord on improving the default client functionality.

Hello,

So someone start the project, do we have a github repo or for the moment it just a Christmas wish list :smiley: