On Tuesday 05 August 2008, D. Michael McIntyre wrote:
> positive this is fixed now. It will take some time to build and test the
> result though.
It was a simple fix that just involved moving some things outside of an if
statement. I wish all bugs were that easy to remedy!
(He says, and then goes to test again, and notices that the fix he just
committed was completely broken. Sigh.)
OK, there we go. Now let's see if that fixed your file too. It might have.
I'm opening the file you sent. All segments on track 1 are highlighted, and I
open in event list editor, which opens a separate event list for every
segment. There are five event lists open on five segments here. The
Composition -> Document Properties page, Segment Summary tab shows two
segments that each contain only two events, and their respective event list
views reveal that each contains only a clef and a key change.
Interesting.
I'm using 1.7.2-svn, and anything from 1.7.0 on should expand the track in a
way that grants access to all overlapping segments, by presenting each one of
them in its own "subtrack" or "lane" as we variously called the concept
during development.
This track is only one segment high. I assume this means that the two
miniature segments that contain only a clef and key change are too short for
the display code to bother doing anything with them. So-called "zero-length"
segments.
The underlying bug or stupid user trick here is how you wound up with these
zero-length segments in the first place. Could be a bug, could be user
error, or some combination. I don't think we'll ever know that answer just
from doing an analysis of the file at this stage of its life. We'll have to
try to catch the action that brings these useless extra segments to life if
we're to have any hope of figuring out whether it's a bug or a feature or
what, etc. (I figure it's some combination of you doing something we didn't
expect, and our doing something unreasonable as a result.)
Anyway, what can we do from here? I can't think of a way to delete what I
cannot get my hands on from the segment canvas.
I suppose the only way to get these segments selected at all is to do what I
just did. Highlight the track, which selects every segment on it, and then
open all of them in separate event list views. This gives me access to the
inside, where these extra, unwanted clefs and key signatures are hiding,
where I can delete them, leaving two completely empty segments behind.
Ugly, admittedly. (The other way would be to go hack the raw XML in the data
file itself, and cut out the bits defining these segments entirely, but I was
trying to find a workaround a normal person could do through the GUI, and it
seems I have found one; though it is admittedly a tedious and potentially
horrible workaround if you have gobs of segments in gobs of event list
windows to weed through.)
OK now we go back and move that key change that should have happened at 24.
Since I already have an event list open, I'll use the filter at the left and
un-check everything except Other[1] so I get the key change by itself
conveniently. Double click to edit its time, and put it at 24:1:0. Now I
apparently still have to use the notation view to go make it invisible. Oh
well.
(Curiously, after I did that, the track just expanded to make room for the
invisible zero-length segments I still can't do anything with from here.
Nice. There's definitely something fishy here, but I'm not going to try to
root it out, because at least we can work around this fishiness and get your
work done today, instead of whenever somebody has time to root around
tracking down a ghost and busting it.)
So to summarize:
1) We deleted the events from the invisible segments that shouldn't have been
there in the first place
2) We ensured every segment had a key change to D major
3) We made all except the first key change invisible
4) We just scratched our head upon realizing that the segment starting at 24
doesn't have a clef. That shouldn't be possible.[2] So we add a treble clef
at 24 and make it invisible.
5) Now we export the whole shebang with today's 1.7.2-svn revision 8989 or
later.
6) We look and realize we forgot to re-fix the C naturals. Oops. And it
looks like some errant F naturals too. Oops again.
The result:
Well, this is copyrighted, so I'll go private for the rest. But it seems to
be fixed this time.
[1] Note to self: this filter could benefit from having notation-related
events spelled out. It suffers from the same kind of MIDI sequencer thinking
that my own probably deprecated selection event filter does. None of that
really considered Rosegarden's true nature in its design, because of where we
were all coming from. Namely, a world in which nothing like Rosegarden
existed yet.
[2] Bug? Does the split code not create a duplicate clef in the cutoff piece?
It really should. Especially if the original clef differed from the default
treble.
--
D. Michael McIntyre
|
