Add splitting (and resizing) to all types of clips

[regulus79]

Makes the knife tool work for all types of clips, not just SampleClips, and adds the ability to resize all types of clips from either side.

Originally, this PR simply added a splitClip function to all the other clip types, which were often quite complex in order to properly divide the notes or automation nodes into the resulting clips. However, due to imperfections in automation clip splitting, and the desire for all clips to be resizable in the future, this PR has expanded to add resizing support to all clip types, including MidiClips and AutomationClips. This allows a more perfect form of clip splitting done via duplicating and resizing.

As a compromise to those who may desire a destructive splitting of midi clips, using shift+knife on midi clips will perform destructive splitting, while the default use of the knife tool will do normal, nondestructive splitting. Note: Shift+kinfe used to perform quantized splitting relative to the clip start/end, but I have combined that functionality with the default knife functionality, so even without holding shift, the split pos will still be quantized either globally or relative to the clip start/end, whichever is closest.

Also, to accommodate workflows which may desire it, a new rightclick option was added to MidiClipViews which deletes all notes outside of a resized clip's bounds.

Changes

• virtual splitClip function added to ClipView
• virtual hardSplitClip function added to ClipView. By default this function does nothing, but it can be implemented by a derived clip view class. Currently only MidiClipView implements hard splitting.
• To aid with clip copying necessary for splitting, copy constructors were added to Clip and all derived clip classes which lacked one. This makes sure things like color, name, muted, etc, are preserved when a clip is split. These copy constructors were made protected by messmerd's advice. Instead, outside classes must use Clip::clone to copy the clip.
• AutomationClipView and MidiClipView updated to support drawing resized clips.
  • PianoRoll and AutomationEditor now have overlays to show where the clip bounds are.
  • The playhead in the PianoRoll limited to only play within the clip bounds
• m_autoResize renamed to m_resizable, and logic negated accordingly.
• m_autoResize added to all clips to tell when to use automatic resizing or not.
• NotePlayHandles will get cut off if they extend past the end of a midi clip. Likewise, if they start before the start of a midi clip and extend past the left bound, they will still play.
• discardNotesOutOfBounds was added to MidiClipView as an option in the context menu, along with a function to operate on a vector of clips, bulkDiscardNotesOutOfBounds.
• An option to change the status of m_hasBeenResized, "Enable/Disable Auto-Resize", was added to the context menus of all clip types, along with support for bulk operation on a selection of clips.
• mergeClips was finally moved from ClipView to MidiClipView where it belongs.
• MidiClipView::mergeClips updated to only merge visible notes.
• AutomationClip::flipX fixed to work with left-resized automation clips.
• Notes with detuning patterns share the same detuning when splitted #5940 was fixed(?) in the process of adding midi clip splitting. A copy constructor was added to DetuningHelper and its parent InlineAutomation, which is used by Note's copy constructor, instead of copying the detuning via sharedObject::ref.
• Clip::updateLength was added as a virtual method. Currently only AutomationClip and MidiClip implement it, but having it there makes the code much simpler.
• Minor: The split line color is now modifiable via css.

Bugs introduced

• When performing destructive splitting of a midi clip right across a note with detuning, the part of the note which ends up in the right clip has its detuning incorrectly positioned. However, this is quite difficult to solve in a nice manner, and it may have to wait until automation clips are reworked. Therefore, I think it is still reasonable to merge this PR in the meantime.

Bugs also in master

• Zooming while holding down the knife tool causes the split marker line position to move around.
• Knife tool doesn't work on selections of clips.

Old PR description

Changes

Most of the code is copied from SampleClipView.cpp's splitClip() function, and then modified for each clip type.

• A couple changes had to be made to ClipView.cpp to allow splitting more than just SampleClips, and to hold off on dragging clips that cannot be resized (MidiClips) when knife mode is enabled.
• Splitting PatternClips was trivial.
• Splitting AutomationClips and MidiClips was more involved, as because setStartTimeOffset() appears to do nothing, it required copying the correct nodes over and offsetting them back by the length of the left clip. However, the original clip still had all the notes, which meant that if the user changed some of them, its length would snap back to full. I had difficulty finding a good way to delete certain notes via a loop, so I decided to instead spawn two new clips, one left and one right, populate them with notes, and delete the original clip.

Notes

• In AutomationClipView.cpp, for some reason when splitting an automation clip, the new clips sometimes sets themselves to record mode. I added a temporary fix for this by setting the recording mode to the mode of the original clip. Fixed
• Because MidiClips are only drawn in multiples of 1 bar, splitting them between bars led to buggy graphics. Because of this, I forced the split position to be a multiple of a bar. Fixed
• I am not an expert in how to have objects properly remove themselves without memory issues. I called remove()close() at the end of spltiClip() for AutomationClipView.cpp and MidiClipView.cpp, so I hope that takes care of everything.

[Rossmaxx]

Style review. Do look at fixing the bracket spacing by looking at the diff.

[Rossmaxx]

Looks good now

[Rossmaxx]

@szeli1 mind reviewing this?

[szeli1]

@szeli1 mind reviewing this?

I will review this soon

[szeli1]

Please make the requested changes for all cases.
You should update this line inside ClipView:

//! Return true iff the clip could be split. Currently only implemented for samples
virtual bool splitClip( const TimePos pos ){ return false; };

And lastly I think using the remove() method is fine.

[messmerd]

Some minor nitpicks before I test it

[messmerd]

Here are some things I noticed while testing it:

• In Knife mode, the knife mouse icon doesn't appear when hovering over midi clips, automation clips, and pattern clips like it does for sample clips.
• Undo works incorrectly for midi clip and automation clip splits - the old singular clip returns, but the two split clips also remain.
• The snapping size is different for midi clips - I can't split into anything smaller than a full measure. Nevermind, midi clips don't work like that
• Double-clicking in Knife mode performs the same action as double-clicking in Draw mode. This problem already existed for sample tracks, but now also exists for other types of tracks too. Double-clicking shouldn't do anything special in Knife mode.
• When splitting midi clips, if the clip is cut down the middle of a note, the clip size of the resulting left clip is too small and hides the note that passed through the cut point. If the two new clips are ordered correctly, you should be able to make the right clip display over top of the left clip without needing to touch the size of the left clip.

Unrelated bug: In the Piano Roll, the mouse icon when in Pitch Bend mode can disappear if you click on a note, then close the note's automation editor window.

Other than the issues above, everything seems to work fine. I'm pretty excited about this feature and hope we can get it merged soon.

[sakertooth]

Can't say I am a fan of the PR, though I do appreciate the work put into it. The changes just seem way too extensive for the problem in question, not to mention the scope creep with adding resizing to all clip types as well.

In my mind, splitting should've worked the same way as sample clips, with the two clips being completely separate. The destructive and nondestructive splitting semantics feel... unusual. The user just wants to split the clip. The way we do right now is what this PR would consider destructive splitting. It may not be perfect in all cases (especially automation clips), but any imperfections could've been fixed later if there was enough reason to be concerned.

Auto resizing originally meant that (specifically in the pattern editor it seems) its length was automatically handled. What does it even mean for the user to be able to auto resize a clip?

Also, the polls to see if users would prefer destructive and nondestructive splitting... weren't effective IMO. To me, it seemed more like users wouldn't mind either way and not a hard yes or no to one or the other.

I can't review this PR and say I feel comfortable with the changes.

[sakertooth]

Update: Thought about the problem some more, and I will say that duplicating the clip and then resizing it is a viable way to implement splitting. The other destructive way that removes the data from the split clip could've also worked, but has clear downsides, with the only upside I see being that there is possibly less data is being copied but moved to the new clip.

As a compromise to those who may desire a destructive splitting of midi clips

I can't think of a situation where destructive splitting would work that nondestructive splitting doesn't. IMO, we should choose one way to split clips, not both. We should stick with non destructive splitting since it seems to work in more cases. This will simplify not only the interface in the code (i.e., developers do not have to worry about the semantics of hard splitting), but also simplify the interface for the user (i.e., so they don't ask the question, "how do I want to split this clip?" when using the application, which is an odd question).

The auto resizing behavior should stay the same. What needs to change is that clips can manually be made shorter on top of the auto resizing functionality that already happens with MIDI clips for example. If we go with the nondestructive splitting approach (which seems like the main idea here), then first we need to allow for all clips to be resized and make sure everything works in that regard. Then we can add nondestructive splitting. Doing both at the same time may complicate things, though this is mostly my opinion in the interest of keeping PRs small, focused, and reviewable.

[sakertooth]

Non destructive splitting should also have the added benefit of working the same way regardless of the clip type, so there shouldn't be any need for virtual functions (though, I guess you would still need a virtual clone function yeah)

[sakertooth]

Peki showcased the PR to me. It looks good. If there are any outstanding functional issues, they can be fixed later. We have to start getting these improvements merged.

[bratpeki]

Can we merge?

[regulus79]

Okay, so apparently I forgot to change how AutomationClip::flipX works to support left-resized clips, and I also accidentally broke recording automation clips. However, those should be fixed in the most recent commit!

I also made it so that AutomationClip::valueAt takes in the time relative to the internal "timeline" rather than relative to the start of the (possibly resized) clip. This makes it more consistent with midi clips, which have all their note functions relative to the internal start of the clip.

[regulus79]

Real quick, I've just made it so that you can't resize midi and automation clips leftwards past their start. It doesn't really make sense to resize them to include negative time values, since you can't edit them from within the piano roll or automation editor. It would be fine to keep it for flexibility, but I and peki were concerned users may find it confusing not being able to access one side of a clip even though you can see it on the song editor.

[bratpeki]

This looks really good! As far as the minor graphics stuff goes, just open a follow-up PR after merging this!

[regulus79]

I've renamed get/setAutoResize to get/setResizable, and I've renamed get/setHasBeenResized to get/setAutoResize. And I changed the xml save name from "been_resized" to "autoresize".
(also I negated all the logic because technically the old autoResize means not resizable, and hasBeenResized means not autoresize. When I say it like that it sounds confusing, but it's fine, everything should work exactly the same)

[firiox]

NotePlayHandles will get cut off if they extend past then end of a midi clip. Likewise, if they start before the start of a midi clip and extend past the left bound, they will still play.

I guess You mean past the end of a midi clip instead of past then end of a midi clip.

[messmerd]

@regulus79 PatternClip has a Qt slot called updateLength that isn't marked with override, and it's causing some warnings in the macOS builds:

/Users/runner/work/lmms/lmms/include/SampleClip.h:89:7: warning: 'updateLength' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
        void updateLength();
             ^
/Users/runner/work/lmms/lmms/include/Clip.h:134:15: note: overridden virtual function is here
        virtual void updateLength() {};
                     ^

Should it be made a regular method (not a slot) and marked with override?

[regulus79]

Oh right! I saw that warning come up a while back, and I was thinking of making a PR to fix it, but it was such a minor change, and it wasn't failing the builds so I sort of forgot about it.

The only issue with making it a normal method might be that it's used as a slot when setting up the connections in SampleClip::SampleClip for tempo and timesig changes. I wonder if it would still work if we kept it a slot and just added override to it in ? Or maybe we should make it a slot in Clip.h?

[messmerd]

I wonder if it would still work if we kept it a slot and just added override to it in ?

I don't know of anywhere else where we do that, so I think you should see if it will work as a regular method first. I'm pretty sure it will work, though I could be wrong.

Or maybe we should make it a slot in Clip.h?

I wouldn't