[Clam-devel] [PATCH] tonal analysis with configuration - episode 2

[Roman Goj]

Hi!

I'll remember to put [PATCH] in my subjects from now on, even if I feel
they're incomplete :) (I thought it was only for "ready to commit" patches)

This patch adds configuration to the Tonal Analysis processing, compared
to the version from my last post it also adds the reconfigure() method
for all the classes I skipped before (at first I added only
ChordExtractor and ConstantQTransform).

This, as expected, solves the problem with setting minimum frequency to
anything lower then something like 70 Hz (now the fourier transform
window can resize itself if that is needed).

I also noticed that if I change the min. frequency I need to adjust the
tunning, so that the results for different settings are still tuned in
the same way. I'm not sure what I did is the nicest way to go about this
though (just changing the referenceTunning variable appriopriately in
the ChordExtractor constructor and reconfigure() )...

It seems to be working nicely, but I guess it needs some testing - and
this is the hard part I guess - I don't exactly have the intuition for
all of the settings that I made configurable - checking whether changing
them works ok is not that easy if I'm not sure what results they should
really produce ;) (at least the change in tunning was easy to notice)
But I guess now playing around with the different configurations
withoug rebuilding clam is a great new way of learning how things really
work :)

Btw. are there any "dead simple" test signals for CLAM? The included
songs are nice, but I'd love to have something even simpler and very
obvious for testing and with graded complexity... i.e. play a single
note... play "happy birthday" with single notes... play "happy birthday"
with chords and single notes... play "happy birthday" with a simphony
orchestra and finally... make a jazzman play "happy birthday" ;) And of
course a woman and a man to sing it... I know it's best to present CLAM
with some nice complex sounds but it's easier for testing and learning
about the algorithm (for me or future clam users) to have simple signals
(I guess...) (also my supervisor pointed out, while I was doing a
presentation on analysing music with STFT, Constant Q, Matching Pursuit
that I should really be using a clean Wave file for testing how the
actuall algorithm works, not an mp3... I'm definitely not an expert in
how mp3s work, but according to my supervisor one might "tune in on the
algorithm parameters" for a specific encoding scheme, so it might be
better to use waves to be general... what's you opinion on this?) ...So
could I add myself a future TODO - record/find in the public domain
these simple signals or are they already there or should I not waste my
time on it anyway?

Also I wanted to avoid recalculating the sparsekernel when it's not
really necessary (when no config parameters affecting the sparse kernel
have been changed). But for this it turned out to be easier to do some
changes, so:

_sparseKernelThreshold is now a member of ConstantQTransform.cxx and not
TonalAnalysis.cxx

(but I'm not sure it should be _spar... maybe mSpare... there are three
different conventions in ConstantQTransform - fmax, _binsPerOctave and
mSpectrumSize... is this intended? i.e. are there groups of variables
that should be called one way and other groups that use a different
naming scheme? sorry if it's not intended and you think I'm just being
annoying - I never really payed attention to these things in my own
code, but now that I need to learn a big library I find it's not that
easy to switch conventions...)

sparsekernel(double thresh) is now sparsekernel() and uses
_sparseKernelThreshold instead of thresh for the threshold

sparsekernel now gets called from within the constructor and
reconfigure() of ConstantQTransform and not in the TonalAnalysis constructor

So - was there a reason this was not done so in the first place? Should
I revert, and go about checking if recalculation is needed in a
different way? Also - last but not least - should I be asking so many
questions...? (and describing what I change in such detail? rats,
another question... ;) )

What still needs to be done:
* adding reconfigure() is not the best way to do this right? So changing
this to ConcreteConfig() is the way to go in the "longer" run, right?
I'll investigate whether I can really do it on my own before monday...

BTW. I'm eagerly awaiting any replies... but unfortunately I'll have no
access to my computer and the net on monday morning, when you're likely
to be replying...  but I should be back in the afternoon/evening
(finally moving my computer to my home in Konin from Warsaw... hello
having two development machines... :) )

I can't seem to keep things short... Sorry! :( what parts of this e-mail
do you actually think were useful/informative? Maybe I should devide the
e-mail into seperate ones with just the patch, just the questions, just
the ideas...?

cheers!
roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TonalAnalysisConfig.patch
Type: text/x-patch
Size: 24872 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070707/1dbd6658/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RegisterConfiguratorLaunchers_TonalAnalysis.cxx
Type: text/x-c++src
Size: 985 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070707/1dbd6658/attachment-0003.cxx>