Dear Michael,
You wrote:
> Chris did that on purpose. We have to have the cursor
> stop at meaningful
> points in notation if it is to serve as the insertion
> cursor. (Because that's
> what the old insertion cursor did, for good reason.)
> I don't like the
> choppiness either, but I'm afraid his reasoning is sound.
But there is no good reason to do this on playback. Specially with multiple
staffs (segments). The currently we just follow the notes on the active staff.
Say the current staff has whole notes on it and the staff below has 16th notes
on it. The cursor is only updated every 4 beats in this case, but clearly
should have advanced on the 16th notes.
So, on playback, the cursor at least needs to respect everything in the windows
and update.
Now for editing, moving in time like it does is good. But doing both creates a
'corner case.' But that is easy to solve. The cursor should just move back to
the last active note or rest in the active segment.
But tracking everything in every segment for cursor playback might get
expensive. So a smooth scrolling solution may be easier to manage, plus we
already have code for that.
So, my thought is to have both. Coarse (duration based movement for editing),
and smooth cursor flow for playback.
This idea can be extended to matrix view, of smooth scrolling on playback, but
snapping to last note (or grid) when payback stops.
You wrote:
> So anyway, taking away from all that, I said "all of this
> is pretty easy to
> control clicking with the mouse to say where you want to do
> something." There
> is one big exception to that, and that is the case of
> overlapping segments on
> the same staff. It's still really hard to control
> that effectively, even in
> Classic, to the point where I usually wind up...
Right, multiple segments on staffs on a segment can be an issue.
First of all moving between staffs has issues if there are no notes or rests.
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.
This could be very useful in chord mode so you could put a chord in one staff,
move down a couple and add the Bass note in at the same location.
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. This could be used to our advantage. We
could have separate segments and then direct notation view to combine them or
split them as we need it to, whether it is for editing purposes or for actual
display reasons.
Sort of like having a first and second violin on a condensed single staff
versus, having them on separate staffs. Maybe we could toggle between options
easily so editing them would be straight forward.
Sincerely,
Julie S.
------------------------------------------------------------------------------
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
