[Clam-devel] [Fwd: about CLAM audio]

[David García Garzón]

El Sunday 12 August 2007 23:25:50 Roman Goj va escriure:
> Pau Arumi wrote:
> > En/na globot ha escrit:
>
> (...)
>
> >> for the moment I don't have time to code the seeking and current time
> >> reading, but if nobody do it in a few weeks i will be obliged to do it
> >>
> >> :) (in fact no because it is not a key feature for my project, but i
> >>
> >> want it).
> >> I don't know exactly when i will do it, i'll keep you informed. You
> >> can add this task to the TODO list (or feature Requests).
> >
> > the feature request has been added to the tracker.
> > whoever needs the feature first, roman, david, you... start
> > implementing it giving a notice to the list.
>
> Time reading seems to be implemented (I hope correctly, works here
> without any problems...) took four lines of code (just shows the
> neatness of clam, I guess! :) ) (Sorry I didn't give the notice here
> first... I wanted to make sure I can do this... and it turned out it was
> just too simple, not that I'm complaining it was ;) )

Definitely one of the best patches in terms of functionality/lines ratio :-)

It would help us a lot to rewrite the Annotator auralization engine but we 
need some more functionality such as the seek feature.

> So - now you can (using svn code from today) display the time using a
> ContolPrinter (in NetEdit under, simply Controls :) ) attached to the
> new control output in the AudioFileReaders.
>
> Probably a TODO/feature request/dream:
> A special ControlTimePrinter that could display the time in different
> formats hh:mm:ss, mm:ss, mm:ss::msmsms ... :-)

Well, one think i would ask for is that at least the control name tells the 
units it sends. "Time Position Milliseconds". This would be control metadata 
but we don't have it, so...

Also I know that port naming is a mess but, as with members, try to use the 
same naming convention than the existing ports controls. In this case, 
capitalized and spaced words. Little patch i think.

> Also! Please note that now the time is only displayed each time audio is
> sent to the sink, so the time resolution is only as good as the audio
> "hop" in the AudioFileReader (or am I completely wrong here? :-) ). This
> does not mean *anything* as it's still not noticeable to the human (mine
> at least) eye :-)

Resolution is ok, the only question that would arise is which time should be 
send: The frame begining time, the mid time, or the end time. We should 
decide that when the first use case is addressed, meanwhile is just a matter 
of documenting the fact that we are sending the starting time of the last 
frame.

> I will try to do the seeking within the file tomorrow morning, if it's
> comparably simple, I'll do it, if not then maybe I'll have to focus on
> my GSoC tasks :-/ ("time out" was a GSoC task, "time in" isn't ;) i'd
> like to see it in CLAM for a number of reasons though... so if not now,
> then for sure first thing September :) )

I agree. It is a very valuable feature but do it if it doesn't take you much 
time of your primary goal.

> hmm... four lines of code and six paragraphs of explanations... I've got
> to "refactor" my e-mail writing skills, oh definitely... where's the
> stupid roman/src/computer-skills/EMailWriting.cxx ... ;)

:-)


David.