[Clam-devel] Setting incontrol bounds + droping mAmount

Pau Arumi parumi at iua.upf.edu
Wed Jun 6 04:59:28 PDT 2007


(sending copy to the list)

Hi Hernan,

I was about doing a spectral-transformation-related refactoring but 
then I thought it better: I think it suits you very much. It should
be a quick task and will surely teach you some things about
these transformations. Tell me if you feel like taking it (or just
send the patch ;))

It is not technically a refactoring since we are adding a little
bit of functionality here. It consists on setting bounds to all
spectral (sms or not) transformations in-controls. So we can add
sliders to them much easier when prototyping, and use double-click
sliders from network-editor.

Take OscillatingSpectralNotch, which I updated last week, as a
model:
http://iua-share.upf.edu/svn/clam/trunk/CLAM/src/Processing/Transformations/Spectral/OscillatingSpectralNotch.hxx

An important detail: many of these processings derive from
FrameTransformationTmpl<DataType>. FrameTransformation interface is
used within the SMSTools to execute a stack of these
transformations on each frame. (this is quite old, from the
pre-streaming era in CLAM.)

You'll see that FrameTransformation base class define the mAmount
InControl. The refactoring should include _not using this control_
(like in the OSN example). Using "Amount" for very different things
--say, a freq now and a gain later-- is too much constrained.
And since rencently, not necessary even for SMSTools: in this file
you can specify by id which control will be automated in SMSTools:

http://iua-share.upf.edu/svn/clam/trunk/CLAM/src/Processing/Transformations/SMS/SMSTransformationChain.hxx

If you take the task, begin with doing a patch for a single
processing. Have into account that you might need also to modify
the .ui (qtdesigner) files accordingly. But it's enough for now.
More details on demand :)

pau





More information about the clam-devel mailing list