[CLAM] Calling processings before the Do

Xavier Amatriain xamat at iua.upf.es
Wed Apr 6 08:52:08 PDT 2005


By the way, in my thesis you have a discussion on some of these issues:

http://www.iua.upf.es/~xamat/Thesis/html/node138.html

(and the following)

El dc 06 de 04 del 2005 a les 15:42 +0000, en/na David Garcia va
escriure:
> 
> On Wed, 6 Apr 2005, Xavier Amatriain wrote:
> 
> > Hi, I will give you my opinion although it is a complex question.
> >
> > > The first, question is that, before any Do i must compute a kernel
> > > (matrix), once i know the configuration parameters. Which should be the
> > > correct place? ConcreteStart? ConcreteConfigure?
> >
> > Complex structural and costly operations should be set at configure
> > time, therefore it should go to ConcreteConfigure. Nevertheless there
> > might be some related initializations (imagine for instance resetting
> > some matrix coefficients) that for convenience could be set in the
> > ConcreteStart.
> 
> Ok. So:
> ConcreteConfigure: Configuration dependand task not in ConcreteStart
> ConcreteStart: Any initialization in order to clear the state
> 
> My case is the first one. It is just a matrix it doesn't need to be reset
> because it is data independent.
> 
> Maybe we should do these cases more extenses and put the criteria in some
> kind of FAQ. 'Where i put some initialization code for a processing?'.
> Some alternative cases are:
>  - Resource locking and unlocking (for example, audio devices)
>  - Initialization independent on the configuration (guess: constructor?)
>  - Initialization dependent on the connections (is that allowed?)
> 
> 
> > > The second related question is that this precomputation is done by appying
> > > the FFT to some constant data depending on the configuration. So, how i
> > > should deal this FFT calling before the Do. Should i create one fft object
> > > on configuration time and call Configure-Start-Do-Stop? Is worth, lazy
> > > initialization for the matrix?
> >
> > My guess here is that you should actually not only have two different
> > Processings but really two different "networks" both of them with
> > different configuration and execution times. You should try to keep all
> > Processings in a network synchronized in that respect (all Processings
> > in a Network should be configured, started... at the same time).
> 
> ok. That seems logical. I'll do that.
> 
> > As I said this is my opinion and it admits discussion ;)
> 
> I couldn't say that i wouldn't discuss someone discussing what you said.
> B-I)
> 
> David.
> 
> 
-- 
/**********************************
********* Xavier Amatriain ********
****** Music Technology Group *****
** IUA- Universitat Pompeu Fabra **
****** www.iua.upf.es/~xamat ******
***********************************/






More information about the clam-users mailing list