(detalhes e conclusões logo mais…)

http://www.youtube.com/watch?v=euv8ZLgPh8A&feature=related
explicação nerd de como funciona (simplificando - medida de tempo de carga e descarga de um capacitor por um microcontrolador).

how to no arduino: http://arduino.cc/en/Tutorial/CapacitanceMeter

theremins com arduino:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1169728880
http://interface.khm.de/index.php/lab/experiments/theremin-as-a-capacitive-sensing-device/

e aqui a cartilha industrial detalhada de algumas técnicas atuais de tela multitoque por capacitância (e outras derivações e híbridos): http://www.atmel.com/dyn/resources/prod_documents/doc10620.pdf

fuçando & compartilhando por aqui…

Toscolão era um instrumento híbrido de violão e computador de 8 bits baseado no hardware livre arduino, onde utilizei a idéia de aplicar uma pequena voltagem na corda e espalhar resistores num tipo de “escala” de diferentes resistências no braço, que quando em contato com a voltagem aplicada na corda controlava esta voltagem funcionando como um tipo de potenciomêtro que controlava paramêtros de um sintetizador sonoro bem simples, funcionando com a técnica de “Modulação por Largura de pulso“, utilizando as saídas digitais do arduino.

Já faz algum tempo que desmontei o braço do toscolão, pois era uma peça bastante improvisada e instável. Quando fiz essa experiência foi muito mais como prova de conceito da idéia dos resistores no braço do que a intenção de dar um acabamento e transformar em algo com mais durabilidade.

Começo aqui a tempestade cerebral e organização de links pra ir pensando na atualização do toscolão ou construção de outro controlador e/ou instrumento baseado no gestual de cordas, usando técnicas e tecnologias que estão ao alcance de um relativo “faça-você-mesmo” que seja viável pra quem vem acompanhando as discussões aqui.

Aqui volto agora a pensar em como retomar o projeto de um controlador baseado no gesto cordas, e revisar algumas técnicas e links que colecionei desde então.

1. A transformação do gesto em controle

A técnica do contato do fio com uma placa de resistores funciona muito bem como exemplo didático de o que é um potenciomêtro (uma resistência variável), porém não me pareceu um controle muito preciso para construção de escalas fixas, e não seria viável para uso de mais cordas - a não ser por alguma modificação pra fazer algum tipo de isolamento por trastes não-condutivos. Só testando pra saber e ter outras idéias em cima.

Penso que pra esta técnica pode ser mais eficiente usar este contato como um sinal digital para cada uma das notas no matriz do braço. No arduino isso exigiria o uso de algum tipo multiplexador ou outra técnica de varredura serial de bytes, para aumentar entradas e saídas. Com o Arduino Mega isto estaria solucionado, mas encareceria bastante o projeto, e impossibilita que seja feito em placas mais artesanais com components grandes, pois o mega usa um atmel pequeno to do tipo smd.

Eu cheguei a fazer uma experiência numa placa com botões pra testar essa entrada, baseado na tecnica “Shift In“, pra tentar utilizar os chips mais baratos possíveis. Porém, fui ansioso demais e resolvi fazer a placa soldando fios, ao invés de desenhar o circuito (foto mais abaixo)… Ficou agora o desafio pra debugar aqueles fios, acabei na época indo pra outros projetos e retomá-lo agora exigiria uma imersão naquela idéia novamente, pois não foi documentada na época.

(frente - abaixo dois chips 4021 para fazer o Shift In das entradas - ainda faltava um circuito para o retorno da matriz de leds )

(Aqui o esquema ansioso de sair soldando o circuito em fios, instabilidade total - “estética da gambiarra” - acidente de estabilidade questionável)

Uma boa referência similar a isso é usar os esquemas que são usados nos clones do projeto Monome - o projeto Arduinome é um caminho pŕoximo do que estamos trabalhando aqui. De qualquer maneira teria que redesenhar a placa. Fica aqui uma boa oportunidade pra experimentar mais a fundo o Kicad o Geda - projetos livres de fazer placas. Eu tenho um pouco de experiência no Eagle, porém é um programa do tipo “demo” (e não é software livre), com um espaço restrito de tamanho de placa (que seria menor que o braço). O Eagle é o programa para manufatura de placas disparadamente mais popular, e é o projeto no qual você vai encontrar a maioria dos arquivos derivados do projeto arduino.

Uma outra referência (até mais próximo daquele estudo inacabado) seria utilizar a técnica usada em algumas destas guitarras midi como as Ztar, que recentemente foi também usada na guitarra MISA (porem a Misa usa uma touchscreen em um computador embarcado no lugar das cordas - “espetacular”, porém caro no momento). Este caso perde-se o gesto de escorregar o dedo sobre a corda e o traste, o “bend” e outras coisas, mas ganha-se precisão da nota, pois fica mais próxima de um teclado. Lembrando também que algumas destas provavelmente tem no lugar dos botões sensores de pressão (que poderiam ser derivados de algo tipo um sensor piezoelétrico )

(Ztar)

(Misa)

O caso da MISA é interessante como exemplo de sistema embarcado, pois inclui um computador de 32 bits embutido rodando linux e poderia-se pensar em rodar um Puredata nele podendo fazer processamentos de áudio muito mais complexos e qualquer outra coisa possível de fazer com um sistema operacional tipo Linux. Porém eu acho que perder as cordas como dedilhado descaracteriza totalmente o gesto, as cordas como medidor de tensão. Acho também vacilo o cara colocar em todos lugares do seu site que ele ta patenteando o “invento” (”patent pending”), pois ele só combinou A com B (veja como a Ztar ja era muito parecida com isso), uma questão de “empreendedorismo”, “chegou primeiro”, foi la e pagou preço pra transformar em “produto”. Ja que ele ta usando Linux porque não faz um open hardware?

Um exemplo é este tutorial aqui de 2006. A idéia do touchpad já estava no KaossPad e o cara adaptou.

O resultado é uma guitarra com um touch pad para controle de efeitos de audio em tempo real (veja bem - isso é diferente de um controlador de parametros de sampler ou síntese sonora, onde voce apenas gera controle de voltagem para controlar a nota independente do timbre, ou qualquer outro controle - videos, eletrodomésticos, robôs, etc).

(guitarra com “kaosspad” adptado)

Obviamente mais bacana de que desmontar um kaospad, o bacana seria fazer um pad artesanal. Este pesquisador chamado Randall Jones da uma explicação de seu pad artesanal em seu blog, com alguns links. O interessante no experimento dele não é a parte de transformação digital (pois ele esta usando o sinal como se fossem microfones, em uma placa multitrack) e sim a maneira como ele solucionou a invenção de uma especie de “piezo elétrico em grade” artesanal. A tese detalhada sobre o trabalho esta neste link.

Captadores hexafônicos

Voltando a maneira como algumas guitarras MIDI funcionam, poderíamos também pensar em simplesmente transformar uma captação independentes das cordas em controle de voltagem. Neste caso duas coisas nos interessam: O envelope de volume das cordas - podendo nos informar quando o sampler ou síntese sonora deveria soar, mas também poderíamos pensar numa transformação direta da frequencia sonora numa escala cromática (de 12 tons) com algum tipo de conversor frequencia para voltagem.

De qualquer maneira precisáriamos de um captador independente para cada corda (no caso dos violões e guitarras este captador é chamado “hexafônico”).

Encontrei poucos links de como fazer este captador, mas acredito que basicamente vocẽ possa trabalhar com algum tipo de eletreto ou piezo individual em cada corda.

Uma alternativa seria encontrar os captadores GK da Roland e adaptar seu cabeamento para ter a saída independente das cordas processados por algum chip conversor de frequencia para voltagem, para eliminar a necessidade de comprar aqueles módulos caríssimos com sons bregas ou no mínimo limitados.

Encontrei também um outro site interessante sobre captadores hexafônicos artesanais, uma pena que ele não divulga a técnica detalhadamente. Se alguem conhece estas técnicas ou tem algum link pra compartilhar, por favor deixe comentários.

Eu desacredito um pouco dessa técnica como uma possibilidade de controle realmente preciso quando se usa acordes, apenas deixo aqui pra receber comentários de quem ja usou algum desses captadores para ver se estou enganado, pois nunca tive oportunidade de testá-los.

Falando em trasformação de freqüencia em controle de voltagem quando estamos ja entrando com o som num computador com sistema operacional e Puredata rodando, daí as reconhecimento de pitch (tons) ficam bem facilitadas pelos objetos [fiddle~] e [sigmund~], mas trabalhar com um computador embutido ou acessado remotamente via rádio ou bluetooth é uma possibilidade que vou falar num próximo post.

Por último colocaria aqui também a possibilidade de utilizar um chip  ou circuito dedicado que converte frequencia pra voltagem, substituíndo o computador. Mas precisaria conhecer melhor os modelos existentes. No momento encontrei apenas este chip aqui, que não tive oportunidade de testar.

2. A transformação do controle em som embarcado

A partir do momento que temos está entrada de parâmetros de controle se optamos por ter um som embarcado como no Toscolão temos que pensar em soluções computacionais que tenham tamanho e possibilidade de autonomia de energia pra ficar conectado no próprio corpo do objeto, além dos autofalantes embutidos. No caso do Toscolão isso foi feito com arduino. Na época não cheguei a experimentar muito com as possibilidades de som com o tanto de memória e processamento que este microprocessador permite. Portanto vou detalhar um pouco aqui essas possibilidades atuais usando este projeto original como base, e depois algumas outras opções que tenho em mente.

Um problema básico de se fazer síntese sonora no arduino é o fato de que você esta limitado dentro do loop do interpretador de comandos dele. É possível fazer um oscilador de pulso pela saída digital PWM  (Pulse with modulation), porém atente o fato que mexer na função delay() de qualquer uma das portas alterararia o atraso das outras. A não ser que você queira utilizar isso como um tipo de “efeito” pra criar um timbre peculiar, onde voce tem várias saídas PWM, sempre com alguma razão entre elas (exemplo: quando a saida 5 esta em 440 hz a 6 está em 220 hz). Este era o caso utilizado no timbre do toscolão - que pode ser conferido aqui nessa música-estudo:

Agora 3 anos depois do projeto, encontrei alguns códigos também onde os autores usam algumas interrupções do chip e acesso a registradores do ATMEGA pra que possa criar possibilidade uma biblioteca de áudio.

Uma delas, a lib Glade, é baseada neste código. Parece um tanto inacabada. Não testei ainda a lib, apenas o código monolítico “PCM audio” e funciona pra um som até mais ou menos de 1 segundo no ATMEGA168.

Outra é a lib Bassdl , não entendi muito bem ainda pois não li o código, mas pareece que consegue fazer multitrack.
Pode ser conferida no video abaixo:

Outra referencia indispensável é este link. Eles dechavam varias possibilidades de usar o arduino como controlador de som, colocando prós e contras detalhadamente.

Fora do arduino e projetos similares de 8 bits ou eletronica analógica a tendência é ja pensar em microcontroladores de 32 bits, onde você poderia instalar um sistema operacional e usar programs complexos ja existentes, como Puredata, Chuck, Supercollider e etc. Ouvi falar muito da Beagleboard, que dizem ser um projeto open hardware, mas ainda não tive oportunidade de testar e ver até onde é aberto e documentado.

Vale também ficar atento ao projeto Maple, que promete ser um 32 bits com pinagem compatível com arduino, e a IDE de compilação similar para criação de firmwares que rodariam num loop também compatível, independente de haver sistema operacional na placa e usando a IDE diretamente.

3. O som controlado remotamente

Neste caso, os softwares e bibliotecas estão por todos os lados, e podemos ir direto ao experimento musical propriamente dito e pensar já em técnicas de composição algorítmica, efeitos e todo o mundo da música computacional obviamente. Minha estratégia de escopo aqui vai ser continuar dexavando derivações nos rascunhos no estudo da interface Navalha e no estudo de Composição Algorítmica.

Deixo aqui também a anotação pra tomar o assunto de transmissão de dados sem fio, em algum outro post mais focado em alguma experiência específica.

O livro que inicio aqui o “Machine Musicianship“, que poderia ser traduzido como “Musicalidade da Máquina” ou algo semelhante. Meu objetivo não é resenhar o livro, apenas tentar resumir algumas idéias que vou capturando e fazer alguns experimentos computacionais em cima.

Tempestade Cerebral

treinando musicos - treinando computadores…

A tarefa de comparar o aprendizado de música de um humano com a de um computador aprendiz é uma metáfora interessante, mas no desdobramento de uma categorização de paramêtros logo nos deparamos com a diferença ente gestos que podem ser matematizados (portanto são computáveis ex: ritmo, afinação, escalas, acordes, etc.) e outros que cairiam numa classificação subjetiva (emoções, memória, condição da escuta, etc.).

Este livro segue uma linha bem pragmática de categorização em busca desta matematização do processo de escolha composicional, com a excelente desculpa de que “é preciso começar de algum lugar”.

Segue pra isso focado em análise de entrada de dados em tempo real e um processamento capaz de reconhecimento de padrões e “estilo musical” (o que pessoalmente eu já considero algo que tem muito critério subjetivo envolvido, mas entendo que ele vai por um caminho de reconhecimento de padrões aplicado a repertório).

No ínicio da pesquisa ele dá uma boa focada no que ele chama de subprocessos, basicamente algumas técnicas algorítmicas para reconhecimento de padrões musicais. Ele baseia estas técnicas em dados que almeja esperar de um performer, trabalhando com um protocolo de parametrização de gestos musicais comum, onde escolhe por uma questão também pragmática, o protocolo MIDI como base.

Interessante aqui notar que escolhendo esse caminho ele evita completamente entrar no campo computacional do processamento de sinal analógico-digital (DSP), o que poderia ser uma estratégia mais abrangente de processamento de padrões musicais provenientes de qualquer tipo de emissor sonoro, mas certamente em 2001 (quando o livro foi escrito) iria exigir um desvio enorme de foco. Considera-se então nesse caso que tal processo já ocorreu e aquilo que era acústico ja foi parametrizado no modo cromático (12 notas e suas oitavas) e toda articulação que o MIDI permitiria armazenar. Ou que estaria se trabalhando com um “seguidor de partitura”(score follower) - algo que ele vai discorrer mais no final do livro quando falar mais objetivamente em composição em tempo real.

Fica também aberto o caminho de pesquisar outros protocolos de articulação e armazenamento de paramêtros em de um gesto sonoro. Ele fala brevemente ali do protocolo “kern” articulado com a coleção de programas para ambiente UNIX “Humdrum“. Um interessante estudo de caso sobre o “processamento simbólico” de padrões que poderia ser mais uma referência na continuidade deste estudo.  ( http://humdrum.org/Humdrum/ )

No próximo post vou focar nos tais “Processos simbólico” que ele trabalha em algoritmos no segundo capitulo do livro.

Além da explicação do algoritmo e sua contextualização ele vai aos poucos introduzindo algumas classes em C++ e patches em max/msp quer seria interessante fazer um paralelo com objetos que ja existem no PureData (só no estudo rápido que fiz já identifico ali nos problemas que ele coloca, alguns objetos prontos como [pitch] , [chord], [ryththm] , [gestalt] , etc. vou tentar explorar estes objetos comparativamente e adentrar tambem na parte de código C deles, pra pensar nos algoritmos.

Me deparei com algumas idéias interessantes: aqui e aqui. Pretendo dar um derivada à partir delas…

De certa maneira isso é o que eu estava buscando com o patch “Navalha” há uns 2 anos atrás, mas exagerei na idéia de “interface final de usuário tudo em 1″, a funcionalidade perdeu-se no mar de possibilidades inacabadas e também uma dificuldade imensa de documentar como o patch foi feito, pra tentar um desenvolvimento opensource colaborativo em cima. Vou tentar reanalisar o cenário e começar um projeto para samples documentado desde o início e mais voltado pra coleção de objetos e prática de uso.

Empacotei alguns simples e funcionais aqui:
estudando_beatslicers.tar.gz
Incluí tambem uma pasta loops, com 2 pequenos samples pra testes.

Baixe e opine sobre o que você gostaria de ver neles e tentarei implementar (e/ou compartilhemos desde já algumas derivações)…

Beatslicer (matrix sequencer) - pasta sample slicer

Este sequencer é bem simples como interface e já da pra pensar em vários usos. Seria muito legal por exemplo poder usá-lo com algum tipo de “Monome” ou de prefêrecia algum derivado artesanal tipo o projeto arduinome.

* com 16 celulas

encontrei também esta versão com 16 células, não muito diferente e facilmente adaptável.

Sample-slicer (técnica pra recortar trechos de um sampler de maneira assimétrica e determinada)

Este patch é bem interessante justamente por não complicar na parte de salvar os presets, deixando bem fácil pra poder tentar entender outras técnicas usadas. Salvar presets usando somente linguagem puredata é uma tarefa que ainda quebra um pouco a cabeça, mas existem algumas soluções como as libs sssad e memento. Por hora vamos entender a solução deste patch, pois é bem básica mas exige uma parte “na unha”.

O grande diferencial deste patch pro patch mais acima é que ele é focado em selcionar o exato trecho que você quer recortar, diferente do exemplo anterior do sequenciador de matriz, onde ele simplemente gera um recorte de partes simétricas da tabela.

Ele é dividido em dois patches complementares. O primeiro chamado breakpoint-maker.pd serve para você salvar presets da sequencia de recortes pra depois usar em um sequenciador, a partir do patch smp-slice-help.pd . A idéia que pode parecer estranha de início é que ele usa o primeiro pra gerar os presets e daí manualmente copia e cola estes presets no patch smp-slice. Obviamente isto pderia ser automatizado, as interessante porque dessa maneira o processo ficou mais explícito.

Inicie selecionando o trecho.

Em seguida selecione store e depois disso escolha um numeros nos botoes vermelhos e selecione save.

Depois de fazer todo o mapa dos breakpoints clique “save-to-message-box”. A mensagem com todo o preset aparecerá dentro do subpatch “pd mesagebox(datasaved)”. copie esta mensagem e para colar no patch smp-slice-help.pd

Aqui você usa o padrão de presete gerado.

Copie e substitua a mensgem original:

Bonkslices (patch que demonstra a possibilidade de detectar os ataques e fazer os cortes automáticamente)

Esta última abordagem é bem interessante, pois ao invés de pedir pra você selecionar os breakpoints, tenta detectá-los automáticamente pelos ataques do loop (usando o objeto bonk~). Este patch não tem interface gráfica, mas interessante porque está bem organizado fácil de ler.

Existe um arquivo chamado “bonkpointmaker” que tenta misturar estas duas últimas abordagens, mas aqui parece que não funcionou, porém resolvi incluí-lo no pacote pra ser debugado.

Não existe nenhum tipo de envelope nele. Estou tentando simplificar e modularizar o máximo possível porque quero que seja um projeto bem didático e menos inchado que o Navalha. Outros sistemas de sample existem como abstractions na comunidade puredata, mas estou tentando fazer isso de modo que mais gente por aqui possa entender como a coisa funciona from scratch. Se alguem quiser um sampler avançado em  puredata, recomendo o sistema que o pessoal do PDMTL, fez: http://wiki.dataflow.ws/PdMtlAbstractions

Isso também é uma maneira que estou buscando de explicar e aprofundar a parte de wavtables no puredata, podendo criar sistemas de sampler mais complexos com maior domínio da manipulação de arrays e tipos de dados.

Segue aqui anexo os dois objetos. Um deles depende -lib iem_tab . Qualquer dúvida entre em contato pela lista de discussão… Breve atualizo aqui:

arquivo:

bs_v01tar

Rbangsample - grava do microfone e dispara com bang.

Bangsample - carrega samples em wav e dispara com bang

Tou construindo este patch, pra criar automaticamente tabelas baseadas na afinação dos samplers, facilitando compor com pequenos trechos de captura ao vivo do mictrofone.

Explico logo mais. Baixe e tente brincar um pouco, as tabelas que gravei a primeira vez estão salvas dentro do patch, por isso o tamanho grande.

Aqui uma pequena amostra em audio:
samplear

hacklab-glermtar

Com isso é possível er mensagens enviadas pra você por msn, gtalk, irc e outros dentro do puredata.

No python:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import socket
 
mySocket = socket.socket ( socket.AF_INET, socket.SOCK_STREAM )
mySocket.connect ( ( 'localhost', 2727 ) ) #socket a ser aberto no puredata
 
 
def recebe_pidgin(account, sender, message, conversation, flags):
    print sender, "disse:", message
    #m= sender + ' - '+ message + ';\n;'
    m=message + ';\n;'
    m=m.encode('utf-8')
    m=m.replace('<body>','').replace('</body>','')
    mySocket.send ( m )
 
 
import dbus, gobject
from dbus.mainloop.glib import DBusGMainLoop
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
 
bus.add_signal_receiver(recebe_pidgin,dbus_interface="im.pidgin.purple.PurpleInterface",
signal_name="ReceivedImMsg")
 
loop = gobject.MainLoop()
loop.run()

Salve como socket.py

rode com
#python socket.py

Inicie o Puredata.

no puredata:

1
2
3
4
5
6

#N canvas 0 0 450 300 10;
#X obj 116 106 netreceive 2727;
#X floatatom 220 127 5 0 0 0 - - -;
#X obj 120 128 print;
#X connect 0 0 2 0;
#X connect 0 1 1 0;

Salve este aquivo como pidgin.pd e abra no puredata.

Você verá todas as saídas de texto das pessoas que você conversar, saindo no puredata, agora basta tratalas dentro de qualquer outro patch.