[ jd303 ]

I have six hardware synthesizers. Each one has its own patch library, its own quirks, its own way of organizing sounds. Some of them have printed manuals. Some have handwritten notes taped to the wall. Some have .ins files that are supposed to tell my DAW what patches exist and where, except those files were wrong. Like, completely wrong.

The practical problem is this: when I sit down to write a track, I don't want to dig through menus on six different pieces of hardware trying to remember where I saved that acid bass patch or which synth has the pad I'm thinking of. I wanted a way to browse across everything, filter by feel, and get to work. That didn't exist, so I built it.

With Claude.

[ claude ]

What's an .ins File and Why Does it Matter

An .ins file is an instrument definition: a text file that tells your DAW the name and location of every patch on a hardware synthesizer. When it's correct, your DAW can send program change messages by patch name instead of just bank and number. You see "ThrilledBass" in a dropdown instead of "A:067." When it's wrong or missing, you're navigating blind.

The format is hierarchical: [INSTRUMENT] blocks containing [PATCH] entries with bank numbers, program numbers, and names. Simple in concept. The problem is that manufacturers don't always ship these, third-party versions float around the internet with errors, and user-created patches don't appear in them at all unless someone updates the file manually.

[ jd303 ]

What Was Built

Using Claude, I organized a complete synthesizer patch library spanning 2,172 patches across 6 synthesizers and created a custom web-based patch generator with a sick cyberpunk aesthetic. The whole thing is self-contained, works offline, and actually solves real workflow problems for music production.

The Cool Problem-Solving Stuff

Multi-Source Data Reconciliation: The data came from everywhere

  • Existing .ins files (some of which were completely wrong)
    • .ins are instrument definitions, which are ways that Digital Audio Workstations (DAWs) know how to communicate with a hardware synthesizer.
  • Screenshots of patch manager software, specific to each synthesizer
  • Printed patch lists with handwritten notes (they were taped to my wall with scribbles of music genres the sound could go into)

Handwritten patch genre classifications

  • User auditions with creative descriptions like "alien spaceship sound" and "says woeugh"
    • Yes, I re-listened to about 80 patches and typed notes.
  • Claude and I had to cross-reference all of this and figure out what was actually correct.

Reading Between the Lines

I had to get creative with some patch identification. For example, there was a Moog patch called "4WAKEMAN." With an Internet search using context and musical knowledge, Claude figured out this referenced Rick Wakeman (the prog rock keyboardist) and categorized it as a lead patch. This kind of domain expertise was critical throughout in identifying many patches that had no description. Sometimes Claude had to be coached, other times it was highly (and surprisingly) accurate. As another example, it deduced a sound called "Sea Ess Hatey" was probably a knock off of the CS-80 Yamaha synth (it was right).

The Moog Little Phatty Situation

The existing .ins file was completely inaccurate. I used 4 screenshots of the actual synth library manager showing the real patch names. Claude went through them line-by-line, and Claude discovered:

  • 3 custom user patches replacing factory sounds: *CBass, *ThrilledBass, *CAcidLead
  • Multiple name discrepancies
  • Completely rebuilt the .ins file from scratch with all 100 correct patches
  • ...actually, I was lazy and just took pictures of the screen with my phone...

MicroKORG From Scratch

I had an .ins file that was basically useless. Just had "A11, A12, B11, B12" with no actual patch names. I used Claude to:

  • Extract all 128 real patch names from screenshots and printed pages*
    • ...actually, I was lazy and just took pictures of the printouts with my phone...
  • Read handwritten genre labels (Trance, House, DnB, Breaks, Electronica)
  • Categorized everything based on sound descriptions, or search the Internet for ideas for descriptions
  • Built a complete .ins file with proper bank positions and names

Poly Evolver Numbering Fix

The original file had completely wrong patch numbering. I had Claude, again, analyze screenshots* and printouts*, figured out the actual structure (4 banks x 128 patches), and rebuilt the entire thing with correct A001-D128 numbering.

  • ...guess why these have an *...

Poly Evolver SoundEditor bank listing, page 1 Poly Evolver SoundEditor bank listing, page 2 Poly Evolver SoundEditor bank listing, page 3

[ claude ]

The Data Problem

Getting to a correct .ins file for each synth meant reconciling multiple imperfect sources at once. Claude can read images: phone photos of screens, photos of printouts, screenshots. The workflow for each synth: photograph the source material, extract patch names and bank positions, cross-reference against the existing .ins file, resolve conflicts.

Any patch Claude couldn't identify from its name or description alone got researched by cross-referencing the name against known synth culture, musician references, and sound design conventions to determine category and likely character. That's where things like "4WAKEMAN" and "Sea Ess Hatey" got figured out. It's not just OCR. It's pattern matching against a lot of domain knowledge.

[ jd303 ]

End Result

Deliverables:

  • 16 markdown reference files (all patches categorized)
  • 3 corrected .ins files (ready to load into DAWs)
  • Complete hyperlinked navigation system
  • Gear list included, with descriptions, manufacturer links, technical specifications, etc.
    • Includes my other items like drums, guitars, mixers, etc.

Patch Breakdown:

  • Bass: 247 patches
  • Leads: 709 patches
  • Pads: 373 patches
  • Arpeggios: 121 patches
  • Symphony: 202 patches
  • Percussion: 296 patches
  • Plus vocals, keys, SFX, etc.
[ claude ]

One Bug Worth Mentioning

168 orchestra patches were showing up as "Unknown" synth. Root cause: nested markdown headers. The patch files use subsections under each synth's header, and the parser was losing the parent synth context when it hit a subsection, treating subsection headers as new top-level entries with no attribution.

Fix was updating the parser to track parent header context through nesting levels. All 202 symphony patches attributed correctly after that.

Worth noting: this one took a few attempts. The actual solution came from the user digging into the variables and pointing at the specific problem. Five minutes of hands-on debugging, then it was done.

[ jd303 ]

Did he just refer to me as a "User"?

Part 2 covers what came next: building an actual patch generator app on top of this library, with Reaper DAW integration and a cyberpunk UI. That's a different kind of project.