On 11/10/06, Juan Vuletich <jvuletich@...> wrote:
> Hola Hernán,
>
> Por aca todo bien. Algún dia tendríamos que encontrarnos, no?

si, che!
que podemos armar?

> > [1] Como el sistema es causal, calculo que se puede usar el método
> > "overlap-add method" para calcular la FFT y creo que con eso se podría
> > hacer algo simil real-time. O sea, dividir la señal en pedazos, a
> > medida que "va llegando" por ejemplo en muestras de tamaño similar a
> > la RI, procesarlas y luego sumar las salidas (el sistema esta
> > "modelado" como lineal y por lo tanto se puede hacer esto)
> >
> Si. No se me había ocurrido, pero creo que tiene que andar bien. De
> cualquier manera, aunque el sistema no necesita "conocer el futuro", tu
> técnica sí. La única manera de hacerlo online (o tiempo real) es
> introductir un retardo de tamaño igual a la longitud de la FFT.

claro

> Me acabo de dar cuenta que como la FFT tiene que tener una longitud al
> menos igual a la suma de la longitud de la respuesta al impulso más la
> longitud de los pedazos de señal que tomás, la maera de reducir el
> retardo es reducir el tamaño de esos pedazos. Esto aumenta el costo de
> cálculo. Llevado al extremo, es tomar pedazos de señal de longitud 1, y
> obtener retardo cero. Y entonces lo que estás haciendo al sumar los
> pedazos es de nuevo la convolución en el dominio temporal!
> O sea, el "overlap-add" de segmentos procesados en el dominio de Fourier
> es un híbrido entre el dominio de Fourier "puro" y la convolución
> temporal. Cuán cerca estas de uno u otro extremo lo decidís con el
> tamaño de segmentos de señal a procesar.
>
> Interesante, no?

La verdad que si. Buen enfoque :D

> > me diste una muy buena idea, gracias!
> > voy a ver si implemento algo de esto cuando me haga un poco de tiempo
> > y lo pongo en el blog y/o aca :D
> Bueno, la idea fue tuya!
>
> Saludos,
> Juan

:D

> Pd. Alguna vez intenté convencerte de programar en Smalltalk? Tiene
> todas las ventajas de Matlab, todas las de C, y algunas extras (bueno
> para interfaces al usuario, por ejemplo). Podés ver algunas cosas que
> hice en Smalltalk en www.jvuletich.org .

ehhh, hehehe, si mencionarlo c/10 palabras no cuenta, creo que esta es
la primera vez... :-D

tenés algún ejemplito sencillo aplicado al audio por ahi para mostrar?

y algún dato para usar bajo linux...? squeak?

una nota aparte para ejemplificar que el método "tradicional" de
convolución puede llegar a tardar mucho (sacando casos especiales de
RI como aclaraste vos):
cuando aprendí lo de la convolución, lo 1ero que hice fue intentar
convolucionar audio con una respuesta impulsiva de algún lugar (usando
la función "conv" del matlab) y la cantidad de tiempo que tardaba era
impresionante, no se si se recuerdo bien, pero creo que "nunca
terminaba" :P (capaz que le puse un audio de 4 o 5 min, je)
esta bien que en ese momento tenía una máquina muy poco potente, pero
apenas vi lo de la FFT en seguida probé con eso y experimentalmente me
resultó rapidísimo (comparativamente)

asi como mencionaste (y con razón) que si la RI tiene pocos valores
distintos de cero y la otra señal es bastante "larga" puede ser más
rápido una convolución en el tiempo optimizada...
conoces(o alguien más) algún ejemplo de optimización de esta? y/o
alguna aplicación? (solo por curiosidad)

digo, si en general se tiende en el diseño de plataformas (tanto vía
hard o soft) a optimizar c/vez más la velocidad de cálculo de una FFT
(bueno la FFT misma es resultado de querer calcular rápido la DFT :D)
con integrados dedicados solo a eso y algoritmos optimizados para
c/plataforma [1], ¿se puede decir (y teniendo en cuenta el ejemplo
anterior en el que convolucionar en el tiempo requeria tanto cálculo
que no se podía hacer en tiempos "normales") que como método general
uno podría optar por conv en frec? ¿y dejar la conv en tiempo
optimizada para casos especiales?

que opinan?


[1] http://www.fftw.org/faq/section4.html#howworks

--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9