trying out microcontrollers

i did some work with the bitbox a long time ago, and i've been excited to try out building my own gadgets. i wanted to work with a 32 bit architecture, which may be overkill for my synth, but it would help with experience for future projects.

i picked up a Raspberry Pi Pico 2, which has nice getting started documentation, but i like doing things with the command line rather than VSCode, so i put together this little tutorial: https://codeberg.org/lowagner/pico-test.

i was getting a ERROR: Cannot determine the binary size, so cannot save the program only, try --all. when doing `picotool save`, but that's because `save` will download from the device, when i wanted to upload (using `load`). well, progress is progress. i have a blinking light on my desk for now.

case iterating

i'm going to be trying a few things; i want to see if i can get the volume/slide knobs in the back for easy movement with the fingers. this will require building out the innards of the case more, which i've been putting off. it looks pretty sleek without anything in the front!

at some point i'll put a logo or name there. another notable change; i've filleted the edges of the natural keys because i think that might help with glissando...

i'm also probably going to be moving the keys down (or inwards) for "protection" against putting them in the pocket (i.e., for the accidentals), and i've increased the size of the keys again because in a loose grip the thumb concerns from some of the previous posts aren't as important. it's also important to have decent size targets for the thumbs anyway.

i've also added some chamfer to the bottom which should help with pinkie comfort.

prototype case print 3

all the prototypes look so great together! the third print is "unripe banana"; i'm printing with whatever is on the AMS at the time so i'm trying to get creative. the retro roller-skate/ice-cream shop print from v2 might be my favorite colorway so far, though.

primary differences from v2 are the different shoulders and the keys are shortened. i prefer v2's proportions from an aesthetic/visual standpoint, but v3 improves the thumb playability. on v2, my thumbs feel like they naturally want to be above the bottom of the accidentals, so it requires a bit of a stretch to hit the naturals.

on v3, my thumbs feel like they naturally hover around the bottom of the accidentals, so it's easy to go above or below. of course it's harder the closer to the edge you are, but not impossible, but this is why i have an edge. (for comparison purposes, v2 and v3 have all the same case dimensions.)

for comparison to the Oskitone Scout, the keys are a bit wider as well so it's harder to fat-finger two notes.

now small differences. one unintentional: i keep forgetting i'm not allowed to put in columns that are merged with the case; they print with terrible tolerances. i suppose i could have cut off the columns, but i used a hot glue gun to weld these together and the result was not as intended. the natural keys are supposed to be flush with the surface, but you can see the tops of the accidentals are now approximately flush.

the Oskitone Scout also makes the accidentals flush with the top of the case; i wanted the natural keys flush to improve thumb feel along the edge of the keyboard but i do have to say the aesthetics look nice. "dimension" is the key word i use when i describe a 3d object that i find aesthetically pleasing, and this goof-up does have some nice dimension. but i think i'll still aim for flat on top here (flush naturals), because the accidentals have dimension and the knobs do as well. as a bonus, it should reduce the amount of space i need inside the case.

one final difference; for feel, i shrunk the "key wiggle bridge widths" which makes the keys looser, because the keys aren't as long, but i think i'll increase it again for naturals and maybe decrease it for accidentals. i can't really tell a difference for the naturals between v2 and v3, but the v3 accidentals seem a bit stiffer.

shoulders that pivot the other way

ok so i did want to try out hinging from the other side for shoulder buttons. i had fun designing this as the intersection (or difference) of a bunch of circle slices, plus fillets:

the other improvement is for ease of putting it together. i've added some pedestals inside the shoulder button that the columns slot onto, so they aren't loose or hard to line up (ideally). here's a cross section.

the columns have a large flat top so they can "support" the keyboard crossbar, which isn't pictured (or really needed) for the shoulder tester.

printing it now, will return with observations. [edit] and now we have it printed.

i think this is better but of course i'll want to test the full case. i'll want to make the button longer; the old version had a little more surface area.

[edit2] started another prototype print on the full case, i'll share that in a new post soon but wanted to show the shoulders in action here.

i think i do like them this way, you're not able to push into the pivot accidentally like you were on the previous model; i.e., there's always a lever arm.

prototype case print 2

the big upgrades here are having a cutout for the palms and beveling (build123d filleting) all the outer edges. it makes it feel more premium to not have the edges attacking you. i've shrunk the length of the keys and case (y direction) as well so it now has adorable proportions. the strawberry mint ice cream color scheme doesn't hurt, either.

the knobs aren't connected to anything so they droop a bit.

under the hood, i've improved the keyboard a bit; accidentals are spaced a bit more like on a real piano (i.e., unevenly), which necessitated moving around the "key wiggle bridge" on the bottom of each key so each bridge was exactly the same width. this took me more time than i'd like to admit.

some notes:

• i may try to bevel the case more; you get elephant's foot on the first layer so the top and bottom edges don't feel super smooth. however it's still a huge improvement on feel.
• i'll probably want to bevel the tops of the accidentals.
• i lied in the last post, you won't want a "relaxed grip" on this so the shoulder buttons should be fine pivoting around the top corners. i may want to try moving the pivot point down but keeping the buttons external profile in about the same spot, so there's a bit of a lever arm no matter where you press it.
• the knobs coming off the bottom of the front look really fun, but the best location for these would be on the back so that your other fingers could adjust them during a performance. but they look really good here, and having them for visual feedback when adjusting isn't the worst. (i may not be leaving enough space for the actual potentiometers, hmm.) if i do move them to the back, there's room for a sick logo in front, or some waveform adjusting button(s), or both.
• assembling this is a bit of a pain right now; i need to add more pedestals for my columns at the very least. i'm also probably overbuilding it, so there's a couple columns i could remove.

prototype case print

refining ideas and cutting back possibilities is hard. i've been wondering whether rear-mounted shoulders would be better (so you press inward but upward through the case), but there's gotta be a reason standard shoulder buttons work so well on controllers.

i did make a test print to start iterating on the "feel" of the device, to see if this or other changes would be necessary.

some notes:

• it's currently about 2.9 cm (1.125") thick, which feels slightly too thick. i think i'll try to get it down to about 1", but the internals will be the constraint here. if we need to remain about this size the shoulder buttons need to be thicker so they're easier to press for a range of z.
• the shoulder buttons should maybe pivot in the other direction. i currently have the pivot near the corner of the case (so the lever arm is inwards), but for a relaxed grip the trigger fingers will want to press at the corner. alternatively i could make it so there is no pure pivot and the whole button should come inwards a little bit, so it doesn't matter as much where you put the force.
• it would be nice to chamfer the bottom left and bottom right edges so the palms don't feel that edge as much.
• for pocketability, it would be nice to not be as long in the y direction. the keys are the primary constraint here, and however big i want the knobs to be, but i'll probably trim off a little blank space where possible.
• also for pocketability, i have been wondering if i should drop the joystick. if i keep it, it needs to be safely tucked under/between the knobs. i still think it would be awesome to have, but i have to see if it still feels easy to reach with the knobs possibly in the way. i would still like some way to select a waveform, see design.

if you've gotten this far, here are some of my thoughts for the possible name.

• patchsoul prodigy
• patchsoul octavio
• patchsoul ponderer
• patchsoul volta
• patchsoul porta (short for portable, or maybe portamento if i get gliding in here)

kyudo was in the running ("cute kiddo" mashed together) but apparently that's a style of serious zen Japanese archery, whose adherents i'd rather not offend.

first shoulder tester print

i got my turn on the 3d printer, and there is something really striking about the cyan and yellow combination (specifically sunflower yellow).

well, the columns didn't print the greatest; there was a lot of fuzzy beard up to the z level of the walls. i tried to sand them down but at some point i ended up breaking one off. i was able to wedge it back in from the bottom so that i could test the shoulders.

i may just print the columns separately and wedge them into the case; it will give a optional color offset. alternatively i may make these screws; it's possible these will be subjected to too much force.

these actually feel pretty good for shoulder buttons, too! so that's a success. but i'll definitely be curious how they feel with a button to activate.

design for constructability

the Oskitone Scout is a huge inspiration for this work, though i am reverse engineering the design into build123d without looking at Oskitone's openSCAD specifics. i printed a copy and am reading rough dimensions with a ruler, and adjusting for look/feel. still you can't argue with how good the Scout looks!

one of the things the Scout keyboard does is put nubs on the top and bottom of the natural keys. i assume these help with keeping the keys inside the case, but they also look kinda cool and mimic the look of a real piano key with its top lip. to get the keys in the Scout case you kinda have to shimmy them in diagonally (or force it a bit).

back to my design. i'm glad i looked closely at this cut away because if i copied the Scout's nubs i'd have a constructability problem:

my keys will have to slot in from the bottom, and will come in straight due to the shoulder columns. i could redesign the shoulders, or i could remove the key lip, and one of these is easier than the other. well, i should probably even add in a key taper, i haven't yet modelled how the keys depress to make sure i'm not running into the edge of the case.

building inside a case

refactored my case code to be generated by a solid that most things should fit inside, which is parametric in the "wall size" so i can generate the outer solid, the inner solid, and an inner solid with some clearance so parts should fit without trouble. the case then simply becomes outer - inner, plus holes for buttons and keys. this allows me to build cross beams a bit more readily, like the keyboard back bar here:

side bar: it looks like the keyboard back bar lays on the shoulder buttons, but there will be another crossbeam in between to avoid the shoulder buttons infringing on the keys' ability to bend, see video below.

the idea is to share as much code between building parts individually and modeling how they fit together, so i have a get_keyboard_pos() function which is used as the first parameter here, and build_case_clearance_solid() is memoized so it only needs to be calculated once. the keyboard position isn't needed when printing so it gets added and subtracted in this method, but not before intersecting with the case's inner clearance.

  def fit_in_case(where, part):
    return where.inverse() * (
        build_case_clearance_solid().intersect(
            where * part
        )
    )

and here is the result with the crossbar.

clip tool in build123d

build123d has a visualizer (ocp_vscode) that you can run in standalone mode (python -m ocp_vscode). it has a nice clip tool that you can use to see into parts, which is handy.

i was having trouble with small mouse movements glitching my ocp_vscode view, but restarting ocp_vscode helped.

synth design

i want some way to change the volume, this will likely go on the right knob.

it would be nice to include a way to increase vibrato. this could easily go on left knob, or on pressing up on the joystick.

it would be nice to include a way to increase glide (or slide/portamento). this could easily go on left knob.

i want some way to change the waveform (e.g., sine, triangle, square); i'd like to break this out as pre-duty positive waveform shape and post-duty negative waveform shape, so you could have sine (well, cosine) for the positive part of your wave and square for the negative part. this involves some state complexity, but the default would be to change both at the same time. it might be nice to have this on left knob, but able to go full circle so you can get back to where you started (so maybe a rotary encoder here). alternatively one or two separate buttons would probably be better. two if we get a large list of shapes, but we probably don't have too many we'd want to include. holding L or R individually could change pre/post shapes independently.

it would be nice to include a way to increase duty delta. i.e., the duty can change over time (defaults to no change, but can be increased), and duty is itself how long you're in the positive part of the waveform.

it would be nice to include pitch bend; this could go on the joystick by pressing left and right.

this is going to be polyphonic (maybe 4-8 voices), and i want some way to hold notes without holding down the key - like a piano pedal. the way this will work, i'm imagining: holding either (or both) L/R shoulder buttons will count as "holding the pedal." any notes that are pressed while holding L or R will be changed into that octave (i.e., R -> octave up, L -> octave down), but holding both L+R means the note will stay in the current octave. releasing L or R will update you into that octave (unless L and R were pressed at the same time).

will need to test that out and see what feels best, of course.

[edited 2026-05-11]

shoulder button tester

using build123d is fun because you can make things parametric, and it seemed obvious that of all the parts to this build, shoulder buttons would require the most fussing with parameters.

so i made a shoulder button tester that would be similar to the case in the upper right corner, but would allow faster iteration in case i needed to change the enclosure and button. here's a first pass on the design:

of course i couldn't help over building it, but i'll be able to use the crenelations for the real enclosure as well.

looks like i'll have to be careful with keyboard + shoulder button overlap. hmm

[edit] i think having an internal stopper will work better for our case, so we can minimize the number of things moving around inside the case where they might not be desired. this column (and where it can move in the negative space) will stop the shoulder button from exiting the device, but could also be engineered to reduce force on the internal button after a certain point.

building a gadget

i have too many interests and too little time for any of them, which is why i recently started a new project. heavily inspired by the Oskitone Scout, and for the purposes of having a handheld pitch generator (for an a cappella group i'm a part of), but also because i wanted a cool synth toy, i made this sketch:

the idea is to be able to change octaves by hitting the shoulder buttons, so you only "need" one octave of notes. it was intended to be played via thumbs.

a few days later, i wanted to lean into the game controller vibe, so it has a joystick, probably for changing pitch by aiming left/right and some other sound qualities like vibrato or duty by aiming up/down. i've been modeling it in build123d, one because i like python as a scripting language and two it feels pretty intuitive (in algebra mode at least).

i am building my 3d printing skills up (i should probably blog about the Catan-like board game i made pieces for), i already am confident in my ability to write code (i've even done low-level microcontroller audio code for the bitbox), but the but the one skill i don't yet have is wiring up circuits and microcontrollers. i'm terrified but also looking forward to trying to develop this.