Re: [Audacity-devel] refactoring
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Dominic M. <do...@au...> - 2003-10-28 17:40:40
|
Joshua Haberman wrote: > On Tue, 2003-10-28 at 00:28, Dominic Mazzoni wrote: > >>Looks like this one never made it to the list. Weird. >>--- >>Hi Josh, >> >>Looks like you've made some great progress. I'm still behind on >>catching up on your Ogg progress; I've been working on 1.2.0 issues >>and playing with Mac OS X 10.3 "Panther" and XCode (both of which >>totally rock, BTW). > > Nice. I don't know if I've mentioned this to you, but I've been > thinking about perhaps getting a PowerBook sometime this year. Awesome! >>On Oct 25, 2003, at 10:34 PM, Joshua Haberman wrote: >> >>>I've been working a lot today on the beginning stages of what will >>>become the long-discussed Track rewrite. I don't have anything ready >>>to >>>show yet, but I wanted to throw some ideas out that I've been thinking >>>about through these initial changes. >>> >>>My first task has been reworking TrackList. The two main changes are >>>that it now uses wxList so we don't have to maintain our own linked >>>list >>>implementation, and we get the benefit of more methods already being >>>written. >> >>That sounds good. >> >>Before it's too late, what would you think about making it a >>dynamic array instead of a list? Conceptually a list seems okay >>but realistically certain operations, like move up/down, are a >>pain to implement for lists. > > > I did consider this, but what it came down to was that you can't derive > from wxArray because its destructor is not virtual. Since move up/down > will be methods of TrackList, at least the client routines won't be > exposed to the complexity. OK, I can see the reasoning for wxList, but do you think it would make sense to support the [] operator? There are times when this would be quite handy. Either way we should support STL-style iterators, rather than the lame ones I added. >>>The more beneficial change is a new type-safe interface to >>>getting specific kinds of tracks from the TrackList: >>> >>>WX_DEFINE_ARRAY(WaveTrack*, WaveTrackArray) >>>WX_DEFINE_ARRAY(NoteTrack*, NoteTrackArray) >>>WX_DEFINE_ARRAY(LabelTrack*, LabelTrackArray) >>>WaveTrackArray GetWaveTracks(bool selectedOnly); >>>NoteTrackArray GetNoteTracks(bool selectedOnly); >>>LabelTrackArray GetLabelTracks(bool selectedOnly); >> >>Those are great. The fact that all of these methods return >>arrays makes me even more sure that it would be better if TrackList >>is really TrackArray. > > One way to see the difference is that the TrackArrays returned above are > "snapshots" of the actual list. The List may own the tracks, but the > arrays never do. The Arrays are not meant to be modified, whereas the > list gets modified all the time. The arrays have short life-spans and > are not passed between procedures, whereas the list is. OK, that makes more sense. What would you think about implementing the very early versions of the TrackList and new Track hierarchy in a little sandbox, maybe a very simple wxWindows main program that just creates some different tracks that draw themselves with a simple rectangle or something? I feel like it might be nice to play with the interface and make all of the changes we want to there first, so that we don't rip up all of the Audacity code that works with tracks before we're totally happy with the details of the rewrite. - Dominic > Thanks for your comments. > > Josh > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |