[Clam-devel] Spectral Analysis/Synthesis

[Karsten Krispin]

Hello Xavier!

Please excuse my late answer in contradiction to all your fast ones.. but I'm 
quite deep in the project now and have not much time to respond.. though I 
recognized it... ;)

Am Freitag 08 Februar 2008 15:58:54 schrieb Xavier Amatriain:
> First, it is great to know that somebody is looking into using CLAM with
> the reactable. Some of us still remember that this was the initial plan
> when the reactable project started. Unfortunately at that point CLAM was
> not production ready and it was much easier to use Pd. I really hope you
> are successful in your project: it would make us very happy in CLAM :-)

Well.. I consider it was more or less just luck, that I found CLAM. I had a 
look for DSP-Libs and found a few and compared them. If found that your 
approach was just perfect to me. And when I was digging through the code, I 
recognized "MTG" within the license header. So I wondered why the origignal 
reactable does not use this library. But I came to this conclusion for my 
self as well, after I read some posts of Martin Kaltenbrunner on the 
reactable-Forum.

But apart from those children's diseases, I think we will. Unfortunately 
especially the reactable-people don't want to share too much of information. 
Nice that at least regarding CLAM you get pretty much and fast help. :)

> Now on to the technical details....
>
> I have to contradict Pau, using the FFT/IFFT directly is not a very good
> idea unless you think you can manage things like windowing, overlap,
> etc... on your own. Spectral Analysis/Synthesis is the way to go.

Well, yep. I see. Why should I care about that if SpectralX does this for me.

> Also, for future reference, if you are trying to implement Spectral
> transformations in between those processes (I bet :-) you should at
> least work with a hopSize of 1/4 the WindowSize. Considering the default
> WindowSize is 1024 you should go into 256 hop size or increase the
> WindowSize (and therefore latency) to 2048. In any case, this should
> only be a problem if you do transformations but not now.

But this would not only mean that my latency-time is higher, but also twice or 
even more of CPU usage, because the FFT/iFFT will run at window-size... 
Just for the table, we bought an intel quadcore with 4Gigs of ram... But I 
don't know how much the load will gonna be with twice the window-size.

How ever, if I run into distorted  sound, I will stick to this advice.

But that thingy that you have to push two buffers to get out a spectrum or 
such is not quite straight-lined to me. If I use ports and set up a 
transformchain, I have to use the supervised Do()-Command. But that would 
mean, that some processings in the chain are unfeeded after the first 
Do()-Cycle... and would fail... Like "nothing to read in reading region" ...? 
Or do I get something wrong here?

Greetings,
Karsten