Upstream Key Tie / Next Transition

[chrisspiegl]

• I'm submitting a ... [ ] bug report [x] feature request (possibly) [ ] question about the decisions made in the repository [x] question about how to use this project

• Summary

I am trying to implement a Upstream Key (PiP) with DVE and that should stay open over multiple transitions.

Specifically I am lacking commands to set the Next Transition stuff and with that transition the Upstream Key with the auto button.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

I have found that the Downstream Key has a "tie" command in the atem-connection, but the upstream key does not?

Right now, the only way to send a Upstream Key is to call myAtem.setUpstreamKeyerOnAir(true) but that makes it just appear and not disappear via auto transition.

I hope this is at least understandable. It's a lot of new terminology for me and I am trying to figure all of this out.

• Idea

Maybe it'd be an idea to implement a myAtem.setUpstreamKeyerTie(true) command so that the upstream key can be loaded in the preview scene before transitioning to it?

[mint-dewit]

Hi Chris, if you want to take the USK on or off air with the transition you'll have to use the setTransitionStyle as documented here: https://nrkno.github.io/tv-automation-atem-connection/classes/atem.html#settransitionstyle

The reason it's part of the transition style and not a "tie" has to do with the difference between upstream keyers and downstream keyers, but I'll spare you the details as it's rather technical.

[chrisspiegl]

Thank you for the quick reply. I actually did look at that function as well but I probably don't have a full understanding of the parameters and all.

The parameters are not clear to me 🙈.

What does the nextSelection ask for? It's only showing that it wants a "number".

I'll play around some more but if you can I'd appreciate a bit more information 😊.

[mint-dewit]

From what I remember it is a bit flag, every option gets a bit to represent a boolean on or off. So if I wanted the background and USK 2 to be included in the transition you'd get the following bits: 101 which is represented as the number 5, if you only want USK 1 to be in the transition you'd get 010 which is the number 2.

[Julusian]

Yes, its a bit flag as @baltedewit describes.

Perhaps we should make an enum here and use an array of values instead? bit flags in js are not very common (and eslint does complain about them).

[chrisspiegl]

Thank you @baltedewit and @Julusian, you are completely right apparently. I was able to now also find how to work the Enums 🙈 (not really used to this type of library yet) but it's really great how much it can do.

One more question, while I am here:

Could you tell me what the difference is between the nextSelection/Style and the selection/style? The later two seem to do nothing (but I am pretty sure that's just me missing something).

And lastly: I think an Enum would be a great idea for the nextSelection / selection stuff.

I got it working with the Atem Mini and:

const nextTransitionSelection = {
  background: 1,
  key1: 2,
  all: 3,
}

[Julusian]

The documentation doesn't make it clear due to how I have implemented the api typings (I need to find some time to simplify them), but selection and style arent possible to set.

The reason for them both is that while you are in the middle of a transition, you cant change the current transition, but you can set what the next one will be. So selection is what the in-progress transition is, with nextSelection being what the next transition will do. And when you are not in a transition, then selection will always match nextSelection

[chrisspiegl]

@Julusian Thank you for the clarification. Now I understand. So I will only set the nextSelection and the nextStyle — I have already implemented them in my Midi Controller now and these two are working as expected.

I totally understand that documentation can be a pain — especially when you are at the same time developing a real thing and you also want to get going with the using.

To be honest: I am absolutely stunned an happy that you are making all of this available anyways! That is awesome and really deeply helpful for me 🌸.

P.S.: I may have one off topic question for someone who knows these mixers better than I do but I have not yet found an answer for that. Sorry for asking here.

Is it possible to fade between two Fill Sources on the same Upstream Key? Since the ATEM Mini only has one Upstream Key and I would like to MIX between two cameras using it as a DVE PiP?

My suspicion is that this is not possible — or only possible with sending code commands after one another to kind of do this by first hiding the USK, then changing the fill source and then showing it again? But then it's not possible to combine this with a background change at the same time?

[mint-dewit]

Video switchers can typically only do transitions on a so called Mix Effect, so if you wanted to do a fade in the DVE only you'd need a second ME for that. If you had 2 DVE's (like on the mini extreme) you could also fade between upstream keyers on a single ME. Since the Atem mini only has a single DVE and a single ME it's really not possible to do this.

[chrisspiegl]

@baltedewit Thank you, that's exactly what I suspected. My solution now is that my MIDI to Atem script will fade everything out when the program + the DVE change (essentially doing a dip to black) / it will fade the DVE out and the new in when just the DVE changes and it will keep the DVE when only the program changes.

Currently I simply do not have the budget for the ATEM Extreme — as lovely as that would be 🙈.

Thank you again for all the help you provided here. If this question issue is no longer needed, I can close it.

Or do you want to keep it open for the ENUM of the nextTransition thingies?

[Julusian]

I have changed this in the 3.0.0-nightly-latest-20210530-132658-16c3cdd.0 beta build, so that nextSelection and selection are an array of values instead. And I have created an enum to clarify valid options. This also matches other bitmasks where we were already converting them to an array

[chrisspiegl]

@Julusian That's awesome to hear, I tried looking for these builds but don't know where I can find them? Do you have some link to point me toward that place? Thank you.

[Julusian]

Its published to npm, so put that version in your package.json and after an npm install/yarn install it should be there. eg

"dependencies": {
  "atem-connection": "3.0.0-nightly-latest-20210530-132658-16c3cdd.0"
},

[chrisspiegl]

@Julusian Thanks, that's awesome - I checked the Git Tags just didn't find it there 🙈. Now it's clear. The docs for this are coming sometime with the official release or are those up somewhere as well?

[Julusian]

I think the docs are only updated once we do a proper release. If you are using vs-code, then intellisense should give the type hinting. Or if you need the proper docs, you could clone this repo and run yarn, yarn build and yarn docs to generate them locally and open that copy

[chrisspiegl]

Thank you so much 🌸. I highly appreciate your help with these things.

I will get to work to add these new features to my project.