Add splitting to all types of clips

[regulus79]

Makes the knife tool work for all types of clips, not just SampleClips.

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.

[regulus79]

I think I have fixed most of the bugs, however I don't understand how journalling works enough to fix the bug where the new clips don't disappear after undoing. I will continue to look into it, but I may need some help.

Also, I decided to remove the restriction on midi clips needing to be split on the bar, and instead implemented your suggestion on letting the left clip's length be longer and extend behind the right clip. So now they can be split at arbitrary positions!

[regulus79]

Ah, nevermind, it seems that using close() instead of remove() makes it work! I will have to look into why that happens.

[messmerd]

A quick review before I test it again

[messmerd]

@regulus79 It seems that when I split a midi clip, the original singular clip still remains though it is invisible. You can hear it when the song plays since it plays twice as loud as before the clip was split, and if you clone the track, it becomes visible in the cloned track.

[regulus79]

Okay that's an interesting bug... I think it may have to do with me using close() instead of remove() when removing the old clip. But that's odd, since it doesn't appear to happen for AutomationClips which also use close() (???)

After some testing, it appears that using remove() solves the issue. I also think I found the cause of the old problem when using remove(), which is that I was calling it after m_clip->getTrack()->restoreJournallingState();. Again, I'm not an expert in Journalling, but calling it before appears to fix the problem.

[messmerd]

Midi clip splitting seems to work fine now. I wasn't able to find any problems with it while testing.

Pattern clip splitting also seems fine.

However, for automation clips, if you make the split directly on a node with modified tangents or with an outValue, it doesn't split correctly.

[regulus79]

I fixed the problem with out/in values and tangents in automation clip splitting.

[messmerd]

Seems pretty good now except for an issue when splitting Cubic Hermite clips, which I explain in a comment below

[messmerd]

For some reason this doesn't seem to be working, since the nodes to the right of the split point still remain in the left clip after the split. It doesn't make a difference though because the left clip's length is shortened which prevents nodes past the clip length from having an effect.

This might be a good thing, because with Cubic Hermite automations, neighboring nodes can affect the shape of the waveform not just between the node and its neighbors but also between its neighbors and their neighbors. This means that simply chopping off nodes to the right of the split point in a Cubic Hermite automation clip cannot really be done without changing the shape of the waveform to the left of the split point, even if you add a new node at the split point.

Simply shortening the length of the left automation clip without removing any of the nodes seems to solve that problem for Cubic Hermite clips, but the problem remains for the right clip. Unfortunately the length of automation clips cannot be modified from the left side the way sample clips can - only the right side - so the clip to the right of the split point cannot be fixed in the same way.

I think these are our options:

1. Make automation clip length adjustable from the left side too (similar to sample clips), and use that feature to split Cubic Hermite automations without changing the resulting waveforms
2. Pretend the problem with splitting Cubic Hermite clips doesn't exist
3. Return false for Cubic Hermite clips (and possibly print a command-line error message) to disallow splitting them, at least for now

Option 1 is the only genuine solution I can think of, but it would be difficult and beyond the scope of this PR. So that leaves options 2 and 3. Personally I favor option 3 to avoid the strong possibility of messing up automations when splitting them.

What are your thoughts?

[regulus79]

For some reason the nodes to the right are being deleted for me; I believe my branch is up to date, so I'm not sure why it is not working for you.

Regarding splitting Cubic Hermite clips; that was also on my mind, and I agree I don't believe it's possible to accurately reconstruct the curve by inserting a new point in the middle. Option 3 seems a bit inconvenient for the user, since I think an approximate split is better than no split at all. I was originally planning to let it slide with the current implementation, but now that you bring it up, I do think it would be good to take the time to do it correctly and make sure everything is exact. I think I will try and see how hard it is to do option 1 and implement ResizeLeft for automation clips.

[regulus79]

Done :) That only took about 30 minutes to code, not bad at all!

I added the ability to resize automation clips from the left (I had to add offsets to a few variables in paintEvent; I think I noticed a minor graphical bug with vertical lines sometimes appearing, I will look into that tomorrow), and I changed the splitClip code to essentially match SampleClip and PatternClip. This does however mean that when editing the right split clip, all the previous nodes are in front of you, which may be a bit odd, but it works.

(Now I'm thinking; it might be good to also change the timeline numbering in the AutomationEditor to help users see where exactly the clip starts...)