Re: [Protux-devel] code cleanup / general improvements

[Luciano Giordana]

> I think the peak improvements are going to an  and, so I try to do some
> code cleanup / general improvements / bug fixing.
>
> Trying to fix the "flicker" I allready reduced some twice or triple
> painting, but for this, I need your advise:
> According the specification a Track = TrackArea + TrackPanel.
> Almost all redrawing in Song are done with: recreate_tracks, thus
> recreating all TrackPanels also. This is (with current use and function of
> TP) not necessary, so I added: recreate_track_area, and changed the
> according calls " recreate_tracks".
> Please, let me know if I can upload this change or if it isn't according
> the way protux works not, but for sure, it reduces painting quite a
> bit.

It is indeed not conformant. Just change the name to from recreate_track_area 
to recreate_mta and it will be fine ;-)

>
> Ehm, Luciano, you asked why PeakThreadBuilding should be serialized.
> All peakBuildThreads are started independently from eachother, and linux
> tries to give an equal amount of cpu time to each thread. If a thread is
> scanning a file, it has to stop and wait for another thread, which also
> scans a piece of a file, and so on, and so on.
> This is really killing your hard drive, and the progress meter in the LCD
> is also a mess (displays for all thread at the same time the progress) I
> hope this makes things a bit more clear. Best way to see it in action is:
> Remove before starting Protux, all peakfiles from a Song (e.a. 6 peakfiles)
> and start protux :-)

I agree they must be rebuilded one at a time. That's what I understand by 
serializing. Did I understand correctly ?

> Other bugs/wishlist: (should I use the BUGLIST for this?)

yeap :-)

> Following action's give unwanted results when status is "GOING" or
> "any_track_armed while not GOING" :
> -goto_begin
> -goto_end
> -all other such kind of actions
>
> Real Bug (don't know how to solve it):
> -Starting a recording in an empty MTA causes the (shuttle?)cursor to act as
> a F1 race car :-)

oops....

> There's a piece of code in Peak.cc which causes random segfaults. I
> commented it out, I'll upload it, so testing can continue (no automatic
> redrawing, so "Building Peaks" isn't updated automaticaly after peak_build)

you can put condition compilation for brand and unsafe new code, so we
can easyly disable it if they are not working properly. I did it in Ogg class.
You can easy disable Ogg code by commenting the line #define OGG_SUPORT in
MustuxAudioFileFormat.hh.
Do conditional compilation #ifs whenever you feel something you gonna do is 
risk, unless
the code is pretty spread around and you cannot isolate it.

> Remon

Thanks Remon, I will looking to the bugs, but I still need to finish xrun new 
handling in MADM before getting back
to protux.
-- 
Best Regards
--
Luciano Giordana - Musician - Certified Java/GNU C++ Developer 
Free Software Evangelist - Project Mustux - Musician Tools for GNU/Linux
http://www.freesoftware.fsf.org/mustux