From: Chris C. <ca...@al...> - 2010-08-21 20:58:13
|
On Sat, Aug 21, 2010 at 7:55 PM, Chris Cannam <ca...@al...> wrote: > On Sat, Aug 21, 2010 at 7:48 PM, Julie S <msj...@ya...> wrote: >> My guess is that "emrum" thought he could knock out an easy O(1) update to an O(n) algorithm. > > Hm. > > Yes, well -- in this case O(n) is fine. It has never been a > bottleneck and it probably never will be. Hang on, we're doing him a disservice here. The commit log said: "bug fixes you can drop multi selections (of files/URIs) on the AudioFileList now ProgessDialog fixed for drop events insertion without dragging is functional" I at first read the commit log but didn't read the whole diff for the commit, and I had assumed that this particular change was additional to the stuff listed in the log. But in fact, this change is the only thing in the diff. It's possible that the log was in error (e.g. written for the wrong commit) but the likelihood is that this change did fix something. And thinking about "you can drop multi selections", that makes sense. If you drop many things at once, the insertion code will (presumably -- I'm not reading the code here) want to get new audio file IDs for all of them at once. But the way getFirstUnusedID works, it will return the first ID that is not of an audio file that has been inserted into the composition -- which means it will return the same ID for each new file, since none of them has been inserted yet. Of course, the fix is itself broken because its IDs don't persist across file save/load (as we saw). What we need it seems is for a getNewAudioFileID function that returns an ID guaranteed not to be in the current composition and also guaranteed not to have been returned by any previous call to getNewAudioFileID during this run of the program. Also, is this function called by any undoable commands? If so, do they assume that the file can be added, removed, and added again using the same ID as it had before? (In which case we need to also ensure that "new" IDs handed out elsewhere between undo and redo differ from any IDs that were in the composition when it was loaded but may have been removed from it since?) Or do they allocate a new ID for the audio file on each redo? (Which would likely be broken in many other ways, since segments owned by other commands in the stack are likely to have references to the audio file ID.) Chris |