From: Tom B. (Tehom) <te...@pa...> - 2013-11-14 01:56:14
|
OK, I have rewritten the tuplet rewrite so it handles the Ravel example, keeping the 6-lets. Also, as Chris wanted, I have made it handle dirty subunits of a bar instead of always doing a while bar. I was only going to do this if needed for performance, but since its absence was felt, I went ahead and did it. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2013-12-03 23:22:59
|
As I mentioned, I have been working on simplifying the new code. I found a few nice ways to simplify it. Also I moved the new code into its own directory except some small classes that seemed to invite general use. It's also more bulletproof, I hope. * Handles slivers, ie notes that go just barely across a barline or other metric line. * Handles truncated bars, ie where some time-signature has started a new bar prematurely. * Almost handles swing, except I'm not sure where to get swing from. When I give it phony swing parameters, it seems to work OK. I thought I could just read swing from BasicQuantizer, but that doesn't seem to stick. Ie, if I use the grid quantizer, set up some swing, then read from the segment's quantizer, swing is still zero. Beyond that, I'm not sure per-segment is the right place to store swing anyways. ISTM swing is more of a vertical thing across segments. Like, you're more likely to have different swing at different times in the same segment than to have different swing at the same time in different segments. I suspect TimeSignature is the right object to hold it. Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2013-12-04 03:21:35
|
On 12/03/2013 06:22 PM, Tom Breton (Tehom) wrote: > It's also more bulletproof, I hope. > * Handles slivers, ie notes that go just barely across a barline or > other metric line. > * Handles truncated bars, ie where some time-signature has started a > new bar prematurely. > * Almost handles swing, except I'm not sure where to get swing from. > When I give it phony swing parameters, it seems to work OK. Sounds interesting. These all sound like good test cases. I did slice up some sheet music and did some initial testing, but I've been distracted by power management problems in the latest Ubuntu 13.10. (Monitor isn't shutting off in specific subtle situations.) Anyway, hoping to get back to this. My initial impressions are that it is better than before. But I have no idea what I'm doing. I was also slowed down by the mouse not working very well for placing notes. Is this a known issue? Or am I doing this wrong? Ted. |
From: D. M. M. <ros...@gm...> - 2013-12-04 12:53:20
|
On 12/03/2013 10:21 PM, Ted Felix wrote: > slice up some sheet music and did some initial testing, but I've been > distracted by power management problems in the latest Ubuntu 13.10. > (Monitor isn't shutting off in specific subtle situations.) No it isn't, and IT'S PISSING ME OFF! You're not alone, Mr. Felix. I rue the day I did that damn upgrade on my laptop. After adding some new acpi crap to the boot loader I made some headway. > I was also slowed down by the mouse not working very well for placing > notes. Is this a known issue? Or am I doing this wrong? I did a quick bit of music work the other day using main line Rosegarden, and I noticed it was laggy. Especially near the end of a measure. Like click... ... ...... ? ....... ???? boink. There it is. Finally. What the hell was that all about? I have nooooo idea what this might be or how far back it might go or who to blame it on. I have various hypotheses, but have done nothing to test them yet. Oh, and it looks like the 12.12 release is scrapped unless there's something really compelling I should get out there. Damn it's busy at work this year! -- D. Michael McIntyre |
From: Ted F. <te...@te...> - 2013-12-04 23:57:57
|
On 12/04/2013 07:53 AM, D. Michael McIntyre wrote: > On 12/03/2013 10:21 PM, Ted Felix wrote: >> (Monitor isn't shutting off in specific subtle situations.) > No it isn't, and IT'S PISSING ME OFF! You too? I'm digging through gnome-screensaver right now (C and GLib and D-Bus, oh my!), but I'm pretty sure my problem is really somewhere in Xorg, so it might be affecting everyone. It appears to be X turning on the monitor due to subtle events like key releases or very slight mouse movements. It seems more touchy than it used to be. Anyway, hopefully I or somebody else finds it. > I did a quick bit of music work the other day using main line > Rosegarden, and I noticed it was laggy. Especially near the end of a > measure. Interesting. I didn't see that. Maybe I should collect all the observations, then have a closer look. It appears there might be several issues that need some attention. A code review might uncover them pretty quickly. > Oh, and it looks like the 12.12 release is scrapped Sounds like the right thing to do at this point. Ted. |
From: D. M. M. <ros...@gm...> - 2013-12-05 11:09:09
|
> Interesting. I didn't see that. Maybe I should collect all the > observations, then have a closer look. It appears there might be > several issues that need some attention. A code review might uncover > them pretty quickly. I never use the keyboard for anything ever, and I go way back, so I'm a good judge of what's out of whack by how much. Right now all I can tell you is something feels wrong, but I don't know what, or by how much. I need to do some methodical testing and observation to define the problem, then turn you loose figuring out what caused it, and how to make it die. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2013-12-04 17:11:10
|
> I was also slowed down by the mouse not working very well for placing > notes. Is this a known issue? Or am I doing this wrong? Hmm, I wasn't sure what mouse behavior you were talking about, so I tried placing notes with mouse. Is it something like this?: At first, clicking to place notes works fine. At some point you deselect, and then even though the draw tool is selected, mouse clicks don't do anything. You select the draw tool again, and it works again. No idea how far back that goes, since I generally edit by keyboard. Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2013-12-04 23:35:17
|
On 12/04/2013 12:11 PM, Tom Breton (Tehom) wrote: > Is it something like this?: > > At first, clicking to place notes works fine. At some point you deselect, > and then even though the draw tool is selected, mouse clicks don't do > anything. You select the draw tool again, and it works again. No, that's not it. More of a finickiness when placing notes in specific places. There seems to be a pattern. Notes that are one step off from where you click are impossible to place. And oddly, notes that are one step off from the first note in a tuplet will jump to the beginning of the tuplet when you move the mouse left/right. > No idea how far back that goes, since I generally edit by keyboard. I had a feeling that was my real problem. I'll have to figure out how to do that. Probably should look at the mouse thing too. It's likely a turn-off for new users. Ted. |
From: D. M. M. <ros...@gm...> - 2013-11-14 10:55:42
|
On 11/13/2013 08:56 PM, Tom Breton (Tehom) wrote: > OK, I have rewritten the tuplet rewrite so it handles the Ravel example, > keeping the 6-lets. Still haven't had a moment to check the damn branch out and play with it. I want to. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-14 17:27:49
|
> On 11/13/2013 08:56 PM, Tom Breton (Tehom) wrote: > >> OK, I have rewritten the tuplet rewrite so it handles the Ravel example, >> keeping the 6-lets. > > Still haven't had a moment to check the damn branch out and play with > it. I want to. I understand. Can't set your own schedule; people need their fuel oil. When you are able to, I'd appreciate comments. Tom Breton (Tehom) |
From: D. M. M. <ros...@gm...> - 2013-11-15 12:09:36
|
On 11/14/2013 12:27 PM, Tom Breton (Tehom) wrote: > I understand. Can't set your own schedule; people need their fuel oil. > When you are able to, I'd appreciate comments. Gasoline, mostly. Damn cars. So all I did was swat at it on the run, but I finally got it built. I'll look more deeply another day, I hope. Two quick observations: 1) I could not repeat Chris's crash with a debug build. 2) I continued flailing around deleting things haphazardly. I never got a crash, but if you start deleting a bunch of random notes from the 12-tuplet groups, you eventually wind up with random triplet rests scattered around, and nothing indicating that the remaining notes are 12 or any other kind of tupleted. 3) I thought to mess around and see how you're handling beaming differently. It looks slightly different, but mostly the same. I might be imagining the differences. I might not even be invoking new code. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-15 18:27:58
|
> So all I did was swat at it on the run, but I finally got it built. > I'll look more deeply another day, I hope. Thanks for looking at it, Michael. > 2) I continued flailing around deleting things haphazardly. I never got > a crash, but if you start deleting a bunch of random notes from the > 12-tuplet groups, you eventually wind up with random triplet rests > scattered around, and nothing indicating that the remaining notes are 12 > or any other kind of tupleted. That is something I can reproduce. The answer seems to be that when I added code a few days ago to figure out what parts of the bar need to be changed and what don't, it wasn't smart about groups. It could sometimes grab just a part of a group, and then the rest of the code wrongly thought that it had the entire group because the previous code always grabbed whole bars. Result: Bad groups. Possible approaches: * Roll that part back. Much as I hate to just give up, it's causing Chris's crashes and this weirdness, and it was really just supposed to be an optimization and minimize what got rewritten. * Make this smarter and also fix that crash. Making it smart about groups looks to be about 50% more complex but doable. Fixing that crash looks tricky. I know how it's dividing by zero - the time signature m_denominator - but I can't see how that can get to be zero. * Minimize rewrites in a different way. I can think of one other way, but that looks problematic. I'm choosing option 1, at least until there's a reason to do differently. (So my approach is actually a retreat) > 3) I thought to mess around and see how you're handling beaming > differently. It looks slightly different, but mostly the same. I might > be imagining the differences. I might not even be invoking new code. Well, the differences in beaming aren't too big. If you put short notes (say, 16ths) so they cross beat lines, you'll see it's paying more attention to beats. But mostly the difference is that it's handling tuplets thru the same path as everything else, rather than invoking TupletCommand on what it hopes is a tupleted group. Tom Breton (Tehom) |
From: Chris C. <ca...@al...> - 2013-11-15 21:40:59
|
On Fri, Nov 15, 2013, at 06:27 PM, Tom Breton (Tehom) wrote: > Possible approaches: > > * Roll that part back. Much as I hate to just give up, it's causing > Chris's crashes and this weirdness, and it was really just supposed to be > an optimization and minimize what got rewritten. That is probably the right thing to do, although it'd be nice to figure out why the crash happens as well! My problem with this, first time around, was basically that it was too intrusive when editing existing material. But being both simpler and more intrusive is going to make it more likely to be right and comprehensible when entering new stuff. (What happens when you edit material with wildly differing recorded and notation times? It should presumably use the notation times as source material...) I would like to encourage everyone who can to test this branch -- I think the approach looks like a very sound one, enough to have provoked me from my slumbers, but there are many possible things that can go wrong and my testing time is very limited. It should get merged and released, most probably, but if it *just* gets merged and released without really being exercised, it won't work. Chris |
From: D. M. M. <ros...@gm...> - 2013-11-15 22:05:47
|
On 11/15/2013 04:40 PM, Chris Cannam wrote: > released, most probably, but if it *just* gets merged and released > without really being exercised, it won't work. I agree, though it's a problematic situation in that I just never deal with tuplets much, and any testing I do will be naive. We really need some tuplet nut other than Tom himself to check out the branch and go crazy with it. I know there are some true tuplet nuts out there. Users? Any volunteers to exercise the big tuplet rewrite? -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2013-11-16 10:08:51
|
On Fri, Nov 15, 2013, at 10:05 PM, D. Michael McIntyre wrote: > On 11/15/2013 04:40 PM, Chris Cannam wrote: > > > released, most probably, but if it *just* gets merged and released > > without really being exercised, it won't work. > > I agree, though it's a problematic situation in that I just never deal > with tuplets much, and any testing I do will be naive. We really need > some tuplet nut other than Tom himself to check out the branch and go > crazy with it. > > I know there are some true tuplet nuts out there. Users? Any > volunteers to exercise the big tuplet rewrite? It doesn't just call for the tuplet-crazy though -- Tom's work will affect quite a lot of things, including (hopefully) big improvements to auto-beaming and the like. Really anyone who enters or records-and-edits notation is likely to see some changes. You should definitely mess around with it even if you never venture outside your most familiar workflow. Chris |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-15 23:07:52
|
> > (What happens when you edit material with wildly differing recorded and > notation times? How wildly? I have these cases: * Tiny notes. Notes that are shorter than Note::m_shortestTime. They're handles as indivisible atoms. They've been exercised a little bit, and so far they have behaved themselves. It has been exercised mostly by crazy 23 vs 3 bars and such that I tried that resulted in some tiny notes. * Notes that leave slivers other than at barlines. They're accepted at the nearest starting time. I conceptually split meterPieces in two halves. A normal note that starts in the first half is notated as starting exactly at the beginning, one in the second half is notated as starting exactly at the end. It doesn't get too crazy because if they start in the middle of a meterpiece, it's split further unless/until it's a 1/64 or shorter. * Notes that leave slivers at barlines. That's not implemented yet. The plan is to coerce them the same way as the ones other than at barlines, but by a different mechanism. * Notes that are a lot longer or shorter than their notation times. Like, they think they're half-notes when they are performed as 1/8 notes. They can get split-and-tied differently than their original notation thinks, according to how their performance times fit the bar. Then their performance times are restored. * "Swung" times. That I have done nothing for yet. I am hoping to get swing info from the notation quantizer and calculate meter-split times accordingly. > It should presumably use the notation times as source > material...) We get the bar splitting from notation times, except in the case of tiny notes. My reasoning on tiny notes is that a tiny note has to go into a single meterpiece. Splitting-and-tying something that small doesn't make sense. It further has to go in the meterpiece that best corresponds to its performance time. > I would like to encourage everyone who can to test this branch -- I > think the approach looks like a very sound one, enough to have provoked > me from my slumbers, but there are many possible things that can go > wrong and my testing time is very limited. It should get merged and > released, most probably, but if it *just* gets merged and released > without really being exercised, it won't work. I completely agree. Tom Breton (Tehom) |
From: Chris C. <ca...@al...> - 2013-11-14 15:06:27
|
On Thu, Nov 14, 2013, at 01:56 AM, Tom Breton (Tehom) wrote: > OK, I have rewritten the tuplet rewrite so it handles the Ravel example, > keeping the 6-lets. > > Also, as Chris wanted, I have made it handle dirty subunits of a bar > instead of always doing a while bar. I was only going to do this if > needed for performance, but since its absence was felt, I went ahead and > did it. Hm, now if I delete one of the 12-tuplets (or try to insert a shorter note over the top) it crashes with an FPE. I don't have full debug (can get it if you like) but it's roughly #0 0x0000000000539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () #1 0x000000000053be40 in Rosegarden::TimeSignature::getNumDivisions(int) const () #2 0x0000000000594578 in Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) () #3 0x0000000000594b93 in Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment&) const () #4 0x000000000059b890 in Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) () #5 0x000000000059b910 in Rosegarden::EraseCommand::modifySegment() () #6 0x000000000045b190 in Rosegarden::BasicCommand::execute() () #7 0x0000000000471e5a in Rosegarden::CommandHistory::addCommand(Rosegarden::Command*, bool, bool) () Chris |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-14 23:18:26
|
> > Hm, now if I delete one of the 12-tuplets (or try to insert a shorter > note over the top) it crashes with an FPE. That's odd. I can't reproduce it. Deleted 12-lets, deleted 12-leted groups, inserted 12-lets, deleted 32nds, nothing crashed. Can you give me a more detailed recipe for reproducing this crash, Chris, please? Tom Breton (Tehom) |
From: Chris C. <ca...@al...> - 2013-11-15 09:50:44
|
On Thu, Nov 14, 2013, at 11:18 PM, Tom Breton (Tehom) wrote: > That's odd. I can't reproduce it. Deleted 12-lets, deleted 12-leted > groups, inserted 12-lets, deleted 32nds, nothing crashed. > > Can you give me a more detailed recipe for reproducing this crash, Chris, > please? Predictably enough, when I compiled again with debug it no longer crashed. Rebuilding once more without debug, but I'm in a meeting for much of the day and I'm not sure when I'll get a moment to get back to it. Hopefully before the end of the day though. In any case, there were multiple ways I could make it crash -- first time was by selecting a hemidemisemi and trying to insert that randomly into the middle of one of the 12-tuplet groups. Chris |
From: Chris C. <ca...@al...> - 2013-11-15 09:57:08
|
On Fri, Nov 15, 2013, at 09:50 AM, Chris Cannam wrote: > Rebuilding once more without debug (btw I had already confirmed the crash -- without debug -- on a build from clean) Chris |
From: Chris C. <ca...@al...> - 2013-11-15 10:30:32
|
OK, here's what I did: * build rev 13554 from clean without debug * open the Ravel example piece * select just the right hand segment, open in notation editor * find the very first 12-tupleted note in the part * select that note only * hit the delete key on the keyboard Program received signal SIGFPE, Arithmetic exception. 0x0000000000539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () (gdb) where #0 0x0000000000539eaf in Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] () #1 0x000000000053be40 in Rosegarden::TimeSignature::getNumDivisions(int) const () #2 0x0000000000594578 in Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) () #3 0x0000000000594b93 in Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment&) const () #4 0x000000000059b890 in Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) () #5 0x000000000059b910 in Rosegarden::EraseCommand::modifySegment() () #6 0x000000000045b190 in Rosegarden::BasicCommand::execute() () Chris |
From: Chris C. <ca...@al...> - 2013-11-15 10:34:09
|
On Fri, Nov 15, 2013, at 10:30 AM, Chris Cannam wrote: > Program received signal SIGFPE, Arithmetic exception. > 0x0000000000539eaf in Rosegarden::TimeSignature::setInternalDurations() And here's valgrind: ==7241== Process terminating with default action of signal 8 (SIGFPE) ==7241== Integer divide by zero at address 0x81141E17B ==7241== at 0x539EA9: Rosegarden::TimeSignature::setInternalDurations() const [clone .part.14] (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x53BE3F: Rosegarden::TimeSignature::getNumDivisions(int) const (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x594577: Rosegarden::DirtyNodeFinder::storeDirtyNodes(Rosegarden::MeterTreeNodeArgs) (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x594B92: Rosegarden::DirtyRanges::fixAll(Rosegarden::Segment&) const (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x59B88F: Rosegarden::EraseCommand::eraseInSegment(Rosegarden::EventSelection*) (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x59B90F: Rosegarden::EraseCommand::modifySegment() (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) ==7241== by 0x45B18F: Rosegarden::BasicCommand::execute() (in /work/rosegarden/build/big-tuplet-rewrite/rosegarden/rosegarden) etc. Chris |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-15 23:49:14
|
> 2) I continued flailing around deleting things haphazardly. I never got > a crash, but if you start deleting a bunch of random notes from the > 12-tuplet groups, you eventually wind up with random triplet rests > scattered around, and nothing indicating that the remaining notes are 12 > or any other kind of tupleted. After some poking around, I realized one other thing that's going on with that. We're re-using grouping Ids, and we have been for a long time. I got some weird beamings I couldn't explain, until I realized the Ravel measure I was fooling with had group Ids of 0, 1, 2, etc. (First measure of 12-lets). Of course Segment::getId starts with 0, 1, 2 too. My fresh new group Ids weren't fresh at all! I will fix that as well. Probably I'll set that count sensibly after a file is loaded. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2013-11-16 02:22:51
|
> I will fix that as well. Probably I'll set that count sensibly after a > file is loaded. It was more surprising than that. RoseXmlHandler already has code to remap segment ID counts. It's just done at the wrong time. It was done as soon as an event was seen, before it has properties, so of course when it tested for group id property, it always found none, so it never remapped anything. I moved it to the end of event, and now it works fine. Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2013-11-16 17:04:54
|
On 11/16/2013 05:08 AM, Chris Cannam wrote: > You should definitely mess > around with it even if you never venture outside your most familiar > workflow. I was thinking of looking for some snippets to use as test cases. Can anyone recommend specific pieces or composers that would be particularly problematic? Preferably public-domain (imslp) so I can put some bars up on the wiki. With a nice collection of these, we can focus the requirements and bug-hunting. Ted. |