Audio VS Sonic Pi

Teensy which gives you a lot of options with its audio library and GUI tool.

Teensy is more powerful than Arduino, 4.X boards are in stock, 8 sets of serial ports, and has a supported audio library

Just in case you don't want to go from low level code and up this is the library development version (there is a release version that you install into the Arduino environment as well) and this is the GUI that makes it simpler to do the layout work for the modules of your device to make it more straight forward to do the build of the design work. You drag the modules from the left into the work area and then connect them up. Once you have the layout you want you then export the code for it into the Arduino IDE. In the right hand panel is the description of each module and what commands are used for it in the IDE.

If you are targetting microprocessors, you are probably best coding it from scratch so you can optimise. Teensy 4 seems to be the platform of choice for a lot of synth projects. The Teensy Audio Library might give you a bit of a head start. Dexed-micro touch is a great open project that can give you an idea of what is possible on Teensy and the dev is quite approachable.

You can overcome the RPi scarcity by migrating the code to the Teensy platform, which aside being cheaper and less power hungry than the 2,3,4 RPi, is a lot cheaper and more easily available. Not an easy task since there's no Linux under the hood, but there are some excellent audio/midi libraries to help. They already built commercial-level synthesizers with it. By combining the breath sensor data with other pressure sensors you could end up with a very expressive instrument.

https://www.pjrc.com/teensy/index.html

https://www.pjrc.com/teensy/td_libs_Audio.html

https://www.pjrc.com/teensy/td_libs_MIDI.html

https://www.youtube.com/watch?v=z2674LdYW5I

Personally, if I need to make custom software modules and design my own PCBs, I'm almost certainly not going to use something like LightShowPi as my starting code. I'd probably use a Teensy + Audio Shield + EL Sequencer and have the Teensy Audio Library do all the FFT/beat detection. It'd be much more power efficient, easier (IMHO) to build and maintain, and it still allows for expansion options for future add-ons. Funny thing is, I actually own an El Escudo Dos, but I have found it to be a giant PITA compared to simple edge-lit "Neon" LED strips or even the newer "nOOds" from Adafruit.

> Silly question but why is the Pi necessary?

Not sure about this project, but generally it is not. All it needs is a small board capable of running Linux and the necessary drivers for external ADCs/DACs where necessary, plus the digital fx software. As an example, Guitarix runs also on ARM and can work on cheaper boards such as the Orange PI, Nano PI and many others cheaper and more obtanium than the Raspberry PI. https://guitarix.org/

In some cases you don't even need to run Linux. There are many effects projects using a cheap Teensy board plus its piggybacked audio card; it features a really powerful audio library and is compatible with the Arduino IDE.

https://www.pjrc.com/teensy/

https://www.pjrc.com/teensy/td_libs_Audio.html

The Teensy is truly amazing, to the point one can build synthesizers that just a few years ago would cost hundreds of bucks. Take a look for example at the TSynth, 100% Open Hardware & Open Source, also available in kit.

https://electrotechnique.cc/

Demo here: https://www.youtube.com/watch?v=uCA2L7CeWSE

I have wondered what grooves it could come with using https://sonic-pi.net/

Something fascinating about seeing a 'score' for generative music written out as a sort of specification like that.

There's enough detail there that you can take those instructions and reimplement your own version of it, and you'll end up with essentially the same 'piece of music', but certainly a different interpretation of it. Because while the score lays out some details precisely, it leaves other choices less clear. What does 'all inversions' really mean when enumerating chords? Does it include open, spread voicings? What durations should we choose from for our random waveforms? How short is 'short' when deciding to repeat? And of course, what wave synths should you use, and how should you modulate them?

All those are similar to the decisions a traditional instrumentalist makes when interpreting a sheet music score for performance - here, a generative music coder can follow this 'score' and produce a program that represents their own interpretation of the piece.

Coding it up in Sonic Pi (https://sonic-pi.net/) was a fun exercise, and I feel like I was able to produce something along the lines of what the composer intended. It carries the same kind of mood that the recording in the video has. But it's my own 'performance' of the work, if that makes sense (even if it's actually Sonic Pi 'performing' it at runtime...)

All of which got me thinking about the relationship more generally between specification, and implementation. Considering different programmers' implementations of algorithms as individual 'performances' of scores from the overall design - and then thinking about developers building elements of a larger system architecture as individual performers working to deliver their part of the performance as part of a band or orchestra. Some groups, maybe they're directed by a conductor-architect; others maybe are improvisers, riffing off one another and occasionally stepping up to deliver a solo. And some are maybe solid session performers, showing up and delivering strong but unflashy performances to a producer's specification.

So overall, a nice meditative coding exercise for a Sunday afternoon, and a shift in perspective. Thanks for sharing it.

On a seriously light-hearted note, Herve Aniglo, talked about teaching children to code with music using Sonic PI, a language agnostic platform that helps you learn recursions, looping, circuit breaking and functional programming by creating simple tunes.

https://www.youtube.com/playlist?list=PLPYzvS8A_rTYEba_4SDvR...

- Sonic Pi is built on-top of SuperCollider, but it's MUCH easier to get started with making bleeps and bloops. Sam Aaron, who originally created Overtone (a Clojure front-end for SuperCollider) created Sonic Pi initially to teach kids computer programming and music, but now it's turning into a pretty nice live-coding setup. The language is basically a DSL extension of Ruby, and although it's very elegant, I feel like it's a little nerfed in terms of a full language when compared to SCLang, so I'm sticking with the latter for now. High recommend checking it out if you're new to making music or code. https://sonic-pi.net/

- This 'Intro To Live Coding' vid from Alex McLean is great. Gives a good overview of a few fun tools out there that I won't mention here for sake of time (check out Gibber and Hydra for web-based coding things. Gibber is really slick). Alex invented Tidal Cycles, which I feel is like god-tier in terms of power and conciseness. Maybe I'll tinker with Tidal someday, but I want to start with SC.

Strange dice that it seems to mostly be c++, sponsored by 3 prominent elixir shops, with an original OSC server implementation by Joe Armstrong.

https://github.com/sonic-pi-net/sonic-pi/tree/dev/app/server...

There is a programming language+IDE called SonicPI. It's designed to create music by writing code. You can install the program from the lin, then ask chatGPT to generate some sonic PI code that produces some nice melody. Then just copy the code and paste it into the sonicPI program, and run it by clicking the run button. Here's a conversation for example