Skip to content

Conversation

@eloisebrosseau
Copy link
Contributor

SG-39445: Enable participants to broadcast annotations in Collaborative mode for OTIO-based Live Review sessions

Summarize your change.

  • Add pydantic to validate payload formats in the Live Review plugin
  • Add setCurrentAnnotateModeNode in rv.commands to manually set the Paint node to use when manipulating stokes in annotate_mode
  • Set the mode property on all strokes even if the mode is RenderOverMode to prevent the code from throwing an exception when trying to get the value. This is necessary to know if the user is erasing or painting before sending an annotations payload.
  • Replace the hardcoded values used to set the width of the stroke with a conversion method from OTIO coordinate to the World Coordinate System in RV.

Describe the reason for the change.

All the changes mentioned above are needed to properly enable participants to broadcast annotations in Collaborative mode for OTIO-based Live Review sessions.

Describe what you have tested and on which operating system.

Drawing strokes with the pen and the eraser tools while being a participant of an OTIO-based Live Review session with Collaborative mode enable. The tests were done on macOS 15.6.1

setCurrentAnnotateModeNode """
Set the Paint node to use for the _currentNode in the annotate mode.
If the node is not a valid Paint node or if it is set to an empty string
(i.e. ""), the _currentNode value will not be overridden.
Copy link
Contributor

@bernie-laberge bernie-laberge Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make it more explicit how to undo this setCurrentAnnotateModeNode(), should we add ?
Therefore, you can reset its action by specifying an empty string to setCurrentAnnotateModeNode().
(I know that the text is legally correct. But when I first read it I was wondering how to reset it and double checked in the code).
Totally optional comment. Feel free to ignore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your first sentence might be missing some words. What are you suggesting to add? I am using the empty string to make sure the current node is reset at the end of a Live Review session in my Commercial RV. I could add a sentence explicitly stating that calling setCurrentAnnotateModeNode() with an empty string will reset its behaviour to make it clearer

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that's what I meant:
calling setCurrentAnnotateModeNode() with an empty string will reset its behaviour.

NODE_RETURN(int(s->getSessionType()));
}

NODE_IMPLEMENTATION(setCurrentAnnotateModeNode, void)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering, should we really add an RV command for this ?
Why couldn't Live Review simply issue the following Annotation package specific event ?
commands.sendInternalEvent("set-current-annotate-mode-node", nodeName)

Copy link
Contributor

@bernie-laberge bernie-laberge Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a philosophical question: Since that annotate_mode.mu is a package that could potentially be replaced by some other package in the future, does it make sense to add an rv command that communicates with the annotation_mode.mu package ? while Live Review could interact directly with the annotation_mode.mu package via commands.sendInternalEvent() ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it would be documented more clearly this way, but since I'm already validating the input inside the annotate-mode package, I agree that I should have simply sent the event with the nodeName. I'll make the change and add the documentation in the internal events page instead of commands.mud


method: activate (void;)
{
sendInternalEvent("annotate-mode-activated");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we set the event after it has actually been activated ? (After setTags()) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll change it!

Copy link
Contributor

@bernie-laberge bernie-laberge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful !
Thank you @eloisebrosseau !

Signed-off-by: Éloïse Brosseau <[email protected]>
Signed-off-by: Éloïse Brosseau <[email protected]>
Signed-off-by: Éloïse Brosseau <[email protected]>
Signed-off-by: Éloïse Brosseau <[email protected]>
Signed-off-by: Éloïse Brosseau <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants