> On 09/25/2013 06:00 PM, Tom Breton (Tehom) wrote:
>
>> What do you think? Does that seem like a reasonable separation of
>> concerns?
>
> Yes. I've had time to ponder on it, and you've just about got it laid
> out.
>
> The big sea change we need is the ability for the individual, isolated
> note to be a triplet note and carry a 3 on itself independently of its
> surroundings. (How that scales to a note from a 22:2 tuplet is a
> question I'm not sure I can entirely get my head around. Would it have
> to show 22:2? I suppose so.)
It can actually display tuplet marks on isolated notes - our display code
doesn't try to count how many notes in a tuplet, so feeding it a "tuplet"
of one event works. It's the rest of the code that believes that
N-tuplets mean N events (or N events with distinct starting times)
> Grouping them together ought to just be done automatically by the layout
> engine, with nothing to export. We could indeed do new tuplet brackets
> as indications, like you thought they were to start with, but these
> indications wouldn't be of much use in LilyPond export.
I've kinda abandoned the idea that they should be like indications because
the display code is locked onto the idea that they are just funky beaming.
> LilyPond does a
> fine job of providing such brackets automatically.
Yes, I was looking at how LilyPond handled tupleting. It can handle some
pretty crazy bracketing.
> If they could be 100%
> generated visible entities with no representation as any kind of events,
> it would greatly simplify keeping them in sync as edits are made.
> Recalculate. No crufty vestiges left over where a tuplet spanner
> indication is lingering in a now inappropriate area.
There is a certain wisdom in that, especially since part of the complexity
is driven by NotationGroup's need to be spoon-fed about beaming. But on
the balance, I have reservations.
* Rests are a big problem. They can't be display-only. So if we want
rests to accomodate tupleting, as they do in eighth-note+quarter-rest
triplets, we still have to understand and manage tuplets well before we
display them.
* If we can get it to work right, then I'd like to be able to feed the
same organized information to the various other outputs (Lilypond, etc),
rather than making them re-code all that functionality. Worst case, the
various outputters would have all different bugs and so the user can have
a document that looks perfect in notation and inexplicably won't work in
the other outputs.
> Meh, I'm late to work again, so I have to leave off. You're left with
> another unedited brainstorm.
Thanks for the evil example. It helped clarify what this stuff needs to do.
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
