[Clam-devel] SMSSynthesis

[Pau Arumi]

En/na Xavier Amatriain ha escrit:
> I am not sure... I mean, creating ports or not depending on the 
> configuration is great and
> should be a direction to go. However, having internal logic that avoids 
> computations depending
> on whether some ports are connected or not also does make sense in many 
> cases. Why do you
> say this would be harder to implement?

After looking at smssynthesis --inner processings use Do with
parameters-- and outport --have HasConnections interface-- classes
i think it's easy  both ways: config time or Do() time.
Howerver, config time is more explicit and consistent with other
classes, so I'd go for it.

Greg, if you need this efficiency improvement take the task.
Advice: I'd start by just commenting out code and measure the
efficiency gain. And only if it's a worth optimization then
implement the good solution and commit it.

pau



> Pau Arumi wrote:
>> I think it wold be more consistent and easier to implement if we
>> put this logic in the configuration.
>> I mean, the presence of audio-out port will depend on boolean
>> parameters on the configuration.
>> Agree, Xavier?
>>
>> pau
>>
>> En/na Xavier Amatriain ha escrit:
>>> That is exactly what I meant... only put in better words ;-) You got it!
>>>
>>> Greg Kellum wrote:
>>>> Hi Xavier,
>>>>
>>>> I wasn't sure what you meant by "doing a consistency check to make 
>>>> sure whether the three output ports are connected or not."  And 
>>>> maybe what I am about to suggest is actually what you meant, but 
>>>> what do you think about checking inside the networked Do() whether 
>>>> all three ports are connected and only computing the IFFTs for those 
>>>> ports which are actually connected?  So, if only the sinuisuid + 
>>>> residual mixdown is connected one would only do one IFFT rather than 
>>>> three.
>>>>
>>>> Best,
>>>> Greg
>>>>
>>>> On 8/2/07, *Xavier Amatriain* <xavier at create.ucsb.edu 
>>>> <mailto:xavier at create.ucsb.edu>> wrote:
>>>>
>>>>     Greg,
>>>>
>>>>     The SMSSynthesis class performs 3 IFFTs (not 2) simply because 
>>>> it aims
>>>>     at outputing also 3 different audios (one for the residual,
>>>>     one for the sinusoidal, and one for the addition of both). If 
>>>> you are
>>>>     only interested in synthesizing the sum you should probably
>>>>     add a Do overload (another one!!! aaarghh!) and for the networked
>>>>     version (Do without params) do a consistency check to make
>>>>     sure whether the three output ports are connected or not.
>>>>
>>>>     But, again, it does not deal with different IFFT sizes. By the
>>>>     time the
>>>>     Spectrums are synthesized they should be the same size
>>>>     (because they have to be added for the complete synthesis among 
>>>> other
>>>>     things).
>>>>
>>>>     Xavier
>>>>
>>>>     Greg Kellum wrote:
>>>>     > Hi all,
>>>>     >
>>>>     > I've been doing some optimizing this week.  Trying to make the
>>>>     > application that I've been working on run faster.  And I've been
>>>>     > looking at the SMSSynthesis class and asking myself whether it is
>>>>     > really necessary for this class to perform two IFFTs.  
>>>> Apparently,
>>>>     > SMSSythesis performs a separate IFFT for the sinusoidal peaks
>>>>     and the
>>>>     > residual, because it's possible that these two could use two
>>>>     different
>>>>     > IFFT sizes.  It would be nice if it only performed one IFFT in 
>>>> the
>>>>     > case that they both had the same size.  Um...  I have been
>>>>     looking at
>>>>     > the configuration file for SMSSynthesis trying to identify the
>>>>     > relevant configuration elements for IFFT size, but actually, I 
>>>> only
>>>>     > saw one configuration element for the IFFT size.  Um...  I've
>>>>     uploaded
>>>>     > an example configuration file to:
>>>>     > http://www.gregkellum.com/temp/synthesis.xml  Could someone 
>>>> tell me
>>>>     > what the relevant configuration elements are?
>>>>     >
>>>>     > Best,
>>>>     > Greg
>>>>     >