Here’s something of a plan…

On the microcontroller side messages get sent as lpserialmsg_t structs:

typedef struct lpserialmsg_t {
    uint16_t type; // corresponds to LPMessageTypes enum used by normal lpmsg_t messages
    size_t size; // when greater than 0, the following bytes have a data payload of `size`
    char instrument_name[LPMAXNAME]; // the instrument name, for message routing
} lpserialmsg_t;

This allows a press-a-button send-a-play-message situation – mapping any control to some astrid message.

When the size field is greater than 0, the listener thread should read size more bytes via serial before processing the message. For now, this is only used as the payload for update messages when sending MIDI-like id/value pairs. It could be expanded for other message types (a DATA or BUFFER message?) to support sending arbitrary data like a stream of onsets, or whatever. I’m leaving that unimplemented for now since I’m still not sure if I need it yet. It also occurred to me since the lpserialmsg_t messages can relay play messages to any instrument, I could just do my onset recordings on the microcontroller, and send sequences via play messages over serial rather than scheduling them in astrid…

This feels a little more sane. I still have some things to think about w/r/t encoding update messages, but I’m leaning toward letting them just be always encoded – in other words, never writing the plain text params into the msg field of the update message, but always using it as a buffer to store the id/value. It could probably use a better name than “update” at some point.