Primeiro trabalho maior: delay

Primeiro trabalho maior: delay

por Thilo Koch -
Número de respostas: 2

Marcelo:

Tenho problemas em ajustar o delay do nosso patch. Mando dois exemplos e um patch teste:

  • somaSenoTest.pd: O patch de teste. Para executar as duas versões do teste é so trocar somaFake~ com directinout~. O patch grava os primeiros 120ms do resultado no vetor.
  • somaFake~.pd: somente inlet~ e outlet~ conectado com +~
  • directinout~.pd: Na forma que nós devemos implementar com tabreceive~ e tabsend~ (mas simplesmente copiando a entrada p/ a saída)

Executando o teste (e comparando os resultados) fica óbvio que nossa metodologia adiciona inevitavelmente um delay.

Estou certo ou entendi algo errado?

Thilo.

Em resposta à Thilo Koch

Re: Primeiro trabalho maior: delay

por Marcelo Queiroz -

Oi, Thilo!

Sim, você tem razão. Eu interpretei mal o [tabsend~], pensando que ele faria a transferência no final do ciclo DSP, mas pensando melhor é claro que ele não poderia fazer isso (o resultado do tabsend~ será utilizado em outros lugares mais para a frente na cadeia de objetos DSP). Em outras palavras, a metodologia proposta no enunciado introduz um delay de 1 bloco... mea culpa.

Isso tem tudo a ver com uma pergunta que me fizeram no final da última aula, sobre o uso do objeto [tabplay~]. De fato a solução parece ser trocar o objeto [tabsend~] por um [tabplay~] e coordenar o envio do |bang< para este [tabplay~] após toda a computação realizada naquele bloco. Ou seja, deve haver um [trigger b b] onde o "b" do outlet direito dispara o laço para preencher o vetor da saída, e o "b" do outlet esquerdo força a transferência do conteúdo recém-atualizado.

Há que se testar essa alternativa, pois pode haver algum detalhezinho que eu não estou percebendo agora. De todo modo, quem não quiser se preocupar com isso pode deixar com o [tabsend~] e este delay de 1 bloco sem prejuízo da nota.

Abraços,

Marcelo

Em resposta à Marcelo Queiroz

Re: Primeiro trabalho maior: delay + novo: reblock com +~

por Thilo Koch -

Obrigado, Marcelo.

  1. Mando uma versão com tabplay~ (ou pelos de maneira que eu entendi) no meu directinout~. Não resolveu o problema! Ou eu fiz algo errado ou tenho que viver com isso. ;) Infelizmente encontrei pouca documentação sobre o ciclo de processamento do pd.
  2. Outro problema: Fiz um teste com +~ e reblocking. Eu mando um subpatch que muda o tamanho do bloco durante a execução. (É só colocar adaptBlockSoma~ no lugar de directinout~ no patch somaSenoTest.pd.) O objeto +~ introduz um bloco de silêncio quando o tamanho do bloco muda. Tem algo errado com o teste ou o built-in +~ faz isso mesmo?

Obrigado, Thilo.