On 09/24/2013 12:32 PM, Tom Breton (Tehom) wrote: > I have bumped into that too. It's basically due to the way we represent > triplets and other tuplets.
I kind of slowly halfway started to figure that out. > We have this hybrid representation that we don't really keep in sync. A > triplet is both some properties in the note (tupletbase, tupletcount) and > an indication-type event, which shows the triplet span, the thing that > says [3]. I guess it's more like a specialized beam group, even for notes that can't be beamed. There's a beam group, and there's a different sort of beam group just for tuplets that results in the 3 (etc.) being drawn. What you end up with all the time is notes that have tupletbase/tupletcount but they aren't part of one of these groups. This is apparently a common enough problem that an old way of dealing with it exists, which is to use the Make Tuplet dialog and [x] timing is already correct. That fixes up the events. The problem is, it takes a segment and an event start time, and it computes time plus duration_of_thing_I'm_making and stops there. If you disable the stop, it will run to the end of the segment making tuplets out of everything in sight. The other problem is when everything else is mostly correct already (eg. these very precise triplets that have the properties but aren't part of a tuplet group) the dialog is just nuts to use that many times in a row. I actually dealt with this by hacking the source temporarily to make that checkbox checked by default, and even then I had to go wiggle various controls 102 times (or will have once I finish the B part). Barf. > So your quarter notes still "know" they are triplets, and represent > themselves accordingly. MIDI import probably never sets those properties. It apparently does. All these notes had the tupled/untupled properties set, and were mostly tuplets, which is why I got all the weird results trying to change the durations. Using the Untuple function clears all that crap out, but a typical user would never know they're even tupled, unless we want to extend the definition of "typical" to mean a user familiar with the extremely dangerous advanced event editor, also known as the make Rosegarden crash dialog, or one familiar with reading XML in the .rg file. Yeesh. > ISTM all of the event time-changing operations should erase the tupletbase > and tupletcount properties (or reset them, for triplet/tuplet). MIDI > import and note-/rest-merging ought to be smarter about those properties > too. The Ctrl+2 (for example) Make Half Notes or whatever and its various kin should probably clear out the tuplet nonsense, or perhaps just ask the user. "Hey mate, I found some tuplet nonsense. Were you wanting to keep that, or what?" > Some beaming problems come from that hybrid representation. If you > re-beam anything about tuplet group, you destroy the indication, so the > note will still think it's a tuplet but there won't be an indication. Right. Just changing the beaming arrangement around fundamentally alters this, which is very bad, since LilyPond export won't know what to do with these notes unless the tuplet groups are set properly. They export as non-tupled versions of themselves, and everything goes all to hell. I suppose if we can't make the data stream less full of garbage, the least we could do is make the LilyPond export smarter about looking for the properties, and using them to determine whether a note is a tuplet or not. > Towards fixing it? ISTM the cleanest way is to completely redo tuplet > indications whenever they might be munged. Make the note properties the > Real Thing and make the indications follow them. Some kind of automatically applied go back and fix up the events that have tupled/untupled but aren't in a tuplet group seems like the path of least resistance, if not the cleanest solution. There's the whole problem of many years of legacy cruft floating around out there to consider, which makes it harder to get really inventive. > This could be a dirty region in a Segment. We'd dirty that when we place a > note, and at some point before we redisplay we would erase all the tuplet > indications in the dirty region and put appropriate indications in place > according to note properties. For tough cases (2 against 3 on the same > staff) we'd need to make sure every vertically-aligned note had the same > tupletbase and tupletcount. Shifting a segment by a fraction of a bar > should dirty the whole Segment. I'm thinking this is probably one of those things where it turns out trying to do it automatically is too much wishful thinking, because of all the edge cases where it doesn't work out right. An equivalent of Ctrl+N to go back and normalize the mutilated rests in a slightly quirky segment might be appropriate here. Some function users can run manually, "Recognize and group tuplets" or something. Maybe run this automatically in certain contexts too. I don't know, I might not be thinking big enough. You're the mad genius, and I tend to be more conservative and much less bold. > Then we have to deal with tuplet indications that are halfway in a dirty > region. We could either: > > * make dirty regions begin and end on bar lines. It doesn't handle > "Everything's Coming Up Roses" and the occasional Chopinesque run of > 23-in-2-measures. > > * expand the dirty region to cover existing tuplet indications. > > > We also have problems with editing in the presence of other notes. > Something about tuplets erases the following note. I once thought it was > because they don't have neat end-times divisible by 480, but it sometimes > happens even for triplets. It depends how you create the tuplets, I think. It's cleanest to enter new ones putting the editor into triplet insert mode before you put any notes there. (I'm not sure off the top of my head if there's a generic tuplet insert mode. Probably is.) When you do this, the notes are born correctly. The alternative is to take existing normal full length notes and make a tuplet out of them, which pulls them back and leaves odd holes in time. (This does not work if the "normal" notes are actually munged tuplets with missing groups.) I've found in practice the latter method never produces good results. Nothing will ever fall neatly around tuplets manufactured in this fashion, and you're better off erasing everything and drawing it from scratch using the tuplet insert mode. Same thing used to be true of grace notes. You made them by drawing normal notes, and then grace-ifying them, which just never fell well with anything, and resulted in notation that was constantly messed up in subtle ways. The original grace note implementation was such crap it was almost impossible to use. The new implementation, off the top of my head, consists of making the things by inserting them that way from the beginning. There's a lesson there, but grace notes are rare, and tuplets common as mud. We need something that doesn't break a million existing compositions, except to the extent it might show up problems like your septupletified whole rests and other garbage that was always there but never visible before. OK, just writing off the cuff here, not thinking deeply. There could be big holes in my thinking. -- D. Michael McIntyre ------------------------------------------------------------------------------ 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
