Pessoal vamos discutir aqui o trabalho.
Então, não entendi. Tem de fazer o que no trabalho?
Galera, vamos dar um, gás aí, que se deixar pra última hora, estamos fritos.
Pelo que entendi, vamos ter de fazer programinhas que cumprem a função daqueles [+~], [*~] e um [osc~]. Tô começando já. Parece que dá um pouco de trabalho.
Oi, Alexandre!
É isso aí, além desses tem também um parecido com o [rms~]. Especificamente, vocês terão que entregar um zip/rar/tar contendo 4 arquivos: soma~.pd, multiplica~.pd, oscila~.pd e amplitude~.pd. Não é necessário entregar arquivos de teste desses objetos, como eu expliquei vocês podem até compartilhar os arquivos de teste aqui no fórum (sem incluir aqueles 4 objetos)
Realmente este trabalho dá trabalho, e foi por isso que dei 3 semanas para ele. Para facilitar, o enunciado já tem mais ou menos a forma de um roteiro, e dá para ir implementando os objetos na ordem do enunciado. Mas quem deixar para a última hora provavelmente descobrirá que não dá mais tempo. Então não percam tempo, ainda é factível para quem começar hoje...
Bom trabalho!
Marcelo
Olá professor,
nos meus patches, bastante código está sendo reutilizado ( = copiado). O multiplica~ é quase uma cópia do soma~ e várias funções de contagem e seleção são reutilizadas nos outros patches também.
Podemos usar abstrações e entregar mais de 4 arquivos no diretório?
Eu tentei implementar as entradas e saídas e o tratamento de sinais da soma.
Mas como posso testar? Não sei se o que estou fazendo está certo...
Não entendi também como usar os vetores. São aqueles que parecem gráficos?
Se forem esses acho que estou no caminho certo. O problema é que não sei o
quê enviar para eles.
E o PD trava o tempo todo, isso é normal?
Oi, Shayenne!
Os vetores têm exatamente esse nome no Pd em português (estão no final do menu Inserir), e no Pd em inglês se chamam arrays. Você envia informação para eles com o objeto [tabwrite], e obtém informações deles com [tabread]. Leia o help desses objetos para ver como funcionam os inlets e outlets.
Para testar, há várias alternativas: você pode por exemplo colocar um "bang de depuração" no patch, que varre exatamente uma vez os índices dos 3 vetores, calculando o que se pede. Aí você pode inspecionar o conteúdo desses vetores, seja de forma aproximada (visualmente), seja acessando os valores armazenados (clicando no vetor, em Propriedades e depois Abrir visualização em lista). Isso facilita muito a depuração, que seria bem mais difícil com um [bang~] forçando o patch a recalcular tudo o tempo todo.
Outra alternativa é usar o ouvido (ele ajuda muito). Por exemplo, crie um patch que some (com [+~]) duas senoides, digamos [osc~440] e [osc~ 660] e preste atenção no som; o objetivo é que o som seja exatamente o mesmo com [+~] e com [soma~].
A preocupação com a adptabilidade do patch a diversos tamanhos de bloco pode ficar para um segundo momento, depois que a [soma~] estiver funcionando bem com o bloco default. Aí o jeito de testar seria criar um subpatch e colocar lá dentro a geração e a soma das senoides junto com um [block~] (o qual você pode configurar mandando mensagens do tipo |64< ou |2048<), e deixando no superpatch apenas a conexão com o [dac~] ou [output~] (pois esses ultimos só funcionam com o tamanho de bloco default).
Quanto ao Pd travar, isso indica que seu programa está entrando em loop. Provavelmente você verá umas mensagens de stack overflow (no console do Pd) ou daquele pd-watchdog (no shell). Isso não é bug do Pd, mas do seu patch. Infelizmente não há um mecanismo de detecção automática de loops infinitos (isso equivale ao problema da parada...), então depende de você revisar o comportamento dos objetos que estão ligados e ver porquê o laço não termina. Os objetos [Uzi] e [until] são fáceis de gerar esse tipo de problema, não por bug deles, mas por que se eles não receberem as entradas no formato esperado a condição de parada deles poderá ficar vazia (algo como while (1)...).
Abraço,
Marcelo
Obrigada professor! Consegui resolver o problema do loop.
Montei um pacth que funciona, mas não do jeito certo...
O resultado não é um som aveludado como o [+~] mas um som cheio de ruídos.
Parece que está no tom certo mas não sei o que fazer quanto ao ruído.
Oi, Shayenne!
Esse problema que você relata acontece sempre ou só quando você experimenta com outros tamanhos de bloco? Pelo que você descreve o ruído pode estar relacionado com as bordas de cada bloco: verifique manualmente (em 1 bloco só) se a sua varredura do vetor está realmente completa (índices de 0 a 63 no bloco default) e também se o resultado da soma está alinhado com os índices da entrada. Qualquer uma destas situações, se não estiverem corretamente implementadas, gerarão descontinuidades a cada bloco, o que certamente será percebido como um ruído possivelmente (mas não necessariamente, pois pode haver espalhamento em todo o espectro) próximo da frequência de 44100/64 ~= 689Hz.
Estou fazendo apenas com 1 bloco de tamanho 64. O contador atribui os índices para os três vetores simultaneamente. Os resultados das somas inicias e finais estão errados, mas não sei porquê, sendo que todas as operações acontecem da mesma forma
.
OK, então isso me dá o ensejo para uma das características do Pd que confunde muita gente no início, e que pode estar na raiz do seu problema. Ela tem a ver com a ordem que as informações trafegam pelas "cordas" que ligam os objetos, e a semântica dos patches.
A primeira coisa a se entender é que se um outlet está ligado a vários objetos diferentes, a ordem de criação das conexões será considerada na execução, isso é, o primeiro ramo a ser executado será o primeiro ramo a ter sido criado. Isso é uma situação confusa, pois visualmente no patch não dá para saber a ordem de criação das conexões. Por isso, a solução elegante para *todas* as situações que requisitarem o envio de um valor para vários objetos é definir de antemão a ordem desejada na entrega destes valores, e usar o objeto [trigger] para separar as entregas e garantir a ordenação. Por exemplo, se um processamento exige que um objeto envie um número para o objeto A, depois um "bang" para o objeto B e finalmente o mesmo número para o objeto C, nessa ordem, então podemos enviar aquele número da entrada para um [trigger float bang float] (ou [t f b f]) e conectar as três saídas do trigger aos objetos C, B e A, respectivamente da esquerda para a direita (pois os valores produzidos pelos outlets seguem o padrão do Pd que é ao contrário, da direita para a esquerda). Outro objeto interessante mas que faz triagem da entrada de acordo com tipo é o [route].
Mas isso deve ser considerado junto com a varredura que o Pd faz do grafo das conexões, que é uma busca em profundidade. Ou seja, cada uma das saídas do trigger vai disparar um "subprocesso" que corresponde à sub-árvore ou sub-grafo começando no nó que recebe o valor (mesmo que esse subprocesso seja bem complicado, inclua laços e etc). Assim, tomando o exemplo anterior, temos a garantia de que todos os valores que precisariam estar computados pelo subprocesso A estarão disponíveis e atualizados quando o objeto B receber o seu bang, e o mesmo vale para os valores que são computados pelo subprocesso B quando o objeto B receber aquele número lá do início.
Especificamente no nosso trabalho se um [tabwrite] receber o valor a ser escrito antes de saber em que índice ele deve escrever, ele vai armazenar o valor no último índice memorizado, pois o inlet do índice é "frio" (não resulta em atribuição), enquanto o inlet do valor é "quente" (corresponde ao momento da atribuição).
Oi pessoal, estou no desespero, trabalhei hoje 14 horas no projeto e não consegui fazer quase que absolutamente nada... o que é desanimador, realmente estou com dificuldades.
Fiz um patch paralelo simples com o [osc~440] [+~][osc~660] = [output~] e ouvi o som. Aí fiz um [pd soma~] e estou no momento utilizando os mesmos osc~ para desenvolver o projeto por ora. No subpatch coloquei os inlets~ ligados direto aos tabsend~, cada um com seu respectivo vetor. Aí já começa um problema, pelo default de 64 as ondas não aparecem completas nos gráficos dos vetores, então redimensionei para tamanho 64. Não sei se vai ser necessário implementar para que o vetor mude seu tamanho automaticamente. Quando o block~fica em 4096, por exemplo aparece completo. Então tudo teve de ser mudado... pois para o loop pegar o tamanho 64, ao invés de 100, está com 64. Apesar de parecer tudo horrível, ainda assim parece que está funcionando porque o contador fica travado no 63, mas os valores oscilam entre -1 e 1... Aí eu não sei se fiz certo, na saída de cada vetor eu coloquei o tabwrite para o vetor3... Aí é o fim do mundo, porque fica numa constante nula e um som que nada tem a ver com o patch paralelo de teste, quando está no block 64. Só que se muda o valor do bloco de samplimpg, aí aparece a curva senoidal, só que quando fica acima de 64 não tem som nenhum. Tentei usar o tabread neste vetor3 e a leitura sempre dá 0. Se o programa fica desligado e eu faço uma varredura manual, aparece as variações, mas não quando está ligado. E eu parei aqui porque já não consigo mais andar. Se alguém conseguir vizualizar o que estou falando agradeceria alguma dica...
Olá, pessoal!
Antes de mais nada, uma dúvida existencial: apenas o Alexandre e a Shayenne estão fazendo o trabalho? Cadê todo mundo? Nenhuma outra dúvida em aberto? Nenhuma mensagem de ajuda daqueles que já resolveram o problema?
Bom, Alexandre, vamos à sua dúvida. Aparentemente um de seus problemas é com o tamanho do vetor. Ele deve ser alocado automaticamente sim, com o mesmo tamanho do bloco do superpatch, usando a estratégia de medição do enunciado. Ou seja, ele deve ser "sensível ao contexto" (se você utilizar o seu soma~ num contexto onde bloco=64, ele vai alocar o vetor com 64, se for outro tamanho, ele vai readequar o vetor).
Mas pra começar, antes de se preocupar com isso, você deveria ter criado os vetores já com tamanho 64 e depurar o patch até ele funcionar nesse contexto default. Pelo visto há um problema aí, pois você disse que as ondas não estavam aparecendo completas. Você falou algo sobre block~ que me deixou confuso: o soma~.pd não deve conter um objeto block~, ele deve trabalhar exclusivamente com o tamanho de bloco do contexto em que estiver inserido. Nenhum dos objetos que o trabalho pede para implementar deve usar o objeto block~, apenas os meta-exemplos de teste (aqueles que *usam* o soma~, etc) é que devem usar block~ para testar a adaptabilidade dos outros patches.
Para esta depuração preliminar, abandone o tempo-real e o som! Desligue o DSP do Pd e crie um "bang" manual que execute o laço de varredura dos vetores apenas 1 vez. Você pode "desenhar" com o mouse qualquer coisa nos vetores 1 e 2 que correspondem à entrada, e observar se a execução do laço (acionada com este bang manual) produz no vetor3 o resultado esperado.
Quando você falou que "acima de 64" não tem som nenhum isso já indica um outro problema, que você provavelmente está usando o dac~ e um block~ diferente de 64 no mesmo contexto. Isso não funciona, está escrito no enunciado, mas talvez não tenha ficado tão claro. Recomendo que você tente realmente primeiro fazer a coisa funcionar no block~ default, sem nenhum block~ em lugar nenhum. Só depois que isso estiver funcionando, aí sim você pode passar a testar com os block~, mas seu meta-arquivo de teste deverá ser estruturado em 2 níveis:
Nível principal: aqui você apenas cria um subpatch chamado [pd processa] por exemplo e conecta ele no output~ ou dac~. Este patch obrigatoriamente tem que usar o bloco default, ou seja, nem terá nenhum objeto [block~].
Nível secundário: dentro do subpatch processa você pode criar os osciladores que você vai somar, conectá-los ao objeto [soma~] (que está em um arquivo diferente), e jogar a saída em um [outlet~] (que é por onde o sinal produzido chega no nível principal). Aqui (e só aqui) você deve colocar o objeto [block~] e testar com várias potências de 2.
Se ao mudar o bloco no nível secundário do arquivo de teste resultar em barulho (agora sim, com o DSP ligado), você pode abrir o [soma~] aí mesmo a partir dessa implementação e checar se você adaptou os tamanhos dos vetores corretamente (você é o responsável por isso, a partir da mensuração direta do tamanho de bloco e de mensagens de resize aos 3 vetores).
Um problema que poderia aparecer no resize dos vetores, e que eu antecipei no enunciado para tentar ajudar, é que não é viável (e não faz sentido) redimensionar o vetor para o tamanho de bloco a cada bloco. Ou seja, antes de ligar o DSP, você pode verificar se o mecanismo de filtragem de valores repetidos para o tamanho de bloco está funcionando. A mensagem de resize só pode ser enviada no momento em que o tamanho de bloco muda, e depois os valores repetidos têm que ser eliminados.
Vamos ver se isso ajuda a sair do lugar.
Acho que consegui avançar e cheguei exatamente no mesmo problema da Shayenne. O som é diferente, parece que tem algum erro na soma dos vetores no vetor final. Eu simplesmente estou "jogando" os valores dos dois loops dos vetores 1 e 2 no vetor final, mas não creio que isso seja certo. Não tô conseguindo criatividade para solucionar isso. Por outro, acabei de fazer um teste com o patch da adição pura, o que parece é que talvez nem seja o problema da adição, talvez seja algum problema de frequência ou tamanho da amostra, porque dá uma impressão de "som quebrado", o ruído talvez seja decorrente desses gaps, eu realmente não sei. Quando tento aumentar o tamanho dos blocos ou fazer aquela jogada de [block~ 64 2] (no meu caso tô usando o switch)ou algo parecido também não está dando certo.
Não use [block~ 64 2], isso vai introduzir sobreposição de 50% entre os blocos, não tem nada a ver com o trabalho, só vai complicar a sua cabeça. Use apenas [block~ N] onde N é potência de 2.
Volte na resposta longa que eu dei para a Shayenne e leia tudo de novo com cuidado. Seu problema aparentemente ainda é na varredura do vetor e na ordem das operações, então ficar experimentando com blocos só vai te atrasar na realização do trabalho. Se você tiver qualquer outlet por onde esteja saindo mais de uma corda, re-escreva o que você queria fazer usando [trigger]. Se você tiver algum inlet onde entra mais de uma corda, tente re-escrever também sem isso. Antes de ter um patch legível (em relação à ordem das computações), nem faz sentido depurá-lo, pois o que você vê pode não corresponder ao que acontece.
Certifique-se antes de mais nada de ter entendido toda aquela discussão de [trigger] e varredura em profundidade da outra mensagem. Depois elimine qualquer block ou switch da sua implementação e faça a coisa funcionar com o bloco default. Isso é imprescindível para passar às demais etapas do trabalho (desenvolvimento incremental, conforme as dicas do enunciado).
Tirei o block~e o switch~e fiz o teste sem o DSP. Testei os vetores isoladamente e percebi duas coisas:
1) O primeiro elemento do vetor 3 não é o mesmo que o vetor 1 (o mesmo vale para o vetor 2), ao observar a lista. É como que se tivesse acontecendo o atraso de um elemento.
2) se eu dou um bang simultâneo nos vetores 1 e 2, o vetor 3 acaba ficando com o sinal somente do vetor 2, não parece haver uma "soma de sinais".
Você está usando [trigger] para ordenar a sequência de leituras e a escrita da soma? Se não estiver, está errado.
Acho que o trigger não vai ser um problemão, mas o que acontece é que o tabwrite tá escrevendo uma sequencia de 1 a 63 no vetor 3, quando na verdade, deveria escrever de 0 a 63, realmente estou batendo cabeça nisso... Ou será que o trigger tem a ver com isso?????
Isso pode ter sim a ver com o trigger. Mesmo sem saber qual mecanismo você está usando para gerar os índices (pode ser counter ou outro mecanismo mais explícito), é você o responsável por garantir que a sequência começa mesmo no zero. No caso do [counter] em particular, o primeiro bang por default envia 1 e não 0, então ao invés de mandar 64 bangs pra ele, é necessário mandar primeiro um 0 para o 3o inlet (que seta o valor em 0 e não produz nada na saída) e depois 64 bangs no primeiro inlet. Pra isso o [trigger] é o mecanismo natural.
Consegui resolver o problema dos valores, coloquei uma mensagem de 0 e com o trigger dei um bang nele e depois, por ordem, no contador. O sinal sai perfeito, inclusive em áudio. Agora vem o segundo problema que é o vetor final. O que acontece é que um sinal tá matando o outro e não tá adiantando usar o trigger com um bang na frente do outro, ou simultaneamente.
Deu certo,hahaha, se realmente é isso!!??? Eu estava com dois contadores e dois tabwrite. Aí usei um único contador e usei o sinal de [+ ] para adicionar o resultados dos vetores. O sinal adicionado então vai em sequência certinho para o vetor final que tá dando os resultados coerentemente, se é que é assim que se faz.... Da mesma forma é com o multipl~, ou seja não precisa fazer nada demais a não ser multiplicar os valores lidos pelo tabread. É assim mesmo que se faz? Porque até com os osc~ tá dando certo.
Se a questão da do soma~e multiplica~ já parece estar resolvida, agora vem a questão da unidade geradora osc~.
Pelo que entendi, a gente vai pegar aquela fórmula e jogar em algum lugar e produzir algum vetor?? Mas aí, como serão colocados os valores das variáveis? E onde será colocada essa fórmula? Vai ter de fazer alguma coisa parecida com um vetor? tipo, a fórmula vai jogando valores em alguma tabela que será lida e gerar uma forma de onda? Dessa vez realmente não sei por onde começar...
Oi, Alexandre!
Leia com atenção a parte do enunciado referente ao oscilador. É outra vez um laço simples, só que dessa vez existe uma variável (objeto [float]) que armazena a fase, e memoriza as fases entre um bloco e outro. O sinal de entrada representa frequência instantânea (e não amplitude como em um sinal de áudio normal), que entra na fórmula da atualização da fase. Aqui a ordem de realização das contas será um fator crucial, assim como saber quando usar os inlets frios e quentes, por exemplo para atualizar apenas ou para "empurrar para a frente" o valor da variável.
Pelo que entendi, vamos começar com um fi(n-1)=0 e posteriormente os outros fi´s serão armazenados no float que entrará num laço que enviará os valores para o cos do y.
Mas aí, já estou com problemas iniciais, porque o x[n] é um sinal(??), mas desse sinal a gente só precisa da frequência dele, existe algum objeto para capturar apenas a frequência? Com snapshot~ funciona? Porque não parece funcionar.
A outra questão é com relação ao cos~, este objeto parece que já manda cos de 2pi(vezes outro valor) para o tabwrite, isso causará algum problema? Em contrapartida tem o que parece ser uma alternativa que é o expr~ cos($v1), que pega o vetor (ou o valor numérico) e joga no cos, mas aí já não sei se os valores que o cos dessa expressão está sendo multiplicado ou não por 2pi (e eu acredito que não, mas não encontro documentação).
Por fim, a operação com o mod é a expressão da esquerda que será divida pelo 2 pi mesmo? (o que dará como resto o valor que irá para o cos).
Alexandre, leia de novo o enunciado inteiro. Você não pode usar nenhum desses objetos com ~, e na realidade eles não serviriam para nada. O sinal da entrada já possui valores de frequência, você não deve "computar" nenhuma frequência a partir desse sinal. Para fazer um teste nessa entrada você pode simplesmente mandar uma mensagem com a frequência desejada (por exemplo 440) para o inlet (a partir do superpatch), ou então usando |440 < →[sig~] no lugar do inlet (para depurar é ok usar o sig~).
Ainda no OSC~
- Realmente, por enquanto estou mandando mensagens numéricas e deixei de usar os objetos "~".
-Não sei se estou fazendo certo, mas ao usar o objeto MOD, a resposta é um valor numérico entre 0 e 5 (pois a divisão é por 2pi= aprox 6.28). Isso quer dizer que, de acordo com a fórmula, será um cos de entre 0 e 5?? ou é pra multiplicar a expressão pelo mod?? O Mod do Pd , na verdade, dá como resultado um resto. Mas se eu for somente fazer as contas do mod do texto, os 2pi se anulam e dá alfa menos alfa que dá 0. Então não tô entendendo. Mas se for multplicar pelo Mod do Pd, qual seria a outra entrada, o dividendo? Pois o divisor é 2pi. Por enquanto estou deixando como dividendo exatamente o que está entre parênteses e o diviso está sendo o 2pi. O resto tá sendo o fi.
- Em seguida tô pegando o fi e jogando o resultado no sig~. Como benchmark sempre uso osc~440, mas meus sons não estão batendo e não tá aparecendo nenhuma senoidal no meu vetor. É assim mesmo?
-O que acho engraçado é que do meu projeto, o sig~ dá algum som, mas quando ligo direto um |440< --> sig~ num outro patch para teste (o que faz com que eu use ainda o osc~440) não dá som nenhum. É isso mesmo?
O valor da expressão com mod é um real entre 0 e 2π, e não um inteiro entre 0 e 5. Não use o objeto [mod] do Pd, o enunciado traz a dica de como implementar isso. Provavelmente você não entendeu o símbolo do "chão" em torno de α/2π (não tem como cancelar/simplificar nada ali). Você pode usar um objeto [i] para calcular esse chão, ou então usar a função int() dentro de um objeto [expr].
Sobre fazer som, espero que você não esteja tentando ouvir um sinal constante com valor 440. Isso realmente não é para ouvir, é apenas para alimentar o [oscila~]. Você só deve tentar ouvir a saída deste último.
Para quem quiser: esse vídeo explica o que o professor Marcelo falou da ordem dos bangs e de operação. Aconteceu um erro parecido comigo e consegui corrigir com ele
Professor, não achei uma definição simbólica de pi no Pd, qual a precisão que devemos utilizar?
Em resposta à Alexandre Batista
Re: Dúvidas - Primeiro trabalho maior
por Carlos Eduardo Elmadjian -
Olá, professor! Tenho mais algumas dúvidas para confirmar se a minha implementação está correta:
1 - No patch [amplitude~], está subentendido que M sempre será passado como parâmetro e que não podemos fazer pressuposição sobre seu tamanho? Implementei dessa maneira...
2 - Ainda nesse patch, vamos supor que estejamos recebendo uma senoide y = A sin(2*PI*f*t) pelo [inlet~]. Está correto afirmar que o valor RMS calculado só poderá ser algo em torno de A/sqrt(2) (como em [rms~]) se o tamanho da nossa janela amostral coincidir com o tamanho do período do bloco lido?
3 - No enunciado é dito que os objetos devem se adaptar ao tamanho do bloco N. Presumi que em cada patch deveria estar implementado um mecanismo para alterar o tamanho desse bloco e fazer os objetos envolvidos se adaptarem à mudança. Era isso mesmo?
4 - Não vi menção alguma no enunciado sobre exigência de documentação para esse trabalho. Isso significa que devemos entregar só os 4 patches pedidos?
Olás!
Nicolas: você pode obter uma aproximação razoável de pi pelo objeto expr (por exemplo 4*atan(1) ou acos(-1)).
Eduardo: 1 - É razoável pressupor que M é um inteiro >=1, sendo um parâmetro de criação do objeto (e não um inlet que pudesse ser alterado dinamicamente). 2 - Sim! Aquela estimação que fizemos considerava que a janela de cálculo do RMS continha um número inteiro de ciclos completos da senoide; especialmente para frequências muito baixas (onde cada ciclo contém muitas amostras) o desvio em relação àquele valor de referência pode ser enorme. 3 - Sim, mas essencialmente essa adaptação se refere à alocação de memória do tamanho dos vetores, pois os demais objetos de DSP utilizados (e.g. [tabsend~]) já se adaptam automaticamente ao tamanho de bloco do superpatch. 4 - Documentação é algo importante em qualquer código computacional; talvez você não devesse esperar ela ser exigida. De todo modo, não é necessário entregar nenhuma documentação externa ao código, basta explicar sucintamente em comentários no patch o que está sendo feito.
Obrigado, professor!
Sobre a documentação, eu concordo inteiramente com você, claro
Eu estou distinguindo o primeiro bang dos seguintes para medir o tempo do ciclo e calcular o número de amostras. No primeiro, eu uso como tamanho do vetor um valor constante inicial, nos seguintes eu uso o tamanho calculado.
Porém, quando o DSP é desligado e religado, o primeiro ciclo vem com um tempo muito maior que o correto.
O PD oferece algum trigger quando o DSP é ligado que eu possa usar para distinguir o "primeiro" bang que receber do bang~ depois de religar o DSP?
Oi, Alessandro!
Você pode usar um [r pd] para receber todas as mensagens que chegam ao Pd, inclusive as de ligar e desligar o dsp. Há muitas maneiras de fazer a triagem destas mensagens, por exemplo, [r pd] --> [unpack s f] --> [sel dsp] --> [f] onde o inlet frio do último [f] recebe a 2a saída do [unpack sf].
Quanto à preocupação de modularizar as implementações usando abstrações adicionais, embora isso faça muito sentido, do ponto de vista de distribuição dos objetos implementados isso seria bem ruim, pois forçaria um potencial usuário desta biblioteca a ficar carregando arquivos que ele nem sabe para que servem de um diretório para outro junto com as implementações de interesse. Se estivéssemos escrevendo externals essas coisas estariam devidamente encapsuladas, mas em patches esse encapsulamento vem às custas de redundância no código. Paciência!
Marcelo
Olá professor!
Estou tentando corrigir o mesmo erro do Alessandro (primeiro(s) bang~ com número de blocos extremamente alto).
Fiz com que na primeira, segunda e terceira vez que se recebe o bang o objeto troque o número gerado por um ideal. Mesmo assim, o pd continua travando quando se inicia o DSP já com as conexões no objeto multiplica~ e soma~. Tem alguma forma de corrigir isso, ou posso só deixar indicado para ligar o DSP antes de se instanciar ou conectar os objetos?
Oi, Antonio!
Pedir para o usuário construir (ou carregar) o patch apenas depois de ligar o DSP não parece muito razoável.
Acredito que a solução do seu problema seja a mesma que eu indiquei na resposta ao Alessandro (http://paca.ime.usp.br/mod/forum/discuss.php?d=25980#p75236). Ou seja, dá para controlar muito bem o que acontece quando o DSP é ligado ou desligado.
Em resposta à Alexandre Batista
Re: Dúvidas - Primeiro trabalho maior
por Vito Romanelli Tricanico -
Ainda não entendi como redimensionar o tamanho do bloco no subpatch da [soma~] e [multiplica~]. A soma está dando certo, o resultado no array está corretamente sendo somado, o problema é que quando vou reproduzir o audio, aparece uns ruídos bem estranhos (possivelmente aliasing), e sei que ta relacionado como tamanho do [block~] (pois quando o vario, os ruidos mudam) no subpatch, mas não sei como redimensionar como o professor sugeriu no enunciado do trabalho. Alguém ai pra me explicar?
Oi, Vito!
Você pode decompor o seu problema em 2: crie uma mensagem de redimensionamento manual para os seus vetores, por exemplo
|;
vetor1 resize 1024;
vetor2 resize 1024;
vetor3 resize 1024;
<
Veja se acionando isso manualmente o resto dos objetos funcionam e o som sai direito como deveria. Se não sair, isso indica que você tem algum outro problema na implementação independente da realocação (por exemplo, alguma condição do laço que só funciona para blocos de 64 amostras).
No momento que o redimensionamento manual estiver funcionando, aí você vê aquele outro mecanismo, que é de medir o tamanho do bloco com um [timer]. A parte de eliminar valores repetidos com [sel] também pode ser testada independentemente (por exemplo, coloque um [print] e vá mandando mensagens com valores alternados e/ou repetidos, checando que na saída não podem aparecer dois prints com o mesmo valor seguido.
O pior é que o ruído aparece com o block~ para 64 amostras junto com meus sinais. Percebi que os sinais não aparecem completamente nos arrays, eles são cortados. Se eu mudo o tamanho do block~ o ruído(um ruído bem agudo) continua, e meus sinais não saem. Fiz uma mensagem para cada vetor com os valores acima como sugeriu, e enviei um bang a elas, era isso? Pois não funcionou, não sei se fiz correto. Tem algum patch exemplo que eu poderia ver essa história de bloco, porque isso está me confundindo, mesmo no livro do Miller Puckette.
Vito,
se o som não está saindo direito com B=64, não é muito produtivo você já estar testando mudanças de tamanho de bloco... seria importante deixar o som perfeito com B=64 para só depois ver o que precisa adaptar com blocos diferentes. De fato o código da soma é o mesmo independentemente do tamanho de bloco.
O exemplo do Pd que mostra redimensionamento é o 15.array.pd. Aquela mensagm você pode clicar com o mouse em cima dela (em modo de execução, não edição), e já deveria funcionar (você veria o resultado abrindo as propriedades do vetor).
Quanto aos testes com tamanhos de bloco diferentes, lembre-se que os [block~] não devem estar junto da soma, mas no patch de cima. Dê uma reolhada nas mensagens anteriores aqui do fórum que falavam sobre como construir os patches de teste.
Agora redimensionei o número de iterações no meu loop para 64. O audio está perfeito, se comparado com os objetos nativos. Porém redimensionei meus vetores para 64 também. Não tinha entendido que o tamanho do vetor tem que ser o tamanho do bloco. Está certa esta conclusão?
Sobre contadores:
Por mais simples que eu consiga deixar meus contadores (muito parecidos com os exemplos 2.6 da documentação), eles dão stack overflow com um N próximo de 200 quando são implementados com retroalimentação (recursivos). Eu só consegui pensar em um jeito iterativo usando o metrônomo, e nesse caso eu teria que setar a frequencia a priori, o que não parece muito correto.
Existe um jeito melhor de eliminar esse tipo de stack overflow ou eu posso deixá-lo assim mesmo?
Estou com um erro recorrente no soma~ e multiplica~ ambos saem uma saída também com ruído, bem similar a +~ e +* mas ainda assim distinta, talvez seja pelo fato de estar usando um metro N/44.1. Mesmo com testes em 64 amostras, a atualização deve ocorrer neste tempo de 0..63. Estou atualizando a posição no vetor no momento que calculo e já mando pra saída, acho que isso causa um problema de atualização excessiva e traz esse erro, se dividindo 2 o resultado da soma ou multiplicação, o som melhora um pouco apesar de aparentemente não ser este objetivo nestes dois patches dividir os valores do som resultante?. Segue um gif dos gráficos dos vetores. Talvez o tabsend~ dos inlets não esteja acompanhando a frequência da atualização que acredito seguir o especificado.
Igor (e Alessandro também),
usar [metro] nesse trabalho não é uma boa estratégia. Não há nada que precise acontecer "sincronizadamente" dentro de cada laço (iniciado pelo [bang~]), e de fato o que queremos é que todas as contas sejam feitas o mais rapidamente possível, por isso é má ideia impor algum outro "ritmo" a essa computação (note que N/44.1 é fracionário, e uma representação imprecisa em ponto flutuante pode induzir um desalinhamento entre o [metro] e os blocos de fato).
Não entendo o que você chama de atualização excessiva, nem a relação da divisão por 2.
Sobre as interfaces gráficas, é importante mencionar que elas não são atualizadas a cada bloco, e nem a gente seria capaz de enxergar nada se elas mudassem a cada 1.5ms. De fato essa visualização não é mais do que um recurso visual para auxiliar a gente a encontrar algum bug maior. Elas são certamente mais úteis quando o DSP está desligado e nós controlamos o início do laço na mão (assim podemos verificar se de fato as contas estão batendo).
Alessandro,
parece que o Pd é chatinho mesmo com a pilha de recursão, não dá para empilhar milhares de chamadas recursivas. É por isso que existem os objetos mais específicos para lidar com contadores (until, Uzi, counter), que efetivamente produzem uma quantidade grande de bangs sob demanda sem sobrecarregar a pilha de execução. Faz totalmente sentido, não?
Dê uma olhada nesse patch em anexo, adaptado do 24.loops.pd, usando [until].
Ok! Vou dar uma olhada melhor pra ver se consigo remover a recursão dos contadores usando esses objetos.
Além disso, gostaria de comentar aqui que tentei implementar meu oscilador com o metrônomo (por ser mais simples, já que o oscilador independe de entrada) e não funcionou. Apenas alterando o gatilho para o bang~ (e dentro de cada ciclo, contando até o tamanho do bloco para totalizar a amostragem) funcionou sem problemas. Ou seja, melhor deixar o metrônomo pra lá mesmo
Consegui resolver os problemas com o soma~ e multiplicação~, creio que o mais difícil de perceber foi que estava testando no mesmo patch, e assim o sinal mesmo correto não saia com o mesmo áudio e por isto achava erroneamente ruidoso. E adaptei pra N e permitir este redimensionamento dos vetores, embora ainda funcione com 64 não sei como testar com mais amostras, e não entendi as respostas anteriores. Quando insero um objeto block~ < 1024 no superpatch mandando os mesmos osciladores osc~440 e osc~660 ele se ouvir no output~ sai o mesmo que se o block estivesse em 64.
Outra coisa as vezes aparece uns warnings de meus vetores.
warning: inlet1: multiply defined
Igor: esse problema do seu inlet é um erro mesmo, apesar do Pd chamar de warning. Dê uma olhada na primeira dica do enunciado que fala exatamente disso.
Alessandro: como assim o oscilador não depende da entrada? Quis checar pra ver se não teve nenhum mal-entendido aqui: a entrada do oscilador é um sinal que representa a frequência instantânea, que é atualizada amostra por amostra no laço através da leitura do vetor que veio do inlet.
Ops, me expressei mal.
O que eu quis dizer foi que o processamento acontece constantemente, sem a necessidade de uma entrada para que a próxima amostra seja calculada. Meu oscilador~ recebe sim uma frequência de entrada, porém salva ela em uma váriável dentro de um subpatch (por meio de um outlet "frio") e a utiliza a cada cálculo da próxima amostra.
É esse mesmo o comportamento esperado ou seria algo mais próximo de |440( --> |sig~| --> |pd oscilador~| ?
Não parece fazer sentido isso de armazenar a frequência em uma variável, dado que a frequência é um sinal (que deve ser enviada com [tabsend~] para um vetor). Rode este patch em anexo para ver como um oscilador pode gerar frequências instantâneas para outro oscilador. Este patch deveria funcionar com [oscila~] no lugar de [osc~].
Quer dizer que no nosso patch temos que enviar um sinal para o [oscilador~] usando [osc~]? Fiquei um pouco confuso agora,pois foi dito que não poderíamos usar osc~.
Em resposta à Vito Romanelli Tricanico
Re: Dúvidas - Primeiro trabalho maior
por Alexandre Batista -
Pessoal, desculpa o sumiço, mas por motivos pessoais tive de, infelizmente, trancar o curso e parar total todas as atividades...
Espero que consigam entregar o trabalho a tempo, e na medida do possível, vou acompanhando as coisas por aqui.
Obrigado ao professor e a todos.
De resto, força na peruca por aí!!!
abraços
Alexandre
Oi, Vito!
Nos patches de teste, que não serão entregues, você pode usar quaisquer objetos que desejar. Eu mandei aquele com [osc~] para vocês poderem ouvir o resultado sonoro e isso servir de comparação, afinal ele deve ter o mesmo resultado com [oscila~] (que pode ser trocado nas duas ocorrências). Aliás, quase daria para trocar também o [+~] e o [*~] pelas versões implementadas, teria que adaptar um pouco pois nossas versões não aceitam parâmetros de criação (como [soma~ X] ou [multiplica~ Y]).
No caso do [oscilador~] então, ao enviá-lo, envio apenas o subpatch [oscilador~]? Está me parecendo meio que um pleonasmo ter que usar um osc~ para um outro "osc~". Tinha pensado que eu deveria criar um sinal com cos ou sin, e enviá-lo a um vetor com tabwrite a uma certa taxa de alguma maneira.
Vito, não entendi a sua dúvida. [oscila~] não é um subpatch, mas uma abstração, encapsulada em um arquivo oscila~.pd independente dos arquivos usados para testar (que podem usar [osc~], [cos~] etc se você quiser).
Você não precisa enviar os arquivos que usou para testar seus objetos. A ideia é que eu posso encaixar qualquer implementação de vocês em um arquivo de teste que use os objetos [soma~], [multiplica~], [oscila~] e [amplitude~], e tem que funcionar.
Uau. Fiz o contador iterativo e ficou bem melhor. Sem mais stack overflows!
A princípio eu usei o sistema recursivo pois eu achei que esse tipo de metralhadora de bangs daria problema por "encavalar" as leituras e escritas, mandando o bang N+1 enquanto eu ainda estivesse lendo e escrevendo no índice N do vetor. A documentação do Uzi diz "Send a specified number of bangs as fast as possible". Pelo que eu tinha entendido sobre mensagens no PD o jeito "recursivo" esperaria que o bang "morresse" para só então mandar o próximo, enquanto o "as fast as possible" do Uzi poderia me trazer problemas.
Vou ler com mais calma as referências indicadas no enunciado pra entender melhor por quê o Uzi funciona.
Sobre o oscilador~: Eu não tinha me tocado que o osc~ também pode receber um sinal como entrada. Esqueçam o que eu falei XD
Esse "as fast as possible" quer dizer que os bangs sairão sequencialmente, mas todos terão o mesmo timestamp. Pela semântica depth-first, cada bang produzirá seu resultado (seguindo o caminho das mensagens e considerando que não haja loops) antes de começar o processamento do próximo bang. Mas todo o processamento de todos os bangs terminará antes que o tempo lógico tenha avançado, então tudo será calculado antes mesmo que se passe o tempo correspondente a uma única amostra de áudio, como se a computação fosse "instantânea".