#1672 Playback pointer and autoscroll with multiple segments per track
RG v23.12: Notation Editor has the problem, but Matrix Editor does not. I'll keep the setup simple i.e multiple MIDI segments on a single MIDI track. The "Follow playback position mode" is on for both editors.
Short version:
1. On opening the Notation Editor, the notes in the active segment should be highlighted in some way (the Matrix Editor highlights its notes).
2. With Follow playback position mode selected, when playback is stopped, the Notation Editor should not autoscroll to the active segment. The view should remain at the playback position like it does in the Matrix Editor.
3. When clicking in the playback pointer area and outside the active segment, the Notation Editor should not autoscroll back to the active segment.
Set up
The details are below, starting first with the Main window and Matrix Editor which do not exhibit the behavior above. Select a track containing multiple segments over a timeline which will require horizontal scrolling.
Main window behavior:
1. Clicking the playback pointer area always moves the playback pointer to that location.
2. Once selected, the playback pointer can be dragged to any location on the timeline.
Matrix Editor behavior
1. Open the Matrix Editor on multiple MIDI segments on a single MIDI track
2. When opened, the Matrix Editor playback location matches that of the main window.
3. The active segment notes are highlighted while all other segment notes are grayed out, regardless of whether the active segment is in view at the time of opening.
4. When the playback pointer area is clicked in the Matrix Editor, the playback pointer moves there and the main window's playback pointer is also updated with the new location.
5. Once clicked, the playback pointer can be dragged to any location on the timeline.
6. And it even works the other way around i.e. changing the playback location in the main window is reflected in the Matrix Editor.
7. In "Follow playback pointer mode", if playback is started when playback pointer is well outside the view in the editor, it correctly autoscrolls to the playback pointer and follows. Then on stopping playback, the playback position is maintained in view i.e. there is no further autoscrolling and the only thing that happens is the stop.
Notation Editor behavior
1. Open the Notation Editor on multiple MIDI segments on a single MIDI track
2. When opened, the Notation Editor does not display a playback location like the above windows. It does have a "short stave cursor" and on opening that matches the playback position of the main window.
3. The notes of the active segment are not highlighted on opening. They appear the same as those in the segments before and after it. Hence the only hint of the active segment is it contains the short stave cursor. However, turning the segment wheel forward or backward changes the highlight of the notes to the prior and following segments, indicating that they are now active. And when the wheel is adjusted back to that of the initial active segment, that is when it's highlighted.
4. When the playback pointer area is clicked within the active segment, the short stave does behave like the playback pointer seen in the Matrix Editor, including matching changes in the Main window. Even though the tool tip says "Click and drag to move the playback pointer", the short stave cursor cannot be visually dragged to segments prior to or following the active segment...the short stave cursor stops at its boundaries. But the underlying playback position drag is still being honored by the Main window playback pointer to locations outside the active segment. The only clue to the final playback position is noting where the left click was released.
5. As an aside, clicking on the stave area (not a note) does move the playback location to that point even outside the active segment and syncs the playback pointer with the main window, but then there is no way to drag the short stave cursor.
6. As with the Matrix Editor, in "Follow playback pointer mode", if playback is started when playback pointer is well outside the view in the editor, it correctly autoscrolls to the playback pointer and follows. But unlike the Matrix Editor, on stopping playback the window autoscrolls back to the active segment (still showing its short stave cursor, which no longer matches the playback pointer location). I'm not sure why the autoscroll is needed? Is there some preference which causes the scroll to the active segment when the user hits stop playback?
7. If the playback pointer area is clicked in the Notation Editor anywhere outside the active segment, the Notation Editor autoscrolls to the active segment.
For discussion:
1. I think that at least on opening the Notation Editor, the active segment notes should be highlighted, because it then matches the Matrix Editor's opening highlights, as well as when the active segment is selected via the wheel.
2. When playback stops, I'm not sure autoscrolling to the active segment in the Notation Editor is necessary...It didn't jump to that location when first opened, when one might consider that a possibility. Here follows an example of where the behavior is undesirable: while observing the notes during playback in Notation Editor and following the playback position as it scrolls the window, a problem is spotted. Hit stop to fix it, only to have autoscroll move the entire segment out of view and replace it with the active segment. Now you have to remember where you were :-). And turning off Follow playback mode won't help if the problem segment is not in view when playback started. Besides, the Matrix Editor does not currently have that behavior either. Furthermore, clicking either the right or left arrow key already takes the user directly to the active segment in both the Notation and Matrix Editors, so why bother autoscrolling?
3. Finally, if the playback pointer area is clicked in the Notation Editor outside the active segment, the Notation Editor should not autoscroll to the active segment as a result of that action alone.
Just pushed [ae27b0] which fixes notation editor not selecting current segment notes on launch. Please test latest git.
Note that this will slow down notation editor launch with large compositions and multiple segments selected.
The two autoscroll issues are next.
Related
Commit: [ae27b0]
The autoscroll issues described were hard to understand until I realized that you have to have a set of sequential segments on a track. Procedure to create a composition to reproduce these issues:
Now I believe we have a setup that will illustrate the autoscroll problems described above. E.g. let the composition play with the notation editor up until it gets to bar 20 or so and the first segment is no longer visible. Hit stop. The display will horizontal scroll back to the end of the first segment (bar 8). That's annoying.
Am I on the right track here (pun intended)?
You are definitely on the right track :-)
It's more that a little annoying though. Imagine you have multiple segments on multiple tracks displayed in a maximized notation editor, and you're following the composition along listening intently. All of a sudden you hear some ugly note clash. You hit stop to investigate and the notes responsible are whisked off screen!
Fortunately, although the notation editor cursor has taken you off some place to the last active segment, the transport cursor in the main window (often behind the maximized notation editor) remains at the scene of the attack on your ears.
I also tested sourceforge master for the notation editor note highlights and they work perfectly now, just like the Matrix Editor.
NotationScene::getCursorCoordinates()is where this pointer position limiting is occurring. It's using the current (active) staff to compute the pointer X. If the time is outside the current staff, the pointer X is limited to within the current staff.We need to do something like pick a new current staff based on the pointer position if it is outside the current staff. But we should only do this when not rolling.
Just a quick update on my research into this one. I'm moving to something else, so if anyone wants to take over, feel free.
There are at least three bugs here that need to be addressed:
Bug 1: Notation jumps on stop with autoscroll enabled.
Solution #1 Keep the restriction that the position pointer must be within the current segment. Change the current segment to the segment that is at the position pointer on stop or when the position pointer is moved.
Search the code for 1672 and there are breadcrumbs related to this.
Solution #2 Allow the position pointer to be outside the time range of the current segment.
Bug 2: Can't move position pointer outside current segment.
Above solutions can address this.
Bug 3: Can't tell which notes are in the current segment.
The notation editor should offer a better way of indicating the current segment. Notes for the non-current segment(s) should be gray.
If we are going to change the current segment without the user's permission (Solution #1 above), we really need to make it clear what we have done.
OK - tricky one - I will have a go.
First Bug 3 above - The select all option seems doubtful - very expensive (for performance testing the Brandenburg-No3 example is good)
I had a try at changing the opacity of the elements - that seems to work and is much more efficient!
Please have a look and merge if this seems a good idea
I have renamed some things and now deal with (hopefully) all graphical elements in the staff.
For bug 1 and 2 above I prefer solution 2 - much easier to implement.
Does anyone need the limiting of the cursor to the current staff ?
Getting back to the current staff is easy with left or right arrow.
I have removed the limiting of the cursor so - no more jumps !
From the perspective of this bug, it depends on the following scenario:
On stop, does the view shift to the start (or end) of the long segment, removing from view the other shorter segments which were at the cursor location when stop was requested? Or does the cursor remain at the stop location on the current staff of the long segment, hence leaving the view unchanged?
I guess it boils down to: When the user hits stop, that is the only action requested i.e. not stop and also change view. Ideally, everything should look the same (or at least similar) to the moment prior to stop.
I agree. In my latest version stop just does stop with no jump to the current staff. This feels right for me - If I want to get back to the current staff a left or right arrow will do that.
This is probably the wrong ticket to mention this, but I do find myself fighting the cursor in another situation. The problem did not occur in v18.12, so I guess it's new functionality, and not a bug.
More often that not, when I use the undo command after a capture, the cursor automatically moves to a location that I didn't expect. There are occasions where this does work, but in my case it often fails to do the right thing i.e. it does not feel like something that can be generally true.
In (2), and after the capture, the user has determined where the cursor should be by moving it there, and then later decides to undo, meaning the capture. RG then moves the cursor as well anyway. I think the situation is exacerbated when using JACK transport and moving the cursor while in another JACK client. On returning to RG, the user knows whether they wish to undo the capture, but might not always be expecting to have the cursor change location...in fact, the user may even have abandoned the idea of capturing at that location.
It's difficult to suggest an improvement, but I think that once the user intentionally moves the cursor, then perhaps RG should not override that decision by incorporating both a capture undo plus what is now not a cursor undo, because the cursor is not at the end of the capture?
Of course, that just may complicate the implementation in which case, it can be lived with...but I thought I would mention it.
The behaviour you see is a result of the fix for bugs 927 and 1679.
So it is intentional that after undo the cursor is reset to where it was before the action was initiated.
Not sure how difficult it would be to stop this behaviour if the cursor is manually changed.
Is this what we want ?
Any ideas or suggestions ?
That one part of your post clarified everything for me. I only ever noticed the automated cursor move when I was recording, and so thought it was related to that. Other cases obviously didn't bother me as much.
I just tried a scenario and it did exactly what was intended. I'll give just one example where this doesn't quite work out:
None of this provides any ideas or suggestions, except to suggest that the above scenario was probably not intended...it's a side-effect. Also note that if I attempt a redo at this point:
The above can be avoided to some extent, by learning habits i.e. move the cursor first to where you want to work or where you expect to return to if an undo turns out to be needed...it's more baggage to remember, but acceptable.
Merge Request #129
This looks really good.
Might be a little much, though. We already have a cursor that shows us where we are vertically and horizontally. We only need the highlighting when dealing with notes in overlapping segments on the same track.
Simple test case:
1. New document
2. Add two four bar segments to track one. Both at bar 1.
3. Add one four bar segment to track two at bar 1.
4. Select all and bring up notation.
If one of the overlapping segments is current, the segment on track two is dimmed. That looks wrong to me. Not sure how the real users will feel about it. The highlighting/dimming on the two segments on track 1 is perfect.
The logic would be something like this:
Only do dimming when the current segment is on a track with multiple segments. Then only dim the non-current segments on that track. All other tracks and segments should not be dimmed.
Hopefully that's easy to implement.
The jumping around is definitely fixed in all originally reported situations.
Hmm.. OK - but I think I still prefer just highlighting the current track. I guess it is a matter of taste !
So.......
I have implemented a setting for how to do the highlighting - it can be chosen in the View menu of the notation editor.
I made the default your suggestion above - but that can be changed.
Please merge,
Pushed as [06c876]. Please test latest git.
This should effectively close this bug report, so please evaluate all the original issues and let us know if there are any further problems. As a bonus we now have more sensible notation highlighting related to the current segment. I'll put together a post for the mailing list to get everyone testing this.
Related
Commit: [06c876]
@musewhirl (and anyone else affected by this bug), please retest latest git to make sure all of these fixes for bug [#1672] are still working properly. Philip made a change for bug [#1704] that may have affected this. I just pushed it as [c006f7]. Thanks.
Related
Bugs: #1672
Bugs: #1704
Commit: [c006f7]
I've not seen any issues with this bug since I commented in July. I'll download and start using the latest from master.
Thanks for testing. Feature freeze is tomorrow, so it's a good time to switch to the latest git and beat this up as much as you can. 24.12 release is December 4.