Add Playhead and Timeline to Pattern Editor

[regulus79]

This PR adds a visual indicator to show the pattern editor playing, along with a timeline widget to allow the user to skip forward/backward in a pattern.

Addresses #1195

2025-03-18.17-00-04.mp4

I noticed that the timeline arrow position moves smoothly while the step highlighting moves in steps, which kind of looks weird. Are you guys okay with that, or do you have any ideas for a better solution?

Changes

• Added a TimeLineWidget to PatternEditor, and set it up in the constructor, along with some helper variables (the track head width, which was copied from the Song Editor, and the max number of steps in the clips to calculate the pixels per bar, which has its own function to update)
• Added a new icon, step_btn_highlight, to overlay the steps which are currently being played.
• Added a getter function, TrackView::getClipViews() to allow the Pattern Editor to access the midi clip views to update them when the playhead moves. Previously, afaik, once the clip views are created, they leave the scope and cannot be accessed again, which is a problem.
• I was not able to neatly solve the issue of reordering the clip views when the clips get reordered (when pattern tracks are moved around in the song editor), so currently I loop over all of them to update them. It's not great, but it works.
• Added a getter function MidiClip::steps() to allow the pattern editor to know how long the clips are, and update the pixelsPerBar for the timeline accordingly (since we don't have scrolling yet; maybe this will change in the future). On second, this could probably be achieved via MidiClip::length(), but it probably doesn't hurt to handle it with steps. I can rework this if anyone wants.

Note: the current signal/slot system for the pattern editor is very odd; updatePosition doesn't seem to be called when the playback position changes, which means that I had to make it be triggered by something else. I have decided to connect it to TimeLineWidget::positionChanged, which works, but this may have to be reworked when #7454 is completed.

[regulus79]

Edit: Fixed. I decided to add a new signal to PatternStore which is triggered by the midi clips when the time signature changes, which in turn is connected to update the pattern editor timeline stuff.

Okay--I'm having a bit of an issue updating the timeline length when the time signature changes, since the midi clips respond to the Song::timeSignatureChanged signal after the pattern editor, so I can't get the updated clip lengths. I could potentially recompute them right there, or I could retrigger MidiClip::changeTimeSignature(), or perhaps something else. I may have to think about this.

[regulus79]

I have decided to make the code simpler by using the clip length instead of the clip steps. This means I do not need to edit MidiClip.h

[regulus79]

Do you guys want me to add some kind of timeline playhead for normal midi clips/sample clips/automation clips in the pattern editor?

[regulus79]

Do you guys want me to add the stop behavior and loop buttons?

[bratpeki]

Just noticed an issue with BB clips where you can make them too big by duplicating the contents, leading to freezing. Opening an appropriate issue. The PR seems great, though! No looping, keep it behaving like how it behaves now, to not make it too large.

[bratpeki]

I'd love some more eyes on this, maybe @szeli1 has time?

[bratpeki]

This is still great.

---

We should address the loop points issue, though.

Getting rid of the playhead is not an option, as it removes the ability to arbitrarily choose where to place the playhead, which is also a great addition.

The other option is removing the looping behavior, which introduces a special case to the playhead behavior in the code. Yikes.

---

There's also how the cells light up but don't play what's inside if your playhead is halfway through the cell:

2025-06-27.00-13-13.mp4

This is standard LMMS behavior, it happens for notes as well, so there's no point in sweating over it, it's actually preferred as it keeps consistency. I just wanted to point it out.

---

In any case, follow up PR material. LGTM and merge.

[messmerd]

Haven't tested it, but it looks fine to me code-wise