#5 Danilo Bellini | Pythonistas que você devia conhecer

#4 Danilo Bellini | Pythonistas que você devia conhecer

O Danilo é um cara que tem projetos sensacionais, um dos que mais me impressiona é o Audiolazy, projeto do qual foi elaborado para a defesa do seu mestrado. E o convido hoje para falar dele e de outros também muito bacanas.

Danilo, fale um pouco sobre você.

Que coisa mais difícil de responder…dizer apenas “um pouco sobre você” serve?

Vou dividir a resposta em tópicos que talvez sejam menos densos, e espero poder entreter o leitor ao invés de fazer disto apenas um curriculum chato e burocrático. O que segue enfatiza explicitamente assuntos voltados ao desenvolvimento de software.

Música

Sou um guitarrista que gosta de metal melódico/progressivo e diversos outros gêneros musicais. Ando com munhequeiras e caveiras, e já tive cabelo bastante longo:

Certo, o instrumento no vídeo não é lá muito parecido com uma guitarra…mas quem se importa? Tem cordas! Continuei deixando o cabelo crescer, e um ano depois desse vídeo, eu o doei:

#4 Danilo Bellini | Pythonistas que você devia conhecer
Doação do cabelo para a ASCCI

Lembro de ter visto a teoria musical básica (notas, partituras, durações, etc.) por volta dos 7 anos de idade, mas somente comecei com a guitarra no início de 2001, já com 15 anos de idade (denunciei minha idade =P), por conta do violão que foi levado ao primeiro dia de aula no colégio por um colega de classe, Arthur. Passei por diversas bandas/grupos musicais, normalmente como guitarrista ou tecladista. Fiz desde covers de bandas como Iron Maiden, Guns N’ Roses, Rhapsody, Helloween, Iced Earth, Djavan e Saltimbancos (com direito a um coral de crianças!), a bandas com músicas próprias como Fenrir, Avattar e Ravenland. Também participei de diversos corais como o Coral da ECA, o Coral da Poli, os 3 corais e camerata do Conservatório Beethoven e o coral do Studio Meyer.

000_0225
Preparando a apresentação com o Epic Tales, cover do Rhapsody, no Café Aurora (São Paulo) em 2004

OLYMPUS DIGITAL CAMERA
Participação tocando flauta doce com o Avantasians, cover do Avantasia, no Blackmore Rock Bar (São Paulo) em 2007

Foto Danilo (Fenrir)
Foto durante ensaio da Avattar com 3 integrantes do Fenrir

IMG_3583
Apresentação do Coral da ECA no MASP em 2009, cantando Carmina Burana de Carl Orff

Desenvolvimento de software até o fim do ensino médio/técnico – Jogos/Games!

Por outro lado, comecei com programação quando ainda tinha 1 dígito de idade, no momento em que meu pai disse que eu poderia criar meus próprios jogos (games) se aprendesse a programar. Embora tenha iniciado com coisas como Basic, Pascal, Visual Basic e Delphi, foi o Klik & Play, um software voltado à criação de jogos, que me manteve nessa direção. Somente em 1999, lembro que decidi parar de usar o Klik & Play, ano em que “retornei” para as linguagens “tradicionais” de programação, de início escrevendo “LuckBone”, um jogo de dominó usando BGI no Turbo Pascal para o DOS para 1 jogador. Isso tudo me trouxe grande interesse e ênfase em processamento gráfico, interatividade, inteligência artificial, roteiro, entre outros aspectos técnicos e “humanos”, embora eu talvez não soubesse onde procurar informação sobre isso tudo na época. Eu já tinha algum interesse por áudio, no sentido de efeitos para ações realizadas em jogos, mas seu processamento ainda não era minha ênfase.

LuckBone

LuckBone, jogo de dominó feito em 1999 com Turbo Pascal (DOS) e BGI, rodando no Linux via DOSBox, 593 linhas de código

No ano 2000 entrei no ensino médio/técnico em informática, especificamente no Colégio Singular, e pela primeira (e única) vez eu saí do sistema público de ensino. Gostei muito daquela época, aquele foi um local onde os valores de meus colegas foram não idênticos, mas pelo menos próximos aos meus em diversos aspectos, tanto técnicos como musicais. Jogos (não apenas games) marcaram essa época, desde cards como “Magic: The Gathering” e Pokémon a games como Warcraft II e horas em LAN Houses com Counter Strike, e até esportes físicos. Embora eu tenha a impressão de que não se tratava de algo tão valorizado no curso técnico, desenvolvi outros games para as exposições da “ExpoInfo” do colégio, por exemplo uma versão minha de clássicos como pacman (com gráficos feitos pelo Guilherme Seligra Lopes) e nibbles. Durante o colégio pude notar uma evidente inclinação a assuntos associados a imagens e jogos, além de ter conhecido nessa época softwares como o Corel Draw e visto um pouco de desenvolvimento web “estático” (eu tive uma página na GeoCities!).

O terceiro ano do colégio (ensino médio/técnico) eu realizei em simultâneo com o cursinho extensivo do Anglo, como bolsista (eu pagava somente o material por conta da minha média geral no colégio), e desde então as simultaneidades de atividades não pararam. 2002 foi também o ano de decidir que carreira escolher no vestibular…tenso! Ao dizer “música”, digamos apenas que o contexto social em que eu me encontrava não aprovou minha ideia. Algo similar ocorreu quando eu disse “matemática”, minha segunda ideia. Seguidamente, entre as opções “engenharia” e “ciência da computação”, fiquei com a primeira por conta do interesse em entender como as coisas funcionavam na prática, seja no assembly ou no hardware diretamente, e também por ter, na época, uma impressão [parcialmente] errônea sobre o que viria a ser o curso de ciência da computação. Certamente essa opinião foi influenciada pelo “choque” das primeiras aulas de “Linguagem de Programação” (segundo ano do colégio), em que era normativa a realização de fluxogramas (com régua específica) antes do código (em pseudo-código Pascal-like), ou ao estudar COBOL e fazer prova da linguagem com papel “retangularizado” para contar espaços de indentação, sem nunca colocar tal código em um computador para ver a coisa funcionar. Sei que houve grandes mudanças no curso já no ano seguinte ao meu (não calcule há quanto tempo terminei o colégio!), mas sem dúvidas vale dizer que quem aprende já desenvolvendo em Python tem a sorte de não precisar passar por essas coisas velhas e antiquadas, hoje posso dizer que já vi muito código em Python mais simples que pseudo-código.

Eletrônica e os passos até a primeira graduação

Arame de amarrar saco de pão e durex foi o material do meu primeiro hardware hack, feito em um modem da U.S. Robotics que havia parado de funcionar, mas que voltou a funcionar após esse hack. Eu literalmente curtei alguns componentes SMD no esquema “acho que o modem não precisa disto aqui para funcionar”, não me perguntem por que funcionou, eu provavelmente vou responder algo como “era óbvio, mas agora já não lembro mais”. Não me olhe com essa cara, eu soldei depois, e funcionou! =)

Meu pai havia comprado um material de eletrônica, daqueles que vendem em bancas de jornal periodicamente, e eu tentei fazer alguns dos experimentos, embora a ausência de ferramentas e de orientação/supervisão tenha sido claramente um impeditivo. Algo motivador para mim foi o uso que tive de um simples simulador de diagramas digitais em software, chamado EasySim, no qual eu podia simular circuitos com LEDs, portas lógicas, flip-flops e displays de 7 segmentos de uma maneira bastante intuitiva.

EasySim_Somador_2005

No final de 2002 e início de 2003, entre as provas da primeira e segunda fase do vestibular da Fuvest, eu precisei mudar. Foi com a prova da primeira fase da Fuvest que eu descobri uma falha no modelo de ensino/aprendizado que eu estava adotando, e substituí da maneira mais incisivamente que consegui a repetição pela “entropia”: li o material teórico inteiro das disciplinas de matemática, física e química ao invés de “perder tempo” fazendo exercícios sobre assuntos que eu já conhecia, trocando isso pela tentativa de realizar os exemplos do texto antes da solução dos mesmos, além de tentar deduzir equacionamentos, por exemplo jogando fora confusas “regras de três” para usar equações derivadas da própria unidade daquilo que eu estava usando. Acho que posso dizer que funcionou, isso fez eu ver até mesmo coisas como derivadas e leis de Kirchhoff antes de entrar na graduação, apesar de eu não ter visto no colégio parte significativa da matéria do ensino médio pelo fato de eu ter seguido o curso técnico. Fui com meus pais à praia nesse período, e lá estava eu à beira da praia, ou estudando uma apostila gigante de química, ou desenhando circuitos de resistores na areia.

Posteriormente me tornei, pela USP, engenheiro eletricista, bacharel em música e mestre em ciência da computação, em que os dois últimos cursos foram realizados em simultâneo.

Poli-USP – Engenharia elétrica com habilitação em computação / sistemas digitais
Em 2003 entrei na Poli. Em simultâneo, de 2003 a 2005 eu trabalhei como monitor/plantonista de exatas (matemática, física e química) no cursinho Anglo. Em 2006 eu iniciei a iniciação científica, meu primeiro instante como colaborador de um projeto open source (C++): escrevi um tutorial de como poderia ser inserido um algoritmo no projeto openModeller, além de um algoritmo simples baseado em distâncias (conforme sugestão do Renato De Giovanni, um dos desenvolvedores do projeto). O openModeller é um software para biólogos, feito para avaliar densidades de probabilidade de ocorrência de espécies em mapas, fornecidas informações sobre o ambiente e pontos de presença/ausência das espécies. Foi também durante essa graduação a primeira vez que compareci em um fisl.

Dentre os diversos projetos realizados durante essa graduação, acho que vale destacar os projetos das disciplinas de fundamentos da computação e de compiladores, além da pequena continuidade que fiz deles. Em uma máquina artificial (simulada) RISC de 14 instruções, um registrador de trabalho e 4KB de RAM denominada “MVN” (provavelmente uma sigla para “Máquina de Von Neumann”), o projeto da primeira disciplina foi a elaboração de um assembler para tal máquina em seu próprio assembly, a ser feito pela turma como um todo. Essa máquina tem como característica a ausência de instrução para endereçamento indireto, o que exige a modificação do próprio código na memória RAM em tempo de execução para realização desse tipo de operação, tornando o código, portanto, auto-modificável. Posteriormente, na disciplina de compiladores, o projeto foi um compilador de uma linguagem estruturada/imperativa para esse mesmo assembly, o qual escrevi em C++. A linguagem estruturada que adotei para a linguagem a ser compilada foi um “Pascal em português”, incluindo todos os laços e vetores do Pascal. Nesse caminho, por não gostar do burocrático simulador CLI em Java fornecido pela disciplina, fiz meu próprio simulador (em Delphi) da máquina, como uma GUI, e que permitia instruções de I/O para “entrar/sair do modo gráfico”, além de um único recurso gráfico: desenhar retângulos em um par de coordenadas fornecidas; o que possibilitou que eu fizesse uma nova versão do LuckBone, embora isso tenha exigido um pequeno otimizador (peephole) para o compilador.

Tetris_MVN

Tetris escrito para a MVN (aproximadamente 2.5KB)

LuckBone_MVN
LuckBone escrito para a MVN (aproximadamente 4KB)

Aparentemente o “gamification” de notas no meio acadêmico funcionou, ou eu talvez nunca tenha “desligado” a intenção de aprender tudo em simultâneo, como precisei para o vestibular. No mundo acadêmico, nunca fui reprovado, nem mesmo nos 3 vestibulares que fiz (Fuvest 2003, Fuvest 2008, Vunesp 2008), e até onde sei fui o único dessa habilitação a concluir o curso em 2007 com média acima de 8, com resultados ainda melhores nos cursos posteriores. Mas talvez paradoxalmente, foi nos dois laboratórios de engenharia de software que obtive minhas maiores notas durante essa graduação, apesar de eu ter sido nessa época muito crítico, talvez até hostil, com relação à normatividade, à burocracia e ao “senso comum” por vezes adotados junto à teoria e a prática relacionada à engenharia de software (não necessariamente nas disciplinas de engenharia de software). Absurdos como a incondicional santificação do uso de flags somado à demonização das quebras de laço como ocorreu em MAC2166 no primeiro semestre já haviam me sensibilizado bastante quanto a isso, muito mais que todo o passado que tive até então. Muitas leituras de textos clássicos fora das solicitações das disciplinas (e.g. “Structured Programming with go to Statements” de Donald Knuth) foram resultantes da aversão à impressão que eu tinha de que havia no curso uma imposição de valores, e valores bastante incompatíveis com os meus. É provável que houvesse um toque de exagero nessa impressão, o assunto tinha mais a ver com um trauma com relação a MAC2166 e minha opinião pouco favorável à ementa “cascata/waterfall + UML + RUP”, incluindo questões sociais e discursos específicos. Mas não devo esquecer dos colegas e professores que demonstravam concordar comigo, ao menos parcialmente, e o fato de que as discórdias aparentemente não tiveram relevância para a avaliação. Por exemplo teve professor me dando dicas de situações em que o famigerado “goto” fazia sentido sem ser nem quebra de laço, nem otimização e nem tratamento de exceção. No fundo, quem tem medo de usar um recurso dificilmente aprenderá quando faz sentido usá-lo. Outro exemplo foi o projeto do segundo laboratório de engenharia de software, um framework de estacionamento realizado pela turma inteira, com as partes se comunicando via SOAP. O Leandro Lameiro e eu ficamos com a GUI para visualização do estado do estacionamento (locais disponíveis/ocupados) e outras tarefas associadas a isso (basicamente um CRUD de vagas), na qual lembro de ter feito o “front-end” e ele o “back-end”. Devo muito a ele, assim como a outros da turma, pelo funcionamento desse projeto. Apesar de eu ter sido sempre bastante explícito ao dizer que considerava alguns diagramas como pouco ou nada importantes, a ênfase do laboratório ainda assim demonstrou ser prática, por exemplo lembro de ter recebido comentários positivos da professora por ter colocado um trecho de comentários no código com a descrição matemática do procedimento “detecção de click interno a uma vaga rotacionada” que precisei usar no projeto, tais comentários demonstraram ter mais valor do que diagramas meramente burocráticos.

Por vezes confesso ter sentido falta de que o curso fornecesse maior embasamento/aprofundamento teórico, por exemplo nas partes de teoria de probabilidades e de processamento [digital] de sinais, assuntos que precisei posteriormente para o mestrado e senti falta, embora eu tenha a impressão de que a recente mudança na estrutura curricular tenha melhorado isso, aproximando essa habilitação das demais dentro da engenharia elétrica e ganhando, por exemplo, uma disciplina extra apenas para teoria de probabilidades (victory!). Parte da teoria era obrigação do aluno ler em casa, e em muitos dos laboratórios (eletricidade, eletrônica, circuitos digitais, processadores, etc.) haviam ou “provinhas” antes do laboratório sobre a leitura proposta, ou até mesmo exigiam que o próprio aluno preparasse o modelo de relatório. Lembro que alguns da turma, eu inclusive, reclamávamos da carga de trabalho extra-aula exigida pelas disciplinas, mas a engenharia é e deve ser vista como enfaticamente prática(sem esquecer da bagagem teórica necessária). Afinal, quem precisa dormir?

Acho que é exagero descrever todos os detalhes do curso ou citar todos os projetos realizados durante essa graduação, e isso provavelmente seria cansativo, mas um último projeto que quero citar é um de meu último ano (2007) como aluno de graduação da Poli: meu TCC (trabalho de conclusão de curso), que foi um software editor/sequenciador de partituras/tablaturas com um pequeno suporte à entrada MIDI, e que era capaz de gerar arquivos MIDI com pulsação múltipla. Talvez eu re-escreva esse editor em Python no futuro, a partir de um refactoring do meu atual mini-projeto Guitar Tab Problem Maker e utilizando recursos prontos e otimizados ao invés de precisar implementar até mesmo o anti-aliasing gráfico e o componente para I/O MIDI. A conversão de partituras em tablaturas rendeu uma publicação no Workshop de Tecnologia Adaptativa graças ao uso de autômatos adaptativos (autômatos auto-modificáveis). Eu não conhecia Python até então, exceto de nome.

ECA-USP – Música com habilitação em composição musical

Durante as aulas de guitarra e outros tópicos acerca da música (percepção, teoria musical, contraponto, etc.) que tive com o Fernando Medeiros durante os anos de 2001 a 2004, ele falou sobre a existência de uma graduação em composição musical, curso que eu passei a ter grande interesse em fazer. Entrei em 2008 no bacharelado em música com habilitação em composição musical, o qual durou 5 anos, como a graduação anterior, embora o tempo ideal para composição fosse de 6 anos. Mas antes de entrar nessa graduação, estudei música em outras escolas, por exemplo o Studio Meyer e o Conservatório Beethoven durante os anos de 2006 e 2007, com diversos professores, voltados para canto e piano além de aulas sobre os diversos assuntos que dizem respeito à atividade musical tanto “tradicional” como “popular”, devido às necessidades que eu tinha tanto para a realização da prova de habilidades específicas em música do vestibular, como para as bandas nas quais eu tocava.

Das diversas atividades extra-curriculares realizadas durante essa graduação, vale destacar a participação junto ao grupo de improvisação livre e alguns mini-cursos que duraram alguns dias, como o de ChucK ministrado pelo Chris Chafe (CCRMA, Stanford) e o de PureData ministrado pelo Miller Puckette (CRCA, UCSD; autor do PureData). Tanto o ChucK como o PureData são linguagens de programação voltadas à síntese e ao processamento de áudio, incluindo interatividade e processamento em tempo real. Embora não tenha sido uma requisição, no terceiro dia do mini-curso de ChucK eu levei um pequeno improvisador de progressões harmônicas tonais escrito na linguagem, aquilo foi divertido.

O TCC da música foi dividido em duas partes, um trabalho acadêmico tradicional e uma apresentação musical com obras minhas. Para a apresentação musical, obtive a ajuda de 20 amigos que colaboraram na interpretação de minhas músicas, 18 dos quais participaram efetivamente como intérpretes de tais músicas em um extraordinário e inesquecível trabalho em equipe, os 2 demais foram responsáveis pelo equipamento eletrônico, além da gravação da Diskhursoopercute, obra minha para quarteto de cordas. A parte acadêmica foi um trabalho sobre H. J. Koellreutter que rendeu 169 páginas e que me levou a estudar alguns aspectos da cultura japonesa, além de educação musical, filosofia, política, entre outros assuntos. Esse trabalho incluiu como apêndice a transcrição fonética (legenda/subtitles) de dois vídeos. O Python se mostrou útil nas duas partes do TCC: na apresentação músical foi fundamental por conta de obras eletroacústicas em que utilizei Python (AudioLazy) para tarefas como segmentação e síntese de áudio (com posterior processamento, utilizando diversos softwares diferentes); para a transcrição fonética ajudou com um script que fiz para facilitar a cópia da legenda do formato Advanced Substation Alpha para uma tabela do LibreOffice, com o código de tal script presente como apêndice no TCC.

IME-USP – Mestrado em ciência da computação

Em simultâneo com a graduação em música, eu fiz o mestrado em ciência da computação, que lidou com processamento de áudio, motivado pelo problema da transcrição musical, que trata, a grosso modo, de construir uma “partitura” a partir do áudio. Resolver esse problema manualmente é uma capacidade necessária ao músico/musicista, principalmente aquele que pretende atuar com música popular, porém este pode consumir muito tempo, a depender do nível de detalhe da obra, da sua duração, da velocidade daquilo que é tocado, da simultaneidade de vozes, da existência de repetições, entre outros aspectos. A ausência da partitura de uma música é um problema que muitos enfrentam ao desejar tocar um “cover”. Na música popular, as partituras não costumam ser divulgadas, e o que existe disponível nem sempre é confiável, o que força tais artistas a serem habituados a realizar eles próprios uma “transcrição” musical, embora nem sempre façam isso por escrito.

O mestrado fez com que eu pesquisasse as áreas de filosofia da mente, ciência cognitiva, psicologia experimental e neurociência em busca de respostas para questionamentos bastante abstratos como “o que é/faz a audição?”, obviamente desejando respostas que fizessem sentido para uso prático, mas já seria de grande ajuda se minimamente pudessem me livrar dos arrogantes discursos que rejeitam “por princípio” (ou “como axioma”) a possibilidade de concretização de tais conversões por um computador. O que raios leva alguém a acreditar que há algo possível para humanos em geral mas “metafisicamente impossível por toda a eternidade” para outras máquinas físicas? É muito arbitrário…quem não acredita em “Strong AI” também não deveria ter motivos para acreditar em “strong natural intelligence”, o modelo ontológico adotado tanto faz na prática, é a segregação que necessita de uma justificativa. O “Computing machinery and intelligence” (1950) de Alan Turing é uma leitura fundamental a qualquer interessado em inteligência artificial e áreas afins. Passei a frequentar as reuniões do Cognitio, núcleo de apoio à pesquisa em ciência cognitiva na USP e posteriormente do Sem Neuras, ciclo de palestras de filosofia da mente na USP.

Foi nessa época que conheci linguagens como CSound, Faust, … e Python! Por conta das disciplinas que fiz na Poli (engenharia elétrica) em 2009 durante o mestrado (Reconhecimento de Padrões e Codificação de Voz, ambas enfaticamente práticas), passei a utilizar o GNU Octave como linguagem padrão para meus trabalhos que tinham a ver com computação, mas tal linguagem passou a ser gradativamente substituída por Python a partir do segundo semestre de 2011, por diversos motivos os quais detalho melhor no texto que segue. Graduação, trabalho, representação discente, computadores pessoais de baixa qualidade (trocas, preparo de ambiente, perda de dados e de hardware), a ausência de um laboratório para o grupo de computação musical do IME-USP e o fato de eu ter transitado entre linguagens (PureData -> Octave/MatLab -> Python) fizeram meu mestrado demorar mais que o comum, concluindo-o em 2013, porém com mais de 250 páginas e um importante legado: a AudioLazy, biblioteca/pacote DSP para o Python. Descrevo melhor o mestrado ao falar da história e das motivações da AudioLazy.

Como conheci o Python?

Apesar do Leandro Lameiro ter comentado comigo sobre o Python durante minha primeira graduação, apenas conheci o Python por conta de um coding dojo. Meu primeiro dojo foi de C++, ocorrido na Google em 2011 e organizado pelo Rodolpho Eckhardt, no qual estive presente para saber o que era um dojo, motivado pelo fato de que eu conhecia a linguagem. Gostei muito daquele dojo, particularmente por conta da questão social associada ao evento: desenvolvedores em um comportamento colaborativo e em um aprendizado coletivo, algo comum na área musical, mas em alguns aspectos inédito para mim na área de desenvolvimento de software, visto que não se tratava nem de uma obrigação acadêmica/corporativa e nem de militância, mas de pessoas que estavam ali porque gostavam de desenvolver software, queriam aprender ou queriam colaborar, construtivamente. Ok, eu tive a impressão de que alguns estiveram presentes apenas para “conhecer” a Google, nem tudo é perfeito. Os dojos seguintes que ocorreram na Google foram sobre Python, e foi então que eu decidi conhecer a linguagem. Esse comportamento colaborativo que descrevo também caracteriza a comunidade Python, cuja existência eu descobri posteriormente.

De julho de 2011 a fevereiro de 2014 eu passei a trabalhar para a Fuvest como prestador de serviços. Algumas das tarefas que me foram pedidas na Fuvest em 2011 e que tinham a ver com desenvolvimento de software, eu tentei fazer com Python, quando possível. Coisas gerais como envio de e-mails com templates (preenchimento automático), geração automática de planilhas (mesmo quando não me pediam para que a geração fosse automatizada), processamentos/verificações em bancos de dados, etc. eu fiz com Python, com aquilo que eu vi nos dojos, somado à rica documentação online disponível. Fiz também os 3 cursos online de Stanford no segundo semestre de 2011, e posso dizer que a disciplina de bancos de dados foi bastante útil no trabalho. Porém socialmente, por diversas razões, aquele ambiente foi, no início de 2012, crescentemente se tornando o mais desagradável de toda a minha vida. No final de 2012 eu migrei para trabalhar junto à reitoria da USP com estatística e desenvolvimento web, situação na qual desenvolvi o sistema do Programa Embaixadores da USP no ano de 2013, projeto em que utilizei diversas tecnologias como Nginx, Flask (Python), MongoDB, Celery e jQuery. Meu contrato foi prorrogado 11 (onze) vezes durante todo o período em que trabalhei na Fuvest, e posso dizer que utilizei Python em todos os anos nos quais trabalhei por lá. Em termos de open source, um dos softwares que desenvolvi nesse período foi um para a contabilidade da Fuvest, o brutoliquido, que foi inicialmente feito como uma GUI com PySide em 2012, e depois migrado para a versão web (Flask) disponível no meu GitHub. Outras contribuições incluem o back-end em MongoDB no simplekv (API do Flask-KVSession) e um exemplo na documentação do MongoDB onde era dito anteriormente não haver equivalente para o recurso SQL descrito, ambas contribuições motivadas pela necessidade prática do desenvolvimento do sistema do Programa Embaixadores.

Até o final de 2011, talvez por conta do que eu já havia feito no mestrado e por conta do curso de Machine Learning do Andrew Ng ter exigido o uso do GNU Octave, eu utilizava o Octave como calculadora até mesmo para as tarefas mais simplórias. No início de 2012, fiz a disciplina de eletrônica do MITx (hoje parte do edX), e tomei uma decisão um pouco radical: evitar o GNU Octave para fazer as contas necessárias utilizando somente o Python (com Numpy, quando necessário). Isso fez eu rapidamente me acostumar com o uso do Python para o meio científico, e com estruturas cada vez mais sofisticadas, e não muito depois passei a me sentir significativamente mais confortável no IPython do que no GNU Octave. Fazer os MOOCs da Udacity e Coursera também colaboraram com isso, inclusive em casos que podem parecer divergentes de início, como o curso de SaaS do Coursera, que me levou a conhecer geradores em Ruby, os quais para minha surpresa também existiam no Python. As necessidades dos projetos que eu tinha, conforme descrito neste texto de forma espalhada, me levaram a utilizar cada vez mais o Python em muitas das áreas em que eu atuava.

Humanidades e política

Enquanto eu cursava a Poli, eu erroneamente associei a ideia de “seguir normas/ordens sem pensar” à área de humanidades. A discussão sobre o que é melhor/pior para a legibilidade/compreensão humana, inclusive no contexto da engenharia de software, tem a ver com psicologia, mas sabemos que não é ela que admite respostas normativas incondicionais ou “sem lógica”. Pelo contrário, os assuntos de psicologia costumam me agradar bastante, era minha associação da área de humanas na época que estava nominalmente vinculada às imagens que eu tinha de comportamentos de determinada prática gerencial, política e jurídica, nas quais “obediência servil/incondicional ao ‘chefe’/administrador/gestor” e “ordem do juiz não se discute, se cumpre” eram vistos por mim como assuntos/responsabilidades “de humanidades”, já que esses são claramente assuntos que têm a ver com relações sociais humanas. Desde aquela época eu podia notar algum problema nessa associação da nomenclatura/referência, dado que eu queria fazer música e estava gostando daquilo que eu lia sobre filosofia, mas não estava clara a distinção entre o que fazia sentido e o que me incomodava, mas pelo menos sei que nunca foi uma área do conhecimento humano. Humanidades não tem lógica? Dificilmente algo poderia ser mais inadequado que dizer isso. Lógica é uma parte da filosofia, referente ao estudo da validade dos argumentos/pensamentos, caracteriza a filosofia analítica. Seguir normas/valores externos incondicionalmente/dogmaticamente é que não tem lógica.

Adentrei de diversas formas na área de humanidades, e hoje confesso, por vezes, sentir falta da área. Em 2007 a Wikipedia me motivou a ler de textos sobre a área de humanidades, por exemplo me levando a conhecer assuntos com os quais eu nunca havia tido contato. Foi como conheci a filosofia analítica e filósofos como Rudolf Carnap, autor da frase que utilizo já há algum tempo como assinatura em meus e-mails “It is not our business to set up prohibitions, but to arrive at conventions”, passagem de um trecho em que o autor fala sobre a amoralidade da lógica (Logical syntax of language, parte 1C17 “The Principle of Tolerance in Syntax”, 1937). Isso tudo me levou a ler os textos dos próprios autores (em PDF, às vezes traduzidos), e a participar de reuniões do grupo de filosofia analítica da FFLCH-USP. Não tive muito tempo para acompanhar tudo o que eles discutiram, e hoje provavelmente todos os que participavam daquele grupo já estão formados, mas em 2009 eu participei a frequentar o Cognitio e posteriormente (2011) o Sem Neuras, como já foi dito. Na continuidade eu entrei no grupo de estudo da racionalidade no Facebook, do qual participo até os dias de hoje. Não são sempre os mesmos temas mas isso tem me mantido próximo junto a discussões que normalmente me agradam bastante.

De 2009 ao primeiro semestre de 2011, fui RD (representante discente) em diversos conselhos da USP. Primeiramente fui RD do conselho do departamento de música, como titular, onde descobri o significado real do que é ser um representante (e como muitos “representantes” são tudo, menos representantes). Posteriormente entrei, como suplente, na CoC (conselho de coordenação de curso, se não me engano) também da música. Diante da greve da USP de 2009, tive evidências explícitas de pessoas mentindo descaradamente somente para chamar atenção das câmeras, colegas sendo violentados, entre outras atitudes que me pareciam tudo menos aceitáveis. Isso fez eu participar de um grupo chamado CDIE (Comissão para a Defesa dos Interesses Estudantis) que posteriormente formou a chapa Reconquista para o DCE. Por poucos votos, perdemos para a chapa “do PSOL”, mas isso foi suficiente para garantir cadeiras nos conselhos centrais da USP. Com isso, fui titular do CoG, conselho central da graduação na USP, do início de 2010 ao início de 2011, tendo o Alcyr Barbin Neto (direito) como suplente. Fui também RD em uma das câmaras anexas do CoG, a CCV (Câmara do Curriculum e Vestibular), e participei do grupo de trabalho que propôs as mudanças no vestibular Fuvest 2012. Talvez algum leitor me odeie por isso, mas fui eu quem defendi o aumento da nota de corte mínima do vestibular da Fuvest de 22 para 27 no momento em que essa ideia seria descartada, argumentando com um pouco de estatística a mudança do risco de se aprovar alguém que responde aleatoriamente a todas as questões, algo que resultou na aprovação da proposta pelo conselho. Para a argumentação precisei gerar uma imagem da distribuição binomial, fiz isso usando o GNU Octave naquela época, mas hoje eu teria feito com Scipy e Matplotlib, é algo bastante simples. Até hoje creio que os membros daquele conselho (daquela época) devem se lembrar de mim.

Como um decidido libriano, no início de 2011 eu participei do GEEA, grupo de estudos da escola austríaca de economia da FEA-USP. Não cheguei a postar nada no blog, mas participei das reuniões presenciais e discutia os assuntos na lista de e-mails. A proposta de Carl Menger foi excelente para me livrar daquela imagem do ourives e do papel-moeda como “origem do dinheiro” que eu havia visto no ensino fundamental [público] e que não fazia sentido algum fora do contexto “moeda lastreada” ou “moeda fiducionária”, como é o próprio caso do ouro (e do BitCoin). Mas por vezes o assunto discutido sempre me parecia algo que eu já havia visto em algum outro lugar. No “Ação Humana” de Mises há muitas passagens que remetem à filosofia da mente, por exemplo quando o autor diz que seguimos os desejos mas não desejamos o que desejar, tornando a noção de “livre arbítrio” irrelevante para a discussão que segue. “Utilidade” é um conceito que eu já tinha visto com o grupo de filosofia analítica (utilitarismo), em inteligência artificial na Poli (otimização multi-objetivo no planejamento de um agente) e até mesmo na aula magna que tive ao entrar na ECA, em 2008 (que por alguma razão lembro dela até hoje, por exemplo lembro que não utilizou nomes mas falou sobre utilidade marginal). Nessa época “econômica” assim como na época em que escrevi o TCC da música lembro de ter lido até partes de “O Capital” de Marx, assim como parte da obra de anarquistas como Rothbard, Proudhon e Bakunin, e posteriormente outros como B. Tucker e K. Carson.

Outros

Durante minha graduação na ECA, do fim de 2008 ao fim de 2009, eu participei da ECAtlética como “DM do xadrez” (diretor de modalidade), visitando outras cidades durante competições. A primeira vez foi o BIFE em Itapeva (SP), lembro de quando cheguei, eu estava completamente perdido, não fazia ideia do que seria, até o colchão inflável eu tive de comprar por lá, mas tudo foi bastante divertido. Posso ter detestado o odor de Piracicaba (SP) no Sampira, mas eu realmente gostei ter participado disso, do contrário estou certo de que teria me arrependido de não ter participado. Minhas viagens para outras cidades somente continuaram anos depois, a partir de 2013, não mais em eventos esportivos mas em eventos de software livre ou específicos de Python nos quais eu palestrei: fisl 14 (Porto Alegre RS), PythonBrasil[9] (Brasília DF), Latinoware 2013 (Foz do Iguaçu PR, e perdi R$10,00 no casino da Argentina), RuPy 2013 (São José dos Campos SP), Python Nordeste 2014 (Salvador BA), Python Vale 2014 (São José dos Campos SP); além de um iMasters’ Dev Day em Adamantina (SP) sobre dojos incluindo git, Ruby e Python, realizado junto com Leandro Facchinetti; e do Taubaté Perl Workshop (Taubaté SP), em que eu fui o “intruso” convidado para falar de Python (AudioLazy) em um evento de Perl, os Perl Mongers foram muito gentis! Dentre os eventos em que palestrei dentro da grande São Paulo, incluo o DevInSampa (2013), o Google Open Source Jam (2013), um Workshop de Python na Poli-USP com dojos simples em dois dias consecutivos (2013), o 7Masters Python de 2014, a Campus Party 2014 paulistana e o primeiro EITCCC (Encontro Internacional de Tecnologia, Comunicação e Ciência Cognitiva) realizado na UMESP, em São Bernardo do Campo. Eu coloco no Slideshare os meus slides das apresentações, cujas imagens de fundo foram feitas com a AudioLazy.

A partir de 2009, em todos os anos fui convidado pelo professor João Kogler para ajudar na disciplina PSI2222 “Práticas de eletricidade e eletrônica II” do segundo ano da engenharia elétrica da Poli como orientador de um projeto com um dos grupos de 4 alunos. Participei em 2009, em que eu propus um “Sequenciador Rítmico”, o qual foi feito com PIC com I/O MIDI; em 2012, em que os alunos propuseram o trabalho “Interruptor Musical”, o qual foi feito com Arduino; e com duas orientações em 2013, ambas utilizando a AudioLazy (Python), sendo um dos projetos uma pedaleira (com Arduino + PC), e o outro um softsynth para um teclado MIDI (com PyGame). Em 2013 expliquei o básico de git para os alunos e solicitei para que colocassem o trabalho deles no GitHub, vale a pena ver o repositório da pedaleira. Atualmente, pela IEEE, estou participando como mentor de um grupo de alunos na Poli que irão participar de maratonas de programação usando Python.

Há outros pontos (e.g. em algum instante eu também colaborei com o py.test, pyNES, Pingo, etc.) e muito que pode ser dito sobre cada assunto destacado aqui, mas acho que já escrevi demais, e acho que apresentei a maioria dos pontos sobre desenvolvimento de software que me pareciam ser relevantes como resposta. Mas para finalizar, um recado meu voltado aos aspirantes a desenvolvedores de software: não existem boas práticas / “atalhos”. Not, at all! Nem mesmo má práticas (ou todas são más, a vida é um inferno…mas isso seria romântico demais, prefiro algo mais contemporâneo). As práticas podem ser avaliadas como “boas” ou “más” para uma dada finalidade específica em um contexto prático específico, mas o resultado não é um “atributo” da prática, sendo necessário pelo menos a “tripla” que inclui a finalidade e o contexto. Vale a pena enfatizar o aprendizado, e principalmente maximizar a quantidade de técnicas/conhecimentos adquiridos, sejam “paradigmas”, “design patterns” ou o que for, visto que não me parece possível avaliar algo sem conhecê-lo ou sem ter com o que comparar. Saber o que fazer, como fazer e como usar cada técnica/tecnologia é mais importante do que saber onde colocar adjetivos. Mas vale acrescentar que esse assunto remete a problemas antigos na filosofia, como o “is-ought problem”, dito por D. Hume há alguns séculos acerca da dificuldade de obter sentenças prescritivas a partir de sentenças descritivas; quem realmente achar que existe boa/má prática, estarei muito curioso em saber como o problema centenário foi solucionado.

And now for something completely diff…

Se você diz educadamente a um humano “acende a luz”, supondo que ele realizará o “comando” solicitado, ele caminhará até algum interruptor e o pressionará, talvez pressionando vários interruptores enquanto a luz não acende, ou mesmo trocando a lâmpada quando notar que esta estava queimada, fazendo algo depois de ter ligado o circuito com a lâmpada, talvez voltando para onde ele estava ou entregando a conta a ser paga pelo serviço, e se não pagar, a lâmpada exibirá uma propaganda nas paredes e teto alternando de tempos em tempos a posição e o produto anunciado. Pelo menos enquanto não houver uma linguagem com similar poder de expressividade para desses 3 “tokens” (extraídos do áudio) possibilitar uma ação similar, pode apostar que as linguagens continuarão mudando bastante. Mas confesso que estou torcendo para o robô dizer “acende você, folgado!”…

O que faz a Audiolazy, qual foi a motivação e os motivos para desenvolvê-la?

https://github.com/danilobellini/audiolazy

A AudioLazy é uma biblioteca (ou um pacote) de DSP (Digital Signal Processing) para o Python. Resumidamente, ela trata de realizar processamento, análise e síntese de sinais unidimensionais no tempo. Há, como o nome já sugere, um destaque aos sinais de áudio, dado seu vínculo com o PyAudio (PortAudio) para realizar entrada/saída de áudio, mas não existe nada que impeça o uso do pacote para outras aplicações. A título de exemplo, a AudioLazy já foi utilizada para geração de imagens (todos os fundos de slides das minhas apresentações dos últimos anos foram criados com a AudioLazy) e criação de sequências utilizadas em cálculo numérico. A grosso modo, a AudioLazy pode ser vista como um complemento aos geradores e aos itertools do Python para lidar com operadores elemento-a-elemento e com estruturas voltadas para processamento de sinais. Mas análise, síntese e processamento são termos muito vagos, e talvez uma especificação dos recursos pareça uma “sopa de letrinhas” para alguém leigo no assunto. Especifico abaixo alguns tópicos, além de seus vínculos com processamento de sinais e, em particular, com a AudioLazy:

* Real-Time + Expressive
A ênfase do desenvolvimento sempre esteve na expressividade de código, no sentido de permitir que abstrações “de alto nível” fossem fáceis de expressar sem perder o controle sobre o “baixo nível”. Em outras palavras, tratar sinais e filtros como objetos sem deixar de lado o controle direto sobre as amostras de áudio (algo similar à ideia de “pixel”, mas para o som). Isso significa que eu queria uma API que evitasse preocupações com detalhes como índices, “condições de contorno/finalização” ou “ordem de parâmetros” a menos que óbvios ou estritamente necessários. Outro aspecto enfatizado foi a possibilidade de funcionamento em tempo real, o que também influenciou a organização do pacote como um todo. Isso foi possibilitado pela adoção de um sistema de avaliação tardia (deferred) para os sinais evitando refazer cálculos quando estes são usados mais de uma vez, algo que leva o nome de avaliação “lazy” (ou “preguiçosa”), de onde o nome “AudioLazy” foi derivado. Além disso tudo, o desenvolvimento buscava manter a máxima integração com o que já existia no Python, por exemplo ao interpretar qualquer iterável do Python contendo números entre -1.0 e 1.0 (ponto flutuante) como um sinal.

* Motivos / motivações
As motivações incluem tanto as necessidades do mestrado como aquilo que eu, como musicista, tinha como intenções práticas. No mestrado eu precisava de modelos psicoacústicos, modelos baseados no processamento direto nas amostras do áudio, e modelos baseados em blocos, todos convivendo simultaneamente para analisar áudio, incluindo modelos psicoacústicos. Minha necessidade prática era também a de um músico que sempre queria poder ouvir o que estava fazendo com aquele monte de números, se possível antes de todo o processamento ser realizado, e se possível enquanto eu estivesse falando/tocando, além de obviamente a vontade de adquirir maior liberdade para manipular o som, seja em termos de processamento ou de síntese. Havia também a intenção de utilizar o pacote em jogos, como ocorreu com o Musical Mines, por exemplo. Após a finalização do mestrado, por dias fiquei horas “brincando” com a AudioLazy procurando novos timbres com variações de parâmetros em efeitos simples e famosos como distorções, delay e flanger. Mas o projeto até o início de 2013 caminhou junto ao desespero em que eu teria de terminar em um semestre o mestrado, e para isso eu precisava enfatizar a análise acima de tudo, porém o fato de que eu sempre enfatizei o processamento em amostras ao invés do processamento em blocos fez com que a divisão análise-processamento-síntese não estivesse tão clara na época, parte dos recursos de processamento foram feitos como etapas de análise (e.g. filtros lineares para implementar o gammatone), assim como parte dos recursos de síntese para análise controlada, comparação de uma ressíntese com o áudio original e reprodutibilidade do trabalho realizado.

* Breve histórico
De início, busquei os recursos que queria em diversas outras linguagens. Cheguei a utilizar PureData, ChucK, CSound e GNU Octave (MatLab) durante a maior parte do meu mestrado, até finalmente projetar um banco de filtros o qual supostamente serviria para coletar a harmonia da música. Diversos experimentos de áudio haviam sido realizados nessas linguagens, incluindo modelos de identificação de ritmo, mas também houve modelos que eu simplesmente não achei uma forma simples de ser implementado nessas linguagens. Em junho de 2012 eu teria de apresentar no IME-USP sobre o capítulo de processamento espectral do DAFx, evento para o qual me preocupei em utilizar o Python onde consegui. Nasceu no dia 27 de maio meus primeiros experimentos com Python para processamento de áudio, motivados pelo agendamento dessa apresentação. Naquele instante, utilizando o Numpy e Matplotlib, criei implementações alternativas da DFT, uma STFT bastante diferente da atual da AudioLazy e um espectrograma, os quais precisava para a apresentação. Isso não foi suficiente, eu precisei utilizar o código do próprio livro, que estava escrito para o MatLab mas funcionou com o GNU Octave. Minha ideia seguinte era a de que eu poderia tentar implementar os códigos do livro em Python e melhorar a implementação para que esta evitasse tortuosidades, isto é, a intenção era uma expressividade de código. Após a apresentação, e já em julho de 2012, iniciei em TDD experimentos que levaram ao surgimento de uma classe: Stream, a qual visava ser um “gerador com operadores do Numpy”, algo bastante similar ao que existe atualmente. Na época havia um monkeypatch de métodos de operadores, e eu continuei com a ideia, criando 2 recursos inexistentes na AudioLazy. Um desses recursos era a classe Function, que lidava com funções com operadores, literalmente permitindo escrever “_ + 2*_” no lugar de “lambda a, b: a + 2*b”. É inegável que eu tinha interesse em fugir do paradigma imperativo. O outro recurso foi a classe LTITime, que criava filtros LTI descritos pelo seu equacionamento no tempo como “y[n] = x[n] – x[n-1]”. Isto tudo funcionou com os objetos x, y, n e _ (que eu chamava de “wire” por conta do Faust), bastando criar um “y” para cada novo filtro a ser criado. Entretanto, os lambdas alternativos posteriormente me pareceram desnecessários naquela época e os filtros no tempo tinham a dificuldade de necessitar de 3 objetos, sendo intratáveis em casos como “y[n] – y[n-1] = x[n]” (expressão à esquerda da atribuição) e “y[n] = y[n-1] * x[n]” (não-linear). Entretanto, o LTITime me levou à criação da classe LTIFreq e do objeto z, os quais estão presentes na AudioLazy (atual classe ZFilter), e permitia implementar os filtros através do equacionamento no domínio Z, “filt = 1 – z ** -1” passaria a ser o “y[n] = x[n] – x[n-1]”. Pode-se dizer que isso foi o período embrionário da AudioLazy, surgindo a partir desses arquivos pouco ou nada vinculados entre si. Os polinômios surgiram posteriormente como uma refatoração da LTIFreq. Conheci o py.test e migrei todos os testes do unittest para o py.test. Após diferentes tentativas de monkeypatch, decorators e class factory para a sobrecarga massiva de operadores que ocorria com o objeto z e com os sinais, descobri como esse processo poderia ser feito com metaclasses com reaproveitamento de código para as diversas classes que precisavam desse recurso, nascendo então uma das classes do “core” da AudioLazy: AbstractOperatorOverloaderMeta. Em outubro, a AudioLazy 0.01 nasceu, e pouco tempo depois lancei a versão 0.02, já com alguns recursos para síntese em tempo real como a classe ControlStream e o exemplo mcfm.py, o primeiro dos exemplos da AudioLazy. O restante da história está no GitHub, mas vale dizer que a versão 0.04 foi a utilizada para a defesa do mestrado, com a qual fiz o modelo modificado do banco de filtros outrora escrito para o GNU Octave. A versão 0.05 foi finalizada para o RuPy de 2013 e a próxima versão, 0.6, está para ser lançada em breve.

* Análise
Análise de áudio ocorre, por exemplo, em um afinador de guitarra, que diz qual é a nota sendo tocada, e esse exemplo está disponível com a AudioLazy. Explicitar o instrumento, os acordes e o ritmo de uma música apenas com sua gravação é um complicado procedimento de análise. Há outras possibilidades que não têm a ver com música, como a identificação de fonemas, locutores (speaker), localização do emissor, etc.. A AudioLazy possui diversos recursos que podem auxiliar nessas tarefas, como a taxa de cruzamentos no zero, a predição linear (LPC), a coleta de envoltórias, entre outros. Minha intenção inicial com a AudioLazy foi possibilitar que complicados modelos de processamento de sinais pudessem ser descritos de maneira simples. Em meu mestrado, eu tinha um grande desafio: criar um algoritmo de análise de áudio que permitisse transcrever músicas, algo que pode ser compreendido como “escrever a partitura de uma música a partir de sua gravação” ou mesmo “converter MP3 em MIDI”. O mestrado resultou em diversas experimentações incluindo tarefas simples de transcrição como a identificação de ritmo de eventos sem “ataque” definido, de altura (afinador de guitarra) e ritmo harmônico, sendo a AudioLazy, em minha opinião, a principal contribuição social resultante.

* Síntese
Síntese de áudio é algo mais comum de ser visto. Quem nunca viu um teclado sintetizador? A síntese por modulação (AM, FM, anel) é trivial na AudioLazy, e muitos sintetizadores famosos (e.g. Yamaha DX7) lidam com esse tipo de síntese. A síntese aditiva, ou “soma de senoides”, também é possível, e com o sistema de consulta à tabela não é difícil personalizar diferentes formas de onda, inclusive formas de onda variantes no tempo. Com gravações e ruído branco é possível realizar síntese subtrativa através do processamento do sinal, com filtros/efeitos. Por exemplo o modelo de Karplus-Strong “digitar” (digital + guitar) é um modelo de síntese subtrativa está implementado em uma linha de código na AudioLazy. Ainda sobre a síntese subtrativa, a AudioLazy inclui um exemplo com síntese de formantes para que o computador pronuncie vogais em cima de uma onda dente-de-serra. Há outros recursos básicos como envoltórias ADSR e exemplos dos diferentes tipos de síntese.

* Processamento
Há muito que poderia ser dito sobre processamento. Fundamental na área de processamento de sinais são os filtros lineares, e a AudioLazy inclui filtros lineares variantes e invariantes no tempo através da própria equação da transformada Z (e.g. “1 – z ** -1”). Alguns dos filtros mais comuns já estão implementados com diversas estratégias diferentes, as quais fazem parte da AudioLazy. Por exemplo, o passa-baixas de um polo variante no tempo serve como modelo digital do potenciômetro e capacitor presentes em muitas guitarras como um knob que fica ao lado do knob de volume, associado à “qualidade” timbrística de uma guitarra. Mas eu queria e precisava de um sistema completo que possibilitasse análise, síntese e processamento de áudio, de maneira simples e que não criasse travas artificiais como a de impossibilitar o acesso às amostras para tarefas não necessariamente lineares. Além de filtros passa-baixas, passa-altas, ressonadores e comb, todos possivelmente variantes no tempo, é também possível realizar processamento não-linear, desde algo simples “memoryless” como uma distorção com “clip” ou com arco-tangente a processamento não-linear variante no tempo através de funções geradoras do Python, as quais podem literalmente fazer qualquer coisa com as amostras de áudio. Como inserção mais recente de recurso à AudioLazy para a futura versão 0.6 (a ser lançada em breve), esta incluirá a simples realização dos 9 passos de processamento via STFT (Short Time Fourier Transform) usando por padrão a FFT do Numpy, o que permite a simples criação de efeitos de phase vocoder como robotização de voz ou time stretch (modificação da duração do áudio sem mudar a altura/frequência).

* Psicoacústica / ciência cognitiva
Para transcrever, minha intenção durante o mestrado era a de qualificar o resultado de uma análise através de uma ressíntese da solução proposta, ou de algo equivalente na forma de um feedback que avaliasse a qualidade da análise realizada. Passei muito tempo transcrevendo músicas manualmente, e minha intenção era levar a experiência do processo manual para o processo automatizado, mas para isso eu precisaria que o computador tivesse uma audição similar à de um humano. Isso teve como consequência a busca por modelos para a audição humana, alguns dos quais implementados na AudioLazy. Em particular, faz parte da AudioLazy o modelo de Patterson-Holdsworth com os filtros gammatone e modelos de ERB, que servem como um modelo linear para a filtragem realizada pelo sistema auditivo, ou como diriam os próprios autores em 1988, “[…] to describe the shape of the impulse response function of the auditory system as estimated by the reverse correlation function of neural firing times”. Atualmente a AudioLazy também conta com o modelo de intensidades, as curvas do ISO/FDIS 226:2003 para conversão de intensidades em *phon* (psicoacústica) para *dB SPL* (física).

Captura de tela de 2014-10-16 18:56:53 Captura de tela de 2014-10-16 18:56:59
“Uma narrativa de ficção” do mestrado em quadrinhos, ilustração da objetividade na transcrição.

* Outros recursos
Há uma integração com o Matplotlib para avaliação de filtros LTI (lineares e invariantes no tempo), o que pode auxiliar no projeto de filtros, mas assim como as demais integrações (PyAudio, Numpy), não se trata de uma dependência, visto que estes não estão disponíveis para o PyPy mas a AudioLazy pode ser utilizada em tal implementação do Python. Algumas coisas úteis para pensar musicalmente são os conversores entre valores de frequência (em hertz), nomes de notas em strings (e.g. “A4” para o lá central) e valor MIDI (em semitons), que facilitam o uso de notações musicais em meio ao código. Os polinômios usando o “x” e a interpolação por polinômios de Waring-Lagrange também podem ser úteis em tarefas envolvendo cálculo numérico. Mas creio que seja desnecessário listar todos os recursos disponíveis, essa informação consta no repositório da AudioLazy.

* Compatibilidade e integração
O código dessa biblioteca é único para ambos o PyPy, o CPython 2.7 e o CPython 3.2+ em múltiplas plataformas. A metaprogramação é fundamental ao núcleo do pacote, dados recursos como a sobrecarga massiva de operadores (através de, literalmente, uma “metaclasse abstrata”) e o JIT (Just In Time) que cria em tempo de execução as funções dos filtros lineares. O resultado é um pacote multiplataforma escrito em puro Python que possibilita processamento de áudio em tempo real. Além da expressividade em buscar a integração com os tipos básicos e interfaces do próprio Python, há exemplos e testes da AudioLazy em conjunto com muitos pacotes como o Scipy, o Sympy ou o music21.

E para quem frequenta coding dojo, foi criado o projeto dose, um sinalizador de testes em tempo real, como ele funciona?

https://github.com/danilobellini/dose

30956_4431661905977_1681362632_n

O dose teve origem com uma tentativa de realizar nuances gráficas em janelas do wxPython, tendo seu desenvolvimento iniciado no dia 26 de julho de 2012. Eu fiquei um tempo considerável “brincando” com os recursos do wx para possibilitar uma estética simples, mas que me agradasse. Por exemplo, o tamanho e orientação precisavam ser ajustáveis, mas eu queria que fosse sem as bordas convencionais de janelas e arredondadas nos cantos, semi-transparente, movido com o click em qualquer lugar da janela mas com tamanho modificado quando o Ctrl fosse mantido pressionado e com a transparência modificada quando o Shift forsse mantido pressionado. Pura estética e interação no início, um “front-end” sem nada sendo realizado internamente no “back-end”.

Mas por que fazer uma janela com tais formato e conteúdo? Desde o início, a intenção era a de criar um semáforo/sinalizador/farol para auxiliar no TDD (Test-Driven Development), em particular para ser utilizado em dojos, informando o estado atual do código: verde representando “testes passando” e vermelho representando “algo quebrou nos testes”. O amarelo foi utilizado como um intermediário para indicar “testes em execução”. O nome, dose, vem de “DOjo + SEmáforo”, cujas sílabas iniciais são as mesmas em português e em inglês. Há quem diga, talvez com muito esforço, que a similaridade com o nome “nose”, um pacote de testes para o Python, vincule o nome “dose” à ideia de testes, ou talvez isso já seja um exagero.

Posterior ao desenvolvimento de toda a interface, busquei informações de como o “tdaemon” funcionava. Esse era o software que utilizávamos em dojos para executar a suíte de testes quando algum arquivo era modificado. Lendo seu código, pude notar que era realizado um polling, sistematicamente verificando a data de modificação do arquivo, o que não era o que eu gostaria que o dose fizesse. Buscando formas alternativas que utilizassem o inotify ou, preferencialmente, fossem multiplataforma sem precisar de polling a menos que estritamente necessário, encontrei o pacote “watchdog” para o Python, dependência do dose para realizar o monitoramento dos arquivos. A ação de chamada dos testes ocorre no evento de mudança em arquivos que estejam em no diretório sendo monitorado (aquele em que o dose é chamado), junto a seus subdiretórios, com algumas restrições configuráveis. Isso significa que os testes são chamados toda vez que algum arquivo é modificado, sem consultas periódicas desnecessárias ao instante de modificação do arquivo. Em setembro de 2012 eu retomei o desenvolvimento do dose.py para unificar o watchdog com a interface gráfica que eu outrora havia criado.

O comando para chamada dos testes é um parâmetro importante para o dose. Antes da existência do dose, por vezes utilizávamos o watch do Linux para rodar periodicamente o comando que realizava os testes, e por conta da maneira como o watch do Linux era utilizado, o dose foi modificado para permitir receber como parâmetros o comando que realiza os testes, por exemplo chamando “dose py.test” no diretório do projeto. Chamar o dose dessa forma o inicia, já rodando o py.test inicialmente e usando o console em que o dose foi aberto para emissão das mensagens resultantes dessas chamadas do comando de chamada dos testes.

Qualquer comando pode ser utilizado, inclusive comandos com parâmetros e para o shell. Chamar o dose com “dose py.test -k arq” irá rodar com o comando “py.test -k arq”; chamar com “dose ‘py.test -vv -k arq | grep arq'” irá rodar o comando que segue. Claramente, qualquer comando pode ser utilizado, mesmo que nada tenha a ver com o Python, o que importa é que este finalize com um valor de retorno 0 caso os testes tenham passado, ou qualquer outro valor, caso contrário. Essa é a informação utilizada pelo dose para selecionar a cor a ser exibida visualmente. Pela liberdade de escolha do comando, o dose é um semáforo agnóstico de linguagem e de framework de testes, e já foi utilizado em dojos de diversas linguagens como Python, shell script e C.

Também temos o fractals, o que ele faz é renderizar fractais. O que é o fractals e e quais as vantagens em utilizá-lo?

https://github.com/danilobellini/fractals

Fractais são construções “recursivas”, isto é, suas partes são réplicas de si próprias. O “fractals” é uma implementação em Python que gera imagens de fractais referentes ao conjunto de Julia para o mapa quadrático com uma constante fornecida como parâmetro, além do famoso fractal de Mandelbrot. Esse micro-projeto foi criado como uma curiosidade após uma conversa sobre imagens de fractais, além da simplicidade para a obtenção de um resultado satisfatório.

O que acontece se repetirmos a mesma operação diversas vezes, gerando uma sequência de valores? Isso depende da operação, mas já conhecemos sequências que podem ser definidas dessa forma, como as progressões aritmética e geométrica: o novo valor é sempre o imediatamente anterior aplicado uma função que no caso é uma soma ou um produto por uma constante. Também sabemos que a progressão geométrica tem um comportamento diferente dependendo da razão utilizada, podendo permanecer constante (razão 1), ser periódica (e.g. razão igual à unidade complexa), crescer ilimitadamente em módulo com alternância de sinal (e.g. razão -2), convergir para um valor específico, entre outros. Esses exemplos incluem comportamentos estacionário, periódico e explosivo para a dinâmica de um sistema. A razão pode ser qualquer número complexo, mas podemos dividir aqui o conjunto dos complexos em duas partes: o conjunto de Fatou e o conjunto de Julia. A grosso modo, o conjunto de Fatou é a união dos abertos caracterizados pelo comportamento “regular” em sua vizinhança, e o conjunto de Julia é seu complemento, caracterizado pela grande variação de comportamento para valores próximos, ou “caótico”. O que vemos nos fractais é o próprio plano complexo, em que cada pixel indica quantas iterações foram necessárias até a sequência ultrapassar, em módulo, um limiar (Escape Time Algorithm), uma forma de estimar uma “distância” da posição central do pixel até o conjunto de Julia. No fractal de Julia, o valor da constante “c” é fixa e o valor inicial é a coordenada complexa do pixel sendo avaliado, no fractal de Mandelbrot o valor inicial é zero e a constante “c” é a coordenada complexa do pixel sendo avaliado. No caso dos fractais gerados pelo software citado, ao invés de aplicar iterativamente a função “f(z) = z * a” relativa à progressão geométrica, é utilizada a função “f(z) = z^2 + c”.

Muita matemática! O objetivo do fractals era criar um maneira simples de gerar as imagens de fractais para diferentes parâmetros, o que ocorre de imediato chamando o software via linha de comando com os parâmetros desejados. É difícil falar em vantagens de utilizá-lo sem uma base de comparação, talvez seja mais relevante dizer que fractais são úteis para o estudo do comportamento de sistemas dinâmicos complexos, para processamento e compressão de imagem e áudio, geração de paisagens artificiais, composição musical, etc., mas obviamente sem esquecer da apreciação estética.

http://www.numberphile.com/videos/minussevenfour.html
Prime Divisors and the Mandelbrot Set

E o Pyturing, uma máquina de Turing feita em Python em uma competição no Garoa Hacker Clube, como foi a experiência de fazer em pouco tempo?

https://github.com/danilobellini/pyturing

Não foi a primeira vez em que tive de fazer um trabalho às pressas, mas devo dizer que essa vez teve aspectos diferentes. A ideia de fazer uma máquina de Turing em Python surgiu ao ler discussões da lista do Garoa, quando alguém falou sobre estudar a máquina de Turing e eu pensei: por que não um dojo de máquina de Turing? E a resposta era óbvia: uma linguagem e um simulador para a máquina de Turing seriam necessários para esse fim. A competição GCC2014 (Garoa Code Competition) exigia que fosse uma aplicação web usando Python, com Flask ou Django, ou então Ruby, com Sinatra ou Rails. Alguns de meus últimos trabalhos na Fuvest e reitoria da USP foram realizados utilizando o Flask, o qual seria minha escolha óbvia para uma “maratona”. Com o tempo disponível, mesmo que a máquina de Turing não fosse o projeto a ser realizado, eu já estaria inclinado a algo mais próximo de um single-page com atualizações via AJAX ou minimamente um back-end e front-end mínimos para que o AJAX fosse deixado para o futuro mas com as saídas em JSON prontas, como ocorreu. Além de evitar tarefas demoradas como a criação de um CMS, eu literalmente pretendia fugir de preocupações com configuração de ambientes e outras atividades “de sysadmin” durante a maratona: quem vai para uma maratona precisa ter preparado a priori o ambiente para possibilitar testes/deploy facilmente, sempre.

Combinei com o Nicolas França que faríamos juntos o Pyturing. Ele queria aprender sobre front-end, e ficou combinado que ele fizesse o HTML e CSS do Pyturing, enquanto eu faria o parser e simulador da máquina. Durante as 11 primeiras horas, eu fiquei lendo e relendo o artigo do Turing, preparei a linguagem em EBNF e iniciei sua implementação. Uma falha, dado que o projeto da linguagem poderia ter sido realizado anteriormente. Primeiramente pensei em deixar a simulação no front-end via JavaScript e até mesmo escrevi algumas linhas de código em CoffeeScript, mas depois abandonei a ideia por achar que seria mais simples, tanto para mim como para o Nicolas, se eu deixasse essa parte no back-end em Python, com a vantagem de que futuramente o código resultante poderia ser utilizado como uma API de máquina de Turing em outros projetos. Todo o Pyturing ficou pronto nas 13 horas restantes, seguindo TDD com o py.test para o módulo da máquina de Turing. O Nicolas fez o front-end usando o Bootstrap, e, durante as últimas horas da maratona, eu expliquei algumas coisas de CSS e de como o navegador poderia ajudar para que ele mesmo fizesse o alinhamento dos elementos, o que também colaborou em minimizar a dependência do projeto com relação ao Bootstrap, que ficou restrita à estética dos botões. Nos últimos minutos precisei fazer apenas os ajustes para que uma versão mínima funcional estivesse finalizada a tempo, o que consegui, embora parcialmente. Tal versão, que não continha todos os recursos atuais, teve seu commit realizado literalmente no último minuto disponível.

O resultado do GCC2014 foi uma API de máquina de Turing com uma singela aplicação web que possibilitasse o uso da API criada. Poucas mudanças foram realizadas posteriormente na interface web, por exemplo o Bootstrap deixou de ser utilizado, embora existam várias propostas de continuação em aberto. Com mais tempo disponível, a API foi complementada, uma interface CLI foi inserida ao projeto, e o Pyturing agora está no PyPI e Travis, como uma aplicação Web + API + interface CLI para máquina de Turing.

Há também um jogo bem bacana derivado da Audiolazy que é o Musical Mines, um jogo de campo minado personalizado, como foi que ele foi desenvolvido?

https://github.com/danilobellini/mmines

Eu gostava do joguinho de campo minado, e várias das tentativas que tive de experimentar jogos educativos voltados ao estudo da percepção musical foram frustradas, ou o “jogo” era chato, ou não ficava claro onde eu acertei/errei, ou o mesmo induzia vícios por repetições que levavam à utilização indevida de contexto. Pretendo no futuro implementar outras das diversas ideias que já tive para jogos voltados para a educação musical, mas no momento o único jogo finalizado que tenho é o Musical Mines.

screenshot
Musical Mines

O objetivo o jogo é o mesmo do campo minado tradicional: identificar todas as posições sem uma mina/bomba que possa explodir. Porém, ao invés de fornecer por escrito o número de células vizinhas explosivos ao clicar em uma posição, o número é fornecido através de um intervalo em semitons. Isso evidentemente cria um vício para intervalos curtos como de semitom e tom, mas auxilia no aprendizado de tais intervalos. Ao clicar em uma posição, o fundo verde indica que ela está selecionada, e você pode digitar um número para ser colocado como o intervalo daquela posição, embora a avaliação se o valor estava correto ou incorreto somente ocorre ao final do jogo (ou, para os cheaters, caso o jogo seja configurado pra sempre exibir os números). O objetivo era criar um jogo de campo minado para ajudar na educação musical, em particular na percepção de intervalos fora de um contexto tonal.

Embora tenha sido recriado posteriormente, ele surgiu primeiramente em C++ com gtkmm/cairomm no primeiro semestre de 2010, como uma tentativa de fazer uma GUI usando gráficos vetoriais similar à abordagem da coletânea de jogos de lógica do Simon Tatham. Apenas posteriormente inseri a lógica do jogo, a qual desde o início enfatizaria a música (diferente do Simon Tatham, que enfatiza puzzles totalmente dedutivos). Eu não cheguei a finalizá-lo naquela época, gastando muito tempo quando precisei de um pacote para síntese e reprodução de áudio em C++. Para pelo menos testar o que eu havia feito, segui a sugestão que me deram de usar o GNU Octave + sox mas o atraso resultante era inaceitável e aquela gambiarra também não era digna de orgulho. Recomendaram que eu tentasse uma integração com o PureData, mas o que eu queria sempre foi algo mais simples, visto que eu mesmo poderia sintetizar/processar o áudio para somente jogar a forma de onda resultante em uma saída de áudio. Em outras palavras, o que eu precisava mesmo era apenas saída de áudio multiplataforma (e.g. PortAudio), o restante eu poderia fazer “na unha”. Posteriormente eu descobri o STK (The Synthesis Toolkit in C++), mas eu acabei abandonando o jogo por outra razão: o uso do gtkmm/cairomm deixou o jogo gigantesco para quem quisesse rodá-lo no Windows.

O Musical Mines também foi um incentivo ao desenvolvimento da parte de síntese da AudioLazy, recursos como o TableLookup e adsr (síntese aditiva) foram de início criados especificamente para esse jogo. Comecei a migrar meu código do C++ com gtkmm/cairomm para o Python com wxPython em 14 de julho de 2012, e creio que a síntese de áudio tenha sido a parte mais simples do código do jogo desde o início de seu desenvolvimento, já que praticamente todas as internalidades dessa parte ficaram com a AudioLazy.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s