Re: [Audacity-devel] Refactoring, Step 1

[Augustus S. <asa...@ea...>]

Ok, I'll let you look at it next week-I won't have access over the 
holiday.  I thought that I would go ahead and describe the architecture 
of my app now, though, so we can talk about what would be applicable to 
Audacity and what wouldn't.  For those who missed my earlier summary of 
the app, I'm writing a tool to record voice annotations for a 
PowerPoint/StarImpress Presentation.  Currently, this means that there 
is one "track" per slide of the presentation.  However, each slide keeps 
its own revision history, so you can flip back and forth between slides 
and pick up undo/redo where you left off.  At some point in the future, 
we may allow a second track per slide for mixing in music or other 
background sounds.  In that case, you could imagine each slide as having 
it's own "project," albeit a very simple one.  My app is then influenced 
by the need to flip back and forth between different projects easily. 
 Therefore, I encapsulate all of my project settings in an object that 
the GUI renders from, so all I have to do is flip the active project and 
invalidate (Refresh() in wxWindows) to display a different project.  To 
support undo/redo, I keep an UndoStack of project settings for each 
project (slide).  My GUI caches nothing, and only handles rendering and 
event handling.  Because my projects currently only have 1 track in 
them, I have really misnamed my classes: WaveState and WaveDisplay 
should be ProjectState and ProjectDisplay.  I will use these better 
names in the rest of this explanation.  So here's a sketch of my 
architecture:

ProjectState
{
    WaveTrack wavetracks[];  // in my app, there's only 1, but there 
could be more.

    //other state like selection, scroll position, zoom level, etc.
}

// very similar to UndoManager
UndoStack
{
    ProjectState projectstates[];
    index currentstate;

    Undo();
    Redo();

    ProjectState* GetProject() { return projectstates[currentstate]; }

    // stuff to handle lables, and other assorted book keeping.
}

IProjectProvider
{
    virtual ProjectState* GetProject();
}

MyApp : IProjectProvider
{
    ProjectID currentProject;

    Map[ ProjectID ] ==> UndoStack projects;

    ProjectState GetProject() { return 
projects[currentProject]->GetProject(); }
}

ProjectDisplay
{
    IProjectProvider *pIProjectProvider;

    OnPaint();
    OnScroll();
    OnMouse();
// etc

}

Now, my ProjectDisplay makes a lot of simplifying assumptions.  All of 
my controls are on the toolbar, so interacting with the ProjectDisplay 
is interacting with the waveform.  I could easily seperate out the 
scrollbar handling from my ProjectDisplay to create a (real) WaveDisplay 
since I have encapsulated all of the state necessary for rendering and 
access it through interfaces.  What I completely lack is anything 
resembling the individual track controls in audacity.  Additionally, I 
only display waveforms, although this would be easy to fix.  I have one 
(simple) function that calls GetWaveFormDisplay on WaveTrack and draws 
into a DC.  The easy solution is what I believe you already do: just 
have a switch in the WaveDisplay on the DisplayType.  But the 
ProjectState would keep the DisplayType for each track.

I guess the point of all of this is that I do recommend encapsulating 
all of the project state into a seperate object.  You can then have 382 
different ways of changing it, and everything will update correctly. 
 Just in general, make GUI classes as stateless as possible.  So 
WaveDisplay uses ProjectState to figure out what parts of a track to 
draw and in what manner and goes to WaveTrack to actually get the data.

Ok, if I've tried to condense too much into this, let me know and I'll 
try and clarify.  Cheers-

Augustus

Dominic Mazzoni wrote:

> Yes, our emails are crossing like crazy!  :)
>
> I'd like to see your WaveState class, because my idea was to do
> something very similar with Audacity.  So libaudacity will only
> work with WaveTracks, but Audacity projects will work with a list
> of TrackDisplays (that was what I've been calling them), each
> one of which contains one WaveTrack.  I was assuming that a
> TrackDisplay would actually know how to draw itself, and handle
> mouse clicks and stuff like that.  You may have thoughts on
> whether or not this would be a good idea.  It seems to me that
> since there is a visual on-screen concept of a "track", it should
> have an object, with methods that respond directly to many
> actions on-screen.  The exception of course is actions like
> selecting which apply to more than one track - these methods
> should stay in TrackPanel.
>
> - Dominic
>
> Augustus Saunders wrote:
>
>>
>> Sorry to pepper you with questions, but what component is actually 
>> *supposed* to keep track of the display variable that I'm taking out 
>> of WakeTrack?  Or was I supposed to come up with that?  In my project 
>> at verilogix, I have a couple of helper classes that I use to keep 
>> track of the display status of a WaveTrack.  I have a WaveState class 
>> that keeps track of zoom level, selection, scroll position, etc, and 
>> there is one WaveState per WaveTrack.  Then, I have an UndoStack of 
>> WaveStates, where UndoStack is very similar to your UndoManager.  
>> Obviously, I'm doing slightly different things than Audacity is  (I 
>> have std::map->UndoStack->WaveState->WaveTrack because my users work 
>> with multiple tracks that are not mixed together and have independant 
>> UndoStacks).  I still find my WaveState to be rather useful in 
>> wrapping up all the GUI attributes related to an individual track, 
>> and it seems reasonable to introduce the concept here.
>>
>> Augustus
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> No, I will not fix your computer.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Audacity-devel mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Audacity-devel mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>