search

nrkno / sofie-atem-connection

Sofie ATEM Connection: A Part of the Sofie TV Studio Automation System
https://github.com/nrkno/Sofie-TV-automation/
MIT License
134 stars 36 forks source link

Some recent breaking changes #95

Closed endreszabo closed 3 years ago

endreszabo commented 4 years ago

Up until yesterday I've been using a $previous version I installed from npm like 3 weeks ago. Now I use the recently published 2.1.0. There must have been some significant changes which made my simple node script fail.

I got the following problems:

  1. Major: The stateChange event gets emitted for tree item video.ME.0.programInput. I use the object-path to get the referenced tree item that returns undefined as the state tree has changed the name for ME leaf to mixEffects so the correct path would be video.mixEffects.0.programInput. My workaround is that now I replace .ME. in the emitted path string to .mixEffects. which is.. unprofessional. :)

  2. Minor: Formerly upon startup every state 'final' path node have emitted a stateChange event and using that I could fill up my macro and input variables. Now I have to use .on('connected') and fetch those values manually. Is it should be done this way from now on?

  3. stateChange now emits an array of state tree paths instead of a single path as before. Workaround is to use a .forEach() on the paths.

I guess ME->mixEffects is a thing in transition. No idea about the others, pls confirm if things will go this way from now on and I'll adapt.

And as always, thank you very much for this lib. Keep up the good work! :+1:

Julusian commented 4 years ago

It sounds like you have made the jump from 1.x to 2.x, so it is expected that some things will break. We follow semver so version jumps like this is when we are allowed to do breaking changes and we ended up with a few things.

  1. The naming was changed as part of a general renaming and tidying, but the events should have been updated to match. So yes the incorrect paths is a bug. I shall try and get this fixed this evening, and write some tests to ensure the same issue isnt present elsewhere

  2. This was an intentional change because often the events would be working with an incomplete and broken state tree, as we were still receiving data. Additionally, for some of the larger models we receive some hundreds of commands, so emitting an event like we were was likely to be a bit of a performance problem. So yes, it is best to listen for 'connected' and do a full update when that is received (which will also happen upon reconnection)

  3. Often multiple updates get received from the atem in a single packet, so we now treat those as a single update. This is especially relevant in fairlight, as sometimes the atem will remove an audio channel and add a replacement.

endreszabo commented 4 years ago

Thank you very much for your detailed and prompt answer. The version jump must have been a major one. :)

For point 2: is the state tree considered complete when the connected event gets emitted?

Julusian commented 4 years ago

Yes, when connected is emitted that means that the tree will be complete.

I have written a fix for your issue, I just need to do a bit more testing before publishing a release

Julusian commented 3 years ago

I believe the last issue flagged here has been resolved as of v2.2.2, the rest was intentional changes. Let me know if I have missed anything