Yes, you are right. It‘s not a matter of being afraid of C++ but a matter of having not too many programmer, that knows it, while everybody here, that does HTML templates knows HTML, CSS and JavaScript.
1 Like
If you know JavaScript, you are half way there… 
OK maybe not. Anyway, you have a point there. I am mostly biased, since C++ is my language of choice.
I think what we really need is libcasparcg written in either C or C++ and bindings for various languages (python, JS, etc.) on top of that. Then people can easily develop apps in their preferred languages.
That’s just my 2 cents.
js is also more complex than people first realise once you start using async and introducing race conditions.
But c++ is definitely a different level.
C is even worse because of having to manage memory too.
I don’t think a libcasparcg will be a worthwhile time investment. While it could be bound into almost every other language, the cost of maintining those bindings and translating the api into a language style will be similar to writing a library from scratch.
Plus, using native bindings isn’t free. I have spent quite a lot of time recently trying to get a few native libraries to play happily with each other in electron. Or to figure out how to package them because it kept not finding some dll files. Even in c# I have had to fight some libraries to get types to work.
Also in the case of js, using a native library will mean that it won’t be usable in a browser. Wasm could resolve that, but that might have some influence on technologies the libcasparcg should use.
Every language has its flaws, but I think that js is easy enough to get proper development from the community, and it will be nice and easy to use as a building block for something custom.
1 Like
I’ll be glad to run your auto-step enabled CasparCG client.on ubuntu. Thank You,
I can do this starting January when I’ll be back to the office.
As an interim (which probably means permanent 
) solution I am writing an OSC server that can be customized to listen for OSC messages and execute arbitrary scripts based on that (I know it sounds bad).
This will allow the existing CasparCG Client application to be used for automation, which we do a fair bit of in our shows.
I am also planning to rewrite my baker app to translate X-Keys key presses into OSC messages. Same with the logi app.
This makes for a very flexible system, as one can write whatever scripts his/her soul desires, including sending key presses, mouse clicks, executing other apps, etc, etc.
Will post here once I have something ready. Stay tuned. 
D-mo
Dear friends.
I hope this discussion is still open. I always be on side of an evolution more than a revolution, so keep the good code is great but, i understand that the client require a path to the future, and C seems not be the best for that.
My points are:
- Agree with the plugins request, a lot of little ideas can be useful. Extensions for new devices.
Boards, routers, switchers and protocols. - Some way to show time events as graphics.
I like the old interface, but one of the most important capabilities of this client is to define delay time between actions. Sometimes it is difficult understand when a macro command (a) is executing an instruction, consuming delay time or stopped. I think some kind of timeline for commands will be a good help. Of course it is easy to say but… - Ndi monitor embedded, a simple one.
Thank you for your work.
Note (a) it’s happen when you call a camera preset, a switcher preset, when you execute a layer move etc.
You can try @dimitry_ishenko pre-built-binary here:
https://github.com/dimitry-ishenko-casparcg/timer/releases/download/v0.5/timer_0.5_armhf.deb
but prior to this you have to install:
https://github.com/dimitry-ishenko-casparcg/liboscpp/releases/download/v0.9/libosc++_0.9_armhf.deb
an it will work.
1 Like
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?