Hexaswitch Handmades

[polyvox]

por partes....

- sobre o lance do Mute, deixa eu ver se entendi: quando entramos no modo "ediçao do preset" ficamos sem som nenhum ? ou isso é alguma funçao especifica do PIC que eu nao entendi ? se for a primeira opçao, ai ja nao é vantajoso. seria legal mao precisar apertar nada, acho que essaa funçao MUTE nao precisa nem ser implementada. os possiveis POPS seriam resolvidos de outra forma, com resistores nas saidas e entradas dos loops, por exemplo.

- sobre salvar os presets, eu insisto naquele lance de programar direto: aperta o botao PROGRAM , os switches ja viram toggles pra ligar ou desligar um loop cada, aperta PROGRAM de novo e ta salvo aquele preset naquele banco. sem aquela coisa toda de ter que selecionar um banco, depois o preset e só depois ativar ou desativar loops. assim fica bem pratico e intuitivo, fora que se abre a possibilidade de usar esse modo pra desligar ou ligar um loop momentaneamente.
 
- sobre o driver pros reles, vc tem razao. cada um deve escolher depois como fará os loops e tal.

- sobre o banco 0, bypass, etc. isso precisa ser decidido antes de fazer a programaçao final do firmware, nao? acho que podemos abolir essa ideia de banco 0 ser bypass fixo. assim todos os presets de todos os bancos disponiveis podem ser programados como o cara que for usar quiser.          

- sobre a questao da EEPROM (dos loops iniciarem ativados ao inves de desativados), eu nao entendo lhufas dessa coisa de programaçao , entao eu vou perguntando baseado na parte funcional da coisa mesmo, pensando em como seria mais funcional pro cara que estaria la no palco usando o looper. as ideias que vou postando aqui são justamente pra saber se seriam possiveis de serem programadas e assim tenhamos uma versao final de firmware 100% funcional e pratica.

- esse esquema de gravador é JDM mesmo ( acho  hehehe ) . é um projeto pronto, pelo que eu entendi, é só montar o circuitinho bem simples e gravar com o programa especifico via cabo e porta serial do pc.


A ideia já evoluiu bastante ... a questao do circuito parece ja praticamente resolvida, falta a fonte que os colegas ali estao discutindo uma melhor forma ... e ai é fechar um firmware 100% e partir pros testes praticos ( construir o prototipo do "monstro" ) e ver se funciona mesmo.
O negocio agora é a gente chegar num firmware "final" , redondinho e ai partir pros testes.


Confesso que esse rojeto me fez pesquisar um pouco sobre os PICs e fiquei fascinado com o poder desse treco. _
Já andei até assistindo aulas sobre o basico de programaçao em assembly e tal ( entendi porcaria nenhuma.. _) . É um assunto bem interessante. Provavelmente eu nao me aprofundarei nisso, mas é bem legal ver como é que funcionam as coisas e tal.
Se você não tiver nenhuma oposiçao, talvez possa me mandar o codigo fonte pra eu entender como é que a coisa funciona e estudar pra ver se levo algum jeito pra isso.
PICs podem ser bem úteis pra gente buscar soluçoes dentro dessa área de equipamentos musicais nacionais.

 




-----

Boa noite!

acompanho este tópico pois muito me interessa o assunto, apesar do limitadíssimo conhecimento. Inclusive lá no tópico do pentaswitch do pedrone postei alguns materiais que pesquisei sobre o assunto na época.

Agora uma coisa sobre o bypass que veio na cabeça, não sei se não foge muito do que o pessoal tem em mente de produzir, mas não custa mencionar: Não seria uma solução colocar uma 3DPT antes de todo o circuito, e fazer um bypass de tudo, como de um pedal?

abraço

essa seria a soluçao pra fazer um MUTE/TUNER. Ou seja, um desvio de sinal logo apos a entrada pra mandar pro afinador externo, por exemplo.

[Bruno Lucca]

Bom pessoal, redesenhei o esquema da fonte e acho que agora está melhor de visualizar, separei bem os terras analógico e digital, unindo-os apenas no capacitor de filtragem principal. Segue abaixo o esquema redesenhado:

Spoiler (clique para mostrar ou esconder)

Layout (ficou com 89mm x 30mm):

Spoiler (clique para mostrar ou esconder)

E uma visão em 3D para ter uma idéia de como fica a montagem

Spoiler (clique para mostrar ou esconder)

Não seria melhor fazer zonas ou grandes planos ao invés de trilhas somente ?  Eu peguei o seu layout e redesenhei no paint mesmo:

Coloque furos para prender a placa ao chassis com espaçadores ou parafusos (nos cantos ?)

Os reguladores terão dissipadores presos a eles e demandam mais espaço na placa e distância dos componentes que estiverem perto. Já dimensionou o tamanho, forma e resistência térmica dos dissipadores pra aguentar a potência que será dissipada neles ?

Eu gosto de usar bornes KRE ou no caso conectores para cabos (tipo de placas mãe) pra facilitar a conexão dos fios de força e da fonte, ao invés de soldar fios.

Também acho queo layout ficaria melhor com zonas, tipo aquelas "manchas" com os furos para os componentes. O problema é que não consegui fazer isso no Proteus de maneira satisfatória, se alguém que souber puder me ajudar em como fazer isso eu faço as mudanças.

A questão dos espaçadores para prender no chassis, acho que fica melhor deixar a critério de cada um na hora de montar. A placa tem um espaço nos cantos suficiente para se colocar espaçadores, ou parafusos de tamanhos variados, então eu acho melhor deixar que cada um escolha como quer fazer.

Eu modifiquei a colocação dos reguladores, agora há espaço suficiente para os dissipadores. Quanto ao dimensionamento, na verdade eu nunca fiz cálculos para escolher o dissipador, sempre uso uns dissipadores que compro aqui na minha cidade e dizem ser próprios para reguladores. Como nunca tive problemas nunca me atentei para isso.

Eu coloquei no layout furos para encaixe de bornes de 2 e 3 vias KRE, para conexão dos fios do transformador e das saídas de 5 e 12 V. Assim pode-se escolher entre usar o conector ou soldar os fios na placa.

Seria bom inverter os capacitores de 10uF e 100nF na saída, ficando os de 100nF conectados aos reguladores e em seguida os eletrolíticos. Os caps. de 100nF ficam, o mais próximo possível dos reguladores para evitar oscilações.
O regulador 7812 está com o dissipador pra dentro da placa, não seria melhor inverter a posição, assim os dois reguladores ficam com os dissipadores para fora.

Fiz isso nesse novo esquema.

Ah pessoal, sobre a fonte em si..... precisaremos de +5V e de +12v ( e de +9V t b (moderador, peço que me suspenda do fórum) se quiserem colocar um buffer no input) , mas isso a gente pode regular com 7805 na propria placa do circuito. (que nao sera grande, pelo que andei pesquisando).

Entao seria legal termos uma boa fonte estavel e ai a gente regula na entrada do circuito do foot mesmo. "roubei" isso do projeto desse italiano maluco que mencionei acima e funciona perfeitamente.

Se eu estiver falando besteira me corrijam, mas no caso de colocar um buffer (com op-amp) no switcher, não seria possível alimentá-lo com 12V?? Assim não precisaríamos de 9V na fonte  só para isso.

Bom pro negócio ir em frente, precisa ter mais gente trabalhando em outras atividades: alguém precisa fazer layouts de placas, ou em placas padrão, como vai ser a fiação (vai ter chicote de leds e chaves pra burro - uma idéia é usar aqueles chicotes de leds usadas em PCs, como vai ser a plaquinha do display (não vai ficar na placa do PIC). Como serão as conexões entre as placas (flat cable, etc).  Uma sugestão: usar resistores  SMD para os que ficarão ligados ao PIC, pra poupar espaço e fazer o negócio em módulos: placa do PIC de controle, placa da fonte e placa de comutação (aí cada um escolhe como prefere fazer a comutação).

Concordo. Acho que deveríamos começar a padronizar algumas coisas, como por exemplo as conexões, assim já poderíamos fazer as coisas nos moldes do projeto. Poderiamos decidir também se haverá ou não um buffer, para saber se a fonte necessitará de modificaçãoes. Uma coisa que acho que seria interessante alguém fazer (não vou me comproeter pois não tenho conehcimento suficiente de todas as partes) é montar um diagrama de blocos só para esquematizar as partes do projeto e sabermos quantas placas teremos, por exemplo, uma placa com a fonte, outra com o controlador PIC, outra com o display, etc, assim já meio que padronizaríamos como será feita a montagem.

Peço que deêm suas opiniões e sugestões sobre a fonte que propus, para podermos fechar essa parte.
Abraços,

[mrmagoo]

Bruno se fosse com o eagle, eu poderia ajudar.

A maioria aqui do forum, manda bem no eagle, não seia bom "padronizar" todo layout do projeto ser feito nele? Assim poderiamos trocar os arquivos e experiencias...assim a coisa vai andando. O que acha?

[visioncb]

Sobre o mute, deixar um resistor em entradasaida de loop não seria uma idéia ruim? quer dizer... se for um banco com 2 pedais, não ficariam vários desses resistores em paralelo?

Não é simples colocar um transistor ligado a entrada do sinal, que é ativado a cada troca de preset, por exemplo, por 100ms?

No projeto do dual rectifier que eu montei, isso funcionou tão bem que toda vez que eu ouço PIC e AUDIO na mesma frase eu penso nesse mute..


Sobre a placa, dizendo um pouco com experiencia propria, é que se estão todos os componentes onboard na mesma placa, sem fiação..

Porém perde na versatilidade de escolha dos componentes e da caixa.. então seria legal pensar em um equilibrio, por exemplo, uma plaquinha só com os leds, utilizando um conector com cabo flat conectando entre as duas placas..

Mas acho também que em um certo ponto teria que ter o código fonte aqui não é? Para discutir possíveis otimizações?
-----Em contrapartida, Sandino, você ainda está participando desse tópico?

Eu estive analisando o que você postou e aquilo me acendeu algumas idéias! Incluindo usar Latch, e num modo, através de portas logicas mesmo, alternar entre o preset gravado e acionamento direto entre os foots

[polyvox]

os resistores de 1M ficariam após o chaveamento dos reles.... ou seja, só entrariam na cadeia do audio quando o rele correspondente estivesse acionado. caso contrario, sao bypassados junto com o loop e o pedal insertado no mesmo. é uma alternativa sugerida no projeto de switcher analogico do GGG. A Carl Martin, por sua vez, sugere que se coloque um buffer de saida no octaswitch ( na versao 2 eles ja implementaram um de entrada ).
sao as variaveis.

esse lance de Mute de sinal (se for disso que estivermos falando) em troca de presets é um saco e um dos grandes viloes de pedaleiras digitais.... vc ta la tocando, vai trocar de preset no meio de uma musica e ... rola aquele lag.
usando o Reaper pra "calcular" o tempo, descobri quem uma GT-10 fica em silencio por +ou- 20ms entre troca de presets... e isso é extremamente perceptivel.

é disso que vc ta falando né? se for de outra coisa, perdão. _
-----sobre as placas, ai teriamos que tomar as decisoes pra começar a pensar nisso....

definir o circuito, vamos usar transistores+diodos+capacitores pra cada rele ou usaremos um ci driver como eu sugeri? teremos um buffer de entrada? os reguladores serao na placa principal? faremos uma placa só, ou dividiremos em seçoes( matriz controladora, reles e jacks, display, leds ) ?

acho que, no momento, o principal é o firmware. tendo um firmware decidido e funcional, ai a gente começa a discutir sobre como serao as placas, de repente rola montar versoes diferentes ( tudo onboard, por seçoes, metade/metade) etc..

ate esse fim de semana eu monto o esquema baseado em alguns projetos semelhantes de gringos que eu encontrei em pesquisas e coloco aqui pra v c s (moderador, peço que me suspenda do fórum) verem o que acham e ai a galera ve como prefere montar e tal.

[visioncb]

hummm era disso mesmo sim, mas não imaginei que fosse perceptivel assim... ainda mais se forem 20ms

é que o meu medo é se algum pop acontecer até chegar no delay, ou reverb..

[polyvox]

hummm era disso mesmo sim, mas não imaginei que fosse perceptivel assim... ainda mais se forem 20ms

é que o meu medo é se algum pop acontecer até chegar no delay, ou reverb..

É... desconfiei que fosse. _
Entao, isso é MUITO RUIM e é EXTREMAMENTE PERCEPTÍVEL, ainda mais que estamos falando em pedais, loops , ou seja, um sistema "analógico". ( pelo menos na parte do audio)
Eu ja sugeri , inclusive, que isso fosse retirado do programa do PIC.
Só não entendi ainda como é que esse mute do PIC deixaria o som mudo, já que em momento/ponto algum o PIC entra em contato com o sinal de audio.

Sinceramente, os problemas com POPs devem ser minimos, isso se existirem.
Se parar pra pensar que todos esses sistemas carissimos de racks controlados via MIDI do Bob Bradshaw, por exemplo, a grosso modo sao exatamente o uso de pedais, amplificadores e racks em loops de audio programaveis e controlados via MIDI e todos esses caras multimilionarios famosos internacionalmente passaram a vida usando esses sistemas em shows pra 50, 60, 70 mil pessoas..... provavelmente, os temidos POPs nao sao um problema. _

 

[xformer]

- sobre o lance do Mute, deixa eu ver se entendi: quando entramos no modo "ediçao do preset" ficamos sem som nenhum ? ou isso é alguma funçao especifica do PIC que eu nao entendi ? se for a primeira opçao, ai ja nao é vantajoso. seria legal mao precisar apertar nada, acho que essaa funçao MUTE nao precisa nem ser implementada. os possiveis POPS seriam resolvidos de outra forma, com resistores nas saidas e entradas dos loops, por exemplo.

Desativei todos os acionamentos de mute automáticos. Só vai ter acionamento de mute via botão select/mute quando o usuário quiser.

- sobre salvar os presets, eu insisto naquele lance de programar direto: aperta o botao PROGRAM , os switches ja viram toggles pra ligar ou desligar um loop cada, aperta PROGRAM de novo e ta salvo aquele preset naquele banco. sem aquela coisa toda de ter que selecionar um banco, depois o preset e só depois ativar ou desativar loops. assim fica bem pratico e intuitivo, fora que se abre a possibilidade de usar esse modo pra desligar ou ligar um loop momentaneamente.

Agora ao apertar o PROGRAM, mantém-se o banco e o preset correntes e passa-se a escolher somente os loops em modo toggle. Apertando PROGRAM novamente, grava os loops no banco e no preset corrente.

- sobre o banco 0, bypass, etc. isso precisa ser decidido antes de fazer a programaçao final do firmware, nao? acho que podemos abolir essa ideia de banco 0 ser bypass fixo. assim todos os presets de todos os bancos disponiveis podem ser programados como o cara que for usar quiser.          

Deixa assim, para o caso de apertar o RESET. Depois tem bancos e presets sobrando (são 15 x 6 combinações de presets)

Confesso que esse rojeto me fez pesquisar um pouco sobre os PICs e fiquei fascinado com o poder desse treco. _
Já andei até assistindo aulas sobre o basico de programaçao em assembly e tal ( entendi porcaria nenhuma.. _) . É um assunto bem interessante. Provavelmente eu nao me aprofundarei nisso, mas é bem legal ver como é que funcionam as coisas e tal.
Se você não tiver nenhuma oposiçao, talvez possa me mandar o codigo fonte pra eu entender como é que a coisa funciona e estudar pra ver se levo algum jeito pra isso.
PICs podem ser bem úteis pra gente buscar soluçoes dentro dessa área de equipamentos musicais nacionais.

Não tenho interesse em divulgar o código fonte para quem não conhece o funcionamento do microcontrolador ou de programação, pois senão vou ter que ficar respondendo às dúvidas e explicar como funciona tal sub-rotina, comando ou mesmo hardware interno para o sujeito. E isso não é o objetivo do projeto (e nem meu). Mas aconselho a estudar sobre microcontroladores sim, é super útil. Só enviei para o Ledod pra ele tentar portar para C.

Só não entendi ainda como é que esse mute do PIC deixaria o som mudo, já que em momento/ponto algum o PIC entra em contato com o sinal de audio.

O PIC não vai ter contato com o sinal de áudio. Ele apenas fornece um sinal de controle (ligar ou desligar) para uma chave eletrônica (relé, 4066, FET, etc) em que o sinal de áudio passa da saída do chaveador para a entrada do ampli.

PS Veja última versão do firmware na pág 14

[hgamal]

Bruno Luca,

Não acho uma boa idéia colocar o regulador de tensão de 5V em série com o de 12V. Isto reduz a capacidade de corrente do regulador de 12V.
-----Pessoal,

O projeto está ficando bem legal. Uma vez que o xformer não está interessado em divulgar o código fonte, aconselho a todos a começar a codificar um sem restrições. A melhor parte de um projeto handmades é poder customizar de acordo com a necessidade do usuário. O código aberto também permite sugestões pelos demais participantes do forum.

Na verdade eu sempre sugiro que os projetos em grupo usem ferramentas livres, assim todos as crianças podem brincar. Programação PIC e layout, podem ser facilmente realizadas com ferramentas open source.

     esquema: kicad - http://www.kicad-pcb.org

     compialdor c para pic: sdcc - http://sdcc.sourceforge.net/

[xformer]

Outra coisa é sobre o lance de o PIC inicar (em nivel lógico 1) ativando todos os loops em todos os bancos (isso é um caos! imagine 8 pedais ligados ao mesmo tempo logo de cara), ao invés disso, seria melhor o PIC iniciar os presets de todos os bancos com todos os reles dos loops desativados (em nivel logico 0 - perdoe-me se eu estiver falando besteira, entendo quase nada disso e só sei o que aprendi com voces aqui esses dias na empolgaçao de desenvolver esse projeto ) pro individuo construir seus sons partindo do som limpo da guitarra pra adiçao de efeitos.
....
- sobre a questao da EEPROM (dos loops iniciarem ativados ao inves de desativados), eu nao entendo lhufas dessa coisa de programaçao , entao eu vou perguntando baseado na parte funcional da coisa mesmo, pensando em como seria mais funcional pro cara que estaria la no palco usando o looper. as ideias que vou postando aqui são justamente pra saber se seriam possiveis de serem programadas e assim tenhamos uma versao final de firmware 100% funcional e pratica.

Talvez eu não expliquei direito.  O PIC vem de fábrica com toda a EEPROM preenchida com bits em 1. E elá é não volátil mas reprogramável,  Uma vez que o sujeito programa um preset, isso fica guardado na EEPROM (electrically erasabe programmable read only memory) mesmo desligando o aparelho e quando é religado, todos os presets programados anteriormente permanecem e só mudam se o usuário quiser mudá-los. Como o PIC virgem vem de fábrica assim, não há nada que se possa fazer a respeito do chip. No programa poderia inverter a lógica (entender bit 1 como sendo desativado) mas vai contra o senso comum e pode trazer confusão. Como eu disse que no processo de gravação do firmware no PIC é possível também zerar toda a EEPROM, não vejo motivo pra mais discussão sobre isso. A ressalva que eu coloquei num post anterior era para o comportamento na simulação pois não haveria como zerar a EEPROM pois não há gravação de FLASH, mas pode ver que o simulador de alguma forma guarda os presets feitos anteriormente.

O projeto está ficando bem legal. Uma vez que o xformer não está interessado em divulgar o código fonte, aconselho a todos a começar a codificar um sem restrições. A melhor parte de um projeto handmades é poder customizar de acordo com a necessidade do usuário. O código aberto também permite sugestões pelos demais participantes do forum.

Para quem não entende, ver o código fonte é  inútil, pois fica como se fosse grego mesmo. Para quem entende de programação de uC, o código é banal e simples demais, por isso dá pra fazer em 1  ou 2 h.  É uma sucessão de leitura de botões e com base neles, apenas ligar ou desligar as portas de saída, sem algoritmo ou cálculo algum e sem usar nenhum periférico de hardware interno. Quem programa uC nem precisa ver o fonte e consegue escrever um firmware semelhante sem qualquer problema. Se o objetivo do projeto é apenas permitir a montagem de um equipamento que faça determinada função por todos, não creio que precise haver discussão no nível do código-fonte, senão a coisa não termina. Se o objetivo do tópico fosse aprender programação de uC, a história seria outra. Mas a maioria apenas quer montar o aparelho (como se fosse um projeto posto num artigo de revista ou site), então o projeto como um todo precisa estar completo e não apenas limitado ao ci de controle e a fonte. Eu me propus a desenvolver o firmware como pediram pois essa era uma dificuldade para implementação do projeto (creio que quase superada), mas eu não vou montar o equipamento, então os interessados precisam desenvolver o restante, senão vai ficar mais 6 meses cozinhando o projeto (já tem 6 meses).

[polyvox]

Xformer,

legal, vou testar o novo codigo.

Sobre o codigo fonte, seria justamente pelo que o Hgamal disse ali sobre cada um customizar o funcionamento a seu modo.
Pra mim serviria como aprendizado, já que eu to começando a me interessar pelo assunto. Seria interessante entender a estrutura do programa, as rotinas necessarias pra que o PIC entenda qual botao faz o que , como salva os presets, como entra em modo edit, etc. E a partir disso , tentar elaborar meu proprio firmware, por exemplo.
Mas não condeno vc nao querer disponibilizar o codigo fonte. Sem problema nenhum.

Hoje eu começo a fazer os esquemas no proteus de como eu acho que deve ser, posto aqui perto do fim de semana e a galera discute o que acha que deve mudar e tal.

Bacana que a coisa esta evoluindo. 


-----só um adendo aqui. na verdade o "hexaswitch" começou com a ideia do Sandino em fazer um controlador de loops analogico, semelhante ao da carl martin e ao do pedrone. ou seja, sem programaçao de presets nem nada, com DIPS.

Essa coisa de fazer com PIC  e tal começou só agora mesmo. A maior dificuldade sempre foi encontrar alguem que programasse o PIC. ë um projeto "novo".

Sobre a fonte, pessoal, nao podemos tambem usar só +5V ? usamos reles de 5v t b (moderador, peço que me suspenda do fórum) e pronto ? assim precisariamos apenas de 9V de entrada, como 99% dos pedais normais e regulariamos com um 7805. Ou voces querem +5V e +12V por conta daquele lance de isolar a alimentaçao do PIC da alimentaçao dos reles?

[mrmagoo]

Na verdade eu sempre sugiro que os projetos em grupo usem ferramentas livres, assim todos as crianças podem brincar. Programação PIC e layout, podem ser facilmente realizadas com ferramentas open source.

     esquema: kicad - http://www.kicad-pcb.org

     compialdor c para pic: sdcc - http://sdcc.sourceforge.net/

Boa ideia! fazendo um curso de Kicad!

[visioncb]

polyvox

Pois é, e o pior é que eu acho a idéia de fazer em apenas circuitos lógicos uma idéia interessante.. tanto que até comentei com essa idéia com o Sandino de continuar, quando eu revi o esquema que ele montou me subiu uma luz aqui na cabeça..

Sobre o código fonte, concordo com o hgamal, seria interessante aproveitar pra fazer um projeto em paralelo a este, com o código fonte aberto para customizações e para aprendizado.. mas principalmente para otimizações

Observem esse vídeo, http://www.youtube.com/watch?v=l5IjTXYgp9A era algo muito assim que eu estava imaginando, pois é bem funcional e ainda simples de programar, mantém esse equilíbrio pra quem quer tanto simplificar quanto aumentar o projeto..

[polyvox]

polyvox

Pois é, e o pior é que eu acho a idéia de fazer em apenas circuitos lógicos uma idéia interessante.. tanto que até comentei com essa idéia com o Sandino de continuar, quando eu revi o esquema que ele montou me subiu uma luz aqui na cabeça..

Sobre o código fonte, concordo com o hgamal, seria interessante aproveitar pra fazer um projeto em paralelo a este, com o código fonte aberto para customizações e para aprendizado.. mas principalmente para otimizações

Observem esse vídeo, http://www.youtube.com/watch?v=l5IjTXYgp9A era algo muito assim que eu estava imaginando, pois é bem funcional e ainda simples de programar, mantém esse equilíbrio pra quem quer tanto simplificar quanto aumentar o projeto..

Mas esse nosso projeto é basicamente parecido com esse que vc postou e com os que eu postei no topico tambem.

Sobre o looper só analogico, é algo até bem simples de fazer, ainda mais se usar um ci do tipo 74LS373 e as DIPS pra cada preset.
o ruim desse tipo de projeto é que vc fica limitado a ter 5, 6, 7 ou 8 presets no total, enquanto esse com PIC vc tem bancos e muitos presets mais pra salvar.

É tudo uma questão de necessidade de quem for usar. se o cara só precisa de uns 4 ou 5 timbres, faça o analogico que é bem mais facil.
agora, se precisa da muitos mais sons diferentes, ai tem que ser com o PIC mesmo.

Sobre o codigo fonte, eu realmente me interessei sobre esse assunto a partir do dia que resolvemos tocar esse projeto em frente. É fascinante o que pode ser feito com um PIC desses e nos abriria uma porta imensa de soluçoes nessa nossa area de equipamentos musicais .

O Xformer ja disse que nao vai liberar o codigo fonte, mas mesmo assim eu vou procurar material pra estudar sobre isso e , quem sabe, desenvolver depois meu proprio firmware pra algum projeto futuro, sei la.


-----visioncb

tem esse aqui tambem ó: http://www.youtube.com/watch?v=KuI1SFjT7uk

[xformer]

Sobre o looper só analogico, é algo até bem simples de fazer, ainda mais se usar um ci do tipo 74LS373 e as DIPS pra cada preset.

Isso também é um circuito digital.

Sobre o codigo fonte, eu realmente me interessei sobre esse assunto a partir do dia que resolvemos tocar esse projeto em frente. É fascinante o que pode ser feito com um PIC desses e nos abriria uma porta imensa de soluçoes nessa nossa area de equipamentos musicais .

O Xformer ja disse que nao vai liberar o codigo fonte, mas mesmo assim eu vou procurar material pra estudar sobre isso e , quem sabe, desenvolver depois meu proprio firmware pra algum projeto futuro, sei la.

Posso passar o código-fonte pra quem quiser (pois já passei para o Ledod,, que foi o único além de mim que disse que podia ajudar nesse aspecto e programa uC, os demais só falaram que não entendem nada do assunto - então pra quê ?).  Só não quero ficar discutindo ou explicando o código-fonte aqui ou em MP. Quem não entende do assunto, vai olhar, e deixar pra lá e fica por isso mesmo. Quem quiser fuçar, tem um caminho muito longo pela frente, antes de poder começar a fazer alguma alteração. Além disso, tem que acontecer uma coincidência de fatores para o cara poder alterar um código-fonte: precisa ter conhecimento do modelo e das características do uC (ler uma datasheet de mais de 400 páginas), entender de eletrônica (não adianta só saber programação geral, pra programar uC precisa saber eletrônica também), precisa saber a linguagem e o compilador usado (pra PIC tem um monte de linguagens e pra cada linguagem um monte de compiladores que não são compatíveis entre si) e como usá-los (mais 400 páginas). Então só pra esse projeto e num curto espaço de tempo, isso é inviável e é balela dizer que muitos iriam ajudar desenvolvimento do firmware, porque vira bagunça ter muitas versões e muita gente palpitando sem entender do assunto. É melhor deixar isso centralizado que a coisa rende mais. Ajuda mais ter gente testando o firmware, apontando os bugs e sugerindo melhorias, como você Polyvox está fazendo (vou passar o fonte pra você e depois você diz aqui se tenho ou não razão),  coisas que o programador as vezes não enxerga.