This might be super trivial (or not in scope) but I can’t figure out which of them it is .
I was trying to figure out if I can have several Caspar clients connected to one server where each of them prepares cg packages without these showing and one of them being “master” client that triggers a selected package to be shown .
Use case : a studio with two positions; CG and TD . The CG position will have a Caspar client using it to prepare next graphics to be shown. When done he/she informs the TD that it’s ready, the TD can then (using his/her own Caspar client) play the prepared graphics at a convenient time while the CG position prepares next graphics
You ask something simple but infact it can be a bit strange how to achief this with the default clients only.
So i understand your confusion.
This is because the client and server are a bit inconsequent in how they do things (and how it is presented) and it also depends on how you designed / programmed the template.
if you added a template in the rundown and only press “F2 / play” the client actually sends a CG ADD command instead off a CG PLAY.
It only send a CG PLAY if you pressed “F3 / load” first (ON THE SAME CLIENT !!!).
with multiple client’s this get’s a bit confusing because the client’s don’t know from each other what they have done.
CG ADD is “sort off” a combination of UPDATE&PLAY
one way to achief what you want is to
make your template in a way that it animates in on invoke instead of play.
let the CG operator play the template with the prepared data
let the TD invoke the template to animate it in.
but there are lot’s of different ways to get this done more conveniently
but again i understand the confusion
Thanks for the thorough explanation , it seems like a bit of odd behaviour . So if I have a package of a number of templates all playing animation on invoke instead of play. Then I have the CG operator play (F2) on each of them , when the TD wants to show the graphics he/she will invoke the server (F7) but will do so in “blind” I.e. will have a blank rundown in the Caspar client window .
Too bad special templates are needed for the workflow, I would be very interested in hearing your ideas of better workflow for this setup . The easy solution would of course be having the TD tell the CG to play the graphics . But for theoretical discussion, say you have a small team of CG operators all working on preparing the same package , then telling one operator to play would not work .
CasparCG allows multiple clients to connect and control the available channels. There is an AMCP command to lock a channel to a user, so you can lock the graphics operator out of controlling the transmission outputs. Or you can also run multiple instances of CasparCG server on a host PC, each server with their own casparcg.config file. One server instance is set to expect control traffic on a selected tcp port (such as the default port 5250), where the second server instance uses a different port (eg 5251). The CG operator has access to server instance 2 through their client config, but no access to server instance 1. The hardware resources on a multi-output card such as a Decklink Duo 2 can be split between the servers to enable a CG client to only display on the port allocated to the CG server instance.
Rundowns and rundown items are associated with the client operation and its manual choice of folder to store rundowns. But it is possible to share rundows via a shared folder, if this can be implemented without network security concerns in your installation. But storage works on a latest action basis, and the TD would have to pull down a full updated rundown (quick to do) or pull in a rundown with limited number of items that the TD copies and pastes into their master rundown.
If the CG graphics preparation process only creates instance data for templates there is a further way to transfer instance data. There are some AMCP commands that store or retrieve data in a folder defined in the server configuration. The AMCP store command can be issued by a client connected to the primary CasparCG server. The TD client then drags the named data set from the library data list, dropping it onto the template instance. When the template runs it reads the data string from the file instead of receiving the string as part of the CG play command. The downside of this type of operation is the standard client is not configured to edit and save named datasets. But the files are easy to write using a third party program, especially if you use JSON aware templates and JSON strings.
You may already be well beyond the following information. I have a more extended description of data operations on pages 10 and 37 of my “An Overview of CasparCG Graphics System” document available from github [link].
This last thought is probably more relevant to just one CG prepare station. Any rundown item can be allocated a OSC remote control trigger of the form ‘control/triggername/play’. Would it be acceptable that the item was on the CG client station, but the trigger is done by the TD? The trigger may be issued by the Caspar Client which has a defined destination IP address. You can also use an Elgato Stream Deck plus Companion software to issue the trigger, or write a simple web page that directly sends the OSC command via a websocket (see page 74 of my document for a simple example HTML page).
Wow, that document is great, many thanks! I’ve read 1/3 of it already and found so much useful info .
Regarding your last suggestion sending OSC commands from TD to CG , that would prevent the CG to prepare next graphics until the TD has played out the current, right?
Perhaps I “need” some sort of web based client that several users can edit simultaneously. This could then be triggered by the TD and will in turn issue the AMCP commands to Caspar server
OSC control of the cliient comes in two parts - rundown control and specific item control.
Rundown control commands essentially provide a remote keyboard for a rundown. Once you have created a rundown you enable it to be remote controlled using the menu Rundown… Enable Remote Triggering. A small red lightening flash appears on the rundown tab to indicate the remote control mode is active. The remote mode property is saved when the rundown is saved.
The OSC messages are of the form: /control/play (play currently selected clip) /control/down (select next item in rundown) /control/playandautostep (play current item, select next item in rundown)
All OSC messages require an interger parameter set to value 1 to trigger. See page 73 and 74 of my github document for the full list of rundown remote controls.
Item controls include a name in the OSC message, for example /control/maintitles/play. These do not need the rundown remote enabling. The client that receives the message will look for a item in the rundown that has Allow Remote Triggering ticked and a URL entry of maintitles. If the item is present it will be actioned even when it is not selected - in this case it plays a video. You can use very simple names like 1 or a1 and lock these names into a Web Osc Trigger. So this control mode should operate even when the client keyboard is active with entries. I have not tested this in detail when things like menu items are being selected as these can be somewhat modal.
I think the item OSC message operates if the addressed item is in an open rundown in the client, but is not the active rundown tab.
If you have programming skills you can create specialist clients using node.js technology. There is a very extensive CasparCG control library for node, called casparcg-connection, created by the team at SuperflyTV. Here is the link to the github repository for the library.
I’m not sure which server and client versions you are using. If you are using client version 2.2 and want it to send OSC messages, there was and I assume still is, a bug in the distribution exe on github that causes the client to crash when it sends the OSC message. That bug and a simple workaround to stop the crash are documented at clientv2d2-OSC-crash.
No, you could have a number of different of these datasets, that can be changed independently. But it stays a workaround.
What you really needs is a client, that supports multiple users, be it web based or not. There needs to be a central database, where all clients writes to and reads from, in a way, that every client instance is seeing the changes the other users have made. That is not, what the official client is good at.
Hi
I agree with Andyw.
The easy solution would to use at client that runs in a browser, SuperFly, SPX etc.
Then the data of the client would be in just one place and the workflow issue would be when to save/update.