Saturday July 25th

Finally did a bit of work on my instrument today! I think the last time I touched it was in May? Sheesh.

The solenoid driver module breakout for it has been sitting partly done for much longer than that, though. I’ve had this nagging feeling that the way I decided to set it up was wrong. Today I decided to change part of it: rather than have the mosfet driver boards connect to a GPIO breakout for my laptop (which I was – still am – pretty excited about) I started testing it with an esp32-S3 – one of the teeny little ones seeed makes.

The GPIO breakout would save writing some code (I’m all for that generally!) and let me drive the solenoids and motors directly from the built-in computer via USB. I’ve changed my mind about actually embedding the computer into the contraption itself, though. I tried to leave lots of space for airflow, but despite that the mainboard tends to get hot and the fans pretty much stay running full speed when it runs.

Rather than embed the main computer (my old laptop mainboard in a standalone case) in the thing itself, I’m planning to use a raspberry pi (for now – later I’d like to make something dedicated with another esp32 + a couple external DACs) and stream audio from my laptop to it over wifi instead.

The entire system is meant to eventually be a loose collection of networked nodes of esp32s and computers funneling audio over wifi in a scheme I’m working out, and sending control signals via wifi via UDP. To that end, I figured it made more sense to just start with wifi for the solenoid/motor module and did some testing today sending nonsense via UDP to it and triggering the solenoid module.

I didn’t measure latency but it seemed to work pretty well. The seeed esp32-S3 supports connecting a rechargeable battery to it directly, as well as charging it via USB-C, so I might just stick a little battery onto the unit instead of powering it from the main battery banks.

I still need to wire up all the rest of the breakout connections (16x going to the solenoid/motor connectors and then I think a row of headers for the signalling connections from the microcontroller, since the wires soldered to the driver board are solid core and should be OK to just plug into a row of headers hopefully) and figure out where to fit the battery for the esp32…

The worrying wrinkle I ran into today after soldering up the final power connections on the board though was that these 12v -> 5v converter components I’ve never used before get pretty hot when I’m routing through them to send 5v to the breakouts. I have no idea if that’s normal…

This is probably a good chance to try to improve my (non-existent) debugging skills and see if I can figure out if there’s actually something wrong with the way I’ve wired things up! It’s likely! I should have tested the components before I soldered them into the module haha, oh well. If I really need to replace them with something else thankfully that bit is fairly malleable – the boards attached to them are just screwed in via standoffs, and there’s enough slack on the connections it shouldn’t be too bad to snip them out and patch in something else if need be.

Here’s hoping!

Also: I forgot how nice the arduino library APIs are. I got into the habit of avoiding it I guess because I hate the IDE, but things like arduino-cli and platformio now make the IDE unnecessary. I set up the seeed via platformio and made a little test sketch that wiggles one of the GPIO pins when it gets anything via UDP. The Wifi/UDP interfaces are so clean and nice it’s lovely. Here’s the little sketch and the platformio config:

#include <Arduino.h>
#include <WiFi.h>
#include <WiFiUdp.h>

WiFiUDP Udp;

char packetBuffer[255];
int status = WL_IDLE_STATUS;

void setup() {
    pinMode(LED_BUILTIN, OUTPUT);
    pinMode(D0, OUTPUT);

    digitalWrite(LED_BUILTIN, HIGH);

    WiFi.begin("<ssid>", "<password>");

    while(status != WL_CONNECTED) {
        status = WiFi.status();
    }

    Udp.begin(2390);

    Serial.begin(9600);
    while(!Serial) { }

    digitalWrite(LED_BUILTIN, LOW);
    digitalWrite(D0, LOW);

    delay(5000);

    IPAddress ip = WiFi.localIP();

    Serial.println("IP:");
    Serial.println(ip);
}

void loop() {
    digitalWrite(LED_BUILTIN, LOW);
    int packetSize = Udp.parsePacket();
    if(packetSize) {
        int len = Udp.read(packetBuffer, 255);
        if(len > 0) {
            packetBuffer[len] = 0;
            digitalWrite(LED_BUILTIN, HIGH);
            digitalWrite(D0, HIGH);
            delay(1000);
            digitalWrite(D0, LOW);
            Serial.println(packetBuffer);
            digitalWrite(LED_BUILTIN, LOW);
        }
    }
}

[env:seeed_xiao_esp32s3]
platform = espressif32
board = seeed_xiao_esp32s3
framework = arduino

Wednesday July 22nd

Lovely lovely weather today

Monday July 20th

I thought a little more about the luvsound backend tonight. Using plain text files as the canonical representation for each entity: eg releases, orders, etc.

Doing reads and writes can be done directly in the filesystem, or through a cache of each record in an sqlite database.

Writes to the database would be serialized into a write queue, with a single writer process that could be optionally paused during manual editing. Writes in the filesystem would be synchronized back to the database (using paths as keys) through a signal mechanism like inotify.

Tools built around the collection of files would use the database cache for search and filtering operations on the files.

The raw file format should be something simple and human-writeable. I sketched out a basic idea based loosely on HTTP headers, but I’m not sure if the header/body paradigm really makes sense. What might be simpler is to refer to adjacent files or directories of files in the main file, so images, HTML, markdown, audio etc can be included easily and pulled in when rendering the view for the given resource.

This sort of suggests some interchange format which can be piped to other tools to render different types of views sort of hypermedia style. I’m not sure what that would be? But it would go something like:

source file -> interchange format -> target format

So the core system would have source -> interchange translators which would do things like typing the resource, validation and etc, and renderers for target formats can be written to consume something standardized and more easily machine-readable.

The pipeline paradigm is intentionally meant to be UNIX-y so that some of these renderers could actually be existing tools…

Building a given client or server application around these core files then would be something like plugging together pipelines of these tools…

That all needs more thought! This is somewhere in line with where I’d like astrid programs to go eventually too. It would be very cool to support pipelines of streams for certain types of resources, handling them as much as a core part of the system as any other type of resource would make doing things like distributing procedural audio on demand etc just another optional part of the system…

Thursday July 9th

I got curious about the kernel errors I see on boot (usually!) complaining GET_CABLE_PROPERTY failed from the ucsi_acpi module – and lo, this is actually a long-tracked issue that explains the frustrating behavior of the framework mainboard embedded in my instrument. The framework firmware fails to report its settings to the kernel and this causes device enumeration to fail (sometimes?) – the result for me is that I have to remove the HDMI module from the framework whenever I turn my instrument on, then wait until it boots, and then reboot (blindly via a bluetooth keyboard) inserting the module again after boot in order to get the screen to work. Inserting the module after a cold boot seems to never work, but rebooting while powered does seem to work consistently. It’s very annoying! This and the cooling issues have been making me think maybe I’ll just put the mainboard back into a laptop shell and put it on the floor below the instrument instead. If I can connect the main instrument to the laptop with a single cable that’d be fine, docking it to the instrument instead. That’s probably still the direction I’ll end up going, especially given this issue is still open and unfixed!

ucsi_acpi USBC000:00: unknown error 0

Saturday July 4th

Computer Music Journal has been a year or more behind on their publishing schedule since the pandemic. They just published the Winter 2024 issue recently, it’s been kind of confusing to be a subscriber. They must have a huge backlog?

This morning I noticed there is a new article on their MIT press page from Barry Traux on microsound composition, dated June 10th 2026! I’m so excited to read this – his articles on live granular synthesis and microsound from the 80s and 90s have been really inspiring, and he’s one of my favorite computer musicians period. But the publication situation is weird. I can’t figure out why it’s only available as a $22 PDF download to subscribers.

I’m happy to support the computer music journal, it’s been an incredible resource for me since I started reading it as a student and I usually find something inspiring or interesting in every issue, I don’t really understand what has been going on recently with the publication schedule though, and this side-channel Barry Traux paper (which, yes, certainly I’m going spend the $22 and print it myself because it’s Barry Traux on microsound in 2026 for crying out loud!) just makes it all the more confusing.

Update: the PDF is watermarked uncorrected proof and when I went to check my subscription I saw this note:

Starting with volume 49, Computer Music Journal will be an online-only journal with articles made available online as they are ready.

I realize now that I skipped the about this issue section in the Winter 2024 issue. Sure enough they announced they’re moving to a new online-only continuous publication model. They’re only publishing a new volume once enough articles have been accumulated. There isn’t much explanation as to why, but I suppose I can guess the way the culture (in a broad sense, whatever that means) seems to be skewing toward having machines read and write for us. Whatever the reason, I’m bummed there will be no more print edition after 50 years of publication.

Well fireworks are fireworks, it was nice to sit by the river tonight and hear the sounds echo across the bluffs.

Friday July 3rd

You bet.

(From UNIX System V Primer by Mitchell Waite, Stephen Prata and Donald Martin – which is also riddled with typos, incorrect & sometimes offensive examples… But also it has lots of fun cartoons by Bob Johnson like the one pictured above!)

Wednesday July 1st

This is an idle thought, but for once I guess I’ll write it down.

I’m working (slowly, it’s a low-ish priority free time project) on a backend for luvsound which I’d like to eventually open source for other indies to use… the project so far is all go + sqlite.

This has been fine. I like go. It’s portable, relatively simple and easy to deploy.

SQLite3 is great. It’s extremely portable and given its age and stability I feel like the time I have invested in learning about it is well spent.

When I transitioned pippi from python 2 to python 3 I decided to move all of the C backend into cython, and then regretted that decision since it makes it basically impossible to embed anywhere outside of python. Since then I’ve mostly ported pippi back into a C library, which has already been useful in microcontrollers and other environments.

I’d like that kind of portability for the work I’m putting into the luvsound backend, too. I realized tonight that it would be worth exploring developing each major feature as its own module (download codes, large file uploads, etc) which could persist its state in sqlite and express its behavior in C.

There would be some additional work in developing interfaces for each environment it could be supported in, but I love the idea of maintaining the core C libraries and some example interfaces in python and other environments I end up using while keeping it all portable enough to allow potential contributions of other target environments.