ASM51

Boa noite a todos!
Estive pesquisando sobre geração de notas musicais na net e encontrei um projeto interessante.
Depois de varias tentativas em rodar o programa que é Open source,acabei desistindo parcialmente do mesmo.
Alguém já viu esse projeto?
Se alguém quiser me ajudar,eu agradeço.
ribeiro220.
site em inglês
http://www.pic24.ru/doku.php/en/osa/art ... _osa_piano

traduzido para portugues.
https://translate.google.com.br/transla ... t=&act=url

Eu quero tambem, mas um som de Orgão, o problema são as teclas, pra gerar tudo isso de tecla precisa multiplexar. Mas a aceitação do usuario seria teclas moveis e pedaleiras, ai sim dificulta. Mas gerar os tons é facil, existe até exemplos disso na net.

Alexandro escreveu:Eu quero tambem, mas um som de Orgão, o problema são as teclas, pra gerar tudo isso de tecla precisa multiplexar. Mas a aceitação do usuario seria teclas moveis e pedaleiras, ai sim dificulta. Mas gerar os tons é facil, existe até exemplos disso na net.

Alexandro,multiplexar da pra fazer nas entradas do pic,não precisa ser o exemplo citado e pode ser teclados com lâminas,o interessante é que fazendo rodar o programa e entendendo o mesmo,dá gerar tons e timbres diferentes como sons de violino,flauta e outros...
Voce gera senoides,dente de serra e quadrada que seria apropiada para sons de órgãos.

Na miha opiniao, pra ficar realistico teria de ter vários timers disponiveis no uC. E pra cada um, a saída deveria ser multiplexada por hadware, mas aí o filtro de saída e o ganho iriam variar conforme o tom. Já usei um uC da Texas (MSP430F149) que possuía 7 timers, mas creio que nem isso seja suficiente para essa aplicaçação, já que apesar de nao usarmos os 10 dedos simultaneamente ao tocar o piano, há o efeito da sustentação da tecla atravez do pedal, o que significa talvez na necessidade de mais de uma duzia de tons ao mesmo tempo. Nesse contexto, talvez o problema recaia num microcontrolador SoC, onde voce possa criar alguns recursos de hardware extra. Uma outra abordagem, mas agora mais profissional seria com a utilização de um DSP, mas aí o buraco seria mais embaixo, pois tudo teria de ser feito matematicamente em algoritmo. Enfim, se quizer algo bom, vai ter de suar mais um pouco.

Vale mesmo a pena se ralar tanto prá sintetizar sons num PIC, ao invés de usar ele como interface midi prá um sintetizador em software? Eu sei que tem toda a diversão de produzir os sons, mas... é muito pouco provável que consiga algo que chegue perto de um sintetizador em um PC. Sei lá, só uma opinião...

Usando um simples MCU, não sei se ficaria bom como um teclado normal, devido a varias limitações dadas como exemplo pelo Andre_teprom.
Eu já consertei alguns teclados antigos da decada de 60/70, fabricados no Brasil. O teclado mais antigo, para cada tecla havia um circuito gerador de tom com transistor, capacitores, resistores e bobina, depois havia outros circuitos para geração de efeitos e tremolo.
Um teclado da decada de 70 que reparei, tinha um circuito a transistor que oscilava a 2mhz, entrava em um circuito integrado divisor de frequencia dedicado que gerava as frequencias mestres para as cinco oitavas do teclado. Para cada oitava/tecla havia um outro divisor de frequencia cmos para gerar os tons.
Já reparei até teclados com CPU Z80, que tinha função para gerenciar os comandos e não gerar os tons das teclas, que eram produzidos por uma placa repleta de circuitos operacionais e varios filtros.
O problema que vejo é acionar teclas em simultaneo, por exemplo formando uma triade. Num teclado normal, há uma somatoria de tons gerando harmonicas, no teclado com um PIC ou oscilador simples, acho que não geraria o mesmo efeito..

Exemplo de um teclado antigo:


Exemplo usando um fpga:
http://jonphilpott.blogspot.com.br/2010 ... chive.html

fantastico este esquema eletrico!

André ,sim DSP seria muito bom,mas como disse é muito mais dificil,
Xultz a ideía com midi é muito boa e até andei vendo sobre isso talvez usando um raspberry mas vi comentários sobre latência ou seja a demora em se apertar uma tecla e o tempo que será emitido o som,porém é uma solução.
Norad58,obrigado pelo diagrama e o link do FPGA,também já pensei nisso.
mas vejam o que o cara faz com o programinha dele no PIC
https://www.youtube.com/watch?time_cont ... oic1seP8u8
Enfim agradeço-lhes pelas respostas.
ribeiro220

andre_teprom escreveu:Na miha opiniao, pra ficar realistico teria de ter vários timers disponiveis no uC. E pra cada um, a saída deveria ser multiplexada por hadware, mas aí o filtro de saída e o ganho iriam variar conforme o tom. Já usei um uC da Texas (MSP430F149) que possuía 7 timers, mas creio que nem isso seja suficiente para essa aplicaçação, já que apesar de nao usarmos os 10 dedos simultaneamente ao tocar o piano, há o efeito da sustentação da tecla atravez do pedal, o que significa talvez na necessidade de mais de uma duzia de tons ao mesmo tempo. Nesse contexto, talvez o problema recaia num microcontrolador SoC, onde voce possa criar alguns recursos de hardware extra. Uma outra abordagem, mas agora mais profissional seria com a utilização de um DSP, mas aí o buraco seria mais embaixo, pois tudo teria de ser feito matematicamente em algoritmo. Enfim, se quizer algo bom, vai ter de suar mais um pouco.

na realidade um unico timer para manter o data rate constante jah eh suficiente! veja este algoritmo gerador de tom ilustrado no apendice A deste paper da texas:

http://www.ti.com/lit/an/spra096a/spra096a.pdf

no caso do paper da texas, eles usam pares de geradores senoidais para gerar pares de tons que sao somados para gerar sinalizacao DTMF. e bom, eh facil imaginar que em telefonia usamos dezenas e dezenas de geradores DTMF em DSPs baratos para gerar e decodificar todo tipo de tom de sinalizacao. o interessante eh que o algoritmo consome muito poucos recursos, o que se traduz em um mar de tons gerados simultaneamente! outra parte interessante eh que sao todos gerados em um unico data rate, o que permite mixar diretamente eles para gerar resultados complexos de forma muito trivial!

basicamente, o gerador de tons trabalha com o seguinte algoritmo para cada amostra:

y[0] = a1*y[1] - y[2] + b0
y[2] = y[1]
y[1] = y[0]

onde vc pre-calcula no excel:

a1 = -2 cos(w)
b0 = A sin(w)
A = amplitude
w =2*PI*f/f0
f = frequencia da senoide
f0 = data rate
y[1] inicial = 0
y[2] inicial = -b0

assim, se vc tem N teclas com N frequencias diferentes, vc vai ter esses N conjuntos de coeficientes pre-calculados. a medida que as teclas sao ativadas, vc vai rodar o algoritmo gerador e ele vai gerar as amostras das respectivas senoides. todas as senoides sao geradas e somadas segundo uma soma ponderada, de modo que provavelmente vc vai ter:

- 1 multiplicacao + 2 somas p/ gerar a amostra de uma frequencia
- 2 copias de dados p/ cada frequencia
- 1 multiplicacao + soma por frequencia para fazer a soma ponderada

o resultado vai ser uma amostra que contem as amostras de todas as senoides somadas e isso vai para o seu DA ou PWM. se vc quiser, pode somar resultados de wave tables, desde que operado no mesmo data rate (existem tecnicas para adaptar o data rate de wave tables).

em termos de performance: sabendo que o cara tem 10 dedos, a composicao de uma amostra com os 10 tons requer 20 multiplicacoes, 20 copias de dados e 30 somas, totalizando 70 operacoes. com loops e controles, talvez chegue a 100 ou 150 instrucoes por amostra. o numero de amostras depende da qualidade desejada, mas supondo 16 bits x 44kHz padrao do CD, sao 44k x 150 instrucoes = 6.6MIPS. qualquer DSP de 20 anos atras ou microcontrolador fajuto de 16 bits que tenha multiplicacao em hardware dah conta de boa. evidentemente, somar 10 amostras de 16 bits vai dar um overflow em um microcontrolador de 16 bits, a menos que vc faca shift previamente. isso pode causar alguma degradacao de qualidade quando comparado a um DSP com acumulador grande, mas funciona. e claro, eh possivel fazer isso em um microcontrolador de 8 bits, as custas de performance para simular inteiros maiores e mais lentos ou as custas de qualidade para trabalhar com inteiros menores e mais rapidos. mas hoje em dia eu diria que qualquer ARM baratinho com registros de 32 bits faz isso com um custo muito baixo e com os pehs nas costas!

um bonus extra de implementar no ARM: vc pode testar todo o conceito matematico previamente no PC, rodando no linux, onde jah tem um acesso facil ao /dev/dsp rodando em 16 bits x 44kHz e compilador gcc. funcionando tudo certo, basta recompilar para o ARM, adaptar algumas firulas de IO e pronto.

Mas voltando as teclas, um orgão eletronico comum possui 2 teclados de 44 teclas e 13 pedals = 101 inputs !!!! Se multiplexar isso vai ter latencia com certeza, ou teria que dividir em 4 Mcu. Isso eu empaquei..

msamsoniuk escreveu:
...

o resultado vai ser uma amostra que contem as amostras de todas as senoides somadas e isso vai para o seu DA ou PWM. se vc quiser, pode somar resultados de wave tables, desde que operado no mesmo data rate (existem tecnicas para adaptar o data rate de wave tables).

....

eh possivel fazer isso em um microcontrolador de 8 bits, as custas de performance para simular inteiros maiores e mais lentos ou as custas de qualidade para trabalhar com inteiros menores e mais rapidos.
...

Estou trabalhando em um projeto que gera frequências tanto via DAC quanto via PWM, inclusive dual tones (DTMF) num AVR de 8 bits.

No DAC, com wave tables, se resume em 2 somas (da amostra wav e do indexador). Rodando a 2,5MHz com taxa de 10KHz numa boa.

Li os posts e não encontrei referência a questão da sensibilidade das teclas, nos teclados este recurso normalmente é dado pela velocidade ou força do acionamento, não imagino mecanica/eletrônicamente como é feito...

Alexandro escreveu:Mas voltando as teclas, um orgão eletronico comum possui 2 teclados de 44 teclas e 13 pedals = 101 inputs !!!! Se multiplexar isso vai ter latencia com certeza, ou teria que dividir em 4 Mcu. Isso eu empaquei..

como raiz quadrada de 101 eh aproximadamente 11, entao uma matriz 11x11 permite vc matar esse problema. e se, digamos, a cada amostra de audio processada a 44.1kHz vc testar uma tecla, vc vai ter 44100/101 = 436Hz de varredura. francamente, nao acho que 1/436 de latencia vai fazer alguma diferenca. mas se vc acha que faz, vc tem opcao de varrer o teclado inteiro a cada amostra: neste caso a latencia vai ser de 1/44100 e qualquer latencia menor eh indiferente, pq eh menor que o data rate do DA! note que isso eh o supra-sumo da precisao tecnologica em termos de teclado e eh indicado apenas para maquinas, aliens e seres capazes de pensar em microsegundos! profundamente inutil e um vasto desperdicio de performance, mas de qq forma, eh possivel e custa barato: se naquela conta de 150 instrucoes para o audio incluir o tempo de varredura de 101 teclas, vc teria 101 testes de tecla, digamos que cada um consome 10 instrucoes: (1010 + 150)*44100 = 52MIPS, bem dentro da faixa de trabalho da maioria dos ARMs baratos!

brasilma escreveu:Li os posts e não encontrei referência a questão da sensibilidade das teclas, nos teclados este recurso normalmente é dado pela velocidade ou força do acionamento, não imagino mecanica/eletrônicamente como é feito...

lembro vagamente de algo sobre isso de uns 30 anos atras e era calculado por um "envelope" que controlava o volume do tom: quando vc apertava a tecla, ele trigava o inicio do envelope e ele evoluia a medida que vc segurava, chegando ao volume maximo. entao, quando vc soltava, ele trigava o final do envelope e o volume ia caindo... eh facil ver que depende apenas da velocidade de ativacao e desativacao da tecla:



note os pontos em que a tecla eh ativada e desativada: quando vc ativa e segura a tecla, os tempos evoluem e o envelope muda. quando vc desativa, ele simplesmente cai ateh zero. e eh por isso a somatoria das amostras tem que ser ponderada: cada tom segue seu envelope particular que depende do momento particular de ativacao. o envelope, por si, eh conjunto de retas e curvas que eh multiplicada com a amostra do tom, onde por sua vez cada tom eh uma senoide calculada segundo aquele filtro que mostrei no outro post.

isso para um caso simples, com ondas senoidais. mas o envelope p/ uma wave table seria mais ou menos caso: vc teria a amostra periodica do instrumento ou voz e, quando ativa a tecla, ele comeca a despachar as amostras segundo o envelope.

Sam, o teclado matricial tem problemas quando você aperta teclas simultaneamente. No caso de um piano, não dá prá prever que teclas serão pressionadas juntas, então tem que ler cada uma de forma independente. Eu acho que dá prá fazer com shift register enorme, porque gastar 101 GPIOs é soda.

Quando a gerar um "velocity" baseado no tempo de acionamento da tecla, é um xunxo da pior espécie. O músico pode querer fazer um stacatto (ou seja uma nota bem curtinha) com um velocity alto (ou seja, alta intensidade sonora), ou baixo. Assim, tem que medir a força que a tecla foi pressionada, não tem jeito.


P.S. Eu usei uns termos difíceis só prá parecer que eu manjo muito de música, mas na verdade eu não entendo P**** nenhuma do assunto, mas ninguém precisa saber disso.