On Thursday, November 25, 2010, Ian Gardner wrote:
> There's a putative implementation of having a relative transposition on a
> linked segment, committed to the linked_segments_ian branch.
Did we ever settle on a better way to create linked segments? I had a lot of
trouble remembering the current scheme in order to create one.
> I've stuck a test UI on it, although I expect a jolly good flaming for my
> crimes against UI standards ;-)
You're right, it really is pretty awful. Let's get you and Yves on the same
page first before I sort that into something presentable though. We need to
figure out what is merging into whose branch, and whose branch is merging into
trunk.
> I've put some buttons in a "Linked segments parameters" collapse container
> under the segment panel on the left hand side - one to bring up a
> transpose dialog on a linked segment, and another to reset the transpose
> on a transposed linked segment.
I couldn't figure out how to make it work for my test problem. Some people
may think that way, but I don't, so we need some other options here for how to
specify by what amount to transpose. Some of the options in this stock
transpose by interval dialog are going to need adjusting for this use too, I
think, but I'm not sure exactly how until I have more experience fooling
around.
> There's also a menu item in the notation editor to add a clef change which
> only applies to one particular linked segment.
It works, and it seems like a good idea. I don't like how hard this is to
discover, and if I want to change the existing clef it's not clear how. I'll
have to think about that stuff.
> 2. press the "Change" button on the linked segment parameters collapse
> control on the left hand side, choose whatever transposition parameters
> you want. You can change key or not, according to your whim.
Just thinking out loud about a better GUI, not writing a prescription for what
you're expected to code...
The UI I'm expecting to see out of Rosegarden would have the segment's
transposition displayed in this special parameter area, so you can see where
you are at a glance.
I'm thinking that instead of having the parameters in a collapsing frame, what
we probably want to do is make the SPB smarter and have it display only
editable properties on linked segments. The controls in the collapsing frame
are useless for normal segments, and vice versa.
This could probably work pretty well, I'm thinking "at a glance." It should
be pretty straightforward to display only certain properties for linked
segments, and make those behave differently. ie. the transpose box shows you
the transpose of the link, no the master, and manipulating that transpose
works on the link only, and so on like that.
Where this gets muddy is what to do when there are both linked and standard
segments in the same selection. In practice, it might not be all that bad
though. There are already a lot of cases where we display a * because
segments in the current selection have conflicting parameters. Probably the
single hardest thing here is that you can edit those *'ed parameters in order
to change all segments at once. What happens if you have a selection that
includes both straight and linked segments that are related to each other, and
they have a different transpose? You could get a race condition, or some
other kind of utter chaos.
> 3. move/add some notes, they should be linked but appear on the stave in
> the correctly offset positions, and if you've chosen to change key also,
> this should be respected.
The key bit is going to need some more thought, so let's do some of that too.
My gut is telling me that while Rosegarden is the application of options and
has resisted the idea of removing functionality for the sake of simplifying
things, we have been trending toward reduced simplicity in new features.
It seems the best approach to this business of keys is not to ask, not to
provide special options, but to just handle it automatically so that the
transposed links are in the same key as the original. Key signatures need
transposed, even clefs need adapted (to be replaced with those special only-
in-the-linked-segment clefs) and that kind of stuff should just happen,
instead of being presented as options that can be turned off.
Not only will that make Rosegarden easier to use, it will make it easier to
test too. When you start allowing n degrees of freedom in all this, it gets
to be a mind twister trying to figure out if the results even match
expectations, and whether something is broken or working.
Toward that end, what I'd like to concentrate on first is setting this change
by interval dialog aside, and using the engine behind the "convert notation
for" function to direct all of this. Instead of saying you want to transpose
by a perfect ninth, you say you want to transpose between a flute and a Bb
trumpet.
Real music guys know all the interval stuff, which is why one of them wrote
that transpose by interval dialog, but I always use the "convert notation for"
thing in my own life. It's easy, and it works well. It's a good place to
start.
> I'm operating at the misty outer limits of my understanding of musical
> notation here, but I *think* I've done the right thing!
My understanding of how to transpose by interval is too bad to really
appreciate whether I accomplished what I meant to or not, but at least it all
came out sounding the same way on the far side. That's the acid test when
you're faffing about with transposition for notation purposes. If the parts no
longer sound in unison, then something got screwed up.
The case of taking a flute part to the tuba is an interesting one.
All the stuff we have up to date would preserve exactly the same sound. I
take a flute part in a high register and "convert notation for" to turn it
into a tuba part, and it comes out way the hell above the staff. When you're
working on copies, it's reasonable to leave the user to just drop the copy a
few octaves, but with this link business I'm thinking we need to either:
a) Try to transpose the part into a suitable register automatically (fine idea
in theory; in practice there would be no recourse if we got off by one octave,
which seems pretty likely to happen in edge cases)
b) Provide a "local transpose" for the linked segment, the way you have local
clefs. This seems like the best approach in some ways, but a complete
nightmare of an interface, and a mine field for confusion.
Then again, there's always:
c) If the user is moving a part that far between instruments, he's going to
have to suck it up and make hard copies of the parts, because we're too dumb
to offer anything more sensible with a reasonable change of getting it right
with sufficient frequency not to be frustrating.
So again, I'm just brain-storming here, but my gut says a combination of a)
and c) sounds about right. Try to do automatic register adjustment so the
tuba part will sound in a suitable octave, and if we bungle it, just leave the
user to make hard copies and fix it manually in those edge cases. The code
for what I'm thinking of is what would be invoked when adding a clef change
and "transpose to suitable octave" or whatever. It works most of the time,
but occasionally misses the target by one octave.
When I think about it all even more deeply, there's only so much we can do
automatically on a good day. What is easy on a flute is not necessarily even
playable on a tuba, even after adjusting it down a few octaves. There will
always be a lot of need for hard copies and manual editing in those cases
where instruments are that far apart.
> As my implementation stands, there's no facility for editing the transpose
> on a linked segment. You can set the transpose on an untransposed segment,
> or remove the transpose on a transposed one. This is because I don't know
> how to handle a composite transpose. i.e. if a transposition is
> represented by m1 semitones and n1 steps, and we apply another transpose
> of m2 semitones and n2 steps, is it true that the composite transposition
> is always represented by (m1+m2) semitones and (n1+n2) steps? If so, maybe
> it's not much work to implement an edit function for the transposition on
> a linked segment.
Yeah, that sounds like b) above, and I don't know how to handle it either
without causing my brain to start sizzling inside my skull.
> The code also makes the (possibly false) assumption that if a transposition
> is characterised by m semitones and n steps, then the inverse
> transposition is always characterised by -m semitones and -n steps. Is
> this a safe assumption? It's what I apply to key change events when going
> from a transposed linked segment to the underlying reference segment.
Yes, everything has to balance out evenly so if you +5 here you -5 there. I
worked out code for transposing the key signature somewhere in the whole
process of working on that "convert notation for" stuff, so there's an
established working example in our code somewhere.
The "convert notation for" stuff I keep referring to is actually in two or
three different places. In Track Parameters, you can use the database to pre-
select properties for segments that have not yet been created, and you can
also use it to transform segments that are already sitting there. In the
notation editor, you can "convert notation for" to change what you're sitting
on top of out from under you. It's all the same mechanism at the core, with
the gigantic, massively comprehensive database of instrument properties
provided by E. Magnus Johannson; essentially we have a good chunk of an
encyclopedia of arranging built right into Rosegarden.
OK then, normally I would make a U-turn and go back through my top-of-the-head
ramblings to try to tidy them up a bit, and make them easier to digest. In
this case, however, I just came from working third shift for the first time in
over a decade, and I don't have the capacity to tidy or make sense of anything
right now. Raw ramblings will have to suffice. Everything I've said that may
have sounded like a prescription is very much open to debate though.
Everybody just bear in mind that my brain is truly fried right now.
Oh, and I never mentioned that this is really wicked awesome, Ian. It's got
lots of rough edges, but it fundamentally works, and that's pretty damn cool!
This has to be the most ambitious thing we've attempted in a couple of years
now. There's so much to talk about because this is so huge, and trying to get
the presentation and behavior right are big challenges. (Combine this with
Yves's ability to show repeating segments right there in notation, and the
release that includes all of these features is going to be a new landmark.)
--
D. Michael McIntyre
|
