#1350 Can't Record Beethoven

Future Release
closed
Ted Felix
sequencer (64)
9
2013-05-30
2012-08-08
Ted Felix
No

Rosegarden cannot handle recording very complex music such as the attached excerpt from the third movement of Beethoven's Moonlight Sonata.

Before running the test, listen to the attached MIDI file to get an idea of what constitutes "correct". Then you'll be ready for the test...

Start from a clean slate with File > New. Go to Composition > Change Composition Start and End... and set the end to 500 bars. Set up rg to record on three tracks. Set the first track to filter channel 3, the second to filter channel 4, and the third (you guessed it) to filter channel 5. Arm all three tracks for record. Start recording. Use aplaymidi (or pmidi) to play the attached .mid file into rosegarden's record input. Once complete, stop rg. Now play what rg recorded back. It will not be correct. Most obviously, some notes in the rolled chords will have the wrong velocities, and the part at the very end where the melody comes back in is completely mangled by missing notes. (The effect is even more pronounced with the MIDI file of the complete piece. It's as if the problems build up as the recording progresses.)

Thanks to Aere Greenway for finding this and providing the test MIDI file.

Related

Bugs: #1193
Bugs: #1391

Discussion

  • Ted Felix
    Ted Felix
    2012-08-08

    Complex MIDI file for testing

     
    Attachments
  • Ted Felix
    Ted Felix
    2012-09-19

    My first clue is that rg appears to be dropping duplicate note on events. But only sometimes. And each time I try the test case, I get a different result.

     
  • Ted Felix
    Ted Felix
    2012-10-05

    It looks as though RosegardenDocument::replaceRecordedEvent() might be the problem. It appears that it can take a vector of note-on events. If multiple note-ons come in via ALSA for the same channel+pitch, this vector will be of size > 1. The problem is that replaceRecordedEvent() replaces each of those unique note-on events with a single "fresh" note-on event, thereby losing the start times of all but one of the note-on events. IOW, one note-on clobbers all the rest. This is my theory at this point. We'll see if it pans out....

     
    Last edit: Ted Felix 2012-10-05
  • Ted Felix
    Ted Felix
    2012-10-05

    Double note-on events without note-offs are certainly an issue for rg when recording from MIDI. Try sending the attached file into rosegarden while it is recording. It contains several overlapping notes which generate consecutive note-ons without note-offs. After rg is done recording, playback will show that there is only a single note. Not at all good.

     
    Attachments
  • Ted Felix
    Ted Felix
    2012-10-08

    The problem is [partially] double note-on events and RosegardenDocument::replaceRecordedEvent(). I've modified replaceRecordedEvent() to only update the duration of each event, and the Beethoven problem is solved.

    The Beethoven test file was filled with note-on events that had no corresponding note-offs. This would prevent future notes from ever sounding since replaceRecordedEvent() would just clobber all the future note-on Events with the first one.

    Need to do some more testing and some cleanup before checking in.

     
    Last edit: Ted Felix 2012-10-08
  • Ted Felix
    Ted Felix
    2012-10-08

    Partial fix in r13116.

    There are more problems when recording the entire third movement MIDI file. Recommend working on MIDI recording performance issues first, as they may be the cause of the problems.

     
    Last edit: Ted Felix 2012-10-08
  • Ted Felix
    Ted Felix
    2012-10-17

    It appears that Segment::insert() and Segment::erase() are the problem. These two fire off a flurry of notifications and set update flags. Any of those could be causing the CPU drain. Need to go through them all one by one.

    I also noticed that the profiler output seems to want to blame CompositionView::viewportPaintEvent() which is called in response to a paint event. So somebody's calling update() a lot.

    Lots of trails to follow.

     
    Last edit: Ted Felix 2012-10-17
  • Ted Felix
    Ted Felix
    2012-11-15

    • assigned_to: Ted Felix
     
  • Status?

     
    • milestone: 12.12 --> Future Release
     
  • Ted Felix
    Ted Felix
    2013-02-08

    To fix this, I believe we must first fix the CPU usage issues when recording MIDI. That is a huge project that will require revisiting SegmentObserver, all code that modifies Segment objects, and all code that responds to SegmentObserver notifications. At my current abysmal rate of one or two hours a week on rg, that translates into decades. I'm moving this to the back burner as I work off other bug reports.

    For more details, see my 10/24/2012 status post to the dev list.

     
  • Ted Felix
    Ted Felix
    2013-05-01

    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,5 +1,7 @@
     Rosegarden cannot handle recording very complex music such as the attached excerpt from the third movement of Beethoven's Moonlight Sonata.  
    
    -Before running the test, listen to the attached MIDI file to get an idea of what constitutes "correct".  Then, for the test, set up rg to record on three tracks.  Set the first track to filter channel 1, the second to filter channel 2, and the third (you guessed it) to filter channel 3.  Arm all three tracks for record.  Start recording.  Use aplaymidi (or pmidi) to play the attached .mid file into rosegarden's record input.  Once complete, stop rg.  Now play what rg recorded back.  It will not be correct.  Most obviously, some notes in the rolled chords will have the wrong velocities, and the part at the very end where the melody comes back in is completely mangled by missing notes.  (The effect is even more pronounced with the MIDI file of the complete piece.  It's as if the problems build up as the recording progresses.)
    +Before running the test, listen to the attached MIDI file to get an idea of what constitutes "correct".  Then you'll be ready for the test...
    +
    +Start from a clean slate with File > New.  Go to Composition > Change Composition Start and End... and set the end to 500 bars.  Set up rg to record on three tracks.  Set the first track to filter channel 3, the second to filter channel 4, and the third (you guessed it) to filter channel 5.  Arm all three tracks for record.  Start recording.  Use aplaymidi (or pmidi) to play the attached .mid file into rosegarden's record input.  Once complete, stop rg.  Now play what rg recorded back.  It will not be correct.  Most obviously, some notes in the rolled chords will have the wrong velocities, and the part at the very end where the melody comes back in is completely mangled by missing notes.  (The effect is even more pronounced with the MIDI file of the complete piece.  It's as if the problems build up as the recording progresses.)
    
     Thanks to Aere Greenway for finding this and providing the test MIDI file.
    
     
  • Ted Felix
    Ted Felix
    2013-05-01

    I've just verified that fixing the CPU usage issues while recording will result in a perfect recording of this Beethoven .mid file. I reduced rg's CPU usage significantly by making four changes to the code.

    1. Increase time interval for RosegardenMainWindow::m_updateUITimer to 500msecs.
    2. A "return" at the top of CompositionView::slotUpdateSegmentsDrawBuffer()
    3. A "return" at the top of TransportDialog::setMidiInLabel()
    4. A "return" at the top of TransportDialog::setMidiOutLabel()

    With those changes the Beethoven test case was successful. So, focusing on rg's CPU usage is the right path to take.

     
  • Ted Felix
    Ted Felix
    2013-05-23

    • status: open --> closed
     
  • Ted Felix
    Ted Felix
    2013-05-23

    I think r13261 takes care of this. It halves the CPU usage while recording and on my hardware, this is enough for a perfect recording of the Beethoven piece.

     
  • Ted Felix
    Ted Felix
    2013-05-30

    Duplicate of [#1193] MIDI notes dropped when recording.

    Looks like many issues were fixed back then. This fixed some more. And there are still more. Think I'll open a new bug report to keep track of my current progress on CPU usage.

     

    Related

    Bugs: #1193