Olá, pessoal!
Espero que todo mundo já tenha lido o enunciado do trabalho. Estou estranhando ainda não haver nenhuma dúvida... deixo aqui a thread aberta para isso.
Abraços,
Marcelo
Então... na verdade eu fiquei feliz de ter conseguido abrir o arquivo .wav na tarefa de terça pra quinta. Mas pra mim que tenho um viés de estudo Marxista na Economia, nesse segundo trabalho tô mais perdido que cego em tiroteio e não sei por onde começar, a não ser ficar lendo os helps...
E não tô conseguindo ouvir o som apenas do exmplo 5, é assim mesmo?? Os dos outros funcionaram perfeitamente
Oi, Alexandre!
Me desculpe pelo exemplo 05, totalmente minha culpa! Ele dependia de um subpatch (oscilador.pd) que não estava junto: na janela do Pd, ao abrir o patch incompleto, os objetos "oscilador" ficavam vermelhos e tracejados, e na janela do Pd aparece as mensagens "oscilador N ... couldn't create" (para cada oscilador N=1...10). Pra mim o erro não aparecia pois eu estava testando no diretório da minha máquina onde o oscilador.pd já estava presente. Isso mostra o quanto eu dependo do feedback de vocês. Baixe por favor outra vez do Paca e diga se funciona agora.
Quanto à sua pergunta anterior, se você já tinha feito tocar o arquivo wav, não há motivo para pânico. A dica é usar "baby steps" como dizem os americanos. Vou sugerir uma lista de pequenos passos incrementais, vários dos quais podem ser feitos independentemente uns dos outros:
1) implementar a abertura do menu para selecionar o arquivo e preparar a mensagem de tocar (isso é quase o pré-exercício que eu sugeri na 3a, e está descrito textualmente no enunciado). Ler o help do [key] e [sel] para ver como acionar esse mecanismo com a tecla "a" (para saber o valor de qualquer tecla, ligue um [print] à saída do [key] e aperte a tecla desejada - o valor será escrito na tela principal do Pd.
2) colocar os objetos que geram os dois tipos de ruído, e escutá-los separadamente (ligando-os ao [output~]) pra ver se estão ok. Eu recomendo o [output~] ao invés do [dac~] pois ele já vem com controle de volume e chave liga-desliga do processamento de sinais (DSP).
3) inserir o mecanismo de chaveamento entre os ruídos, lendo o help do [multiplex~].
4) inserir o mecanismo de geração da rampa de volume, lendo o help do [line~] e as dicas do enunciado. Para ouvir se esse mecanismo está funcionando, é necessário multiplicar [*~] a saída do ruído (ou do [multiplex~] se você já fez o passo 3) com a saída do [line~] e jogar esse sinal no [output~].
5) inserir o mecanismo de medição de nível do ruído ([rms~] e [rmstodb]). Para visualizar, talvez seja mais interessante usar um slider vertical (Ctrl-Shift-V). Como dica para a impressão do valor (que só deve acontecer no comando "p"), joguem os valores gerados no inlet *direito* de um objeto [float] (ou [f]). Isso funciona como uma variável, armazenando o valor sem produzir saída. A qualquer momento o valor dessa variável pode ser "produzido" no outlet dela enviando um bang para o inlet esquerdo.
6) inserir o mecanismo de atraso do início do ruído; esse passo pode ser quebrado em passos menores:
6.1) gerar o delta aleatoriamente com o objeto [random] (no enunciado eu me confundi e escrevi [rand], por favor corrijam). Liguem um gerador de bang (Ctrl-Shift-B) na entrada e um [print] ou caixa de número (Ctrl-3) na saída para visualizar o valor gerado. Não se preocupem que o valor gerado seja sempre inteiro... isso não estará em desacordo com o enunciado. Quem quiser gerar deltas fracionários pode gerar números muito grandes com [random] e ajustar a escala com outro objeto.
6.2) usar esse delta para atrasar um bang (Ctrl-Shift-B ou mensagem |bang<) lendo o help do objeto [del]. Esse bang atrasado deve ser ligado à mensagem que inicia a rampa de volume (descrita no enunciado).
Uma dica importante para o passo 6.2 e que servirá também para os passos abaixo é sequenciar ações através do objeto [trigger] ou [t] (leiam o help). Por exemplo, ao gerar o número aleatório delta ele deve *antes* ser usado para definir o tempo de atraso (inlet direito do [del]) e *depois* enviar um bang para o inlet esquerdo do [del]. Isso é feito fazendo o número entrar em um [trigger bang float] (ou equivalentemente [t b f]), que garante a ordenação dos disparos sempre do outlet mais à direita até o outlet mais à esquerda (portanto nesse caso primeiro o float da entrada depois o bang). Em outro exemplo, [t b b b b b] ao receber uma mensagem enviará 5 bangs sequenciados, pelos outlets 5, 4, 3, 2 e 1 (nessa ordem).
7) processar o comando "t" (selecionado da saída do [key]). Isso consiste em sequenciar (com [trigger]) o início das seguintes ações, implementadas em passos anteriores: gerar aleatoriamente o tipo de ruído (0 ou 1 no [multiplex~]), gerar o delta para dar início à rampa (dependendo da implementação isso pode ser uma única ação ou duas ações), disparar o início da reprodução do arquivo.
8) processar o comando "p". Isso consiste em sequenciar as ações: imprimir o valor atual do ruído em dB, imprimir o código do ruído utilizado (0 ou 1) e interromper a execução da música com a mensagem |0< ou |stop< para o [readsf~].
O trabalho consiste essencialmente nesses 8 passos. Como é nossa primeira experiência com essa linguagem, pode parecer muita coisa... o trabalho em si não é complicado, mas usar pela primeira vez uma linguagem ao mesmo tempo em que temos que resolver um problema específico pode ser uma sobrecarga.
Estou pensando em adiar a entrega do trabalho para 5a-feira até 12:00, considerando o fato de ser o nosso primeiro contato com a linguagem. Já vi que isso não vai atrasar nosso cronograma, e imagino que fará uma diferença positiva para quem estiver pensando em se desesperar. Mas tentem ainda assim terminar até 3a. Quem conseguir, terá esses dois dias adicionais para pensar em melhorar a inteligibilidade do patch (com documentação no código, melhor organização espacial, modularização em subpatches, substituir "cordas" entre objetos muito distantes por pares send/receive), incrementar a interface (oferecendo visualizações das coisas que o patch está fazendo), e conduzir o "auto-experimento perceptual" com mais calma, mais músicas, etc.
Abraços,
Marcelo
Professor,
No passo 5 o senhor sugere o uso dos objetos [rms~] e [rmstodb] para capturarmos o valor em dB do ruido,
porém não seria a mesma coisa se apenas utilizássemos um objeto [env~] ?
A estrutura do rms é um "[inlet] -> [env~] -> [dbtorms] -> [outlet]", logo, se eu não estiver errado,
a saída do [env~] já se encontra em dB.
E outra dúvida,
Ao invés de criar um número grande e depois ajustá-lo para que seja um
número fracionário entre 0 e 20, não é possivel apenas gerar um numero entre 0 e 20000
e passá-lo direto ao delay (simulando um delta entre 0 e 20000 milisegundos) ?
Olá, professor. Eu também fiquei com algumas dúvidas conforme fui desenvolvendo o patch, só que mais relacionadas ao enunciado:
1) Como devemos discretizar o tempo para o retardo da introdução do ruído e para o crescendo? Intervalos de um segundo estão ok?
2) O enunciado diz que quando pararmos a reprodução, devemos imprimir na saída padrão do PD o nível e o tipo de ruído. Existe uma formatação desejada para saída? Além disso, não precisamos mostrar o valor do ruído em dB também?
3) Na seção "dicas" do enunciado, você disse para conectarmos o outlet do [line~] a cada um dos inlets de um [*~]. Mas depois não ficou claro pra mim se era pra conectar o outlet desse [*~] a um dos inlets de outro [*~], agora em conjunto com o ruído ligado ao inlet sobressalente. Não sei se ficou clara minha dúvida, mas talvez parte dela esteja relacionada ao fato de não entender perfeitamente o que um multiplicador faz (embora consiga perceber o resultado)...
[]s
Olá professor!
É necessário utilizar aquele método de iniciar a execução do áudio ou pode-se realizar de outra forma?
O comando [rand] que você escreveu não realiza o que queremos, acho que o comando correto seria [random].
Outra dúvida, devemos por todos os sinais de saída em um mesmo lugar?
Olás!
Carlos Eduardo, em relação às suas dúvidas: (1) está OK sortear Delta com valores inteiros entre 0 e 30 (dê uma olhada na resposta longa ao Alexandre que enviei recentemente), ou aumentar a granularidade (por exemplo [random 10000]->[expr 20*$f1/10000]); (2) A saída não tem uma formatação especificada, mas o nível do ruído deve ser em dB (e não rms), conforme o enunciado; se você quiser converter a impressão do tipo do ruído de 0/1 (controle do toggle) para textos (banda-larga/banda-estreita) pode fazê-lo; (3) o que o objeto [*~] faz é multiplicar os sinais dos dois inlets amostra-por-amostra; digamos se as entradas fossem representadas por x[n] e y[n] a saída seria x[n]*y[n]; por isso quando o sinal é o mesmo (no caso os valores da rampa de volume entre 0 e 1) o resultado é elevar cada valor do sinal ao quadrado; e esse "controle de volume ao quadrado" precisa sim entrar em outro [*~], dessa vez para ajustar a amplitude do ruído (aqui um dos inlets recebe o ruído e o outro recebe a "rampa quadrática").
Shayenne, em relação às suas dúvidas: (1) você pode usar quaisquer objetos do pd-extended para abrir e tocar o áudio, basta que seu patch responda adequadamente aos comandos "a", "t" e "p"; cuidado que conforme a implementação talvez o comando "t" só funcione da primeira vez, e da segunda algum objeto reclame que você não especificou o arquivo a tocar (o [readsf~] por exemplo sempre exige uma mensagem |open arquivo< antes do |start<); certifique-se portanto que seu patch faz a coisa correta (uma única seleção do arquivo com o comando "a" deve servir para quantos "t" e "p" o usuário desejar); (2) era [random] mesmo, eu me confundi e avisei na mensagem longa dirigida ao Alexandre; (3) não sei se entendi sua dúvida, mas a saída de áudio deve ser encaminhada para o [output~] e deve produzir a cada comando "t" uma única execução do arquivo de áudio misturado com um dos dois ruídos (e não os dois ruídos juntos), que aparecerá tardiamente (após Delta segundos) e com amplitude crescente (quadraticamente entre 0 e 1 ao longo de 10 segundos). Note que ao mandar tocar o arquivo o ruído deve iniciar sempre com volume 0, e esse detalhe ficou faltando no passo (7) da minha sugestão de implementação incremental (ou seja, antes de disparar o início da reprodução da música, o objeto [line~] que controla a rampa quadrática deve receber uma mensagem |0<).
Abraços,
Marcelo
Professor, gostaria de saber se o ruído será executado apenas uma vez após o atraso sorteado, ou se repetirá em ciclos desse atraso e seu aparecimento do ruído até o término da música selecionada.
Outra dúvida é que meu console alerta stack overflow, mesmo funcionando será descontado nota pelos alertas?
Olá, estou tendo problemas na abertura do arquivo nos dois pds que tenho instalados tanto no win como no mac. eles não abrem o arquivo através do |readsf~| vem uma mensagem de erro dizendo que o header do arquivo eh desconhecido ou esta corrompido, ja testei com .wav, .m4a, mp3, e até com o arquivo sugerido pelo trabalho.
O que será que há?
Olás!
Igor: (1) a rampa de volume do ruído, após atingir a amplitude máxima, ficará nesse nível "para sempre" (isso é, até fechar o patch ou reiniciar a execução da música com outro comando "t", quando então a amplitude do ruído deve voltar a 0), mesmo que a música acabe; note que não é necessário fazer nenhuma ação em particular, pois o [line~] continuará enviando "1" até segunda ordem. (2) stack overflow indica um erro de programação, mesmo que o resto do programa aparentemente funcione. Ele é gerado por algum loop no seu programa; esses loops podem ser visíveis nas cordas que ligam os objetos, ou invisíveis no caso de sends/receives que fazem alguma informação recircular indefinidamente. Um loop em Pd pode ser pensado como uma recursão, e o stack overflow indica que a recursão não está detectando o último nível onde ela deveria parar. Alguns links úteis: http://puredata.info/docs/faq/stack-overflow e http://lists.puredata.info/pipermail/pd-list/2007-12/057872.html
Samuel: o objeto [readsf~] não funciona com .mp3 ou .m4a, conforme a documentação dele (apenas os formatos wave, aiff e nextstep são suportados); por isso no enunciado eu disse que a música sugerida teria que ser convertida para .wav. Pra facilitar, coloquei o arquivo já em formato .wav aqui:
e para testá-lo sugiro você abrir esse patch: http://www.ime.usp.br/~mqz/toca.pd. Esse patch toca.pd foi testado em linux e win. Se isso não funcionar, sugiro você rever suas instalações do Pd. Estamos usando o Pd-extended versão 0.43.4.
Abraços,
Marcelo
Boa tarde,
Professor consegui corrigir aquele erro, agora tenho outro alerta noise~: no method for 'float' no ruído de banda estreita, preciso fazer uma correção pra inteiro? Ainda assim funcionam.
Outra questão a rampa de volume segue a distribuição 1/20*1/20, 1/19*1/19 ... 1/1*1/1?
Se puder explicar novamente a questão do multiplexador agradeceria.
Abraços.
Olás!
Igor: se o noise~ está reclamando que não tem método para float, é porque você está tentando jogar um float dentro do noise~. Não é isso que o enunciado pede, dê uma revisada. Quanto à rampa, não entendi sua pergunta: os valores começam em 0 e vão até 1 ao longo de 20 segundos, portanto levaria 20*44100 amostras para chegar no valor máximo... mas a ideia não é gerar os valores intermediários na mão como você está tentando, e sim deixar o objeto line~ gerá-los para você. Sobre o multiplex, também não entendi sua dúvida: experimentar com os controles no help do objeto não foi suficiente?
Lucas: sim, você tem toda a razão, basta usar [env~] que o valor já sai em dB, é muito mais lógico (não lembrei disso quando escrevi o enunciado). Quanto à sua outra dúvida, é possível conectar o [random] no [del] de mil maneiras diferentes, inclusive da maneira que você propôs; é como em qualquer outra implementação, há sempre espaço para a criatividade e o gosto pessoal.
Abraços,
Marcelo
Miraculosamente estou conseguindo fazer o patch, com a ajuda dos steps... Mas estou com 2 dúvidas:
Primeiro, no caso do [*~], a gente coloca um em seguido do outro não é? Tipo [*~] ----> [*~] aí depois, a saída soma com o som da música [*~]-->[+~], é isso mesmo? Porque o que estou achando estranho é que quanto mais faz [*~] mais baixo o ruído fica, ou seja quase imperceptível... Tô fazendo alguma coisa errada???
A segunda questão é aquela que já foi discutida, tô usando o [readsf~] e realmente não dá pra tocar quantas vezes eu quiser apertando "t" ou desligar com "p", algum objeto para superar isso? É até ruim, pois depois que abre o arquivo, tem até de clicar no painel do PD, senão nem adianta apertar o "t".
E a pergunta bônus é saber por em que lugar do PACA a gente envia os arquivos.
Obrigado por ora e o exemplo 5 funcionou.
Consegui resolver a primeira questão, era só seguir o enunciado,haha.
Mas ainda gostaria de saber a respeito da primeira questão...
digo, consegui resolver a segunda questão das teclas que tocam e param, mas realmente estou preocupado com o fato do ruído diminuir, quando toca a música ao mesmo tempo nem dá pra ouvir, ou eu tô surdo já...
Oi, Alexandre!
Provavelmente você conectou os multiplicadores de algum jeito errado, e acabou elevando o ruído ao quadrado ou algo assim. Note que cada inlet deve receber apenas 1 sinal. A expressão que queremos definir é
música[n]+ruido[n]*(line[n]*line[n]).
Crie uma mensagem de teste com o conteúdo |1< e conecte-a ao [line~]; quando você clicar nessa mensagem (ou Ctrl-click em modo de edição) fará line[n]=1 na expressão acima e portanto você deve ouvir o mix da música com o ruído no volume original (ou seja, o mesmo nível que sai do [noise~]).
Quanto ao lugar de enviar o trabalho no PACA, vou criar isso mais tarde. Lembrem-se que o trabalho ficou para 5a às 12:00.
Abraços,
Marcelo
Descobri o erro! De fato era a questão da mensagem do line~. Eu tava colocando [0.1 20000], quando o que parece ser o correto é [1 20000]. Aí o ruído ficou bem mais nítido.
Acho que terminei o trabalho então,hahaha
Valeu!
Só para esclarecer, a mensagem |0, 1 20000< sugerida no enunciado são na realidade duas mensagens em sequência, uma que define instantaneamente o valor 0, e outra que faz o valor subir de 0 para 1 em 20000 milissegundos. Mas não era mesmo necessário mandar esse primeiro |0<, afinal isso era feito antes, logo que começava o início da música.
Professor, uma duvida meio besta:
influencia negativa do ruido eh quando comecamos a percebe-lo ou quando
ele parece reduzir o volume do som da musica?
Oi, Samuel!
Não acho que sua dúvida seja besta. Realmente não fui muito preciso, mas em descrições desse tipo sempre haverá um grande espaço para uma interpretação mais subjetiva. Eu pretendia dizer para pararmos (e medirmos o nível de ruído) no momento em que começamos a percebê-lo. De repente alguém pode achar que o ruído até melhora a música e portanto não há qualquer influência negativa...
Sobre se o ruído parece reduzir o volume da música, essa é uma observação interessante. Não sei se todo mundo percebe o efeito do aumento do volume do ruído dessa maneira (eu acho que eu não percebo).
Abraços,
Marcelo