Re: [Traverso-devel] csound api introduction

[Remon]

Hi,

> > overview how things work. Nicola, you had/have this 'problem' too,
> > getting used to the code, anything you can recommend ?
>
> Hm, not really. Most of what I've coded are modules which were written from
> scratch. 

Yeah, that's right.

> Your API documentation is very helpful, though. 

I'd like to have more of it obviously, however things are moving around 
sometimes, which means that documentation could get incorrect, and as a 
result, I wasted my time writing it.
But some core concepts and classes indeed need more documentation, added it 
for AddRemoveItemCommand today, it's a rather important one.

Some sort of flow diagram, or block diagram would be great too. Something to 
work on for you, Niklas? With doing so you'll get used to the way Traverso 
works internally very quickly :-)
Problem of course is that something like that needs to be updated all the 
time, would be very handy if it can be extracted from the code automatically 
somehow.. ?

There are at least some core concepts that are unlikely to change, so that 
could be a good start point too.

> I started with  
> tiny things like fixing font alignments in the VUMeters, then I started
> redesigning them, and finally they were largely rewritten ;-).

Hehe, I don't wanna know how it looks now (the code) :-P

> > At this very moment, after all the lovely GUI improvements Nicola has
> > made, we
> > are gearing towards making cvs usable again, finishing the port to
> > QGraphicsView which has it's own set of odities that has to be worked
> > out. Certain features either need to be disabled or finished for the
> > 0.40.0.
>
> Remon: Do you have a TODO list for 0.40.0? I know I've sent you lots of
> suggestions in a rather unorganized manner, so I wonder what you really
> plan to do for the next release.

Me too, I've added your suggestions in the TODO list, maybe not all of them 
though. I'll update it some more with items I'd like to see finished for the 
0.40.0 release, you can add your own then, see if there is anything you 
can/will work on. (TODO file in cvs root dir)

> > P.S.
> > Before I forget, here is one:
> > When importing audio files ( < I > on Track), we store the absolute file
> > path
> > to that file, and the peakfile
> > in /project/path/projectname/peaks/audiofilename.peak-channel-0/1
> > As Nicola pointed out some time ago, it's quite possible to import
> > another file with the same name from another location. The peak file name
> > will clash,
> > you get the wrong wave form visualization, or in the worst case a crash.
> > What about looking into that routine, and e.g. making the peak file name
> > on
> > import more unique ?
> > (e.g. grep for the create_id() function which creates a 64 bit id that
> > consists of the timeofday() and random() values., just an idea)
> > Related classes: src/commands/Import src/core/Peak src/core/Utils,
> > src/core/ReadSource src/core/AudioSourcesManager
>
> It should also detect if the file was changed by another application, and
> if yes, recalculate the wave form. QFileInfo offers lastModified(),
> lastRead() and created() functions which may be useful. Perhaps created()
> and lastModified() can be stored in the wave form, and if a clip is
> imported and they don't match, the wave form is recalculated.

It's doing this allready :-)
(I've forgotten to answer your mail regarding this I think)


Here's the code:

Peak::read_header()
{
        <snip>
        QDateTime fileModTime = file.lastModified();
        QDateTime peakModTime = peakFile.lastModified();
        
        if (fileModTime > peakModTime) {
                PERROR("Source and Peak file modification time do not match");
                printf("SourceFile modification time is %s\n", 
fileModTime.toString().toAscii().data());
                printf("PeakFile modification time is %s\n", 
peakModTime.toString().toAscii().data());
                return -1;
        }
}

If read_header() fails, Peak will try to create a new peak file from scratch, 
and in case that's not working it bails out and set permanentFailure to true, 
which means the calculate_peaks() function always returns -1;

Ah well, point is of course, does the above code handle the situation 
correctly ?
The 'file' is the audiosources file, 'peakFile' the peaksfile (both QFile's)


Greetings,

Remon