>
> On Fri, Nov 8, 2013, at 05:32 PM, Tom Breton (Tehom) wrote:
>> Oh, it doesn't just go by timing, it also goes by existing beamings and
>> tuplings.
>
> Oh -- very good to hear the detail you've thought about this in already.
>
>> * It will force a new group ID for tupleted groups that don't already
>> start with a fresh group. That's because it fears using a non-tupleted
>> beaming for a tupleted group. The Ravel example shows that this is
>> perhaps too strict.
>
> Can you explain in more detail what you mean by this? Particularly "that
> don't already start with a fresh group".
OK. I collect the old groupings, and the beaming code consults them.
Beaming is done on subtrees of a bar (MeterTreeNodes). For the most part,
they re-use the old beamings. But when a MeterTreeNode sees the start of
a tupleted group, it (anthromorphically) says:
"Aha, a tupleted group. It should all be one group, so it's going to need
a unique group ID. (looks) Do the old beamings already start a beamed
group right here? No, they don't. The current old beamed group starts a
while ago. There's no way to keep the old grouping and still do this
tupleted group correctly, and I probably already used that ID for some
notes that aren't part of this group. I'll get a brand new unused ID from
Segment and use that from my entire subtree."
Or alternatively it thinks: "Yes, the old beamings already start a beamed
group here. Since it starts right here, it's probably the ID that this
tupleted group had before. I'll re-use that ID."
Now that I think of it, I need to treat the ends of tupleted groups more
carefully.
> I'm particularly concerned in the Ravel example by the fact that the
> *other* 12-tuplets in the bar were also split into triplets, not only
> the one in which the immediate edit happened.
It rewrites complete bars.
I originally wrote something that treated single notes - really just
extended makeThisNoteViable to handle tuplings - but it ran into problems.
Somewhere in my notes (can't find it right now) there are problems it had
because it wasn't really treating chords but just kinda pretending to
while really splitting one note. After wrestling with that approach, I
was convinced it was important to treat all vertically aligned notes at
once, which meant getting a well-defined region of them, which was most
easily done by treating whole bars.
I could rewrite single beats if they are bounded by chords, or even binary
splits of beats (1/8, 1/16, etc). Any fancier and it probably constitutes
a redesign.
That might actually work. What I do now is I take dirty regions and
extend them to a well-behaved time - right now that means a barline. I
could delay expanding dirty regions and rewriting until I have figured out
the MeterTreeNode tree.
>> * It always tries the natural metrical decomposition first. Ie, mostly
>> binary splits.
>
> a la TimeSignature::getDivisions(), or something else?
Basically getDivisions. The only thing is, for 4/4 it divides 2x2. It
doesn't do anything special for (say) 4/2 or 8/4, but it wouldn't be hard
to.
I saw that there was some back-and-forth about whether getDivisions should
split 4/4 as 2x2 or into beats. I didn't change getDivisions but I added
a new field in TimeSignature (m_beatDepth or something) that makes it easy
for getDivisions to have it both ways by a flag or something.
> A tree
> decomposition using this hierarchy is the way I always meant to rewrite
> autobeam on insert, and I take it your code handles autobeam instead in
> this branch.
Yes, exactly.
> While it'd be great to lose the old code because it was basically crap,
> it'd be a bit sad to lose it so near to its 20th birthday.)
By the time this is ready, the old code may be old enough to vote.
> I think these are related to the Ravel question actually. The problem
> there is that you're doing something that *is* correct, in isolation,
> except that the user has already given some other preference. People
> interested in notation will get awfully troublesome if they decide to
> express something in an unlikely way and then you go and change it.
>
> It may be that the right thing is to tie all of this to autobeaming or
> some other option for "rapid, generally correct" entry, which can be
> switched off, and let expert/opinionated users and those trying to match
> an existing score do their own thing separately.
That sounds sensible. ISTM the split-and-tie flag is the right one for that.
> That said -- to answer the actual questions -- I think since we got the
> ability to overlay segments, there is probably no case in which the old
> half-arsed counterpoint is a good idea when entering new music. It's
> just the opinionated-user case that's the problem.
Thanks.
Tom Breton (Tehom)
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
