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.
porl
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:
http://www.sawstudio.com/products_midi_workshop.htm
This might be a way to keep the current audio application ‘lean and clean’ while still adding a dedicated sequencer for those who want it.
Just a thought. Have a great new year all!
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
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.
Shorter black keys? Could do that.
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.
porl
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.
midi scroomer implemented!
rendered using cairo, to get those nice antialiased keys.
midi-scroomer1.png
Great, looking forward to try it!
very nice. looks like it will fit right in with ardour’s look too. nice job
porl
The latest screenshot showing both scroomer and piano roll header. The keys on the scroomer are likely to be removed. Also changed the midi region transparency to enhance the visibility of the piano roll lines beneath regions:
ardour-scroomer-pianoroll3.png
i think the keys need to be on the ‘scroomer’, otherwise it is much harder to get a quick idea of the exact location of the zoom area. to tell you the truth, i’d prefer it without the larger keys next to it, as the light/dark areas on the region area show essentially the same information. i’m sure a lot of people would disagree with me though. maybe make it toggleable?
porl
The argument to make it stay there is to use it for testing notes, and to highlight notes when played. Initially I thought that it need not be there too, but now I’m convinced that it is a necessity.
yeah, i didn’t think of that. you are right.
keep it up!
porl
New mockup based on audun’s latest:
I have now created a patch for people to test. It contains new scroomer widget/midi scroomer, new (unfinished) piano roll header widget, and a new Lineset canvas item that draws the midi track underlay.
i really like the mockup thorwil. the circles do make sense (in terms of ensuring they aren’t confused for ranges). i also like the diagonal ‘zoom’ highlight (don’t know how else to describe it… it is almost 2am here…). i still believe the circles (or whatever handles) should only appear when the mouse is over some part of the scroomer widgit. i don’t mean the mouse has to be where the circles are for them to appear, but anywhere on the piano scroomer widget itself. i think many midi tracks on screen will look messy otherwise.
this is all looking really good though guys
porl
thorwil: love those retro looking piano keys with the little shadow:) Will try to do something similar in the code!
