I've been trying to finish up the last row (er, row and a third) of a eurorack drum machine for a long while now. The other week I finally got the actual case and racked&routed everything up.

The machine is itself is based around an 8-channel gate "bus," which is really all to say that it's built for triggering 8 simultaneous drum sounds. These are by default allocated to Kick, Snare, Hat (closed), Hat (open), Tom 1, Tom2, Clap, Cymbal using the wonderful drum modules from WMD and Erica.

Speaking of Erica, when they released the Perkons Voice I got the GAS (Gear Acquisition Syndrome) bad. Still haven't picked one up but I loved the sounds of the Perkons Drums machine and this would be an awesome way to get the sound into my own workflow.....I was worried about how it would fit into the signal path of my drum machine though. I had the actual room in the case to fit it but how could/should I incorporate it into the actual signal flow since all 8 of my gates were currently spoken for?

The way I saw it, I had a couple options:

• do nothing, and just manually re-patch the Perkons Voice in as I need it (un-patching another drum in the bus)
• build or buy a little switch so that the Perkons Voice could be swappable with a single voice easily (e.g, flip a switch and the gate that was triggering the Snare is now triggering Perkons Voice)
• build or buy a couple little crossfaders so that I could "inject" the Perkons Voice into the signal path of another drum and fade between them

I liked the last option the best even though it involved building or acquiring more modules. What it does allow is for the Perkons Voice to either be blended with a voice or replace it...but for it to work best every drum voice that I might want to blend with the Perkons would need a crossfader placed after it.

To save on costs I figured I'd build them myself, then I looked at PCB prices with current economic uncertainty and tariffs. Untenable.

So to save further I decided I'd just use some protoboard and 3D print a shitty face plate, hoping I could scrounge the parts I needed from what I already had in the bins. Let's get started!

Starting off I used this Instructables by ozerik as a schematic reference

This'll work well for the intended application; it does invert the signal which is fine for audio but if we were using this to mix control voltage it would obviously not be ideal. I also only had a 50k pot lying around so I had to go with that instead of something like 20k which probably would have been better. Otherwise I had the parts!

I was going to make this a 1U module which means the PCB can't be taller than 22.5mm. First thing to do was try and figure out how to fit everything in that size

Naturally I had to split the circuit into two boards stacked vertically to maintain a reasonable width. This is pretty typical in eurorack design so no big deal. We'll have one for the interface elements (jacks, knobs) and one that has the power header and op-amp package.

Once I got the interface elements placed on a board in an ergonomic way I had to start sketching out the "traces" for how everything would connect. This is definitely where you miss going through the PCB design process since the software to turn a schematic into a PCB has a lot of helpful features and error checking even if it does require a lot of set up. Instead I had to stare at this over and over after a couple context breaks just to be sure everything was right. Once the soldering started going back and fixing any mistakes would be really unfun so I did not want to beef it in the planning steps.

One thing I was super worried about getting the pins that connect the boards correct. It felt like it would be so easy during this phase or the building phase to forget what side of the board I'm looking at for any given node and put something in the wrong spot. Fingers crossed!

Main board wired up! Onto the interface board, luckily much simpler.

I almost did forget a power conditioning capacitor, quickly added that and smooshed the boards together:

For the faceplate I just quickly got something drawn up in openSCAD

and after a few iterations to nudge everything in the right place....

It fits! It powers on! It works! Here's me crossfading between a snare and a kick drum as proof of life.

Now I just need to make like 2 more...

• intro
• the joystick build
• the throttle build
• the macropad
• mounting everything
• arduino code (utilizing this joystick library)

Intro

I have a friend who got me into No Man's Sky many years ago. I still really love that game and the team who makes it and I often go back for more --

But as anyone with a passing interest knows, the space simulators are numerous. Another friend got deep into Elite Dangerous and had been evangelizing it to me for years, often telling funny stories of emergent or in-game events and showing off some truly beautiful screenshots.

For some reason or another, I finally caved...Perhaps it was because picking up the game would mean having an excuse to see if I could print and wire up a full HOTAS (Hands On Stick And Throttle). Elite Dangerous is arguably more of a space flight simulator for a lot of the gameplay so I thought having these sort of controls would be super fun to learn.

It's probably not worth going into examples of how complicated and expensive a sturdy pre-built and designed HOTAS might be...and suffice it to say I had the hubris to immediately think I could slap an arduino in a printed shell and be done with it. I didn't have a lot of an idea of what I needed, so my only requirements were that I had a joystick with some buttons and a throttle and that both should report their rotation axis' using magnetic hall effect sensors for minimal wear & tear.

The Joystick build

Naturally we're standing on a lot of shoulders here; I was lucky to find this small but helpful wiki purely for 3D printing flight sim gear. Through that I discovered the apparently popular Olukelo Gimbal – a 2 axis joystick gimbal.

For the actual Joystick and Throttle I ended up finding a creator on Cults3D who designed what looked to me to be pretty awesome gear. I could see the Olukelo Gimbal in the photos for the Joystick so I knew it would fit somehow and the purly rendered photos of the Throttle made it look very cool and well thought out. That's honestly about as much thought as I put into it since I have no real flight sim experience... these looked "good enough" (well, they look great) and had at least some documentation on the build. Thanks Miso988!

Get ready for some 90's Nickelodeon colors, because that's the filment I had most of the time I was working on this build – first up was the gimbal because I wasn't sure if my crappy little printer could print something "this mechanical." I've really only ever printed keyboard parts and other small, static things.

So yeah, it actually went really well! this gimbal was a neat little design and I'm really glad I got to put it together like this. You might have noticed in that video but there's already a little cavity in the center of the main axis bearing carriers for little cylindrical magnets -- that's where we'll measure the rotation for the arduino controller.

Onto the actual stick! It doesn't look like anything to me!

I gave it a light (er, shitty) sand to soften it up a tad. There was also this little thumb button (the green one in the pictures) that was supposed to slide into this spot with this little collar and – well I was a little incredulous it was actually going to sit in there. So I tested that here as well as the cable routing through the gimbal. Foreshadowing: 2 wires for one button as pictured here is a dumb strategy and there's gonna be more of it before there's less.

Look -- it's starting to seem familiar! As a joystick...not the other thing.

The top of the stick (where most of the buttons will be) wasn't too bad, though I did hate soldering these push buttons and then trying to slide them into the little jig for the directional input in the center here:

The rest of the top is split in half so that you can install a little leaf switch for the main trigger, which has a satisfying click:

There is a secondary trigger that I had to set similarly, thought this will sit at the bottom of the shaft, er..stick.

Here's me holding it where it'll end up for proof:

Then it was time to screw all those parts together!

Now I had already started to sweat on the number of wires coming out of this thing – for some reason I sent two wires out per switch just out of some kind of weird or bad habit.

Sure enough, this bundle was too thick to get through the gimbal channel. Time to take it all apart and rewire the buttons so that one lug of each button was tied to one single common wire inside the stick.

This would allow me to use the buttons as ACTIVE LOW inputs to the logic I would program later.

Basically, we can take that common wire that all switches are connected to and send one wire through the channel to connect that to ground.

In the arduino code we will then set the button input pins to use an internal pullup resistor to tigh those inputs HIGH be default. Then, when the button for any given pin is pushed, it will shift from that tied HIGH to the common ground wire.

This allows us to check if arduino pins are LOW instead of high to know if a button is pressed, but more importantly cuts our wire bundle from the stick in half.

Probably the only picture I have of this ordeal... but hey there are less wires!

And they all fit! got the joystick on the gimbal and programmed the buttons to test all the connections and the code (I'll share the link to all that below).

The buttons work! using a simple game tester site to make sure.

Okay so that was all great news...but to be honest I still hadn't decided or figured out how I was going to do the hall effect stuff for the actual joystick axis, arguably the most crucial part of the build.

Orginally I bought some SS495A Linear hall effect sensors, thinking I just needed anything with an analog output but of course that was under thinking it a bit.

The other main way the SS495A packages work is that they detect magnetic poles from the front of the little transister-esque body. As you approach the front of the package with one end of a cylindrical magnet (the kind we are embedding in our bearing carriers) the signal voltage goes toward the positive voltage rail. Approaching with the other end of the magnet, and the signal voltage goes toward ground.

There is no way to mount this sensor in such a way that it will work for our use case, however. Our magnets are not approaching our sensor no matter how we mount them -- they aren't really approaching anything. They rotate inside the bearing carriers.

So the SS495A was the wrong part for the job. After some searching however I did find a different package that was still in production, the AS5600. This is a rotary position sensor for magnets and is meant to be used for contactless knobs and encoders, but it should work perfectly for our purposes as well.

When they finally arrived the analog output was busted on the board that was sent over...big box stores and their bullshit... Luckily clipping out a resistor that fixed that hah.

My new problem was mounting these on the gimbal securely. they were kind of a perfect size to just be slapped on top of the bearing carriers so the chip sat right over the magnets, but I decided to print new carries so that I could mount it properly & securly (after attaching it to a protoboard to give it some width).

Once I finally got these mounted I slapped the gimbal back together with these new bearing carriers and testing right on the scope – success!!

I got the other axis wired up anddd

Flight! Now onto the throttle....

The Throttle build

The throttle as modeled has two axis and, lucky for me, is designed for the type of package that those SS495A linear hall effect sensors are! These little square magnets sit between the columns and must be placed correctly so that opposing poles are facing "inward" of the little magnet mounting piece.

The SS495A gets glued in this little channel and given some longer leads for the rest of the way out.

Slather it with some hot glue so it doesn't move in there....

I could then thread & mount these together and in the box! I would later weight this down so the top heaviness of it all would be less of an issue

Overall the throttle was a lot less painful than the Stick since there's no real gimbal to worry about and the hall effect design was more straight-forward. However, there are a lot more of those directional "hats" on the throttle control which meant more delicate wire soldering for small push buttons.

But I managed to get it all in there (with some more hot glue, of course)

You might see there I've also added the triggers to the posts which will push those buttons on the bottom of the grips that you can kinda see in that last picture.

Then I could screw the actual grips on the posts!

Cool, now I just gotta get all those wires to another arduino... I ended up using a ribbon cable this time so that the arduino board could just be soldered to a header and the rest could be a little more modular. I would eventually go back and re-do the end of the Stick wiring to use the same strategy.

then I tied the wires up and added a bunch of tire weights to the bottom of the box where there was still room to balance the weight out.

I ended up going into Blender and splitting the top plate of the throttle into two so I could get it on...I didn't think too hard about how that should have all worked and honestly this solution is fine for me. But having that top plate allowed me to also install the designed "stoppers" which was useful to me for a few reasons – mostly though the hall effect sensors were working great but at some point in the back-travel they would flip power rails and I didn't want to take this all apart and try to sort that (or, hell, try and code for it. That's some 'fix it in post' energy).

Also at this point I shoved a rod into an open hole on both the throttle posts to "join" the axis together and ended up cutting one of the hall effect sensors out of the arduino code entirely simply because having 2 thrust axis in Elite Dangerous wouldn't make a ton of sense. I can always remove this post and put the other axis back in the code if I need to.

But that was it for the throttle! Not as much re-doing or experimentation as the stick which was a nice change of pace.

The Macro pad

There are a lot of mappable controls in Elite Dangerous and it's pretty nice to have quick access to many of them, so I also decided to create a small macropad for anything else I would want a button for.

I also really wanted to try out these really cool looking keycaps from KBDCraft

Once they arrived, I started getting a rough idea of how I wanted the keys to be laid out for a single-hand ergo macropad

and then modeling a "plate" in blender to print and test the layout on

once I was happy with the placement on the test plate, I modeled the rest of the "case" for the keyboard, keeping it very simple and low profile. The bottom of the case would attach which several magnets around the edges of the inside of the top.

on the underside of the case I also added some extra rails for rigidity and some negative space to glue the microcontroller in place.

the switches themselves also ended up in little wells on the top so that the keycaps would sit in a way that would hide the switch bodies

Then I added the magnets, soldered up the switches to the controller, and made some choices on cap colors to wrap it up

Mounting everything

This is the thing that is probably most subject to change but mounting these so they weren't just sitting on top of my desks was important – they sit kind of tall so if I did that I feel like it would be like riding one of these motorcycles (no thanks).

An obvious choice was a VESA mount, especially since I have an extra monitor arm lying around at the moment.

Unfortunately the best way to mount the arm was "upside down" which is tricky since it wants to spring up against something as heavy as a computer monitor. It works, though, and I can leave it attached to my desk at all time since it swings in from the outside, it actually tucks away nicely!

But I also couldn't just leave the stick gimbal exposed and the microcontroller dangling by wires that were going to be moving back and forth a lot... so I had to get back to blender to model an enclosure that would house the gimbal and a hold a microcontroller rigged up with a ribbon connector

once that was all re-housed and re-wired to the controller I could put it back on the VESA

For the throttle for now I just tossed it on an old G5 tower (I have so many of these lol) and just slide it out as needed.

Then I just tossed the macropad on the laptop stand I use when this desk is for actual work and that was that! It took a bit to map all the controls in Elite but it is extremely fun and I'm surprised in the end how well it all worked!

Listen: Bandcamp YouTube Music Spotify

I've been trying and failing for so long to commit myself to releasing some solo songs – but today's the day!

It's a small release – a 2 sided-single – but I'm really excited about it :]

While Princess Barbara used to be a collaboration between Pat Coyle and I, it's currently moving forward as a solo project and I'm proud for this to be the first step in that journey.

Much of the instrumentation and song writing for this project used to be heavily based around patches created in Crystal SoftSynth. I used to sit for hours tweaking sounds in that VST or more often rolling the dice on the breed feature:

Patch breeding enables you to create new patches which are combinations of existing patches [...] Select a father patch and a mother patch. Optionally select an amount of mutation, which will introduce a degree of randomness which is not directly derived from either the father or mother. Then press the "Breed" button to create a new patch. (Caution: you can sometimes get unpleasant sounds, so be ready to press Breed again [...]).
- Crystal user guide

But I've gotten really into hardware synthesizers lately so this single is another kind of first step – the shift from Princess Barbara being a band with a limitless instrumentation palette to one limited by the physical instruments I have here at the "studio." Gone are the MIDI horns and the CPU-melting VSTs and the decision paralysis that comes with that – I want to finish more songs now.

Side A of the single, Frend, follow this new "rule" almost entirely – I do think there's one computer synth in there technically.

Side B, Return to Amender, is actually a resurrection of an old sketch done when I was still writing with Pat. That song used to have a ton of Crystal sounds in it and an entirely different vibe and chorus that all got removed. I kept the first vocal melody and Pat's drum parts that went along with that but re-wrote everything around it, gave the song a new chorus, and buttoned it up. I always really regretted that we never finished this one and I kinda wish I knew what it would have sounded like if we had... but all that considered I'm happy with how it ended up.

There is a spoken work portion of Return to Amender – it's from the speedrunner tomatoanus who explains how other runners beat games on youtube. In particular, this sample is edited from the explanation for How Speedrunners Beat Tony Hawk's Underground in 32 minutes, but he actually takes a break in all of these videos for this sentiment. There have been a lot of really down times in my life where I was watching his videos in the background and I heard this shit just when I needed it. It fit for the song for me, so it's there, just wanted to call it out.

For the cover art I reached out to an old pal I met working in software consulting, Alex Baratta. I follow him on Instagram and noticed he started experimenting with linocut around the time I was wrapping up the writing for the two songs. I am a sucker for most any kind of print and I really liked his style – so we agreed to collab! Just as I remembered Alex was wonderful to work with; he immediately had an idea of what he wanted to do and sent a ton of scans for me to pick from before sending my favorites in the mail. I think it turned out _perfect_:

TL;DR: listen to EP Pathwork here

During the initial covid isolation, friend Andrew and I started playing around with what we called "horizontal" song writing as an experiment. We released a single I wrote about here and it randomly got added to a pretty rad tape compilation for Infinito Audio Network.

Well, that magazine/label did ask us if we had more music for a solo tape. We did not have more music but decided to get to it, deciding to try and write a thematic EP.

The theme ended up being something like "spooky love songs" or perhaps "romance with ill intent" and we ended up with 6 tracks we were pretty proud of! Unfortunately we did take a long time to do so – by the time we sent rough mixes to Infinito they either didn't like what they heard or had moved on and decided they didn't want to release the tape.

We did kinda just sit on it for a little bit, wondering if we should try to reach out to other small labels for help on physical copies, distribution, outreach.... but it does seem like that kind of work (sending countless emails) doesn't excite Andrew or I enough to do it effectively.

So, finally, here it is! The drums were written by friend Pat Coyle and the EP was mastered by the ever-kind David Klug

I have been long putting together an LZX video synth and with the eventual arrival of my TBC2 module I finally had a reliable way to send external video into the gear. While I initially had a lot of fun with an old VCR and thrift store VHS finds....well, it turns out having to rewind all those VHS' kinda sucks, hah. Then once they are rewound you have to fast-forward them to the actual content you want to see or at least past all the trailers and FBI warnings.

want to go straight to the code?
check out the repo here

So I decided I wanted to design and build a dedicated video player to be able to loop through smaller chunks of more curated content using a Raspberry Pi 4. My initial sketch looked like this:

The main features I laid out were:

• 12 Banks of 12 Clips
  • use a 7 segment display to show current Bank & Clip indexes
  • managed via a local web server/interface
• Radial Playhead to show progress of current Clip
• 6 Buttons
  • Mode: toggle between random/sequential playing of the current Bank
  • Prev: go to previous video in Bank
  • Play: toggle play/pause of Clip
  • Next: go to next video in Bank
  • Hold: loop current Clip indefinitely (toggle)
  • Shft: shift button. hold and use Prev/Next to switch Banks

It all seemed pretty doable from a high-level!

First thing I did was try and source the components for the 'Radial Playhead' and Segmented Displays just to make sure they were something I could find and work with reasonably. Of course, Adafruit had everything I needed, including the libraries and helpful documentation to take out a lot of guess work. I grabbed a 12 pixel Neopixel Ring for the Playhead and a 4-Digit 7 Segment Display for the Bank/Clip indicators. I would have preferred 2 2-digit displays as I sketched out, but they only had the 4-digit variety over there and it came included with a "backpack" to handle all the i2c matrix nonsense so it was a no-brainer. Once they all showed up in the mail I started plopping everything down:

Not bad! I got all the main interface hardware on a breadboard and wired it up to the power and the Raspberry Pi. Which meant I had to get started on the actual software side of the project.

The first part of the software I went after was creating the web server/interface to manage the Banks and Clips on the machine. I was inspired by how norns used a local web interface for its own management and building a norns was also the last time I used a Raspberry Pi so it easily came to mind. Since I am not really worried about security as this is only accessible through LAN, I went with a simple flask app. It did take me a full weekend of working on/off to get all this work done, but I think it has all the features you'd want:

• Upload files from the computer accessing the web interface
• Download YouTube videos straight to a Bank
  - optionally provide start/end timestamps to only download part of the video
• Rename Clip
• Re-order Clip in Bank
• Delete Clip

Once that was all done, I could move on to sorting out how to actually play and loop content on the Pi.

After searching around I landed on MPlayer because it seemed to have good documentation and had playlist support which I thought might come in handy as a representation of a Bank.

It took me a little bit to figure out how to manage MPlayer best from the python script that was my main Clip player application. Sparing boring tales of trial and error I ended up using MPlayer in "Slave Mode." This mode allowed me to send MPlayer commands via stdin, which is how I would issue the commands to go to the next clip, etc. Combining that with pexpect meant I could spawn a process of MPlayer in "Slave Mode" and issue it commands, then wait for and read responses while still handling button presses in the app code.

Once I finally was able to upload clips to the device via the web interface and play them with MPlayer, I could actually test the full content loop for the first time:

Once I had this proof of life, I could write the rest of the code to implement all of the features I lined out above – I was lucky to be able to include them all! The application code can be viewed here if you're curious to see how I accomplished that.

Back to the circuit! I had all the buttons wired up and their respective functions working in the software, but I still hadn't made this thing LZX/Eurorack compatible, i.e I had yet to add voltage control.

I quickly made a circuit for a voltage control input with my best attempt at negative voltage protection, over-voltage protection, proper impedance, and amplification.

The protections were to stop any damage occurring to components down line in the circuit or any GPIO pins on the Pi itself if any incoming voltage was outside a safe range. I added an amplifier to the end of this part of the circuit so that voltage as low as ~1v would be scaled up to something that the Pi GPIO would detect (>= ~3.3v). LZX format synths usually work in the 0-1v range which is what motivated this addition.

Just after the amplifier I added a single signal diode that will share a Cathode with a diode trailing the Button paired with the voltage input. This should create a passive logical 'OR' between the voltage controlled input and the button so that if they are activated at the same time the voltage doesn't stack. I could/should have added a high value resistor to ground at this same node but I think the internal pull down at the GPIO should suffice.

It should probably be noted that I'm a total novice when it comes to analog circuit design and there are probably better and cheaper ways to accomplish my goals in general, and especially in this case.

That voltage input was the last part of the circuit I need to move on to designing the PCBs! There was going to be one for the control board (where the buttons and voltage input circuits would be) and a "hat" for the Pi connected by a ribbon cable. I decided to use KiCad so I first had to convert my breadboard into a schematic with actual part footprints that could be brought into the PCB designer.

I did replace the quad level-shifter I had on the breadboard with a more discreet single level-shifter in the final schematic since I only needed the one.

Once that was done I could do the actual PCB layout and get them manufactured. This took a week or so per board so I had to do a little waiting.

But they did arrive!

The first thing I did was solder up a control board and test it against the breadboard version of the Pi hat just to make sure that was working properly. I also did create a ribbon cable helper for the breadboard to help.

Now with all the circuitry and software pieces complete, I had to finally bite the bullet on making some kind of enclosure. I am novice enough at analogue circuit design, but this was an even larger uphill battle for me as I've never had the attention span to really learn Blender past the very basics, but I headed on as the plan was to 3D print the enclosure.

I started by making sure I could get a good fit for the pi and the control board, even that took more than a couple tries for me

After much trial and error I eventually did end up with some kind of enclosure. I wasn't really that happy with it but I got it to the point where I could at least test fit everything. It was just so blocky and tall.

A big part of me didn't want to, but I took it back to the drawing board at this point. I really felt that after stumbling through Blender for a week to get here and picking up some knowledge I could make something better in a shorter amount of time.

The first thing I did was tilt the control board in Blender to try and get some vertical space back, I moved it up a bit as well.

Then I brought in reference models for the Radial Playhead and the 7 Segment display and tried get a good position for those.

From there I just shaped a Plane to the profile of the new layout of all the components. After extruding that to the proper width I could start to make it an actual box, i.e removing inner volume and separating top & bottom. Then there was the busy work of punching all the IO and thread holes... As I predicted it was not long before I had something I was much happier with.

Some lightly rounded corners went a very long way but I think the overall shape is much more pleasing and interesting now as well! It also come out pretty decent in the print!

Now that I had an enclosure I was more proud of I could move on to adding the threads and wiring everything up. Most of this was pretty simple...the one thing that I would like to change in another iteration of this enclosure is the 'captive' Radial playhead, though. At the moment you have to solder the Playead wires after they are already routed and connected on one end, just not ideal.

After wiring everything up I could finally turn it back on! Looking prettttyyy good.

This was my very first time taking a circuit/gizmo idea from literal sketch to working "product." I've never completed a real schematic before in proper software and definitely hadn't designed and gotten my own PCBs milled. The whole Blender process was such a big hill to climb in its own right.

I used to look at schematics and PCBs with total awe, thinking there would never be a way I could understand let alone make something like that. This feels incredibly cool.

I'm still using Obsidian and I'm still using that "Good Reads for Games" plugin I wrote about a bit ago.

Since then I've built a nice gaming PC for myself and lot of my gaming has been more split between more platforms (previously I was almost exclusively playing switch games with the occasional PS4 title). I of course also became a much heavier Steam user which has a fantastic Wishlist feature that most people use pretty frequently.

This presented a new redundancy problem for me – I was hearing about games and adding them to my Steam Wishlist....well then I'd have to remember to add them to my backlog in my Obsidian Vault. THEN when I got a notification that a game on my Wishlist was on sale I had to remember to move my vault file from my internal "wishlist" to "owned backlog" upon purchase. This was super annoying and no doubt games get lost in the shuffle.

So I set out to add Steam integration to my Game Search Plugin. And I did! Introducing 0.2.0 of Game Search, live now.

While the new feature does require you to get a Steam API key and do a few more set up steps, it has at the very least solved my problem of having two sets of "backlogs" to maintain. (One easy thing to miss is that your Wishlist on Steam must be set to Public to be queryable!)

After entering your Steam credentials in the plugin settings you can invoke Sync Steam as a command. It's important to note that this can take some time, especially for larger libraries, since the plugin has to iterate over each game in your Steam Library and Wishlist and try to match it with a game in your vault OR from the RAWG API, then either create a new file (requiring another RAWG Api call) or update the matched one with the proper metadata.

By default all the Steam Sync actually does is ensure that there is a file for all the games in your Library and Wishlist and that they have a steamId metadata property.

In the Settings for the Game Search Plugin there are two text fields, metadata for owned Steam games and metadata for wishlisted Steam games. Use these fields to inject metadata key/value pairs into wishlist and library games upon sync.

For example, my metadata for owned Steam games looks like this:

owned: true
owned_platform: steam

And my metadata for wishlisted Steam games looks like this:

owned: false
status: backlog

So now I can differentiate between wishlisted and owned games through the metadata of the game files!

Right now the injected metadata for Steam games does not support templating or any kind of variable injecting and instead relies on hard-coded values like the above examples but I could see adding on some kind of templating feature in the future if it's requested enough.

This was all I needed to solve my problem! Hopefully it helps others, though while it is working on my machine please feel free to open an issue on Github for any bugs or feature requests!

One more thing...

There is another thing that's been bothering me about my Game Search plugin.

There is a feature buried in the Settings page to Regenerate all of your game files based on your Template file. The idea behind this is that you might change how you want your files to be generated but you already have many many files built on an old template.

Until now, using this feature would completely regenerate your notes so you would lose any and all non-templated content to the process.

This bothered me as a fan of "keepsake" games – I actually do take notes in some of these game files to remember tasks or secrets, or of course to solve puzzles. Regenerating all the files to a template would lose all of my important, actual game notes.

So now the Regenerate button works differently – the only portion of your existing game files that is regenerated is the metadata, the rest is left alone. I have a hunch this fits better with how folks use the plugin but I'm eager to hear if I'm way off base.

One important piece to this is that while the previous metadata for a file gets blown away during Regeneration, steamId and any custom metadata provided via metadata for owned Steam games or metadata for wishlisted Steam games will be copied over to the newly regenerated metadata for preservation.

It's been a couple years since I got to work professionally on Swift applications, and I have to say, I miss it! The language has always been super attractive to me as someone who prefers to more defensive and opinionated environments.... yeah, I kinda like thinking about memory!

So I'm looking to get back into the Swift game, but the language has released a lot of updates since I last used it professionally on the GiantEagle grocery app (oddly under two different companies, Giant Eagle themselves and Hatched Labs. Not worth getting into here but basically the former bought the latter and moved all their mobile dev over to them).

I've had to watch from the sidelines (& with little test projects to keep up) as Swift finally got async/await syntax among so many other features. Even SwiftUI finally became more viable as a framework, something we only got to experiment with at GiantEagle/Hatched (our application was built on UIKit and Auto Layout).

Then there was The Composable Architecture! I had been hearing a lot of rumbles about this redux-elm-like, swift-first framework and I wanted to try it out since we were using RxSwift at GE/Hatched.

So over the recent holiday I set off to make a tiny complete application with SwiftUI and The Composable Architecture, using Realm for local data storage. The choice to use Realm was another attempt to broaden my experience – I haven't used it in so many years and definitely not in a uni-directional Swift application. In hindsight I wish I could've spent more time understanding how I could cleanly fit Realm in a bit better, and that's something I definitely look to improve after this initial work.

I grew up in State College PA, so I have always been a big fan of The Arboretum at PSU. In an often over-crowded campus this is a beautiful reprieve and the staff works really hard to make sure it's always alive and changing. In the last few years they opened their Pollinator Garden which was an insanely large and incredible expansion of an already inspiring space. It's one of the last great human-managed things in State College to check out – if you get a chance you must go.

The Arboretum also served as a great subject for this little micro-app project. The staff at The Arboretum keeps meticulous amounts of data on their collections and have a nice interactive ArcGIS/ESRI map with all the plants mapped out on their property. Opening that map and looking at the network tab of your browser will expose the actual requests for the map data, here's the url of the request I ended up using:

https://apps.pasda.psu.edu/arcgis/rest/services/PlantFinder_Combined_Accessions_01212019/FeatureServer/0/query?f=json&returnGeometry=true&spatialRel=esriSpatialRelIntersects&geometry=%7B%22xmin%22%3A-8668570.5047493%2C%22ymin%22%3A4983694.245496575%2C%22xmax%22%3A-8667959.008523071%2C%22ymax%22%3A4984305.741722804%2C%22spatialReference%22%3A%7B%22wkid%22%3A102100%7D%7D&geometryType=esriGeometryEnvelope&inSR=102100&outFields=*&outSR=4326&resultType=til

Actually, that request is slightly modified. The value for the query param `outSR` has been changed from its original value to `4326`, which signifies that we want our returned data to be projected into Web Mercator space (id found here). The map as it exists on the web is projected in NAD 1983 space, which makes sense since that projection seems to be focused on the continental United States and the Arboretum map has no need for accuracy outside of that.

But, alas, iOS maps (like many other tools) project in Web Mercator space. So I had to look up that proper projection id to make sure all of the map annotations didn't appear dozens of meters away from where they should be when I went to add them to the iOS map.

After about a week of poking at this in between holiday plans and family visits, I did complete the app. It's not published on the AppStore or anything since it is really just an educational tool for me, but perhaps I will add more polish and release it some day. Check out the code and some screen grabs below, if you're interested in a little more info on some choices, features, and challenges keep scrolling past that.

Check it out on Github!

The app uses the latest/new SwiftUI Map to drive the main exploration view. There was one main challenge with this, however, just in that the Arboretum has a lot of plants on their Plant Finder map...my dataset is even currently missing that giant pollinator garden I mentioned earlier, but still drawing all the markers on the map at once was causing some serious performance issues. You wouldn't notice it too much scrolling around the map or zooming in/out but there were two very nasty side effects. The main issue was that tapping on a map annotation seemed to be causing the map to do a redraw pass on all of its annotations before my navigation code was able to execute, causing there to be a multi-second delay between an annotation tap and seeing the plant detail view. The less show-stopping but equally annoying issue was that on the initial draw of all the annotations the map seemed to take a broad and then narrow phase of actually placing the annotations, causing items to be drawn in the wrong spot on app load before seemingly re-drawing and correcting itself. As a quick sanity check I reduced the amount of items being drawn from almost 3k to 10 and those bugs were gone so I knew what the culprit was for sure. I was not able to test if annotation clustering would reduce the problem since it is not yet supported on the new SwiftUI maps, but I have a suspicion it wouldn't have helped much since the underlying mapkit logic would still have to process all that data to visually cluster it.

The only way I could quickly solve this performance problem was simply to limit the user to being able to look at one area of the Arboretum at a time. The data I ripped from the web map included a location field for the plants that denoted (by simple string, unfortunately) where they were within the Arboretum. I added a navigation bar drop-down control so the user could select which area to view and the map would only draw the markers for that area. This change significantly helped those major performance issues... unfortunately some of these locations still contain a lot of data (looking at you, Children's Garden) so there is still sometimes a small but annoying nav delay for detail pages in those more dense areas but nothing close to what it was before.

Once that was all sorted I was able to try and put Realm in for the map data. I created a main AppView/Reducer to host the TabView and read the actual data, then write it to Realm. This way the MapReducer didn't have to interact with that data layer at all, and instead subscribes to the Realm collection for the map items and just draw them, which felt a lot cleaner and makes app start up super snappy after the first open. I couldn't quickly find a lot of examples online for integrating Realm with the latest Composable Architecture, so I'm hoping to think more on this and improve the code to be more readable and extendable over some more time....but it seems to work for okay now!

I also used Realm to store some kind of "User Settings" and some idea of the "Last Session State" so that I could allow a user to decide what portion of the Arboretum map to load on app-start, which felt like it would soften the blow of not being able to see all the data at once. The user can decide to always open the map on the last area they selected, or if they'd rather, always have it open on a specific location. The latter is a little brittle since the data is all scraped and the location field in there are just "magic strings", but I have to work with what I got. In the case of mis-aligned or missing location data the app should just fall back to using the last selected location since that is always tracked in the separate "Last Session State" Realm object.

And that's about it for now! I have a couple of open issues on GH as of writing this for both bugs and ways to improve the experience...hopefully I'm able to do so soon!

I HAVE FINALLY DONE IT. So many abandoned games lay in my waste but it has always been a goal of mine to make some kind of video game. It's an art form I've really come to appreciate more and more especially as I've started and failed to complete so many over the last decade or so.

Background

Making games is hard. A new kind of hard. Coming up with what feels like a compelling idea is a challenge in any art but making a game feels like it demands something much more -- the difficulty in hooking and maintaining player engagement sounds similar to, perhaps, writing a movie or a song but --  because the player is an (inter)active participant in the piece the maker is presented with a new and task of creating a balanced challenge for the player. The extra addition of interactivity and the expectation players have when installing any kind of video game really narrows the sweet spot of success.

Then of course there's the more obvious difficulty of just how much raw work goes into game making. Game logic must be programmed, possibly even physics simulations; art must be created -- that means the concept of characters to all the possible animations to the background to the menu screens; music must be written and recorded to fit the game; sound effects have to be carefully designed and implemented. Not only do all of these needs span across multiple (and deep) art specialties, the scale of all of it all even for a small game is overwhelmingly intimidating...and it grows exponentially with game complexity.

Luckily there's a lot of tools out there to help bootstrap people into game making. Fully-fledged and ubiquitous game engines like Unity and Unreal seemingly make up a large portion of indies and even some AAA games and the former even has an OpenSource alternative in the form of Godot. Engines like these at their very basic help with scene management, playing and rendering art/music, input handling, and other functionality that just about every game needs. Many (like the ones listed) go way further, adding physics simulation, lighting, pathfinding, and countless other useful tools. ALSO for the engines mentioned there are robust collections of extensions and tools other developers have made in order to improve workflow even more. That is really all to say that the complexity of making games is softened at least a little by the existence of flourishing (& free) communities and tools as game making has become more accessible for folks of all skill levels.

My first game sits on the shoulders of many tools, the first being the platform itself: the Panic Playdate

What a lovely little console. Y'all know I love specialty and novel hardware and I'm so glad there are designers out there still making and supporting stuff like this. The main oddities are thus: the playdate has a 1-bit (black and white only) screen with no backlight that reads closer to eink....and there's a crank. Pretty "quirky" or whatever! I preordered one after they were announced and waiting my long ass time to get one (the parts shortages ahhhhhhh). Since then I've really enjoyed lurking the communities and playing as many games as I can manage -- some are truly inspiring!

The extra great thing about the playdate is that it is also a devkit. Anyone can just download the SDK, start making games, uploading them to their device, and sharing them with folks to test. It is so encouraged to make games for this console that the company who makes them created a web app for people with no programming or game dev knowledge to jump right in (called pulp). You don't even need to have a playdate device in hand yet to give game dev a try on the platform -- the SDK comes with a simulator!

I feel that the experience developing for the playdate is not unlike the famous PICO-8. By imposing many limitations on the game designer and providing an easy-to-iterate experience the playdate developers are encouraged to be focused but explorative. Especially with the SDK's Lua support, trying out a quick idea just to see if it works on the console is a breeze and makes it easier and more fun to "feel out" what works as you discover the potential (or lack of potential) for an idea. After many failed attempts to build games in the larger engines mentioned earlier, this felt like a great place for me to be.

But I still left many unfinished playdate scribbles unfinished in my quest. I started a little pinball game, a tattooing minigame, a rhythm game, and I even tried to create an impuse based physics engine to use in other projects. None of them quite got finished or panned out how I liked.

Then came a nice set of coincidences. My girlfriend decided to head home to see her family one weekend and happened to tell me the moment I saw a tweet reminding me of PlayJam4 happening over the same few days. Daylight savings time had just ended and there's a lot less daylight and warmth to go around outside so I would have plenty of time to try and complete something for this jam. The theme was announced that Friday ("Your Time Is Up") and I got to scribbling.

Getting Started

All of my previous (unfinished) playdate projects had been written 100% in C for my own stubbornness and learning opportunity. I'm a criminal when it comes to premature optimization and I don't get to program that low level very often so that had so far been my language of choice for playdate dev. That was going to change for this, though, as I knew I needed to be able to iterate a lot faster and not get hung up on memory issues. So, I looked around all the sample apps in the PlaydateSDK that use the Lua language and checked out existing tools that might exist for that environment.

Lucky for me, switching to Lua opened up a ton of libraries and examples to work from as it seems most stick to this environment for playdate dev, at least as of now. For my project I ended up using the Noble Engine which just made for really simple "Scene" and input management. It also nicely provides a template repository so I just cloned that and got to it! The one other library I used was AnimatedSprite which simplifies playing sprite animations from an imagetable (a collection of images in the playdate sdk) and adds state management to sprite animations. I think NobleEngine has its own animation system that I probably should have looked into deeper but this worked out fine for me.

With the theme being declared, "Your Time Is Up," the fastest idea I had on paper was only "something about a grim reaper." There was a vague image in my head of a 2D platformer type game where the player would play as a grim reaper and control their scythe with 1:1 crank movement....What came would be a bit different in gameplay but the overall idea stuck.

Art

While I had to use a lot of pre-existing assets, I did end up drawing quite a bit! Like many, I love aseprite so that's my pixel art editor of choice. I ended up doing the art for the main player character (a grim reaper sort) and their weapon.

For other character art I would have to leverage opengameart a lot. I am not super speedy at pixel art (or any good at it in any other way) so being stubborn about painting every pixel was not going to get me across the finish line. Specifically for this game I grabbed Stendhal Ghost and MV Platformer Male.

I also did all of the environment pieces, health bars, secondary screens (game over, etc), and all the metadata art for the game (images that show up on the device for the eventual installer). Showing some examples here will also expose that the game's eventual name was Scythe Shepard, though that was a pretty last minute decision.

Lastly I did also use Pixel FX Designer to create a little particle explosion sprite animation for the ghost death.

Gameplay

Initially I had imagined a single screen game with a flat floor and 3 static platforms with the idea being to survive as long as possible. There would be enemy characters appearing on the edges of the screen and following the user to attack them -- the player would have to use the crank to swing their scythe and kill an attacker. After a short time the dead attacker would turn into a ghost and start floating up towards the top of the screen. The player would need to switch to a "Net" weapon that behaved the same as the scythe but was used to catch ghosts and stop the ghost from leaving the top of the screen. This would give the player two game-crucial goals to balance -- don't get killed by the attackers and don't let too many ghosts get off screen. I felt this would provide enough healthy stress to the player to make it feel like a real game.

As the deadline loomed, though, I ended up changing the verticality of the idea a lot to cut down on (mostly) art work -- adding jumping animations to all the characters was a bit of a non-starter.

So, the "Net" weapon got scrapped, as did the 3 static platforms. Instead of the net to catch the ghosts I added some Speaker looking devices to the top of the screen and forced the ghosts to try and escape out of the middle there. Once the ghosts were close enough to their escape the user could activate the little speakers and they would kill any nearby ghosts.

This ended up being the entire gameplay loop as I was otherwise occupied with bug fixes, art, and sound; the only thing left to work out was the "difficulty curve." I ended up making it so that the game was played in "waves" -- each wave would spawn n human enemies where n was the wave number. The number of humans spawn at once was n/5 rounded up -- this meant that every 5 levels the game would increase the enemies spawn at once by one, making the player have to deal with more simultaneous threats as they progress. Simple, but effective enough in test play ... my biggest concern was players having too easy a time and having to put down the game out of boredom before it overtook them.

Speaking of play testing, this was an exciting thing to do! I wish I had more time and testers, of course, but this felt like a big moment....even if it was just my sister/BIL.

Sound

Let's get this out of the way -- I didn't have time to make music! This bums me out greatly, but I simply ran out of time and really feared making a quick loop that was just dreadful to listen to over and over. I also felt that adding music would require adding a "Settings" screen to allow the user to toggle the music/on and off and I didn't want to add that work either.

What I did gladly get to do is some quick sound design on the eurorack gear. Nothing very complex but here's a quick video of me trying to find the last bit of the sound that would play when a player swung the scythe and hit something (note: you may need to turn your volume up a little, this might be quiet.)

I really enjoyed making all the little sounds for this and next time hope to have more time to experiment and make more interesting and unique fodder -- such a unique challenge!

Submission and voting

After a couple days of constant work, I turned in my game along with about 20 other folks! Some of these I was really excited to try out since some devs were posting work-in-progress stuff on twitter.

Now that everyone was submitted, it was time for a week-long voting phase where everyone (participators and spectators) were encouraged to try to play and rate the other games on the categories of "fun," "creativity," and "use of console." Each game also has a comment section in the jam -- these were immediately readable while we would have to wait the full week to see any results from the ratings.

I got way more feedback on my game than I expected during the voting phase. I am often a little disappointed on the amount/depth of feedback I get for music so this was really fun for me. I think what helped draw in the reviews, though, were of course the contained context of the game jam, the specialty of the hardware, and the fact that games are interactive and much easier (I think) for someone to have more concrete responses to. Either way, it makes me excited to try another jam in the future! The whole community for both game dev and especially playdate dev in my experience has been so positive :]

That written feedback was so valuable to me I almost forgot about the week long numerical/categorized voting... I did end up getting 4th (out of 21) overall which ain't bad! Didn't come on top in any individual category but that doesn't surprise me or anything. Just happy I finished and people tried the game.

So happy to have climbed this mountain, even if the game is pretty small. It feels real!

I've always admired monome's work but never got my hands on any of their hardware. Like a lot of folk I was mostly drawn in by their grid controller ages ago...never pulled the trigger on one of those. Got very close a few times to grabbing a teletype, and still might some day – it would certainly make a lot of sense for me. The lines forum is a gem on its own.

What brought me first to norns though was the complete DIY spirit of the project both in hardware and software. You can buy an official machine from monome themselves (and it has many extra QOL upgrades over the raspberry-pi version I built here) but I was very interested in using this project as an excuse to try ordering PCBs from a manufacturer myself – I've never actually done that before!

Though no longer officially supported by monome as an open source hardware project, it was originally and the repo is still out there. It even has a few different hardware revisions – I chose the `210330` revision as suggested by the README and paired it with a Raspberry Pi 3B+ by the same recommendation. I should note, however, that the audio codec chip (CS4270) is marked as "scheduled for obsolescence" when I ordered the components from a supplier.

To my joy ordering the PCBs was actually very simple. The repo had EAGLE files and a quick web search walked me through creating the gerber files from those. Got those uploaded to some manufacturer's site, luckily they looked over it and helped correct a trivial drilling template issue, and then the boards showed up a couple weeks later!

I did have to order 5 PCBs minimum...gonna be giving away some norns I guess.

There was a sort of inherent trust at this point that the EAGLE files in the repo and the instructions I followed to create the drilling files were all accurate... but everything looked really good and clean and the right size and all that! The most reasonable way to know for sure (to me) was just to start soldering.

Though I've done pretty tight surface mount soldering before, this felt... tinier and tighter. The biggest and most obvious worry was that 24 pin codec chip

And for the sake of honesty I did burn through one of these codec chips and had to order another...I also then waited for smaller solder tips and thinner solder to arrive which would prove very helpful – I did not burn another chip!

Finally got it. The other nice thing about having the EAGLE files for the boards was that it was very easy for me to see where the pins were connected and test to make sure everything was solid and nothing was shorted. There are a lot of snake bites on the board for that already but it was nice to just use the board file to be sure.

The rest of the work was pretty boring surface mount stuff, one particularly annoying clock...a lot of the tightness of the layout was relieved by the smaller tips & solder I ended up buying.

Even testing as I went I did have a few panic moments, though – the first norns I put together didn't seem to boot. I followed the troubleshooting section of the monome site and was able to deduce that the machine was booting, I just wasn't seeing anything on the display. A quick re-flow of the screen component and I was up and running!

The second I built didn't boot at all at first, which was certainly concerning. I did the typical thing – took a long break, came back, and very closely looked at every joint and re-flowed any suspicious ones. It booted! But it displayed an error message about the audio server (jack) not being able to start. Assuming this would be an issue with the codec chip, I went back to testing those pins again. Turns out the reflow that fixed the boot also bridged a subsequent connected pad to a (very) nearby ground snakebite. Sucked that up, carefully reapplied solder, retested, and we were good to go.

I whipped another up right after the first one worked because I was going on a little music-writing trip with a friend who's birthday was also coming up and felt he might appreciate some of the odd norns scripts/apps out there.

The case is 3D printed, maybe someday I'll make something nicer for an enclosure. To be honest, I'd like to get to writing apps for it first but even now my eyes are on other music-related projects so I'll have to come back to the norns to dig deeper.

Until then I'm really excited to check out the existing community scripts and I'm happy to have unlocked "using a PCB manufacturer."

I love Obsidian. I use it to keep longer term reference notes for work and for personal projects. I'm hardly a power user though, some people go pretty heavy, its a very powerful tool with a dense community plugin repository.

Elsewhere I also have been constantly frustrated that there isn't a simple video game backlog management website/app/service. Something close to goodreads in simplicity of managing your "shelves" of books.

Then - poof - I came across several Obsidian tutorials (like this one) where folks were using the community plugins dataview and book search to create and manage their own book backlog & reviews. This was perfect: I didn't need or want the social features of goodreads, just the ability to list and organize some metadata around games with some degree of flexibility. Obsidian was again the answer.

There was no game search plugin to match book search, but luck would grace me again as not only is book search open source but the code is also very clean! So I quickly forked it annndddd....

here's the link for the game search Obsidian plugin

and here is the Github

Installation & Configuration

game search can be installed from within Obsidian community plugins and must be provided at least a RAWG Api Key in the plugin settings. You can request an API key from RAWG here. If other API providers are desired feel free to open a github issue!

I do recommend also changing the settings to use a new folder for your new game files so they don't crowd your vault. It's also recommended to provide a template file in the settings to insert yaml metadata to your game notes so that you can query them with dataview. The available properties returned from the RAWG Api and an example template file are in the README of the repo.

The plugin adds a command to the palette, "add new game note." This brings up a text search which, when executed, will result in a list of suggestions of games accompanied by their release year to help distinguish any similar titles. Selecting one of those creates a new note for that game in your vault!

I keep it pretty simple – here's what my "game shelf" looks like (dataview code example below):

the data view for "Playing" section, for example:

That's that! I got what I wanted – a very simple (and local!) way to manage my own little game backlog, notes, and reviews. With what comes back from the RAWG Api and the power of dataview I expect you might be able to push it a bit further if you'd like. If there's anything missing (or broken!) feel free to open a Github issue :]

Because I am restless I have begun to expand my eurorack format gear into the wild, expensive, and rare world of ~Video Synthesis~

While I have been slowly gathering some LZX modules after their GEN3 modules started rolling out, I've also been hanging out* on the LZX discord which has been helping me find other video synth makers. It's seemingly a much more DIY community than your typical eurorack group (which is saying something) so finding all these individual bespoke creators not only fun, but crucial.

The first non-LZX, non-prebuilt video gear I picked up was the Mainbow from Chroma Cauldron.

Aside from the attractive price for the features, I just wanted to do something more DIY and this machine included some cool features I wanted like external video input/processing and a basic audio analyzer to incorporate some more reactive elements from my audio tools.

One of the best parts – I must say – was the packaging of the kit itself. The PCB and the faceplate were wrapped and protected while ever other part was stapled to an enlarged BOM where it was marked what the part was and how many you should have. It basically took out the first 45 minutes or so of organizing and preparing that usually comes with pulling out a kit.

There was even an error in one of the resistor values on the silkscreen of the PCB so that single resister came pre-soldered to avoid any confusion with having to put a 'wrong' resistor in yourself according to the labeling. Top notch thoughtfulness.

Then of course the PCB layout itself was really well designed. All the resistors are in a neat row & everything was clearly marked – I had no issues whatsoever putting this together it almost felt too easy.

and so it came to plugging in and testing (without external input).

and then with external video! Here I plugged the output of a VCR playing an X-Files episode in and made it all liquid

So much fun! Now I just need to add more power and space to the existing LZX rack...