Preliminary plan for CLAMS
"In the beginning, there was a plan, And then came the assumptions, And the assumptions were without form, And the plan without substance, "And the darkness was upon the face of the workers, And they spoke among themselves saying, ..." - unknown NSFW cubicle worker
I have a preliminary road map to share with you. The plan is very preliminary for two reasons:
This second reason is why I have inserted a proof-of-concept phase up front. I have a pretty good idea of what I would do if someone handed me working Raspberry Pi Pico audio hardware and well-documented sample code. That is not the starting point for CLAMS.
I’m not a hardware hacker by any stretch of the imagination. I don’t even have a soldering station! CLAMS is open source. The code is licensed GPL-3. The documentation and any media I produce with CLAMS is licensed Creative Commons Attribution / Share-Alike. If someone wants to build CLAMS gizmos and sell them, that’s fine with me as long as they give me credit and give their users a copy of what I’m providing with CLAMS.
First of all you will need a Raspberry Pi Pico H. This is the Raspberry Pi branded board with headers and a serial wire debug (SWD) connector pre-soldered onto the board. Here’s the link for the store locator:
https://www.raspberrypi.com/products/raspberry-pi-pico/
Important! You need the one without wireless and with headers!
You will also need a Raspberry Pi Debug Probe. Here’s the store locator link:
https://www.raspberrypi.com/products/debug-probe/
This is newly-announced and I don’t know about availablilty. I have four on order that I expect to be here next week. If you can’t get them, there is a workaround, which I’ll publish in a separate post.
The reason you need this is that zeptoforth communicates with a host computer via a serial connection, not USB. The debug probe connects a USB port on the host computer with a Raspberry Pi Pico serial port and translates the signals. The host computer sees a serial port over USB.
I am testing two audio boards for CLAMS. The first one is the Pimoroni Pico Audio Pack:
The store is in the United Kingdom but I’ve had good luck with their shipping.
Because the debug probe needs to connect directly to the serial pins on the Pico, you will also need either a Pico Omnibus or a Pico Decker.
The Omnibus has two expansion slots. The audio pack will take up one, and you will need to leave the other one unused. That’s where you’ll connect the debug probe to the Pico serial port pins. I’ll post a picture as soon as the debug probes get here.
The Decker has four expansion slots. The audio pack takes up one and you need to reserve one for the debug probe connections. But you can put two other packs on the remaining slots, so feel free to explore the Pico universe!
The second audio board I’m testing is the Waveshare Electronics Audio Expansion Module. The store is in China, so availability may be a challenge. I have some on order, so I can’t give much more data.
The Waveshare Electonics add-on appears to be more convenient than the Pimoroni pack. The documentation is better, it comes with speakers, and the hardware interface with the Pico leaves a full set of open Pico male header pins. This last part means you can use an ordinary breadboard to connect the serial port pins to the debug probe; you don’t need an expander.
The primary goal of the proof of concept is to make a sound - at least a 440 hz sine wave - with just a Raspberry Pi Pico running zeptoforth and the Pimoroni audio pack. A large part of this effor is finding out where the performance constraints are going to be for synthesizing audio in real time with a Raspberry Pi Pico.
Initially, I want to know how much audio I can make in real time with 24-bit samples at 48 kHz using a single Pico. I can’t rule out dropping back to 16-bit / 44.1 kHz audio, multi-Pico configurations or both without this testing.
The planned audio software includes:
audio hardware interface words, and
a direct sound synthesis (Cordesses 2004a), (Cordesses 2004b), (Bochkarev et al. 2019) signal generator.
At this early stage I probably won’t need a real-time operating system capability.
I’m calling the proof of concept release v0.2.5. I’ve set the due date to March 17, 2023. I expect to have Waveshare devices here but the software for them probably won’t be done by then.
Once I know what the audio constraints on a single Pico are, I’ll re-scope the project. I’d strongly prefer a one-to-one ratio of performers to Picos. There is no hardware “Pico cluster” available as far as I know. Interconnecting multiple Picos adds complexity to the breadboarding process and printed circuit board design is way above my pay grade.
Given that all of this could change after the proof of concept, here’s the rest of the plan.
Text and figures are licensed under Creative Commons Attribution CC BY-SA 4.0. The figures that have been reused from other sources don't fall under this license and can be recognized by a note in their caption: "Figure from ...".
For attribution, please cite this work as
Borasky (2023, Feb. 26). AlgoCompSynth by znmeb: A Man, A Plan, A Clam ... er .... Retrieved from https://www.algocompsynth.com/posts/2023-02-26-proof-of-concept-plan/
BibTeX citation
@misc{borasky2023a,
author = {Borasky, M. Edward (Ed)},
title = {AlgoCompSynth by znmeb: A Man, A Plan, A Clam ... er ...},
url = {https://www.algocompsynth.com/posts/2023-02-26-proof-of-concept-plan/},
year = {2023}
}