Discussion about the specification of a new "official" client

Let us discuss here, what we would like a new “official” client be like. In other topics the idea of a Electron (or similar framework) app came up, because this would allow the client to run on all platforms. Another priority for a “official” client would also be, that it supports the full set of AMCP commands.

1 Like

I must say that I like the look&feel off the “old client”

left the toolbox
middle the rundown
right the inspector

is for me quite a nice way off working

but I guess the first question would be language / framework / lib choices

and if it needs to be backward compatible


A non-exhaustive list of things that I find useful in the current client or would like to see (not ordered and in no way a Minimum Viable Product)

What I’m currently happy about:

  • Media library (with search/filter)
  • Tools section
  • Grouping
  • Remote triggering over OSC
  • OSC feedback for countdowns
  • Audio Meters
  • Multi Server Support
  • JSON template data (for html templates)
  • The UI in general seems intuitive to me, especially once you know (or gaffe tape) the shortcuts on the fn keys

What I’m currently not happy about (besides maintainability)

  • OSC data from multiple servers is interpreted as one server
  • Performance is bad with a lot of servers sending OSC data
  • The OSC data is a bit shady, sometimes doesn’t work (may not be client related but a flaw in OSC in general)
  • The tools for adding in data to templates is limited to key-value pairs. I would love to see some more UI options
  • No tools to link external data feeds (XML / JSON API’s or maybe even excel sheets?)

Other wishes:

  • Looping groups
  • No configuration tools for server
  • Having server and client always run as separate processes can be confusing to new users and to some may seem unnecessary, a possibility to always run a server executable in parallel (like the 3rd party launchers do currently) sounds nice

One wish from my side is that the backend would be losely tied, such that it would be reasonable to rewire this for other protocols

I too like the feel of the current client. It does the job, and I think is a good starting point to aim for a first version.

To me the main problem with the current client is that it is a pain to maintain.
I agree that something electron based would be ideal. I have suggested this to others before, as if done correctly, the same code could run in electron or a browser.

Adding on to what others have said, some key things I think that could be improved on:

  • Multiple users working on/in the same rundown (separate data inputter and operator)
  • Better custom commands/triggering of things with non-standard hotkeys (eg, when loading a group I want to not apply the transform. or when loading a group I actually want to play some of the things)
  • Integrate the client with companion, to allow for proper control from there
  • Able to run the server (and scanner) as child processes. This should be optional
  • Upload media to the server media folder (possibly only viable if used via a browser on another machine)

I would add that I think that some bits like the atem & tricaster integrations should be left out, as that could instead be achieved by either running the show from companion, or letting the client trigger some companion keypresses

1 Like

Agree I think it made sence back then but there are other nice tools now.
If people need it maybe on a plugin bases / being maintained separate.

Simple tying in external datafeeds would be nice indeed

I like the current client, only some things have to be added or fixed and it´s fine… Just finish the open topics on the official Github Client page and we´re good.

Add possibility to schedule command.
Add possibilty to make a playout playlist with schedule and switch for live.
Add a panel of buttons where you can assign custom command. Like a pad
Plugin management like vs code to allow user to design custom panels and tools

That is correct. The problem with the current client is, that it is written in C++ and there are not too many of these developers available to keep it updated. That i why we wanted to have a new one developed in a technology “for the rest of us” :slight_smile:

Personally I don’t like the way the editing of template data is solved on the current client. That list on the bottom right is very basic. Nice would be a way to query the variable names and types from the templates on the server (currently still only possible in Flash) and auto create a form view with all available fields to be filled out.

But I know, that would involve us to come up with a solution to query the variable names and types from HTML (and PSD) templates. I think I did a feature request for that long ago, but it seems I am the only one, that likes the idea.


Yes - a uniform way of querying variables or public functions would be great.

Also a uniform way of generating previews for templates would be fab.


The only two things I’m missing on client are autostep (play next clip without grouping) and decklink videohub matrix router control (for example to pre switch the next live source from within the same playlist)

I have to admit that for being a real playout server replacement those two functions should happen on an automation service either on the server itself or on a separate one but not on client side since client can be disconnected at last when running unattended.

1 Like

If we would add a way to send OSC commands, that could easy be done by using Companion, as it has commands to simulate button clicks.

1 Like

Another simple idea instead of implementing specific protocol for matrix router is to be able to trigger external script.
I can imagine a script which telnet to the matrix router perform a matrix switch and then exit.
Also if we have other devices which can be controlled by telnet for example we will be able to trigger some functions from within playlist.

It would be nice if the new client will be web based with authentication.
(Pandemic forced us to work remotely as much as we can)

1 Like

In Official client there is no MOS connection with NRCS. if any open source NRCS software available build the client with NRCS. It is useful for every broadcast news channels.


I saw the website for opensource NRCS i got the below information.

Previously, most TV channels in Bangladesh and around the world had to purchase expensive software solutions called News Room Control Systems (NRCS) to produce and run their news. These systems have to be bought from proprietary foreign vendors, and require steep annual maintenance fees; however, Deepto TV has been able to replace its expensive foreign-supplied NRCS software with free/open-source alternatives, saving foreign currency and allowing the TV industry to be more technologically independent.

TV news production involves several tasks which need synchronization. First, reporters and cameramen have to go out every day to gather news stories. News cameras record video footage which has to be saved on to the hard drive of a computer for editing down to a usable length using video editing software.

At the same time, the reporter has to write up news text to accompany the video, which will be displayed on a teleprompter and read aloud by a news reader. A news editor has to modify or approve the news text, decide the sequence of the news stories, and schedule the news text and videos to air at the same time.

NRCS software is normally used to synchronize news videos and news story text; during a live news broadcast, the news text has to appear in front of the newsreader teleprompter at the same time that the associated video is played. While it sounds complex, Deepto has been able to get all the above functionality by customizing free/open-source software.

Deepto TV (and its parent company, Kazi Farms Group) is already a user of free software like Ubuntu Linux (www.ubuntu.com/desktop) and LibreOffice (www.libreoffice.org) instead of proprietary alternatives. In addition, Deepto TV has used the free/open-source CasparCG (www.casparcg.com) playout server developed by Swedish state TV to play out all programs and ads for the last two years.

Journalists edit their news footage using KDEnlive free video editor (www.kdenlive.org), and save videos in the media folder of CasparCG playout server, which can play them out during news broadcast. CasparCG playout server can also add various graphics to news videos (Deepto used CasparCG for all 2018 Bangladesh election news graphics).

However, CasparCG is not set up by default to manage news text, which has to be read by the newsreader alongside the news videos. But the free/open-source CasparCG Clip Tool extension to CasparCG can schedule and queue video clips (https://github.com/olzzon/). This enabled Deepto to utilize CasparCG to control news video playout as well as programs.

Fortunately, the writing of news text by a journalist and editing of the text by a news editor can be accomplished by Newscoop (https://www.sourcefabric.org/), a free/open-source software designed primarily as a content management system (CMS) for news websites. Since Deepto TV already uses Newscoop to run its news website, it made sense to also use Newscoop to create and edit news story text. Once the news text is uploaded into Newscoop, the news video clip in the CasparCG media folder can be linked with the Newscoop text, which ensures that these two can be synchronized.

Once Newscoop news text is linked to news videos in the CasparCG playout server, an editor has to order the news stories of the day for playout (this sequence is called the run-down). In Newscoop, the run-down takes the form of a web page containing a list of news stories with associated video clips, which can be dragged and dropped in to the appropriate order.

Once the run-down order is finalized, the news text is sent to the news reader teleprompter in the correct order in the form of a web-page which can be scrolled down and read by the news-reader. Likewise, the CasparCG news playout operator can see the rundown and play out the appropriate news videos at the right times.

In this way, the combination of free software like KDEnlive video editor, CasparCG playout server, and Newscoop CMS fulfill all the required functions of an expensive/proprietary NRCS for Deepto. However, as the new system is entirely composed of free components, there is no purchase cost or annual maintenance fee. This has allowed Deepto to run its TV news entirely on free/open-source software.

It is hoped that other companies in Bangladesh will adopt free/open-source software to enable the country to achieve technological independence from foreign vendors. Ultimately, a country should aim to be an innovator of technology rather than just a customer. Open-source software offers a means to accomplish this.

It‘s not the intention to have a MOS enabled client, as that is a very small part of the game. There are news room solutions for Caspar already available (Sofie). This is meant to target any other program, that needs graphics and where there is no news room background.


You are correct that is without MOS. Is it possible to integrate Our Official Client with MOS and NRCS ?

You did not understand. There is the Sofie TV automation system, that you can use. So, in my opinion, it does not make much sense to try to integrate MOS into such a general purpose client software. But we sure can discuss it. As said, for me this has the lowest priority.

Ok sir,

Thank you. I will try to integrate this.