feat: qt6 and update build tooling

[Julusian]

I think this is a useful project, but as it does not have a maintainer it is going rather stale and falling out of sync with changes to the server.

The aim of this is change to get this repository into a better state where it is easier to clone and develop, and ensure that there is a recent release that is easily usable on current oses.

Long term, someone either needs to take over maintenance, or a replacement general purpose client should be made.

This PR does a few things:

• Replace QT buildsystem with cmake
• Update to QT6
• remove atem, panasonic, spyder, sony and tricaster integrations
  • These add complexity for little benefit. The atem integration in particular has many bug reports of crashes. If you need to do these things, I would suggest using companion as a middleware.
• Update other dependencies, and remove all binaries committed to the repository
  • They are pulled in now as either a git submodule, or cmake externalproject
• Package linux build as a deb
  • This is intended for ubuntu 22.04, as I expect this will cover most users

TODO:

• [x] build in github actions
• [x] fix macos build
• [x] fix windows build

[5opr4ni]

Hi Julian

Thanks for paying some attention to this and that you do an effort to make it possible for others to dig in here. I am doing a lot of time in different trucks and galleries all over the world, and everywhere I go I see CasparCG Client, more than the most realizes, and it has also been my main tool when working with Caspar. It would be a grate loss for Caspar if this client didn’t survive. Thanks again Julian

[j3po]

Hi Julian, thanks for pushing. The CasparCG Client is our main tool for small streaming projects including video clips. I am a bit sad to see that it is planned to remove the ATEM commands - we use them quite often to start and switch at the same time. Maybe I can have a look at this next year and find some students to help me work out a solution. See ya!

[herzogmedia]

@j3po We do the same thing. One workaround you could try is to use Companion as an inbetween. Instead of triggering the ATEM directly you could trigger a companion button with OSC that does the same thing. Edit: which is exactly what @Julusian suggested in his posting, I now see...

[Julusian]

@j3po I suggest using https://bitfocus.io/companion to do the atem side of things. You can send osc/http commands from this client to trigger things in companion. (I think it is also possible to send osc back to the client to trigger things the other way too, but I havent tried this). The benefit of this is that companion can control a lot more things on the atem than used to be possible here, it can talk to hundreds of different devices, and doesnt have the stability issues that the atem integration in this client had. So while this flow is less intuitive and a bit more awkward to setup, it is much more powerful, more stable and has less maintenance cost here.

[j3po]

My concern is exatly that: increased complexity and a non-intuitive solution. My case is somehow special: I am working with students that are not familiar with network protocols and getting them to 'use' a software is much more easy than learning another control interface. I will have a look at the companion setup and try it out to see if the configuration is managable.

Up until now, we did not discover issues with the ATEM integration using simple commands, e.g. select input or fade.

[dimitry-ishenko]

@j3po if you are on Linux one solution is to switch to OSC. This is what I did in one of my setups.

I've set up OSC gateway which receives OSC commands from the Client and calls a custom binary that switches inputs on the ATEM switcher.

Lemme know if you are interested.