> On 09/24/2013 10:37 PM, Tom Breton (Tehom) wrote:
>
>> 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.
>
> Hairpins, ottavas, slurs, things like that are indications. They have a
> beginning time, an end time, but no pitch. Tuplets have pitch, and
> they're often grouped together, so I suppose that's why Chris decided to
> hang that functionality off of the beaming logic.
I get that beaming and tupleting often go together, but it brings in so
many edge and corner cases. I was just looking at BeamCommand and
BreakCommand, which bring in yet more issues.
In many ways our work would probably be simpler if beaming and tupleting
were treated separately. But then display would be trickier, since
NotationGroup wants to handle both types of grouping and tuplet groups use
the beam line when it's available.
So how to separate concerns? We really have three concerns:
* Display-wise beaming, just what BEAMED_GROUP_ID indicates now, what
NotationGroup understands as beaming.
* Groups of notes that want real, honest beams, or that don't.
* An individual note's or rest's notation-wise duration, including an
idea of M-in-time-of-N. This is just one note's time, ignoring other
notes. Basically what {NOTE_TYPE, BEAMED_GROUP_UNTUPLED_COUNT,
BEAMED_GROUP_TUPLED_COUNT, BEAMED_GROUP_TUPLET_BASE} indicate now.
We could separate the concerns as follows:
* Something (NotationQuantizer or SegmentNotationHelper) has the
responsibility to create and maintain coherent display-wise groupings.
It must maintain tupleted notes in properly time-aligned groups, and is
allowed to split and tupletize notes and rests to do so. It is the only
thing that may set BEAMED_GROUP_ID. It is allowed to ignore or punt
impossible requests for real beaming, eg requests to beam tuplets of
incompatible ratios together.
* NotationGroup and ?? that feeds it are allowed to read all those things
but not allowed to change them. It is allowed to give priority to
BEAMED_GROUP_ID rather than do tricky things. Eg if given a quintuplet
that wants to physically beam notes 1&2 and 4&5, it could display it as
one beamed group of five.
* BeamCommand, BreakCommand, etc can request real beaming to their
heart's content, regardless what tupleting is in place.
* Inserters, squashing, duration-changes, etc can change the
notation-wise duration freely, regardless of beaming or lack of it.
What do you think? Does that seem like a reasonable separation of concerns?
>> 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.
>
> [NotationQuantizer] is getting the tupled/untupled just fine in THIS
case, which is
> probably one of the more optimistic ones. I'm pretty sure this file I
> snagged was machine-generated. So what's missing is the grouping.
Hmm. When I wrote that, I had just tried the quantizer on some hand-made
triplets, and it turned them into a chaos of dotted notes. There's
something that it's not doing right.
It's not simply ignoring grouping, though. NotationQuantizer erases and
resets BEAMED_GROUP_ID and the tuplet properties.
>> 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.
>
> If it makes you feel any better--and it does me--I ran into a situation
> like that with MuseScore. I really want to love it so much I ditch
> Rosegarden and switch teams, but every time I get into some tricky
> situation I realize that doing notation with computer is just a bitch no
> matter what you do, and no matter who you are.
FWIW, I found exactly where that happens, in
NoteRestInserter::doAddCommand. In order to fix other bugs, we added code
that first places a double-duration rest. I'm not at all sure that fix
was worth it, for many reasons.
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
