On 09/24/2013 10:37 PM, Tom Breton (Tehom) wrote: > Yes. For some reason I thought that was an indication, but a quick look > at BaseProperties shows me that you are right, it's a specialized beam > group.
Hairpins, ottavas, slurs, things like that are indications. They have a beginning time, an end time, but no pitch. Tuplets have pitch, and they're often grouped together, so I suppose that's why Chris decided to hang that functionality off of the beaming logic. > Hmm. That stuff isn't set in MidiFile or Segment::insert, so I wonder > what's going on. Probably a quantizer is working on it after that. Yes, > createDocumentFromMIDIFile uses EventQuantizeCommand. Now I remember. > Bad news: Looks to me like NotationQuantizer is already doing it kinda the > way I described. It erases all those properties and recalculates tuplet > groups. Obviously it's not working so well. There are some comments > suggesting that the tuplet code there is not entirely right. It's getting the tupled/untupled just fine in THIS case, which is probably one of the more optimistic ones. I'm pretty sure this file I snagged was machine-generated. So what's missing is the grouping. The best case is Chris almost had it figured out, and we just have to bridge a little tiny gap. The worst case is we have to tear down the walls and rethink everything. > Yes. I just searched thru the source for BEAMED_GROUP_TUPLET* and what I > found is frightening. NotationQuantizer and SegmentNotationHelper each > try to do everything, and Segment, NoteRestInserter, NoteInsertionCommand, > and TupletCommand all fiddle with those properties. ISTM there should be > only one module that handles the tricky stuff (group ID, etc), and > everything else should call it. I wholeheartedly agree that's how it should be. Whether it's worth the effort to refactor all of it is another matter, I suppose. > Anyways, that might be moot. If the quantizer is buggy (and it clearly > is) and we fix it, it can fix groupings - which it *thinks* it's doing > now. Then there's much less need to do it automatically. Fix the quantizer, and we solve a lot of problems. The first thing I did trying to resolve this mess automatically was try the quantizer. The notes were obviously lined up with perfect mathematical precision, and it should have been an easy job to sort it out. This rabbit hole may or may not get tied up with automatic beaming. If it does, that's something that has been on my list of most hated bugs for nigh on 10 years now. Automatic beaming has a lot of bugs, and frequently does an awful job. I scarcely know where to begin on that one though. I've looked into it once or twice, and always slammed the lid shut and walked away. I bet they're closely related, but that's just a hunch. > Yes, I find that's cleanest way to do it. With larger tuplet groups, if a > note follows it I have to find an empty bar, insert everything there, then > copy it to where it is supposed to be. If it makes you feel any better--and it does me--I ran into a situation like that with MuseScore. I really want to love it so much I ditch Rosegarden and switch teams, but every time I get into some tricky situation I realize that doing notation with computer is just a bitch no matter what you do, and no matter who you are. Rosegarden is a big ball of quirks, hacks, and workarounds at this point, but it still has the home team advantage. Incidentally, now that I've spent some time with the development tree of MuseScore, I think it's appropriate to start taking Rosegarden in a direction where we work with LilyPond more closely instead of fighting against LilyPond. We have been heading down that road for a long time, but instead of implementing native versions of a bunch of things, I think we should just add more non-native things, and make it all easier to work with. I'm starting to get funky ideas, like a dialog where you can zoom in on an individual note, and it shows up like a character in a video game with little slots where you can put things from a palette. There are six slots where you can put a fingering, you can toggle every kind of mark, flip the stem, and whatever else comes to mind; all closely coupled to LilyPond in the end, with our on-screen display just essentially a crude rough draft that doesn't even attempt to show a lot of these things. We might have been better off on micro-positioning of various notation elements coupling it more closely to LilyPond, for example. What we've got in practice now attempts to translate across two totally different and unrelated scales, and it's quirky. MuseScore has taught me that you can have 500,001 excellent features that allow massive precision in positioning and tweaking everything, and you can have all that and your printed notation still looks crappy compared to LilyPond. -- 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 Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
