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.
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.
@All the community… Are you interested to manage a repo with me. I’m planned to write a client with the electron framework. We could see easier the benefits of this technology with some applications like VS Code.
We can wrote a basic core engine with connection mechanism to acess to caspar CG. After that need to wrote a structure to allow users to create their plugins. Users can write their plugins with JS Framework like Vue, React or Angular.
Can we create a repo first. After that we need to create issue on it to trace different request. Maybe create a discord channel or other ?
Looks like discussion around a new client sadly stopped… I think, like many others have mentioned Electron is the best option to go for if there will be a new client as that is what is now a popular language. I have started to play around with the ideas from the messages above and have started working on a design taking all that in to concideration (it is basicly the same as the OG client, that is what most of us want and knows to use) with some minor fixes.
It is not finished yet to be shared here yet but are there people still intrested in trying to get something made?
I was wondering on another way, like making a relay in Node.js that takes websocket messages and channel them to normal socket, both ways.
So the client could be a simple web page, or wrapped in an app later.
I actually started doing it for my self, but maybe other are interested.
Could be nice then make some kind of library or modules, to load into the client-page, very similar to the official client when you add items on the rundown (video, template…)
don’t know, but probably NodeCG works in a very similar way
There seems to be efforts made by several people, but sadly I have not heard more on it yet.
I just looked at NodeCG (again): Seems quite a good approach doing things. Something similar as these dashboards could be created with a library, that sends commands to CasparCG instead of directly to the graphic, as they do. What maybe could be added out of the box, is a database (MongoDB?) to have a list of items, so that we get a bit closer to the way the existing official client works, what is more what is needed in a broadcasting.
thanks, I missed that part, so not very useful for a client replacement if actually needs the client
yes, why not, but I’m not familiar in what is needed in broadcasting, so I’m not sure what would be the path to follow
for now I’m thinking to a very basic template/video/audio player as an html div element. Then add the elements on a web page, similar to the center part of the official client. Mostly to setup the basic functions and have something working.
What I mean by writing this is, that in broadcasting we normally need to be able to create a rundown beforehand. For instance in talk-show it must be possible to create a bunch of lower thirds for all participants of the show. It is not enough, when only a single instance is editable. That may work in a e-sports environment etc.
