Here are some thoughts on midi editing and view presentation, especially in the “midi track” domain. I am fully aware that the current implementation is far from finished, so I consider this input to the discussion on how things should work in the end.
The current midi track draws note separators across the entire session from start to end. Note separators only makes sense inside a region. Outside a region they only provides noise to the overall editor “picture”, especially if they are close together.
A user might not want the same view range for every region in the track, even if stuff inside one track often corresponds to one instrument, which normally stays inside one consistent range of the frequency spectrum throughout a musical piece. Thus we may consider to attach the piano to the region itself, to allow different view ranges per region in a track. This again will result in problems when the start of the region (where such a piano would be attached) is beyond visibility. The remaining options are then to not allow different view ranges per track, and the other option is to not use a piano header at all, but only highlight the note fields (between the note separators) according to whether it represents a white note or a black note.
View range selection. The current model features two choices: View the entire note range (0-127) or view the range from the lowest note present to the highest note present. The problem here is when you want to add one note by using the mouse above or below the currently visible range. Assuming a uniform view range for all regions in a given track, i propose adding a vertical scrollbar to every midi track header. Some scrollbars have “zoom handles” at
each side of the box that represent the visible range, allowing to change the size of the visible range (Some other DAWs make use of the horizontal version of this type of scrollbar for the view selection of the session (often also with a miniature view of the session drawn behind it)). The ASCII mockup of the horizontal version:
In order to extend the visible view, one grabs handle 2 or 4, given the direction one would want to extend in. To move the range, grab 3. Or optionally press 1 or 5, which strictly speaking are not needed.
Maximum track height. I consider the current limitation of track height too small to do efficient midi editing in all cases. If the view range includes many notes, the notes become too narrow to hit with the mouse pointer.
Right now I’m starting to do an implementation of the said “scrollbar” in GTK+/C, and I would surely appreciate comments on it’s appearance and an appropriate name for it, or if there are simpler solutions to the range size/range movement problem.
I also propose extraction and modularization of “track background”: A piano roll track background (with note separators or black and white fields) are naturally used for midi track background, but can also be used for automation track background, where the parameter controlled describes frequency or other note related data.
As illustrated in Thorwil’s blog, it should be possible to provide a “ghost background”/“underlay” to every track with a piano roll background. The ghost background mirrors other tracks or regions below what is actually part of the track, and helps musically arranging different tracks in accordance with one another.
nothing really interesting to say, other than the fact that i’m really interested to see what comes of this. i definitely like the piano roll black/white background (obviously more grey/darker grey) idea
Then the first test shot of a scrollbar for selecting note range. This shot features the standard gtk scrollbar, which does not meet the needs of what I want. The special purpose scrollbar is not finished yet. Also it looks a bit cheesy with the gray color inside the red track header, but I hope people will at least understand the idea. ardour_piano_roll2.png
The piano bars should be more prominent inside the regions, not less. Empty track space could do without them, even. Then again, they help to identify midi tracks as such.
Moving the RMS buttons in the track headers out of line to fit in a scrollbar is not acceptable. I’d prefer to have dB rulers for audio tracks in one column with midi scrollers. dB rulers could work like in some sample editors, allowing to zoom into a dB range (nice on low level passages).
I totally agree with you. But there are several technical “difficulties” (I don’t know color math that well, maybe others may have some ideas) when it comes to making the bars less prominent outside the regions. Unless it is possible to provide another alpha compositing function making the colors in the underlay more clear in the region, we may have to draw rectangles between the regions instead, to make the colors there less prominent. Currently (I think) it’s impossible to increase the contrast between white and black bars by putting another rectangle above it, the colors would only tend towards the color of that rectangle, at best leaving contrast intact or reducing it.
Ruler/range selector: The plan is not to break the alignment of the buttons, but adding something into an audio track that I suspect might be a rarely used feature just to keep the alignment is not an optimal choice. I would prefer to alternatively keep that area in audio tracks empty.
We may also think of alternative ways to select the midi note range effectively, maybe something other than the proposed ruler/scrollbar. Any thoughts on that thorwil?
It appears that the range scrollbar is not the publicly wanted solution. There exists some other approaches though:
Use a modifier key combination and the mouse wheel inside the track to increase/decrease the view range. When in the upper part of the track, it increases/decreases the max note visible, and while in the lower track area the same applies to the lowest note visible.
i think the modifier key+scrollwheel is the best. assuming there is some other ‘full’ view of the note matrix, changing the range in the arrange view is a convenience rather than a necessity, so it doesn’t necessarily need to have screenspace dedicated to it. if there is no dedicated matrix window (i can’t seem to get the trunk to compile so i can’t check) then that is a different story though.
Has anyone brought up the idea of a dedicated ‘sister’ application to give midi sequencing support to Ardour, rather than adding to the primary codebase itself?
This could be much along the lines of SAWStudio’s midi package:
skipkent: That discussion is over. MIDI is implemented in trunk. Nobody is going to remove it. Lean and clean? sheesh. You will hardly notice if you don’t add MIDI tracks.
A trio of concept mockups on scrolling and zooming:
not a big fan of the third mockup, but i think the first two work well. maybe implement the second as the ‘mouse over’ version of the first? one thing though is i think the keyboard should look look a little more ‘realistic’, with the black keys shorter than the white. looks too much like a barcode otherwise
porl: the handles from the 2nd shouldn’t appear on mouse-over only, because you need to either aim at them or avoid them, depending on what you want to do. Both much easier/faster if you can see them all the time.
wouldn’t the lighter/darker region show where to aim anyway? i pictured the handles more as a visual clue to highlight what that region does. when i say mouseover though, i mean when the mouse is over any part of the scroller, not individual mouse-over areas inside it.
ie: move the mouse over any part of the scroller area and the ends of the ‘bright’ section are highlighted to show they are ‘hotspots’. i think having them on all the time will lead to a messy appearance, especially with many midi tracks on screen.
I think the clue here is whether the range is what’s between the handles or the handles are also part of the range. In the case of the former, handles should not be transparent, or much less transparent than they appear in the mockup. In the case of the latter, the interesting information (where the range starts and ends) is made more difficult to see, because of the very prominence of the handlers… Anyway I think the latter is the way to go, because that way we can draw the key range across the entire track height, and not subtract the height of the handlers at the top or at the bottom… eh, right! I hope this was clear enough.
audun: clear enough
The handles are drawn on top of the view range. But if the view range becomes too small, they would need to be drawn outside. Maybe they should default to half inside / half outside, but for this mockup I decided otherwise to not have it look more complicated.
Having the full area for drag-scrolling with no ifs or buts would be nice, so zooming via left-right movement should be considered even without on overlay (yellow lines). Another option would be using a modifier key for resizing the view range.
The handles could stay inside when the range is small, if the height of the handles is set to minimum-range/2. For instance we might decide that the smallest possible range in the midi editor is one octave.
We still have problems when the track height is small though. We cannot fit the scroomer into the smallest tracks.
