Independent Project

Personal Information Systems

Creating clarity from complexity in my own creative workflow

Personal Project · AI-Assisted Development · Information Systems

One of the phrases I've started using to describe the kind of work I do is "Creating Clarity From Complexity."

Most of my professional examples involve communications, operations, reporting, dashboards, knowledge systems, and digital experience.

But I've realized that I apply the same thinking to my own projects.

I'm a musician, and I play keyboards in several rock-oriented bands, spanning a wide range of repertoires, performance settings, and musical demands. I own a collection of keyboards, but three of my primary gigging instruments — the Korg Triton, Korg Nautilus, and Roland AX-Edge — presented particularly interesting information-management problems.

Each instrument has its own capabilities, limitations, documentation, sounds, custom patches, set lists, performance notes, and accumulated knowledge.

The information wasn't missing.

There was simply too much of it, and it wasn't organized around the way I actually used the instruments.

The Problem

Keyboard manufacturers do a good job documenting their instruments. The manuals can tell me exactly what a particular parameter does.

But that's usually not the question I'm asking.

The question is more likely to be:

I've got rehearsal tomorrow. I need a sound for this particular part of this particular song. Which of these thousands of programs should I start with?

Those are very different questions.

The manufacturer's documentation is designed to explain the instrument. I needed something designed around using the instrument.

I also had information that existed nowhere in the manufacturer's documentation: my own patches, set lists, performance notes, backup history, hardware concerns, and plans for future projects.

So I built systems that brought all of that information together.

The Solution

Using Kiro, an AI-powered development environment, I built personalized local reference sites for each instrument.

These aren't copies of the manuals. They're purpose-built information systems that combine three different layers of knowledge:

Manufacturer documentation

Manuals, parameter guides, voice lists, editor documentation, and other reference material are extracted and reorganized into searchable web content.

Personal instrument data

My actual programs, combinations, set lists, performance notes, backup information, hardware details, and other instrument-specific information become part of the system.

Creative workflow

The sites also support the work I'm actually trying to accomplish: identifying candidate sounds for songs, planning layers, auditioning patches, tracking progress, and documenting decisions.

The result is a reference system that is organized around my workflow rather than the manufacturer's information architecture.

Turning Documentation Into Usable Information

The source material for these instruments is substantial.

Across the three systems, I've processed more than 1,500 pages of manufacturer documentation, along with thousands of individual program and sound definitions.

For the Korg Nautilus alone, the system includes:

  • 269 pages of Operation Guide material
  • 965 pages of Parameter Guide material
  • 309 pages of Voice Name List information
  • 1,792 individual program entries
  • Information covering multiple sound engines and instrument modes

Rather than repeatedly searching through PDFs, the information is transformed into structured data that the site can search, filter, organize, and present in the context of the instrument.

This is one of the areas where AI-assisted development has been particularly useful. The difficult part wasn't writing a web page. It was doing the tedious work of extracting, interpreting, structuring, and organizing a large amount of information.

Making the Keyboard's Own Data Accessible

The Nautilus presented a different problem.

The instrument stores its configuration in a proprietary .PCG backup file. That file contains information about programs, combinations, set lists, and other instrument state, but it isn't something I can simply open and browse on my computer.

I used Kiro to investigate the binary structure of the files and build tools capable of extracting useful information from them.

That allowed the support site to surface information that previously existed primarily inside the keyboard.

The system can identify custom combinations, their bank and slot locations, set-list relationships, and performance notes I've recorded for them.

It can also show which banks are being used and which are available for future work.

That's an important distinction.

The project isn't simply creating better documentation.

It's turning previously inaccessible or fragmented information into something I can actually work with.

From Reference Tool to Creative Workspace

The most interesting evolution was moving beyond reference material.

I'm currently preparing sounds for a new musical project. For each song, I can define the kinds of sounds I need and provide the musical context.

The system can then work through the available programs and identify candidates.

For example, instead of simply searching for "bass," I can describe the character I'm looking for in the context of the song. The resulting candidates can then be auditioned on the actual keyboard.

The Nautilus also allows me to build combinations using multiple timbres, so the system can help me think beyond individual programs and consider complementary layers.

The workflow becomes:

Identify → Search → Evaluate → Audition → Select → Build → Document

As I work through the songs, the system tracks progress and records the decisions I've made.

At that point, the support site has stopped being a manual.

It's become part of the creative process.

Three Instruments, Three Approaches

The three systems aren't identical because the three instruments aren't identical.

Korg Triton

The Triton is a 1999-era instrument with aging hardware, legacy operating-system limitations, and a very different approach to backup and configuration. Its support system therefore places more emphasis on hardware considerations, documentation, programs, combinations, and practical reference information.

Korg Nautilus

The Nautilus presented the largest information-management challenge. Its support system incorporates extensive searchable documentation, thousands of programs, proprietary backup-file extraction, set-list cross-referencing, performance notes, backup tracking, and creative sound-development workflows.

Roland AX-Edge

The AX-Edge required a different approach because much of its editing workflow is built around its companion mobile application. Rather than reproducing a large parameter database, the support system focuses more heavily on the editor workflow, connectivity, patch management, and practical operating procedures.

The principle stayed the same. The implementation changed to fit the problem.

What AI Changed

I could have built these systems manually.

I probably wouldn't have.

The amount of information extraction, parsing, restructuring, cross-referencing, and repetitive development involved would have made the project impractical for a personal tool.

AI-assisted development changed that equation.

Kiro helped me move between very different kinds of work:

  • Extracting information from hundreds of pages of PDFs
  • Transforming documentation into structured data
  • Analyzing proprietary binary files
  • Identifying relationships between different data sources
  • Generating interfaces around those data structures
  • Building search and filtering functionality
  • Organizing creative workflow information
  • Iterating on the systems as I discovered new requirements

The important part isn't that AI built the sites for me.

I still had to understand the problem, decide what the system needed to do, evaluate the results, and determine what information was actually useful.

AI made it practical for me to turn those ideas into working tools.

The Broader Lesson

This project reinforced something I've seen repeatedly in my professional work:

Complexity isn't necessarily the problem. Unstructured complexity is.

The information already existed.

It was in the manuals. It was in the backup files. It was in the keyboards. It was in my notes. And some of it was in my head.

The challenge was creating a system that connected those pieces in a way that matched the work I was actually trying to do.

That's what I mean by Creating Clarity From Complexity.

At work, the "user" might be a stakeholder, an editor, a developer, a leader, or an entire operating team.

Here, the user is me.

The domain happens to be keyboards and music rather than enterprise operations.

But the underlying approach is the same:

Understand the information. Understand the workflow. Find the friction. Build the system that makes the complexity useful.

What This Project Demonstrates

This personal project combines several capabilities that also inform my professional work:

Information Architecture
Structuring large amounts of information around how people actually need to use it.
Systems Thinking
Understanding relationships between documentation, data, tools, and workflow rather than treating each as an isolated problem.
AI-Assisted Development
Using AI to accelerate exploration, data transformation, development, and iteration.
Workflow Design
Designing tools around the actual sequence of decisions a user needs to make.
Data Transformation
Turning PDFs, proprietary data, and other difficult-to-use sources into structured, accessible information.
Human-Centered Design
Starting with the user's real-world need rather than the structure of the source material.

Creating Clarity From Complexity

I didn't set out to build three information systems for my keyboards as an example of professional methodology.

I built them because I needed them.

But that's probably why I find the project so satisfying.

The same instinct that leads me to build a dashboard instead of answering the same status question over and over, or to turn a collection of Word documents into a living knowledge system, led me to look at thousands of sounds and hundreds of pages of manuals and think:

There has to be a better way to work with all of this.

So I built one.