Olá professor.
Estou tendo dificuldades com o cálculo das reflexões.
A parte inicial, calculada através do comprimento percorrido pelo som,
está devolvendo um valor maior que o esperado.
Por exemplo, defino uma resposta de 3 segundos, sendo 10% calculada, mas os
tempos devolvidos possuem mais de 3 segundos.
Estou fazendo o cálculo dos comprimentos com norma 2.
Consegui resolver... Havia feito de forma errada o calculo do tempo. Obrigada!
Oi, Shayenne!
Você poderia enviar um exemplo, com as dimensões da sala, os índices da sala virtual, e o valor da distância calculada?
Se o erro for bem pequeno (tempo pouco maior que os 3 segundos esperados), isso pode se dever à aproximação no laço que percorre os índices das salas virtuais, e nesse caso você pode deixar o erro na implementação, não faz mal.
Abraço,
Marcelo
Agora estou com dúvidas com a auralização.
Sei que tenho que usar um [fexpr~] mas não sei como utilizá-lo, quais cálculos fazer.
Oi, Shayenne!
Na realidade o [fexpr~] não vai te ajudar em nada... você precisa jogar a entrada numa tabela, operar diretamente nesta tabela (fazendo laços e etc) e escrever a saída em outra tabela, para copiá-la no [outlet~], exatamente como havíamos feito com os objetos [soma~] ou [amplitude~] no primeiro trabalho.
Olá professor,
Agradeço pelas respostas anteriores!
Novamente estou sem direção no auraliza-sala.
Não sei como convoluir os sinais. Tenho os vetores de entrada, de memória, das respostas impulsivas e das saídas.
Defini o bloco em 64, era para ser flexível?
Assim, os vetores possuem tamanhos, respectivamente, 64, 64+tamanho da resposta, tamanho da resposta e 64.
Para realizar a convolução fiz uma expressão: [expr $f1+($f2*$f3)], onde $f1 é o resultado anterior, $f2 o valor da resposta impulsiva e $f3 o valor armazenado da entrada. Mas isto não funciona...
Olá, Shayenne!
Tudo bem usar o bloco default de 64, a especificação não pede nada mais genérico do que isso. Em teoria, para usar o auralizador ligado direto ao DAC ele teria que rodar mesmo com o bloco default.
Quanto à convolução, queria entender se há alguma dúvida conceitual, ou se a dificuldade é só com o Pd. Isso porque a fórmula do z[n] no enunciado (corrigindo aquele termo y[m] que deveria aparecer dentro da somatória ao invés de y[n]) é tudo o que precisa ser calculado na saída (para cada amostra n do vetor onde você vai escrever o resultado). Então o [expr] que você mostrou está certo, afinal ele é um acumulador ($f1+...) que atualiza a soma com o produto de dois termos, um que vem da entrada e outro da resposta impulsiva. O problema que você está tendo então tem que estar fora do [expr]: ou você não inicializa a soma com 0 a cada nova amostra, ou você não está realizando as consultas dos vetores nos índices corretos (o que seria y[m] e x[n-m] na fórmula), ou então você não está sequenciando as operações dos dois laços corretamente: o laço externo varreria os índices n do bloco de saída, e o laço interno o m da somatória, e tudo precisa ser regido através de [triggers] para garantir que você lê os dois vetores e alimenta o [fexpr] antes de jogar o valor anterior da soma no inlet "quente" associado ao $f1, e detecta o final da soma no momento certo para alimentar o vetor de saída na posição correta.
Verifiquei tudo e parece que está como você explicou.
Procurando pelo problema, parece que o loop interno está demorando mais do que pode no ciclo e por isso não sai o som.
Ao apagar a ligação do loop interno o áudio funciona na velocidade normal. Fiz o loop com until. Existe alguma restrição para o uso desse objeto?
Olá, Shayenne!
De fato o Pd não consegue executar em tempo real a auralização com respostas impulsivas longas. Dê uma olhada por favor na mensagem abaixo (e a sugestão pragmática da minha resposta):
http://paca.ime.usp.br/mod/forum/discuss.php?d=26941#p77192
Abraço,
Marcelo
Oi professor,
tentei utilizar o writesf~ mas não funcionou. O arquivo de áudio não toca mesmo gravando osc~ puros.
Tentei diminuir o tamanho da resposta impulsiva para dar tempo de calcular a cada ciclo, mas a resposta fica tão pequena que, multiplicada pelo sinal, fica quase zero.
Pela aparência dos vetores, acredito que o programa esteja funcionando. O problema é apenas ouvir o resultado.
Oi, Shayenne!
O writesf~ tem um help. Se você abrir esse help e clicar na mensagem open e depois no bang ele deve gerar um arquivo /tmp/foo.wav. Na sua máquina esse arquivo não é gerado, não toca ou tem conteúdo incorreto? Na minha maquina funcionou normalmente. Note que enquanto o Pd está aberto outros players provavelmente não terão acesso à placa de áudio.
Consegui ouvir. O problema era o PD aberto. Mas as respostas são muito grandes, demoram para terminar.
Deixei o pc rodando duas horas e só calculou 2 segundos de chiado.
Existe algum arquivo teste que funcione melhor? Tentei usar as especificações do EP mas mesmo assim ficam grandes os resultados.