Olá, estamos ainda com algumas dificuldades na parte A que não conseguimos resolver. Podemos colocar um external nosso, feito em C, como parte da parte A?? O processamento seria feito com os objetos do PD até certo ponto e, em seguida, o resultado intermediário seria mandado para o nosso external, que faria as contas finais e escreveria no arquivo de saída.
Henrique, a parte A deve ser feita obrigatoriamente usando objetos Pd num patch. A proposta é vencer estes desafios e aprender a trabalhar neste ambiente. Tendo implementado a parte A tanto em external como em patch, posso te garantir que a versão em patch é MUITO mais simples, embora eu entenda que a gente esteja menos familiarizado com o modo de pensar em fluxos de dados (esse é o principal desafio a ser vencido na parte A).
A única exceção a esta regra foi o próprio objeto fprintf~, pois as opções que existem no Pd para manipular arquivos texto têm certas limitações que tornariam esta última parte do processo (que é a menos interessante do ponto de vista do processamento sonoro no PV) desproporcionalmente complicada.
OK, é que ao fazer a parte S achamos relativamente simples fazer as coisas como externals.
O problema que estamos tendo seria muito simples de se fazer em C, mas nao sabemos em PD. Na formula do enunciado devemos fazer: (M*delta_phi(k)/2pi + k)*f_0 para encontrar as frequencias reais.
Nao conseguimos fazer o "+k" dessa formula. Temos o sinal M*delta_phi(k)/2pi e para fazer o +k, deveríamos somar com um outro sinal da forma [1, 2, 3, .... N], é isso?
Henrique, vocês podem usar o objeto [line~] para isso (veja o help dele).
Para que o [line~] gere exatamente um vetor de 1 até N para ser utilizado na análise em um ciclo DSP, é necessário que o tempo de geração da rampa seja igual ao período do ciclo DSP, ou seja, N/(MR) segundos.
Isto, combinado com o objeto [expr~ floor($v1, 0)] (veja a documentação aqui) deve resolver o problema.
[fexpr~ floor($v1)] é uma expressão inválida...
AHHH!!! Só falta essa lista pra terminar a parte A!!!
AJUDA PLZ!!!
Ops, olhando direito a documentação e também esse bug aberto desde 2006, vi que o objeto correto não é o [fexp~] e que a função float() recebe 2 argumentos e ignora o segundo. =/
Já corrigi no post acima com o objeto correto.
Olá Henrique
Discutimos isto na monitoria de ontem. Em princípio o que a Transformada Discreta de Fourier (DFT) faz é mudar o domínio de tempo para o domínio das frequências. Isto significa que ela irá gerar um array aonde as posições do array seriam relativas as frequências que os mesmos podem representar.
Sendo bastante simplista, se seu array de entrada tivesse 44100 amostras, por exemplo, e no mesmo tivéssemos apenas uma senóide de 440hz, no array de saída teríamos quase todos valores do vetor de saída com 0 e na posição 440, a amplitude da senóide (lembrando que a amplitude tem de ser calculada com a parte imaginária e complexa). Ou seja saida[0] = 0, saida[1] = 0, saida[2] = 0, ..., saida[440] = algum valor, saida[441] = 0, saida[442] = 0, ...
Como o nosso vetor de entrada possui menos de 44100 amostras, é necessário calcular a frequencia fundamental (f0) que seria o primeiro valor representado. A conta desta f0 está na descrição do EP.
Uma vez calculado o f0, basta multiplicar pelo k das posições do array de saída e teremos assim as k frequencias de saída.Chegando neste ponto só falta calcular a fase relativa para afirmarmos com precisão qual a frequência de cada amostra.
Na nossa implementação criamos um array auxiliar com k posições e colocamos valores de 0 a k no mesmo para calcular a frequência. A f0 é simples de ser calculada. A fase também está explicada na descrição do EP e será calculada na saída da FFT.
Acho que é isto. Espero ter ajudado. Abraços.
Schiavoni