pianoroll: add FL Studio-style draw mode (FL mode)

[pyrotek45]

FL mode is toggled via an 'FL' button in the pianoroll toolbar.

Behaviour:

• Left-click / drag on empty canvas: draw/create notes (MouseDraw)
• Right-click on a note: delete it immediately (no context menu)
• Right-click on background: no context menu ( menus slow you down here )
• Ctrl + drag on empty canvas: rubber-band box select
• Ctrl + drag on a note: copy-drag the note(s)
• Pressing 'e' / Edit button while FL active: turns FL mode off, returns to edit mode
• Pressing FL button again: turns FL off, restores mode that was active before FL

Implementation:

• EditingContext: virtual fl_mode() accessor (defaults false)
• Pianoroll: _fl_mode bool, _pre_fl_mode to restore previous mode, fl_mode_button ArdourButton, toggle_fl_mode(), mouse_mode_chosen() override to catch global keybinding action path
• MidiView::button_press: intercept Ctrl+left in fl_mode to launch MidiRubberbandSelectDrag instead of NoteCreateDrag; suppress show_context_menu when fl_mode active
• pianoroll.cc button handlers: rubberband only on non-note items, suppress context menu in release handler

ive alwayed dreamed of having a piano roll like fl studio again. this mode works to mimic the piano roll from fl. its very fast and easy to edit midi this way.

fl_mode.webm

im also these using the patches for the piano roll snap, and drag and drop from here in the video. ( its terrible without them ), but this commit is just for the fl mode.
#1077
#1078

[pauldavisthefirst]

I am in the middle (or maybe just the beginning) of the cubasish3 branch, which is bringing in many features of the cubase pianorolll. I'm not averse to bringing in the best features of the FL one too, but the master branch is not the target for pianoroll PRs at this point.

the cubasish3 branch already features the ability to see > 1 region at a time and x :cross-cursor"

When I'm done with my current goals for the cubasish3 branch, I can review these changes.

The next generation of cubase-related changes require scale-awareness which will involve merging another work-in-progress branch call scale-provider

[pauldavisthefirst]

BTW, how much of this was LLM coded?

[pyrotek45]

@pauldavisthefirst all of it. i did some manual editing of the fade canvas patch, but thats it. im not very well versed in c++ to do much help my self ( thought i do manually steer it when its making some pretty obviously bad decisions, whilst also making sure the changes are in separate branches and small enough to look over manually and lots of recompiling and testing ), and i figured this was just a cool idea that ive thought about for a really long time and wondered other peoples thoughts. ai seemed like a great way to see it come to life. also, adding in more features from cubase sounds like a really good idea, and sorry, i dont know how your github/pull request work or the branches you have in place for this stuff. anyways, im just trying to help you guys at least find the bugs and get them fixed. i tried to send in reports from 1 to 2 years ago on mantis and nothing ever really came through from it. im just hoping this stuff helps someone. i was originally just going to keep these changes for personal use. but i figured i might as well send them over here for review. BTW im spending my own money for the best version of claude for this.

[pauldavisthefirst]

I appreciate the effort. It will be a while before I'm ready to review this patch, but I will do so eventually. We're not likely to do the "FL button" idea, because otherwise there would need to be a "Cubase" button and a "Live" button, but I do want to get the best ideas from other DAWs, without questiom.

[pyrotek45]

that's great news honestly. looking forwards to what you have in mind. btw what are you ideas adding new modes like this though ( even though the fl button idea isnt gonna happen ,which is fair btw ), how do you plan on adding in in more features like this in your mind? perhaps a drop down menu of sorts or just different shortcuts?

[pauldavisthefirst]

I feel like I need to explain why Ardour's "draw" and "edit" modes exist.

A central problem in any MIDI editor is identifying whether a mouse drag by the user is intended to create new notes or select existing notes. Many other DAWs use a modifier key to do this (e.g. drag to draw, ctrl-drag to select).

Watching videos of experienced MIDI editors convinced me that typical workflows tend to consist of a series of note-creating operations, followed by a period of editing those notes. Obviously, there are always variations on this, but this seemed like the common pattern, rather than, for example "draw-edit-draw-edit".

So, in most other DAWs you have to press modifier every time you want to "do the other thing" (depending on the DAW, could be the draw op or the selection op). This means that if you use the "draw-draw-draw-edit-edit-edit" pattern, you have to use the modifier key every time the edit involves a rubberband select of existing notes.

This struck me as not very ergonomic, so in Ardour, you pressed one key ("d" or "e") to identify how you intend to use mouse drags for "the next little while". When done with that phase (drawing or editing), you press the other key to switch back.

This is not to die on - if a person almost never rubber-band selects notes, then the benefits of this design are missing. But at the moment, I still think it is a better design. I am open to being persuaded otherwise,.

[pyrotek45]

I see, when you explain your mindset like that, i can more easily understand your design. it makes a lot of sense. however, i do personally think ( after many years of using midi editors , that using a ctrl-drag to select ) at least in practice, has always felt easier to use, and faster.

when it comes to ergonomics, a ctrl-drag is often a very short operation. its not something you tend to need to hold the key down for very long, and it means when i let go, im back to drawing, which means i dont have to juggle more than one mode in my mind. also, depending on the workflow, your way could end up having a person press more buttons in a short period of time, than if they had a ctrl-drag option. for instance, in your example, i would agree that if the work was draw->draw->draw->edit->edit->edit, then in theory, you would only have to press d->e. 2 button presses. but if you change the order to a more flexible workflow which im prone to do when writing ( because i use the copy midi drag to help compose chords progressions often ), you end up with draw->edit->draw->edit->draw->edit , which ends up being 6 button presses to go between modes. where as, a ctrl-drag would have only had 3 presses in comparison, and less mental overhead of switching between modes.

normally, i use the rubber-band select as a second way of drawing new midi ( by grabbing a note or a set of notes that i want the shape of and copying them somewhere else ). this is a trick i see just about everyone online use, not just me. so having that as a separate mode here, really hurts my workflow ( and probably others ), since i will have to constantly switch between two modes even though in practice i kind of see them both as a drawing tool. i think you can kind of see me do that in the short video i posted where i use notes that ive already drawn, as sort of my brush. i very often use the rubber-band select as a draw tool, and when viewed that way, it opens up a lot of speed when composing midi for me. in the video, i draw 4 notes, and then use the ctrl-drag to sort of build a chord progression out of, but in my head, im still drawing, not editing. im also not thinking about modes, im just writing midi. all i need to worry about is, if i wanna rubberband select some midi, i just hold control. easy to remember and use.

[pyrotek45]

also, a quick side note. the way i have learned to use ardour when writing, is to just stay in edit mode. and use ctrl-click to draw. two main reasons. before you had the piano roll. editing was done on the timeline, which meant, that if i wanted to scroll on the "piano roll" within the timeline, i needed to have it selected, and be in edit mode. if i was in draw mode, i would be scrolling to other tracks if i accidentally tried to scroll up on the piano roll. The main thing i was missing was a way to just only edit the midi section. this is one of the biggest reasons why i never understood not having a dedicated midi editor. it just made it hard to work with a lot of midi imho. however, with the piano roll, that issue is gone completely! which means that using the draw tool doesn't feel as bad is it did before. however, even in the piano roll, i still stay in edit mode to have easy access to the rubber-band select, and i can use ctrl-click to draw in notes. so the edit mode has become my main way of drawing, which is ironic. let me know what you think of these points if you get the chance. having a dedicated piano roll is defiantly a big, no HUGE improvement to workflow imho, esp for someone like me, where most of my work is just editing midi. basically, the only time i use the draw mode is to create a midi region. but i use the edit mode to write/draw and edit the midi. which is kind of weird i think. i also think this is how most people end up using the midi editor when doing midi heavy tracks. even in unfa's midi editing vidio ( which is like 2 hours long btw ) , he says the same thing. and that was 5 years ago. https://youtu.be/ACJ1suTVouw?si=m6LOWf9fceyQX9Oo&t=2696