From: Chris C. <ca...@al...> - 2004-03-02 11:01:58
|
On Tuesday 02 Mar 2004 7:45 am, Richard Bown wrote: > At this stage the size of the buffer has already changed to the new > smaller version (when deleting a group of notes from a segment) so > any zeroing of data in that buffer is going not going to extend to > the end of it anymore. The important question is whether the sequencer knows the new size or not. If it does, then it shouldn't matter whether there's garbage at the end or not as it should stop before reading it. If it doesn't then that's pretty bad, and looking at it, I think that probably is the case. Currently the way the sequencer keeps track of the size is that it just looks at the file size first, and then it expects remapSegment calls when something changes, passing in the new size. remapSegment didn't originally pass in the size, I added that to deal with the crash when unrepeating. Unfortunately remapSegment is only called if the segment changes during playback, not when stopped. So that suggests that if you change the segment when playback is stopped, you will get ghost notes: but as soon as you then make another change during playback, it should resynchronise itself. Is that the case? During our discussions about unrepeating I seem to remember wondering why we didn't just write the number of events into the shared memory area itself rather than having the sequencer guess it from the file size and expect to be told when it changes. I don't remember whether we ever worked out a reason not to do that. The other big question I have about all this is what happens at the sequencer if the remap call at gui/mmappedsegment.cpp:107 results in the memory location actually having to move. (As you see, I put in a warning to remind me to keep an eye out for that case, but I've never actually seen one yet. I should just make a test program.) Chris |