Added camera control

[gavalierm]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) This have resolved conflicts and is possible to auto-merge.

• What is the current behavior? (You can also link to an open issue here)

• What is the new behavior (if this is a feature change)?

• Other information:

[gavalierm]

@Julusian any ideas? I was hoping that will be easy to merge.

[Julusian]

I've reworked how the command is implemented to make it generic https://github.com/nrkno/sofie-atem-connection/pull/144. The deserialization/serialization logic that this PR has in the command should be refactored into some util and used in the applyToState function instead.

I would also like to see some justification for ids used at various points, as some of them differ from what the arduino sdi shield use, so I am unsure which is correct.

[gavalierm]

Ok i see, thank you for your work. You rock (as i see in many others projects where your name is present).

I do not know what exactly is done and what needs to be done, but it is useable in some way?

This merge means that atem-library starts passing the CCU data?

[Julusian]

I do not know what exactly is done and what needs to be done, but it is useable in some way?

Yes, you can manually construct and send CameraControlCommand

This merge means that atem-library starts passing the CCU data?

Yes, by listening to the receivedCommands event on the Atem client, that will now contain these CameraControlUpdateCommand commands which are the ccu data.

In both cases this library is providing no help as to what the data in the commands means or looks like, that will come later. Instead for now it is up to you/the application to know and handle that

This change is published in 3.3.0-nightly-master-20230413-093956-1951a9ce.0, and will be in a proper release at some point

[gavalierm]

Thats amazing news! I can co struct datas on my own. (I do it for bluethooth control) so sounds like something what i can handle.

Many thanks. 💪

I hope for “public” release soon ;) until tthis day i will use mentioned commit.

[Julusian]

With #144 this can be done entirely in user code, perhaps written as a separate library. If someone writes this library, we will happily link to it from here to help other users find it. We are open to accepting a PR which adds better support for this camera control, but without a need for it ourselves or a way to perform any testing, we are hesitant. Our recommendation for now is to do this as a separate library, or directly in your codebase and once there is an implementation which is proven to work reliably we can reconsider including it here. With #144, hooking into this library is pretty simple:

const connection = new Atem()

// Receiving state updates
connection.on('receivedCommands', (commands) => {
    for (const command of commands) {
        if (command instanceof CameraControlUpdateCommand) {
            // TODO - update your state object here
        }
    }
})

// Sending a command
const cameraCommand = new CameraControlCommand(1, 2, 3, {}) // TODO populate this with real parameters
await connection.sendCommand(cameraCommand)

I think that in the past (in another library) I have seen that the data received can vary either across camera model, or across firmware versions, which reduces my confidence that an implementation will work reliably and consistently.
That said, I (personally not as part of nrkno) might be interested in implementing some of this or at least a subset of the state for Companion to make use of.