Dear Chris,
You wrote:
> Nice idea, but it's not likely to be simple in cases where
> the thing
> in the ruler is not an event (e.g. velocity).
Well, yes and no. We both know that velocities are tied to the note event
itself. We've always had to handle the velocity ruler differently in some
respects because of this fact.
So it isn't any harder than it already is to implement cut and paste, etc
features to the event rulers, but it does require some thought.
Since we already know velocities "must" be tied to a note. Selecting them in
the velocity ruler should select the notes that go with them. The
reverse--selecting notes--does select the velocity bars associated with them.
So in this sense moving, deleting, etc will happen as a group between the
velocity ruler event and the actual notes.
We already allow via the velocity tool to select notes and alter their
velocity. We can also select velocity bars when notes are selected. These
bars can be grabbed and altered.
So really for velocities, the selection tool just needs to allow selecting of
velocities in the ruler--though I admit this could be a poor user choice for
anything but the monophonic sections.
But that would round out the velocity selecting paradigm.
Basically, if the user selects velocity bars, the notes associated with the
bars are selected.
So yes the velocity ruler is special, but it always has been a bit special,
since it was providing meta data about the actual notes, where as the other
event rulers are providing data not tied to any note.
At least if we allowed this kind of selection in the event rulers, we could
allow some sort of grouping to occur during editing without actually providing
a way to anchor events ruler events to notes.
So this is a flexible solution that lets users decide if they need to grab
events ruler items along with notes before editing them. This grouping occurs
without much extra baggage, since the reality is that all RG cares about is
what is in or not in a selection. We just lets the user decide if events are
associated in some relative fashion and don;t have to provide and new way to
anchor events to notes.
It's a fairly low cost (computing resourse-wise) solution that has a nice perk
to it.
The people power side of it...hmmm seems feasible, but I hadn't really studied
our code it in-depth.
Sincerely,
Julie S.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
