#1777 Event editor selection highlighted, but item not selected

[musewhirl]

Steps to reproduce:

1. Place playhead before a note in the Matrix Editor
2. Switch to the Main Window and hit Eto open the Event Editor
3. The note appears to be selected, but is not
4. Try edit by pressing E (Edit) and nothing happens
5. Even the Edit menu items appear to be enabled
6. Worse still, try I(Insert) e.g. a pitch bend
7. On OK, the pitch bend dialog does open, but the Absolute time is zero i.e nothing to do with the selected note
8. If the time error is noticed, Canceling the window returns to the Event Editor, but the false selection persists
9. The user can click on the item to actually select it...nothing appears to happen, but on opening the pitch bend editor again, the Absolute time is correct
10. In addition, the Edit menu items now match up if the user selects the row.
11. Also, on CTRL-click the fake selection highlight vanishes, and the Edit menu responds by disabling Edit

Just an additional comment...perhaps the Absolute time field should be selected on opening. That way, left arrow will move the cursor to the start of the time (unlikely wanted by the user), while right arrow will move it to the end, where they can more easily adjust the relative position. And of course, if high-lighted, delete the whole field in one go...again unlikely. Opening with a field selected is how track name editing, and volume change editors open. It's not crucial though.

[Philip Leishman]

Yes - the initial selection is not done properly.
See merge request.

[musewhirl]

Note that I have not tested the latest fix yet, since I await feedback about the compatibility popup window in master. In the meantime...

First off, I'm amazed that pasting events in the EventEditor works. It looks deceptively simple, but is not. But I can see one small problem, and it's related to selections.

Scenario: Here are some made up events as seen in the EventEditor:

73920    noteA
73921    pitchbend
74040    pitchbend
74060    pitchbend
74080    pitchbend

Now, say I want to copy the pitchbends (not the note) elsewhere to a different segment. Obvious solution is to select the pitchbends, copy them, then find the segment and open the EventEditor for that.

Let's say there is one note in the destination segment:

83280 noteB

I select that note meaning to bend it like the one at 73920 above and get this.

83280    pitchbend
83280    noteB
83399    pitchbend
83419    pitchbend
83439    pitchbend

Alright, so the order is mixed up, but it's the same time location anyway.

However, I wanted the pitch bend locations to reflect those at the other location (no 9's). So, I return to the original location, and this time include the note in the copy. When I paste, I get:

83280    noteB
83280    noteA
83281    pitchbend
83400    pitchbend
83420    pitchbend
83440    pitchbend

And I can delete noteA, and I get what I want. I've seen no obvious other way to get this. Is there one?

83280    note
83281    pitchbend
83400    pitchbend
83420    pitchbend
83440    pitchbend

Assuming the answer is no: If a location to paste was offered with a popup, I could pick 83281 (i.e. the offset of 1) and would get that precise positioning too. But that gets in the way of the quick intuitive paste at the selection.

Consider what happens when nothing is selected the EventEditor. The paste automatically goes to the start of the segment (in my case) i.e. an assumption, which is fine when there are no already existing events. But, if there are events AND no selection AND we remove the assumption to instead popup a window with the start of the segment as default, the user could edit it to paste the sequence of events where they really want it to go without the above workaround.

Does that seem like a way to solve the problem? Or do we just live with the workaround?

[Ted Felix]

The event list editor doesn't have a playback position pointer like matrix and notation. With them, you can set the PPP anywhere you want and paste.

How about a "Paste At..." feature? Ctrl+V (Paste) would put it down at the currently selected event like it does now. A new Ctrl+Shift+V (Paste At...) would pop up a time dialog primed with the currently selected event time and paste at the time the user selects. You can always remap using the shortcut editor if you find yourself needing the time dialog more frequently.

[musewhirl]

Funny enough, the method I used made the event editor behave as though it had a PPP. That's why I visited a segment first using the MatrixEditor AND selected the note BEFORE returning and opening the event editor. The PPP was then just before that note. A bit cumbersome, but it worked. But since the timeline itself is created in the event editor as events appear, points in between don't really exist...that's why I said I was amazed pastes worked at all...but it uses relative time from a known point to overcome that...which is why we need to specify that start point.

But the PasteAt feature is excellent. I didn't mean to ask for a whole new feature for something so minor, but if it's simple to implement, it solves the problem completely. Do you want me to create a new feature request around this or should we just let it absorb into the event editor in this bug along with the selection changes?

[Ted Felix]

But the PasteAt feature is excellent. I didn't mean to ask for a whole new feature for something so minor, but if it's simple to implement, it solves the problem completely.

Should be very easy. (But then I've said that before and spent days on something that just got more and more complicated. 🤣)

Do you want me to create a new feature request around this or should we just let it absorb into the event editor in this bug along with the selection changes?

It's fine here. I've got it in my email, so it will end up on my todo.

[Ted Felix]

Pushed new Event List Editor Paste At... feature as [b3682e]. Please test latest git.

[Ted Felix]

Merged Philip's change as [1a171a]. Please test latest git.

I put back the setCurrentItem() call to make sure the keyboard works correctly if the user tabs into the table and wants to navigate that way.

[Ted Felix]

perhaps the Absolute time field should be selected on opening.

This is EditEvent::m_timeSpinBox. Selecting the text within would be consistent with tabbing through the dialog. I'll have a look.

[Ted Felix]

Just pushed [9d3dca] which selects the text in the time field when the Edit Event dialog is launched. Please test latest git.

I think this one is finished.

[musewhirl]

There's still a minor problem with the selection.

1. Open the EventEditor on a segment with multiple notes, where the playhead is at the start of a note
2. Use the up and down arrow keys, and the selection does not move to the other events
3. In other words, the event is not properly selected
4. Now mouse click the event
5. The up and down arrow keys now move the selection i.e. properly selected
6. Why use the word properly? Because E to edit opens the Edit Event window on that event, andI to insert opens a window primed to insert at that event location, so it's apparently selected

And something I didn't mention last time because it's all related to selections and I thought it would be seen:

1. Hit I to insert an event
2. The Absolute time field now has contents selected i.e. confirmed fix for this bug
3. Alter the location to be just ahead of the event e.g. add 1 to the selected Absolute time field value
4. Use ALT-O to close the window
5. The previous event is still selected in the EventEditor, when I would have expected the new inserted event to be selected
6. Of course, for Edit, the selection is expected to remain with the event, but if the Absolute time was changed, then it still must follow the edited note to its new location (feels like the situation for tempo editing some time ago)

I guess the next best selection after editing an event could depend on what one is doing. However, if adding one event after the other, then the new event should be selected so that when E or Iis hit, the new location is in the Absolute time...just an opinion though.

[Ted Felix]

Use the up and down arrow keys, and the selection does not move to the other events

This is because keyboard focus is on the "Note" checkbox in the left column. Press Shift+Tab and the list will have focus, and the up/down arrow keys will work.

Some things that probably should be addressed for keyboard users:

1. Give the event list keyboard focus on launch.
2. Fix the practically invisible keyboard focus indication for the checkboxes. Black on dark gray is not a good color scheme. Go with something brighter.
3. There is no way with the tab key to get out of the event list and back over to the checkboxes. Tab goes through the items in the list and there is no way to leave. Is there some other key combination that gets us out? Seems like since the arrow keys allow navigation through the list, tab shouldn't go through the items. Is there a way to turn that off?

[Ted Felix]

Event List Editor initial focus fix pushed as [c527a2]. Please test latest git.

[musewhirl]

Works just great.
I'm one for noticing new log entries though:

[PasteEventsCommand] pasting when not possible

I'm not sure what that can mean since obviously it was possible :-) It worked! Anyway, and the log entry is harmless, although misleading.

[Ted Felix]

Erroneous logging removed in [bdc32c]. It may have been useful to someone years ago, but now it is completely wrong.

[Ted Felix]

Event List Editor "select new event after insert" fix pushed as [5131ab]. Please test latest git.

[musewhirl]

Field selection on opening now works.

Inserting an event causes that new event to be selected when the popup is closed. The latest fix says for insert, but just in case, when editing an event, nothing is selected on closing the popup, so you don't know which one was edited. Perhaps you're already working on it.

The next two would likely be different bugs, but it was uncovered during this bug. I'll mention them here and if they are separate bugs, let me know and I'll open them.

Set Event Velocities used to default to 100, which is the default value of a note. Now it defaults to an unlikely value of zero now. Was that an intentional change?

Steps to reproduce:

1. Select one or more notes in Matrix Editor
2. Select menu option Adjust/Set Event Velocities
3. Its popup is now zero

There is also potentially another bug: Event velocities only work for the first of tied notes.

Difficult to know if this is a design decision, but RG allows the user to set the velocities of two sequential notes individually. When the notes are tied and played, both notes play with the velocity of the first note only. Note, that the velocities can be set individually, even when tied.

Steps to reproduce:

1. In matrix editor create a 1/16 note followed by a longer note
2. For an extreme case, change the second note to e.g. zero velocity
3. Tie the notes
4. The velocity will sound like the 1/16 note for the entire tied duration

I expected the velocity MIDI message to still be sent with the second note, and the MIDI sound module to adjust the velocity accordingly, while still holding the note. Or is it only ever the duration which counts? For all I know a MIDI sound module can't even do that.

[Ted Felix]

There is also potentially another bug: Event velocities only work for the first of tied notes.

This is working as designed. Tied notes are reduced to a single MIDI "note-on" event at playback. That single note-on has a single velocity. The expression controller is for changing the intensity of a note in progress.

The other two issues look legit. I'll have a look.

[Ted Felix]

when editing an event, nothing is selected on closing the popup, so you don't know which one was edited

Fixed in [c6ec41]. Please test latest git.

[musewhirl]

The edited note now remains selected in the EventEditor after the editing popup closes, even if its location was changed.

[Ted Felix]

Set Event Velocities used to default to 100, which is the default value of a note. Now it defaults to an unlikely value of zero now. Was that an intentional change?

Check the "Velocity" value in the toolbar between Grid and Quantize. It's using the value from there.

[musewhirl]

Ahhhh, but I didn't change the default. This problem is related to that change involving the "deprecated elements" popup mentioned in [#1774]. Prior to popup, the rg file <matrix> element has velocity=100. But after that popup instructs the user to save, the velocity in the rg file is changed to zero. The default velocity in the menu bar is correspondingly set to zero on opening the MatrixEditor on those elements leading to new notes being zero.

Now that is going to cause considerable grief to anyone caught up in this, because that value is set per segment. Of course, like you mentioned before, the official off-master users will not see this problem, although I have not verified that.

Assuming that the above analysis is correct, how is this going to fixed in general for those who saved after that popup?

[Ted Felix]

A note-on event with velocity zero is essentially a note off. We probably shouldn't even allow that drop down to have the number zero in it. It makes no sense given that rg avoids exposing the "note-off" concept to the user.

At any rate, I'll take a quick look and see if I can figure this out. I think I have some old example files lying around from this that I can use to test.

[musewhirl]

It's important to bear in mind that it's not the zero per se which is the problem. The zero was always in the dropdown, but it was never the default. It becomes default when the OK is hit on that deprecated popup i.e. the one to correct the previous problem velocity issue. I can even see it happen now, but only with sessions after the change you made and removed from master. If any of those sessions are saved after the popup, then all the segments default velocities become zero. If the save is aborted, then they are all 100 in my case.