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". 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 always tries the natural metrical decomposition first. Ie, mostly > binary splits. a la TimeSignature::getDivisions(), or something else? 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. (The old autobeam code dates from me as an undergrad pissing about with the problem until it appeared to work mostly, without ever thinking about what the problem truly consisted of. 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.) > On a similar note, Rewriter also decounterpoints everything. I have two > questions about that: > > * Are there any use-cases where it's important to *not* split-and-tie > across barlines? Having to do that would really make this difficult, and > it seems just wrong anyways. > > * Are there any use-cases where it's important not to decounterpoint? > That I can handle by just not rewriting except to split at barlines, and > I take the flag to do so, I just don't act on it because I'm not sure > it's the right thing to do. 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 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. Chris ------------------------------------------------------------------------------ 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
