Post-refactor TODO list

[IanCaio]

For the sake of starting the reorganization sooner and moving away from our current "feature-freeze", some improvements that were not vital but interesting for particular PRs were postponed for after the refactoring. This issue is just a placeholder for those particular tasks, so they don't get lost inside the code-base and we get right into them once the reorg is over.

This is not a complete TODO list of the project, it just refers to things that were allowed to be delayed during the reviewing of PRs before the refactoring

• Fixing the AutomationPattern rescaling

_{Currently (on the master branch) the rescaling of Automation Patterns behaves quite oddly and isn't very useful on the UX perspective. #5712 changes a lot of the AutomationPattern class, but doesn't fix this odd behavior. There has been some discussion on how to improve it, but it was decided to do it in a separate PR. While it isn't changed, the rescaling of Automation Patterns discards discrete jump information of nodes, which shouldn't be a problem visible to the user considering how the rescaling is applied now (refer to the discussion on the PR page).}

• Improving the thread management on AutomationPattern class

_{#5712 removes race-conditions that were present on the AutomationPattern class by using mutexes. This however could cause issues with RT threads. A better approach to manage multi-thread access to the class is preferred.}

• Refactoring PianoRoll::dragNotes and changing the arguments so a single modifier argument is used

_{#5848 improves the grid snapping by adding another mode where the snapping is relative to the grid, not the offset. It involved adding code to dragNotes, and during review it was noticed that the method (before the PR) was disorganized and could use some refactoring. An idea was also raised that instead of using 3 arguments for the key modifiers we used a single one and that the modifier name was more generic and not the name of the key being used to enable it.}

• Possibly changing the PianoRoll Razor behavior when shift is pressed

_{#5845 adds a razor tool that splits notes in the PianoRoll. Currently shift is used to enable multiple splits in a row, but ideas were brought up that maybe it should behave the same as shift on the Knife tool. After the reorg we should discuss whether we should change the shift behavior to match that from the Knife tool.}

---

Let me know if other tasks should be added to the list from the reviewing of other PRs.

[cyber-bridge]

Possibly changing the PianoRoll Razor behavior when shift is pressed isn't a issue anymore since the shift behaviour got deleted from the piano-roll knife (former razor) tool so it can be removed from the list :-) See #5845 (comment)