Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1078 Some notes are misaligned after pasting

closed
nobody
matrix (53)
8
2012-09-16
2007-08-26
Juuso Alasuutari
No

When pasting anything in the matrix and percussion matrix editors, occasionally some some notes will be offset by a small amount. This will sometimes happen even with a short snippet. If the pasted section is long, the chance of some notes being misaligned seems to increase towards the end. The misbehaving notes always seem to slip forward in time, and the offset is usually less than 1/16.

This keeps bugging the bejesus out of me, because it forces me to manually inspect everything I paste. Even quantizing the pasted area doesn't work because the misaligned notes may be closer to the next note position than the correct one.

Just so that you know: I have paid close attention to actually pasting in the correct place, for instance by zooming in 1000% and then setting the cursor position. This bug isn't the result of sloppy mouse usage.

To reproduce create a short drumbeat, copy it, and paste it successively until you observe the bug. If you want me to trace what the program does when this happens I'll be glad to, just tell me how.

Discussion

1 2 > >> (Page 1 of 2)
  • Logged In: YES
    user_id=663564
    Originator: NO

    I haven't tried to reproduce it here and now, but this sounds like an old ghost I thought I was imagining, which I chalked up to user error.

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I kept an eye out for this bug yesterday as I was editing a song. It seems that I was wrong when I said, "the chance of some notes being misaligned seems to increase towards the end". In fact, it looks more like a random occurrence. But the notes do always slip forward, never backwards.

    As I said I'd be happy to trace this. Are there any tools that I could use to produce meaningful debug info?

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    I'm not sure what would be useful. I've never played around with any of that code, and I'm not familiar with it.

    I'm afraid I can't suggest anything better than rebuilding with full debugging enabled, run from a terminal, and sift through the stream of traces to see if a pattern emerges. I'm not even sure any relevant traces are enabled in the code. We tend to comment out noisy traces after fixing a problem, so there are tons of traces that won't be built even with full debugging. Not being familiar with any of this code, I can only speak in general terms.

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    File Added: good_paste.txt

     
  • Full debug from a flawless paste

     
    Attachments
  • Logged In: YES
    user_id=1707301
    Originator: YES

    File Added: bad_paste.txt

     
  • Full debug from a misaligned paste

     
    Attachments
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I managed to reproduce the bug while capturing debug messages. I uploaded the data captured during both succesful and misaligned pastings. I couldn't see anything alarming in them, though. Perhaps I couldn't interpret the data or there indeed isn't enough debug output available.

    If this gives you more clues about where to search, and you can write up a patch for outputting more detailed debug info, I'll gladly apply the patch and do a re-run.

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    I don't see anything standing out, except different paste times. Makes me suspect something going wrong on the clicking end. We're interpreting what to you seems to be an identical click slightly differently, and sliding the events over a hair.

    Or something. Is it the same mechanism in all cases? I seem to remember an old bug where there was a difference between click pasting and ^V pasting.

    Chris would be the best person to offer the insight here, but he's not around this week.

    I'll see if I can even reproduce it for starters, and we'll go from there. Maybe I'll have time to think more by the weekend. I hope.

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I used ^V pasting (after carefully aligning the bar with the mouse, of course). What in my opinion would seem to contradict the "slip of the mouse" hypothesis is that not all of the notes become misaligned. It's most often only one or two in a short selection.

    Also, I zoomed in so close that the smallest possible bar movement was several pixels wide. That makes it seem unlikely that the focus could be off by a hair. (But if that sort of thing is indeed possible, I would consider it a bug.)

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    OK.

    I'm not calling it the "slip of the mouse" hypothesis anyway. More like the "insane superhuman hypersensitivity" hypothesis. Nobody's accusing you of bad mouse work. :D

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I like the way you label things. :)

    It wouldn't insult me one bit even if this turned out to be a wetware bug at my end. Whatever helps me focus on the music is good. Until then, I'm all ears.

     
  • RG file including a misaligned paste

     
    Attachments
  • Logged In: YES
    user_id=1707301
    Originator: YES

    File Added: test.rg

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    We talked about this with Chris on #lad and he asked for an example RG file. I uploaded test.rg which includes the bug's footprint.

    I started off by creating a bassline the lenght of one bar in the matrix editor. I then copied and pasted it to the next seven bars without running into the bug. Then I copied the whole eight bars and pasted it to the beginning of the ninth bar. That did the trick: there's a clearly visible offset beginning from the 11th bar.

    In the matrix editor, the grid was set to 1/32 and zooming to 500 %. I was very careful to point the cursor to the correct position (which is implied in that the offset doesn't begin until the third bar of the pasted region). I can't remember if quantizing was on when I pasted the region, and to be honest I have no idea if it would make any difference.

     
  • Chris Cannam
    Chris Cannam
    2007-09-04

    Logged In: YES
    user_id=13489
    Originator: NO

    Probable fix in SVN trunk (rev 8210). Please test and comment!

     
  • Heikki Junes
    Heikki Junes
    2007-09-04

    Logged In: YES
    user_id=30776
    Originator: NO

    Just changing category... (I did not test it, sorry.)

    Good catch from the original submitter!

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    Will try to schedule time for a testing session today or tomorrow night (EET).

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    Seems like the fix is missing an include statement or a linker flag:

    /usr/src/rosegarden-svn/src/gui/editors/matrix/MatrixHLayout.cpp: In member function 'virtual void Rosegarden::MatrixHLayout::scanStaff(Rosegarden::Staff&, Rosegarden::timeT, Rosegarden::timeT)':
    /usr/src/rosegarden-svn/src/gui/editors/matrix/MatrixHLayout.cpp:161: error: 'lrint' was not declared in this scope

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I compiled rev 8211 and worked on a song for maybe an hour; unfortunately the bug is still there. I copied a section of two bars' length and pasted it, which resulted in the notes in the second bar of the pasted area to shift forward approximately 1/64 or less.

     
  • Chris Cannam
    Chris Cannam
    2007-09-06

    Logged In: YES
    user_id=13489
    Originator: NO

    Damn. Oh well, I'm pretty sure I did fix a real bug at least.

    Could you include another example .rg file, so I can check whether the symptom still looks the same in terms of detail event timing or whether the fix I made has altered things as well? An example derived from the same original loop as the previous example would be good.

    Thanks.

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    Will do. I'll have time this evening or tomorrow.

     
  • Rev 8214, failed paste in bars 14 & 15

     
    Attachments
  • Logged In: YES
    user_id=1707301
    Originator: YES

    Uploaded test2.rg.

    I downloaded test.rg and opened it with rev 8214. I opened the matrix editor, deleted all bars beginning from the 9th, copied bars 1-8, and pasted them in the beginning of the (now empty) 9th bar. This time, bars 14 and 15 are misaligned. Their "parents", bars 6 and 7 are fine. Curiously, the last bar (16) is OK.
    File Added: test2.rg

     
  • Logged In: YES
    user_id=1707301
    Originator: YES

    I should add that test.rg was produced with a desktop running Source Mage GNU/Linux (a source-based distro), and test2.rg with a laptop running Debian unstable.

     
1 2 > >> (Page 1 of 2)