> > On Fri, Sep 27, 2013, at 02:50 AM, Tom Breton (Tehom) wrote: >> 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) > > There shouldn't be any code that wants N events for an N-tuplet -- > things like crotchet-quaver triplets would have been a normal use case > from the start. (Though who knows what cruft has grown over the years.)
When you add another tripletted note to that crotchet-quaver triplet, RG believes that the new note is the third note in the triplet. Gives it the same group id, so display groups it all as one triplet. > Might be worth going over some of the early docs for this stuff, which > can still be found in Subversion at e.g. > https://svn.code.sf.net/p/rosegarden/code/branches/obsolete/docs/data_struct/tuplets.txt Thanks for that link! It filled in some of the missing pieces. > * The initial idea was that you should be able to play the notes and > get the right results even if you didn't know about tuplets, so the > base timings stored were for the performed rather than notated tuplets Right, that makes complete sense. Separating performance and notation times was a great idea. I mentally group tupleting information with the notation time information. > A problem of course with this, particularly the final point, is that > there's no way to mark the start and end of a group in a way that > remains consistent "by itself" when events inside the group are added or > edited. Right. That was the indication issue. Michael's evil example showed me that it's tricky to delineate them neatly. It could be done, splitting innocent untupleted notes to fully populate the tuplets. If there are only rests and one type of tuplet, the splitting points are fairly natural. It'd be considerably nastier if other counterpointing tuplets were present. What if we have 3-against-5? Split into 15-lets? Another nasty case is 4-in-3 groupings (or 8-in-7, 7-in-5, almost anything where the denominator isn't a power of 2). 4-in-3 quarter-notes in 4/4 could start on beat 1 ending on beat 4, or start on beat 2 ending on the bar line. We don't (can't, shouldn't) require the user to say where a tupleted group starts and ends. In a similar vein, it's possible for tuplets to just start at a bad place. Make a tuplet, cut it, put an eighth-note rest at the start of the bar, and paste the tuplet after it. Where should the tupleted group start, displaywise? There I don't think we have much choice but to display a bizarrely-timed tupleted group. Some of the evil examples are just the user's own fault and if they look bizarre in the display, so be it. All that leads us in the direction of complete ~laissez faire~, but ISTM that's not ideal. Reasonable tupleted groups ought to start neatly on beats no matter how they came to exist. Tuplets ought to be enterable normally regardless what else is in the Segment. So ISTM we should do more work to figure out healthy tuplets and less micro-management of them in the various other code. I've sketched some code but I'm not satisfied with it yet. 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
