> I guess it's more like a specialized beam group, even for notes that
> can't be beamed. There's a beam group, and there's a different sort of
> beam group just for tuplets that results in the 3 (etc.) being drawn.
Yes. For some reason I thought that was an indication, but a quick look
at BaseProperties shows me that you are right, it's a specialized beam
group.
>> So your quarter notes still "know" they are triplets, and represent
>> themselves accordingly. MIDI import probably never sets those
>> properties.
>
> It apparently does. All these notes had the tupled/untupled properties
> set, and were mostly tuplets, which is why I got all the weird results
> trying to change the durations.
Hmm. That stuff isn't set in MidiFile or Segment::insert, so I wonder
what's going on. Probably a quantizer is working on it after that. Yes,
createDocumentFromMIDIFile uses EventQuantizeCommand.
So ISTM whatever MIDI import weirdness is happening is due to a quantizer.
Bad news: Looks to me like NotationQuantizer is already doing it kinda the
way I described. It erases all those properties and recalculates tuplet
groups. Obviously it's not working so well. There are some comments
suggesting that the tuplet code there is not entirely right.
> There's the whole
> problem of many years of legacy cruft floating around out there to
> consider, which makes it harder to get really inventive.
Yes. I just searched thru the source for BEAMED_GROUP_TUPLET* and what I
found is frightening. NotationQuantizer and SegmentNotationHelper each
try to do everything, and Segment, NoteRestInserter, NoteInsertionCommand,
and TupletCommand all fiddle with those properties. ISTM there should be
only one module that handles the tricky stuff (group ID, etc), and
everything else should call it.
> I'm thinking this is probably one of those things where it turns out
> trying to do it automatically is too much wishful thinking, because of
> all the edge cases where it doesn't work out right.
Yes, it could be. There are a ton of edge cases. OTOH, it might be the
trick that allows us to separate concerns.
Anyways, that might be moot. If the quantizer is buggy (and it clearly
is) and we fix it, it can fix groupings - which it *thinks* it's doing
now. Then there's much less need to do it automatically.
>> 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.
>
> It depends how you create the tuplets, I think. It's cleanest to enter
> new ones putting the editor into triplet insert mode before you put any
> notes there. (I'm not sure off the top of my head if there's a generic
> tuplet insert mode. Probably is.) When you do this, the notes are born
> correctly.
Yes, I find that's cleanest way to do it. With larger tuplet groups, if a
note follows it I have to find an empty bar, insert everything there, then
copy it to where it is supposed to be.
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
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
