> (On the broader issue, I can't find anything in Rosegarden that makes me
think we handle importing triplets from MIDI correctly. I'm dealing
with triplets that aren't triplets, with all kinds of superfluous and
incorrect properties. I despair of fixing it short of a marathon
session hand hacking the XML. Blah.)
> [And from your wiki edit]
> I tried to turn all the triplet 8th notes into
> quarter notes with Ctrl+4. They all became dotted quarter notes! (It's
worth
> noting that no 3 show up in the interface anywhere, but the events have
duration
> 320, so they are triplet 8th notes. This file seems to have confused
Rosegarden
> mightily. It's basically a piece in 9/8 that everybody writes in 3/4
with a solid
> wall of triplets for some reason. I thought to just put the piece in
9/8, but that
> didn't work out either.
I have bumped into that too. It's basically due to the way we represent
triplets and other tuplets.
We have this hybrid representation that we don't really keep in sync. A
triplet is both some properties in the note (tupletbase, tupletcount) and
an indication-type event, which shows the triplet span, the thing that
says [3].
That would be perfect if you never edited a note after it was inserted.
We do some stuff to extend the triplet indication if you insert a note
after it, but IIUC that's about all we do to keep it in sync.
So your quarter notes still "know" they are triplets, and represent
themselves accordingly. MIDI import probably never sets those properties.
ISTM all of the event time-changing operations should erase the tupletbase
and tupletcount properties (or reset them, for triplet/tuplet). MIDI
import and note-/rest-merging ought to be smarter about those properties
too.
Some beaming problems come from that hybrid representation. If you
re-beam anything about tuplet group, you destroy the indication, so the
note will still think it's a tuplet but there won't be an indication. We
do something to shorten them when contrasting notes are added, but it ends
up fairly messy. I have some true abominations in my files, eg whole note
rests that think they are septuplets.
Towards fixing it? ISTM the cleanest way is to completely redo tuplet
indications whenever they might be munged. Make the note properties the
Real Thing and make the indications follow them.
This could be a dirty region in a Segment. We'd dirty that when we place a
note, and at some point before we redisplay we would erase all the tuplet
indications in the dirty region and put appropriate indications in place
according to note properties. For tough cases (2 against 3 on the same
staff) we'd need to make sure every vertically-aligned note had the same
tupletbase and tupletcount. Shifting a segment by a fraction of a bar
should dirty the whole Segment.
Then we have to deal with tuplet indications that are halfway in a dirty
region. We could either:
* make dirty regions begin and end on bar lines. It doesn't handle
"Everything's Coming Up Roses" and the occasional Chopinesque run of
23-in-2-measures.
* expand the dirty region to cover existing tuplet indications.
We also have problems with editing in the presence of other notes.
Something about tuplets erases the following note. I once thought it was
because they don't have neat end-times divisible by 480, but it sometimes
happens even for triplets.
Tom Breton (Tehom)
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
