Re: [Audacity-devel] just refactored TrackArtist
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: James C. <cr...@in...> - 2011-11-22 12:41:35
|
Andreas, I really want to thank you for your initiative in improving the structure of Audacity. * I notice some changes in this patch that go beyond refactoring, for example a change in the minimum frequency gain. What are the other changes that aren't pure refactoring that you made? * I notice the care with which you've preserved even USE_MIDI code that was currently disabled. That bodes well - and gives me a lot of confidence in what you are doing. * I wondered about "this->GetFullPath()" Why not just "GetFullPath()"? Exactly as Vaughan says, this will NOT be going into Audacity anytime soon. We have to fix bugs. I (and Martyn, Richard and indeed Vaughan) totally share your frustration at how Audacity is log jammed. But we have a stark choice. If we release versions of Audacity that lose people's work, Audacity will become known as junk-ware. We don't have much choice but to tackle serious bugs first. Forking the Audacity project is not going to be a good solution. I don't believe that Git, suggested by Alexandre, will solve the problem either, because with no forking any changes like yours will just get parked indefinitely. The way I see to solve it is to turn mod-track-panel (which is in lib-src) into a real plug in that actually does something. It will bring up a new alternative track panel that we can do exactly what we like with. It will be fine to have a lot of code copied and then refactored from Audacity in this plug-in. One of the new features of mod-track-panel that the main track panel doesn't have will be the ability to have plug-in track types. Another new feature, that will be easy, will be to have overlays, i.e draw multiple types of data on the same track. If you want to superimpose labels over the waveform you can. I would hope that in time we reach a turning point where mod-track-panel is a compelling alternative to the main track panel and can graduate to being a standard part of Audacity. We then remove the unfactored unused old track-panel code from Audacity. The beauty is that in the meantime, whilst its stability/utility/functionality is still in question, the new code is still available to early adopters and tinkerers who are OK with taking the (low) additional risk. I hope you can see that having TrackArtist derive from each of the possible component tracks as you have is the wrong architecture for this. It prevents new track types that haven't already been thought of from being provided as additional plug-ins. Better would be to trampoline from TrackArtist to a component track. The general idea of refactoring into component types and eliminating big switch statements, though, is absolutely on target. If you are interested in going down this route, talk with me off list (copy Vaughan and Martyn too). I could be interested in working closely with you to make this happen. --James. On 22/11/2011 02:46, Andreas Micheler wrote: > Hallo Audacity Team, > > I was very unsatisfied with TrackArtist > and I am still very unsatisfied with TrackPanel. > > So I just took a chance and refactored TrackArtist, just in case someone > cares. > It looks like this at the moment (and it still works as usual, without > new defects): > ___________________________________________________________________ > > class AUDACITY_DLL_API TrackArtist : > virtual public LabelTrackV, > virtual public TimeTrackV, > virtual public NoteTrackV, > virtual public WaveTrackV, > virtual public SpecTrackV > { > public: > TrackArtist(); > ~TrackArtist(); > > void UpdatePrefs(); > > void DrawTracks(wxEvtHandler *win, TrackList *tracks, Track *start, > wxDC& dc, wxRegion& reg, > wxRect& r, wxRect& clip, ViewInfo *viewInfo, > bool drawEnvelope, bool drawSamples, bool drawSliders); > > void DrawTrack(wxEvtHandler *win, const Track *t, > wxDC& dc, const wxRect& r, const ViewInfo *viewInfo, > bool drawEnvelope, bool drawSamples, bool drawSliders, > bool hasSolo); > > void SetInset(int left, int top, int right, int bottom); > void SetColours(); > void SetBackgroundBrushes(wxBrush unselectedBrush, wxBrush > selectedBrush, > wxPen unselectedPen, wxPen selectedPen); > > private: > int mInsetLeft; > int mInsetTop; > int mInsetRight; > int mInsetBottom; > > #ifdef EXPERIMENTAL_DRAW_THREAD > public: > int OnUpdateAfterThreadRunID; > #endif //EXPERIMENTAL_DRAW_THREAD > }; > ___________________________________________________________________ > > No magic until now, because I just divided the module into several new > files, > but I will try to do some wxPanel magic soon to have each widget draw > itself. > > The new files are in src/view: > BaseV.cpp& .h > LabelTrackV.cpp& .h > NoteTrackV.cpp& .h > SpecTrackV.cpp& .h > TimeTrackV.cpp& .h > TrackV.cpp& .h > VRulerV.cpp& .h > WaveTrackV.cpp& .h > > I've made another patch and uploaded it to my homepage. > I just cant wait for the 2.0 Release, because this would take another > two years. > More patches from me will come soon. > > Cheers, > Andreas |