Olá!
Ontem na monitoria o André falou que podíamos usar a própria implementação do phase vocoder do pd para fazermos a parte A do EP.
Só que não consigo decifrar as contas malucas que o Miller faz. André, poderia indicar onde está a saída (cara de pau!) das amplitudes e frequencias a serem escritas no arquivo de saída do analisador?
Qualquer ajuda é benvinda!
Oi, André!
No PV do Miller ele calcula as amplitudes no subpatch "pd fft-analysis", através dos objetos *~ (para elevar ao quadrado a parte real e imaginária da FFT) e +~, porém o que ele faz com estes valores depois é diferente,pois a ressíntese dele é baseada na iFFT, enquanto a nossa é por síntese aditiva. Isso faz com que ele não precise calcular as frequências, apesar de que o modo como ele guarda as fases da janela anterior para comparar com as fases da janela atual no mesmo subpatch também pode ser aproveitado.
A parte que eu não recomendo aproveitar é a leitura das janelas (subpatch "pd read-windows"), pois aqui ele gerencia na mão o recorte e posicionamento das janelas, com overlap e tudo, o que é muito mais complicado do que o que a gente precisa: pra gente basta ler o arquivo sonoro com soundfiler ou readsf~ e mandar para um subpatch de análise com block~ definido de acordo com os parâmetros M e N. Desse jeito não temos que nos preocupar com localizar início e fim de janelas, pois o ciclo do DSP estará "formatando" os dados pra gente.
Olá!
Ontem ficamos um "bom" tempo tentando fazer corretamente a leitura da tabela para passar pra fft. Eu não achoque seja difícil mas não estamos nada confiantes nos nossos conhecimentos de PD. Ainda mais blocado e com overlap!
Não tem algum jeito de aproveitar essas contas do Miller para mndar amplitudes e frequencias pro fprintf ? [DESESPERO on]
Talvez o primeiro passo seja [DESESPERO off]
Esqueça o block e o overlap. As contas não têm NADA a ver com isso. Será que você está tentando fazer justamente do jeito que eu sugeri que NÃO valia a pena? Não tente imitar o subpatch "pd read-windows" do PV do Miller.
Tente resolver inicialmente sem block, fazendo a análise com os blocos default de 64 amostras, o que vai dar 31 valores de amplitude e frequência para cada ciclo do DSP.
Tudo o que você precisa considerar é que os objetos de áudio passam vetores uns pros outros. E o melhor é que você não precisa percorrer estes vetores nunca, pois todos os objetos aritméticos para áudio (+~,-~,*~,/~, etc) fazem a mesma conta para cada elemento do vetor. A conta da amplitude é feita somente a partir dos dois vetores que saem da FFT (parte real,parte imaginária), com *~ e +~. A conta da fase atual também só usa estes dados, e atan2~. A única parte minimamente trabalhosa é guardar este vetor de fases numa tabela para ler na próxima iteração e poder calcular as frequências. Mas são sempre vetores do mesmo tamanho, que é o bloco de áudio do DSP.
Se você resolver sem block~, a única modificação que faltará é processar os comandos para definir N e M, calcular o número K de osciladores, e setar o block~. O resto da implementação é igual.
Bom, acho que estou conseguindo alguma coisa com as amplitudes...
Aproveitei o [pd insample] do I07.phase.vocoder e, em um patch que estou criando, (o [pd analysis]) uso o [tabreceive~ $0-sample] como entrada para a [rfft].
Com isso, consegui escrever um fluxo que escreve 32 valores (ex: 4.8345e-07) e 32 ZEROS mas todas as linhas do fluxo são iguais.
Alguma ajuda?
Não entendo como funciona o tabreceive~ alguém tem algum exemplo?
Fiz um "grep tabreceive~ *.pd" no diretório /usr/lib/pd/doc/3.audio.examples e encontrei hits nos arquivos I02, I03, ..., I10, ou seja, todos os exemplos correspondentes ao capítulo 9 (com exceção do I01) usam tabreceive~. Algum destes pode te ajudar.
Sobre o $0- que precede o nome da tabela, isso é um macro que corresponde a um identificador unívoco associado à janela. Tabelas com nomes assim permitem que várias instâncias de um mesmo patch rodem simultaneamente usando tabelas que têm "o mesmo nome" ($0-sample por exemplo), mas que são independentes, uma para cada instância daquele patch.
No nosso caso, não estamos com intenção de rodar vários analisadores PV simultaneamente, então talvez o melhor seja nem usar estes nomes com macros, que podem facilmente confundir a gente (por exemplo tentando fazer um tabreceive~ $0-sample num subpatch diferente daquele onde está o tabsend~).
Ah, sim, sobre o rfft~ produzir 32 valores de análise e 32 ZEROS, isso é o comportamento normal dele. Ao invés de calcular a fft completa (64 valores) ela produz somente a parte correspondente às frequências 0,R/N,2R/N,...,(N/2)R/N=R/2, e o resto ele nem calcula. Na fft completa, os valores restantes são complexo-conjugados dos valores iniciais: FFT(N-k)=FFT(k)*.
Nós só vamos usar os resultados das contas para os índices 1 a (N/2)-1, então não se preocupe com estes índices a mais. Monte o patch correspondente às contas que precisam ser feitas (e que serão feitas nos vetores inteiros, inclusive na porção de ZEROS), e só na hora de escrever no arquivo texto é que você vai selecionar os valores de 1 a (n/2)-1 (usando as opções "first 1" e "last (N/2)-1" no fprintf~).