On Sun, 13 Sep 2009 16:26:45 -0400 "D. Michael McIntyre" <[email protected]> wrote:
> 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. Maybe you could borrow a paradigm from graphic drawing programs where there are layers, one *is* the base layer, the first created and others that you create are layers that you can edit separately and flatten (or merge) when you get ready to export. You move between layers to edit them. Might not be relevant at all, but that was the picture I got in my mind when reading this post. SOM > > 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. -- ---------------------------------------------------------------- Jabber: [email protected] Skype: shelagh2648 ---------------------------------------------------------------- ------------------------------------------------------------------------------ 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
