Whiteboard jumping back to beginning of timeline
Whiteboard jumping back to beginning of timeline
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.
Banquetburger
12-05-2023, 06:48 PM #1Hi 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.
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.
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.
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 #3Yup, 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.
Please I need help fixing this.
I've further traced this down. If I use ONE tag IN ANY BEAT it will jump back to the start. It doesn't matter where the beat is, if you tag it, this bug manifests itself.
What is a workaround for this as one of the most important reasons I'm diagramming the story is to use tags to show adherence to theme. Now I cannot use tags as I planned to.
alan.knittel1@gmail.com
07-05-2024, 07:27 PM #5THis is not a "polish" issue. I cant use this product now. I tried the workarounds and they don't work. All blocks/groups now have a single placeholder beat that is "visible". That didnt do anything for me as a workaround.
Please I need help fixing this.
I've further traced this down. If I use ONE tag IN ANY BEAT it will jump back to the start. It doesn't matter where the beat is, if you tag it, this bug manifests itself.
What is a workaround for this as one of the most important reasons I'm diagramming the story is to use tags to show adherence to theme. Now I cannot use tags as I planned to.
alan.knittel1@gmail.com
07-05-2024, 08:40 PM #6I deleted the original tag I had, then recreated a brand new tag with the same name, re-associated the beats with the new tag and now the issue is gone. I think if you want users to embrace these features, you need to fix the underlying issue and make it a priority to do so. For me the story outlining feature of Causality is more important than the script or narrative writing part. For my usage scenario, I need the whiteboard to be bullet-proof.
It's difficult to understand how re-doing a tag has any influence on this. This is purely about the time indicator being out of view, and the auto-positioning logic jumping back there.
You're certainly right that it should be fixed, and it's top of the list. We've just gone through fundamental retooling where we couldn't do releases for a while, and we're all out on the other side. I'll double-check if this issue is still there. Many such things have fixed themselves with the new internal signal paths in the app. Basically, going to collaboration has demanded cleaning up any unclear signal paths, and this issue was part of that.
Hi Alan,
It's difficult to understand how re-doing a tag has any influence on this. This is purely about the time indicator being out of view, and the auto-positioning logic jumping back there.
You're certainly right that it should be fixed, and it's top of the list. We've just gone through fundamental retooling where we couldn't do releases for a while, and we're all out on the other side. I'll double-check if this issue is still there. Many such things have fixed themselves with the new internal signal paths in the app. Basically, going to collaboration has demanded cleaning up any unclear signal paths, and this issue was part of that.
alan.knittel1@gmail.com
07-08-2024, 04:37 PM #8Appreciate the response. Are you going to be asking for beta users for the cleaned up release?
Beyond Emotion Tracking, there isn't that much that looks different, but the guts are completely changed and aligned with collaboration. We had to pay significant technical debt, because our assumption of how we were going to do sync was incorrect 10 years ago.
I'll add you to the beta email list.
Yes, definitely! There are many areas that are total rewrites, and we're honestly nervous. This is why we're releasing this along with another major feature, Emotion Tracking, which is both a very important feature, and a chance for us to alpha test the new app.
Beyond Emotion Tracking, there isn't that much that looks different, but the guts are completely changed and aligned with collaboration. We had to pay significant technical debt, because our assumption of how we were going to do sync was incorrect 10 years ago.
I'll add you to the beta email list.
1 Guest(s)
1 Guest(s)