Hollywood Camera Work Support Product Support Causality Story Sequencer Whiteboard jumping back to beginning of timeline

Whiteboard jumping back to beginning of timeline

Whiteboard jumping back to beginning of timeline

Banquetburger
Junior Member
7
12-05-2023, 06:48 PM
#1
Hi there -

I'm running into an issue where the whiteboard view keeps jumping back to the beginning when I'm trying to work on beats further down the timeline.


Here's how it manifests:
  • I pan down the timeline and click on a beat that I'd like to edit.
  • Snap - the Whiteboard view snaps to the beginning of the timeline and the beat I'd like to edit is now off screen.


I believe I've hunted down what's causing the behaviour:
Working on beats that are tagged to be hidden from the script pane.
  • If you have a string of beats that are hidden from the Script (which is the method that I use for my outlines/breakdowns) then the Script panel essentially "runs out of runway" and stops at the last visible beat it can display.
  • Clicking on a "hidden" beat in the Whiteboard asks the Script pane to focus on that hidden beat, but it only go as far as the last beat it can display - that sends a cue to the whiteboard to focus at that dead end spot as well, sending the view to the beginning (or wherever you last "visible" beat is).


A suggested fix for the app:
  • Have the Whiteboard not get it's focus cue from the Script, unless the script itself is manually refocussed.


As a workaround, I'm simply putting an empty "script-visible" beat at the end of my outline, so the script pane has somewhere to go.

Certainly not a deal-breaker, but putting this here in case it crops up for anyone else.
This post was last modified: 12-05-2023, 06:55 PM by Banquetburger.
Banquetburger
12-05-2023, 06:48 PM #1

Hi there -

I'm running into an issue where the whiteboard view keeps jumping back to the beginning when I'm trying to work on beats further down the timeline.


Here's how it manifests:

  • I pan down the timeline and click on a beat that I'd like to edit.
  • Snap - the Whiteboard view snaps to the beginning of the timeline and the beat I'd like to edit is now off screen.


I believe I've hunted down what's causing the behaviour:
Working on beats that are tagged to be hidden from the script pane.
  • If you have a string of beats that are hidden from the Script (which is the method that I use for my outlines/breakdowns) then the Script panel essentially "runs out of runway" and stops at the last visible beat it can display.
  • Clicking on a "hidden" beat in the Whiteboard asks the Script pane to focus on that hidden beat, but it only go as far as the last beat it can display - that sends a cue to the whiteboard to focus at that dead end spot as well, sending the view to the beginning (or wherever you last "visible" beat is).


A suggested fix for the app:
  • Have the Whiteboard not get it's focus cue from the Script, unless the script itself is manually refocussed.


As a workaround, I'm simply putting an empty "script-visible" beat at the end of my outline, so the script pane has somewhere to go.

Certainly not a deal-breaker, but putting this here in case it crops up for anyone else.

perholmes
Per Holmes
43
12-05-2023, 06:54 PM
#2
I agree, it shouldn't behave like this. It's a more complex issue, but we've had to wait to debug it until we're out on the other side of the major refactor we've been working on for a year, because all the signal paths inside the app have changed.

Basically, the problem is direct signaling between the areas, and the whole code design around it that ended up requiring it. The timeline is telling the whiteboard to reposition, and the whiteboard is telling the timeline to reposition. Now add all the fun of animation of scrolling to positions, and various little automations in each area, and the ground is set for a feedback loop.

This particular feedback loop can happen when the whiteboard is showing something else than the current position, meaning that the time indicator in the whiteboard is off screen. You'll find that if you bring the whiteboard time indicator into the current whiteboard range (by clicking anywhere in the scene bar at the top of the whiteboard), this doesn't happen.

To be clear, this is a workaround. What we have in Causality is a bad solution for how to handle signaling between areas. Instead of the inherent anarchy of areas just shouting randomly to each other, there should be a single time controller that decides where "Now" is. We halfway have that. Otherwise, you'd see this happen a lot more.

It'll be fixed. It's just that it needs a proper solution, not more duct tape, and that pushes it back in the line.
This post was last modified: 12-05-2023, 06:54 PM by perholmes.
perholmes
12-05-2023, 06:54 PM #2

I agree, it shouldn't behave like this. It's a more complex issue, but we've had to wait to debug it until we're out on the other side of the major refactor we've been working on for a year, because all the signal paths inside the app have changed.

Basically, the problem is direct signaling between the areas, and the whole code design around it that ended up requiring it. The timeline is telling the whiteboard to reposition, and the whiteboard is telling the timeline to reposition. Now add all the fun of animation of scrolling to positions, and various little automations in each area, and the ground is set for a feedback loop.

This particular feedback loop can happen when the whiteboard is showing something else than the current position, meaning that the time indicator in the whiteboard is off screen. You'll find that if you bring the whiteboard time indicator into the current whiteboard range (by clicking anywhere in the scene bar at the top of the whiteboard), this doesn't happen.

To be clear, this is a workaround. What we have in Causality is a bad solution for how to handle signaling between areas. Instead of the inherent anarchy of areas just shouting randomly to each other, there should be a single time controller that decides where "Now" is. We halfway have that. Otherwise, you'd see this happen a lot more.

It'll be fixed. It's just that it needs a proper solution, not more duct tape, and that pushes it back in the line.

Banquetburger
Junior Member
7
12-05-2023, 07:01 PM
#3
Yup, that all sounds about right - totally not a big problem once I figured out what was going on.

If I come across any other small issues like this I'll try to post about it framed more as what workaround I've figured out, so you can stay focussed on the big picture stuff.

Thanks for the response.
Banquetburger
12-05-2023, 07:01 PM #3

Yup, that all sounds about right - totally not a big problem once I figured out what was going on.

If I come across any other small issues like this I'll try to post about it framed more as what workaround I've figured out, so you can stay focussed on the big picture stuff.

Thanks for the response.

perholmes
Per Holmes
43
12-05-2023, 07:05 PM
#4
Thanks! We collect all polish issues into our internal ticket system. There's a lot in there, but I'm trying to keep us focused on major initiatives, and this means ignoring some polish for a while.
perholmes
12-05-2023, 07:05 PM #4

Thanks! We collect all polish issues into our internal ticket system. There's a lot in there, but I'm trying to keep us focused on major initiatives, and this means ignoring some polish for a while.

Users browsing this thread:
 1 Guest(s)
Users browsing this thread:
 1 Guest(s)