[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