On Sunday 13 September 2009, Julie S wrote: The biggest problem I can see with smooth scrolling where the cursor position represents something very significant is that when you stop, it could wind up anywhere. Moving it to a logical "snap point" does indeed make sense as a solution to that.
So how complicated is it to implement? One problem is there is one cursor sweeping through time across 42 different edit views, and we have a global transport. User hits stop on the global transport, we have 42 different edit views that all could have a quite different idea about a logical place to go park the cursor afterwards. So what already happens here? Two segments, one full of whole notes, one full of 16th notes. Four edit views, two notation, two matrix. Hit play, hit stop. The two notation cursors are drawn in completely different places. Where does the cursor update happen, and why? The advantage of the current scheme is that wherever it is when you hit stop is a logical place for it to be in that edit view. No "transport stopped" update action has to be triggered, if one even exists to trigger. It's just there. Your idea would require some thinking. I have no idea how much, and no idea how any of this code works off the top of my head. I'm just looking and thinking with no opinions implied. > First of all moving between staffs has issues if there are no notes or > rests. Very true. I just experienced that first-hand. It's almost impossible to control, currently, because these up/down are missing. > But here is my thought: > Since the cursor is already at a known place (duration-wise) in the > notation view when the cursor moves up and down the staff at the "known" > position, interprolating if necessary to calculate where that would be on a > staff that doesn't have an explicit note or rest there. That way as the > cursor moves from say the top staff to the bottom staff (maybe 3 or 4 > staffs) away, the position in the work is not lost. Interesting thing about that is the way each staff seems to have its own cursor resolution ideas. You're on the seventh 16th note up here and you move down here where the half note is, and the cursor wants to move left. > Now about multiple segments on a single staff.... > > All thought I have on this seems expensive, including graying out notes or > coloring the active segment differently. > > Another expensive solution is to implement a virtual breakout of the > segments onto separate staffs for editing. I wonder how firm the staff/track relationship is, and how much rework would be required to get segments that belong to the same track to display on different staffs. I love the idea of doing a quick and easy breakout and collapse, but I find the implementation looks like a dark and dangerous forest. If we had it, I could definitely live with that myself. Expand the "layers" to edit them (otherwise you can only edit the "base" layer) and collapse them back up. One huge problem with that idea is there *is* no "base" layer at all. What segment is on the "bottom" of all this? This is also a problem on the main window with expanding height tracks. Depending on what you do in the way of making segments overlap, they change which "lane" they are in to minimize the use of space. It isn't a fixed relationship. I don't remember any of the details now, but at the time Chris implemented expanding height tracks, we talked about this, and just couldn't come up with a sensible way to give an individual segment a fixed position in this scheme. Letting them "float" was much more practical. It still is in this scheme too, but if there's no way to establish the "base" layer for editing, then you could only edit overlapping segments when the staff was exploded out. That might be workable. Noteworthy Composer required you to edit everything on completely discrete staffs, and then use some dialog to merge this with that. Our scheme would at least be quicker and less involved to use. Just a wild thought, since they're all on the same track, the track header should grow tall enough to encompass all of them. The track header itself would be a logical place to put the expand/contract control. Well, off to work now. Fun day of tossing ideas around. I hope we can get a plan together and figure this out soon. Unfortunately, we have to add another mountain to tunnel through to our list. -- D. Michael McIntyre ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
