Instead of placing notes at their defined position, both DrumPatternEditor and PianoRollEditor do now take the lead-lag of each note into account and displace them accordingly. Altering the lead-lag in NotePropertiesRuler results in an immediate position update in the editor.

As the lead/lag of a node is an integer between [-1,1] scaling the maximum allowed value of 5 ticks we do not run in any trouble, like rescaling lead/lag on different tempo and sample rates, since the editors themselves are tick-based too.

Current UI when creating a chord/flam (both as the actual chord and the individual notes dragged into a diagonal to see their lead-lag values):

With this patch it will look like this:

I like it a lot. Previously the amount of lead/lag always felt a little bit esoteric. Now one can really see what is going on.

But the first thing that came to my mind is that it is now able to place on top of each other (three of them in 64 resolution). On the other hand, this is not a real issue as it was possible the whole time. It's just the first time you actually see it.

Nevertheless, there are a number of UX changes that are required

• lead/lag has to be taken into account in NotePropertiesRuler as well (the bar will move when dragged up/down?)
• select/drag/drop must also account for the displacement (in NotePropertiesRuler too)
• I found editing of properties of multiple notes stacked on top of each other to be quite glitchy. At least when subset of notes in a chord is selected, all changes should only affect these.
• in case multiple notes have been moved to the exact same position, do we use the 2x symbols to indicate this? Selection will be tricky in such a case. I would suggest rectangles with starting points (Note::__position) to the right of the notes will select the note with the right-most onset first and require another nudge for the note starting left of it and vice versa.

But there a couple of other things I need to address first.

@cme what do you think.

Addresses #2010