mixGUI

• 

  Splash screen

• 

  Actual screenshot

Inspiration

I am a software developer who also produces music. My idea was to combine current software ergonomics with music production and music theory so I get a useful tool to produce music. I also found it important to integrate AI into the mix - not the way commercial AI products work, but rather a helpful partner who makes is easier to create.

What it does

mixGUI is a desktop music production interface built around safe experimentation. This is a GUI built on one of my previous projects: mixDIFF, but makes the work user friendly.

A producer can:

• open or automatically generate a real mixDIFF project
• browse songs, arrangements, parts, MIDI clips, and instruments
• inspect MIDI content and arrangement timing visually
• move parts along a zoomable timeline
• render and audition the current song
• ask the Assistant for a musical change in natural language
• review the exact operations before anything is modified
• apply or discard the proposed plan
• inspect automatically created checkpoints in project history
• create manually described checkpoints
• undo an AI edit or check out an earlier version

How we built it

mixGUI is a native desktop application written in Object Pascal with Lazarus and GTK3 to have a cross platform experience.

It uses the mixDIFF project (https://gitlab.com/iso88592/mixDIFF) as its backend through the public C ABI and Pascal binding. The responsibilities are deliberately separated:

• mixGUI displays the project, handles interactions
• mixDIFF handles project storage, musical entities, rendering, validation, version control, and AI execution.

The GUI never uses the standalone mixdiff binary as its application backend. Operations pass through typed library calls. Rendering, Assistant requests, and history operations run on separate background threads so the app stays responsive. Completed operations are stored in an immutable project snapshot that can be applied and are shown in the interface.

Challenges we ran into

One of the largest challenges was turning free text musical requests into dependable operations. Early plans sometimes referenced invalid entities, repeated commands, or created objects without placing them in an arrangement which caused errors in the execution. These were all addressed with complete-plan preflight validation, bounded planning retries, project-state fingerprints, explicit Apply or Discard approval, automatic checkpoints and rollback.

Since my dev environment was Wayland on Linux, many other GTK related challenges surfaced and I had to experiment how to handle these in a cross platform way.

Accomplishments that we're proud of

I am especially proud of completing a real end-to-end AI music-editing workflow while integrating it to an existing project:

A producer submits a natural-language request -> the selected AI model produces exact operations -> the producer reviews those operations -> mixDIFF validates and applies them -> the arrangement visibly updates -> a checkpoint appears in history -> the entire edit can be reversed.

The reviewed plan is executed exactly as shown. It is not silently reinterpreted by a second model call.

We are also proud of the deterministic offline test suite. It verifies the most important Assistant and history behaviors without spending provider tokens merely to test plumbing.

Other project highlights:

• an idempotent demo project is generated on the first execution
• native GTK3 dark theming
• isolated Wayland validation
• responsive background rendering and Assistant jobs
• readable snapshot names alongside exact hashes
• manual checkpoints with custom descriptions
• accurate region lengths and draggable arrangement parts
• scale-aware MIDI-note previews
• a moving playback cursor during rendered audition

What we learned

I learned that reliable AI integration is a workflow-design problem, and making a good harness is hard. For a creative application we also need:

• precise context
• constrained operations
• non-mutating previews
• deterministic validation
• explicit approval
• understandable progress and error states
• automatic recovery
• visible history

I also learned that musicians and developers often need the same underlying capabilities presented differently. A commit is essentially a checkpoint, instead of using diffs, we use musical changes.

Most importantly, reversibility changes the relationship between a creator and an AI Assistant. Like in every AI project, we don't blindly accept what the AI generates. We experiment, try out what happened, and either accept or reject it.

What's next for mixGUI

I focused on implementing complete features, but the current version is far from a usable DAW.

Here are the next major steps that are needed for the project:

• embedded live playback, seeking, and looping
• generated waveform caches and waveform editing
• a complete piano-roll editor
• live recording of instruments
• mixer, routing, automation, and plugin workflows
• recording and audio-device configuration
• richer branches, comparisons, merges, and conflict handling
• recent-project and workspace persistence

The long-term vision is a fully functional (but not realtime) DAW where manual edits, AI-assisted changes, and version history are parts of one coherent creative workflow.

Built With

• daw
• music
• pascal
• version-control