DEV Community: Melogen

Building a Piano Roll Editor From Scratch in React

Melogen — Tue, 03 Mar 2026 15:36:04 +0000

No libraries. No canvas. Pure React + DOM + math. Here's every decision I made and why.

I'm building Melogen — a web editor that turns AI-generated music into editable MIDI. The centerpiece of the UI is a piano roll: the same grid-based note editor you'd find in FL Studio, Ableton, or Logic Pro.

Except I built mine from scratch in React, using nothing but div elements, pointer events, and coordinate math.

This is how it works, what went wrong, and what I'd do differently.

Why Not Use a Library?

I tried. Here's what I found:

abcjs — Renders sheet music notation, not a piano roll grid. Meant for displaying, not editing. I initially used it for parsing ABC notation but ended up replacing it with a custom parser because the library had rendering side effects I couldn't control.

MIDI.js / Tone.js — Audio playback libraries, not visual editors. Tone.js handles the sound. I needed something to handle the screen.

Canvas-based editors — A few exist on GitHub. But canvas means you lose React's component model, accessibility, and the ability to style notes with CSS. Every interaction becomes manual hit-testing.

I wanted notes to be real DOM elements. Clickable, draggable, style-able, inspectable in DevTools. So I built it with divs.

The Coordinate System

A piano roll is a 2D grid:

X axis = time (beats / bars)
Y axis = pitch (MIDI note numbers)

The fundamental challenge is converting between three coordinate spaces:

Musical space:  { bar: 3, offset_beats: 1.5, midi: 67, dur_beats: 0.5 }
         ↕
Grid space:     { col: 14, row: 5, width: 2_columns }
         ↕
Pixel space:    { left: 672px, top: 110px, width: 96px, height: 22px }

Every interaction — click, drag, resize, playhead sync — requires round-trips between these three spaces.

Musical → Pixel

const PX_PER_BEAT = 48;    // each beat = 48 pixels wide
const PIANO_WIDTH = 56;     // left sidebar for key labels
const HEADER_HEIGHT = 20;   // top bar for bar numbers

function noteToPixel(note: FlatNote, rowHeight: number, beatsPerBar: number) {
  const totalBeat = note.bar * beatsPerBar + note.offset_beats;
  return {
    left: PIANO_WIDTH + totalBeat * PX_PER_BEAT,
    top:  HEADER_HEIGHT + (maxMidi - note.midi) * rowHeight,
    width: note.dur_beats * PX_PER_BEAT,
    height: rowHeight,
  };
}

Notice maxMidi - note.midi: higher pitches go up on screen (lower Y value), which means the MIDI axis is inverted. I got this wrong the first time and spent an hour wondering why all my notes were upside down.

Pixel → Musical (for drag operations)

function pixelToMusical(clientX: number, clientY: number, gridRect: DOMRect) {
  const relX = clientX - gridRect.left - PIANO_WIDTH + scrollLeft;
  const relY = clientY - gridRect.top - HEADER_HEIGHT + scrollTop;

  const beat = relX / PX_PER_BEAT;
  const midi = maxMidi - Math.floor(relY / rowHeight);

  // Snap to grid
  const snappedBeat = Math.round(beat / snapBeat) * snapBeat;
  const bar = Math.floor(snappedBeat / beatsPerBar);
![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a55rmi6jitgljqcfrx85.png)
  const offset = snappedBeat - bar * beatsPerBar;

  return { bar, offset_beats: offset, midi };
}

The snapBeat parameter controls quantization. 0.25 snaps to sixteenth notes. 0.5 snaps to eighth notes. Users don't see this math — they just feel their notes "locking" into place.

Rendering the Grid

The grid has several visual layers, rendered bottom-to-top:

Row stripes — alternating colors for white/black piano keys
Vertical lines — beat divisions (thicker every bar)
Horizontal lines — pitch rows
Notes — colored rectangles
Playhead — vertical line during playback
Selection marquee — rubber-band rectangle

All of these are absolutely positioned divs inside a scrollable container.

Black Key Detection

const NOTE_NAMES = ["C","C#","D","D#","E","F","F#","G","G#","A","A#","B"];

function isBlackKey(midi: number): boolean {
  return NOTE_NAMES[midi % 12].includes("#");
}

Black-key rows get a darker background. This is pure cosmetics but makes the piano roll instantly readable — you can see octave boundaries at a glance.

Beat Lines

const totalBeats = bars * beatsPerBar;
const lines = [];

for (let b = 0; b <= totalBeats; b++) {
  const isBarLine = b % beatsPerBar === 0;
  lines.push(
    <div
      key={b}
      style={{
        position: 'absolute',
        left: b * PX_PER_BEAT,
        top: 0,
        width: 1,
        height: fullHeight,
        background: isBarLine 
          ? 'rgba(148,163,184,0.4)'   // strong line at bar boundaries
          : 'rgba(51,65,85,0.6)',     // subtle line at beats
      }}
    />
  );
}

I also add sub-beat lines at sixteenth-note intervals (every PX_PER_BEAT / 4 pixels) with very low opacity. They're invisible until you zoom in, but they give the grid a "real DAW" feel.

Note Rendering

Each note is a rounded rectangle with three interaction zones:

┌──────────────────────────┐
│ ◄──── body (drag) ────► ▐│ ◄── right edge (resize)
└──────────────────────────┘

function NoteBlock({ note, index }: { note: FlatNote; index: number }) {
  const pos = noteToPixel(note, rowHeight, beatsPerBar);
  const isSelected = selected.includes(index);

  return (
    <div
      style={{
        position: 'absolute',
        left: pos.left,
        top: pos.top,
        width: Math.max(pos.width, 6), // minimum visible width
        height: pos.height - 2,        // 1px gap between rows
        borderRadius: 3,
        background: isSelected ? SELECTED_COLOR : trackColor,
        cursor: 'grab',
      }}
      onPointerDown={(e) => handleNotePointerDown(e, index)}
    >
      {/* Resize handle */}
      <div
        style={{
          position: 'absolute',
          right: 0,
          top: 0,
          width: 6,
          height: '100%',
          cursor: 'ew-resize',
        }}
        onPointerDown={(e) => {
          e.stopPropagation();
          startResize(e, index);
        }}
      />
    </div>
  );
}

The Math.max(pos.width, 6) is critical. Very short notes (a thirty-second note at normal zoom) would be 6 pixels wide — too small to click. The minimum width ensures every note is always grabbable.

Drag & Drop: The Hard Part

Dragging notes requires tracking three distinct modes:

type DragMode = 'none' | 'move' | 'resize' | 'create' | 'marquee';

Move vs. Click Disambiguation

When a user presses down on a note, they might want to:

Click it (select)
Drag it (move)

I distinguish these with a dead zone:

const DRAG_THRESHOLD = 4; // pixels

function handlePointerMove(e: PointerEvent) {
  if (dragMode === 'none' && dragStartRef.current) {
    const dx = e.clientX - dragStartRef.current.x;
    const dy = e.clientY - dragStartRef.current.y;

    if (Math.hypot(dx, dy) > DRAG_THRESHOLD) {
      setDragMode('move');
    }
    return;
  }

  if (dragMode === 'move') {
    // Calculate new position with snap
    const newPos = pixelToMusical(e.clientX, e.clientY, gridRect);

    // Apply delta from original position
    updateNote(dragIdx, {
      bar: newPos.bar,
      offset_beats: newPos.offset_beats,
      midi: newPos.midi,
    });
  }
}

Without the dead zone, every click would turn into a tiny drag, and notes would jump by one pixel on every selection.

Resize

Resizing changes only the duration, not the position:

if (dragMode === 'resize') {
  const relX = e.clientX - gridRect.left - PIANO_WIDTH + scrollLeft;
  const endBeat = relX / PX_PER_BEAT;
  const startBeat = note.bar * beatsPerBar + note.offset_beats;

  let newDur = endBeat - startBeat;
  newDur = Math.max(snapBeat, Math.round(newDur / snapBeat) * snapBeat);

  updateNote(dragIdx, { dur_beats: newDur });
}

The Math.max(snapBeat, ...) prevents notes from being resized to zero or negative length.

Creating Notes

Clicking on empty grid space creates a new note:

function handleGridClick(e: PointerEvent) {
  if (e.target !== gridRef.current) return; // only on empty space

  const pos = pixelToMusical(e.clientX, e.clientY, gridRect);

  const newNote: FlatNote = {
    bar: pos.bar,
    offset_beats: pos.offset_beats,
    midi: pos.midi,
    dur_beats: snapBeat * 4, // default: one beat
    vel: 80,
  };

  setLocal([...local, newNote]);
}

Deleting Notes

Double-click or Delete key. I chose both because DAW users have different muscle memory:

// Double-click on note
function handleNoteDoubleClick(index: number) {
  const next = local.filter((_, i) => i !== index);
  setLocal(next);
  onChange?.(next);
}

// Delete key for selected notes (ripple delete)
function handleKeyDown(e: KeyboardEvent) {
  if (e.key === 'Delete' || e.key === 'Backspace') {
    const next = local.filter((_, i) => !selected.includes(i));
    setLocal(next);
    setSelected([]);
    onChange?.(next);
  }
}

Multi-Select with Marquee

Rubber-band selection was the most technically fiddly feature. The marquee is a translucent rectangle that appears when you drag on empty space:

const [marquee, setMarquee] = useState<{
  x0: number; y0: number; x1: number; y1: number;
} | null>(null);

// During drag on empty space:
setMarquee({
  x0: startX,
  y0: startY,
  x1: currentX,
  y1: currentY,
});

// Render:
{marquee && (
  <div style={{
    position: 'absolute',
    left: Math.min(marquee.x0, marquee.x1),
    top: Math.min(marquee.y0, marquee.y1),
    width: Math.abs(marquee.x1 - marquee.x0),
    height: Math.abs(marquee.y1 - marquee.y0),
    background: 'rgba(99,102,241,0.2)',
    border: '1px solid rgba(99,102,241,0.6)',
    pointerEvents: 'none',
  }} />
)}

On pointer-up, I check which notes intersect the marquee rectangle:

function getNotesInMarquee(marquee, notes) {
  const rect = normalizeRect(marquee);

  return notes.filter((note, i) => {
    const noteRect = noteToPixel(note, rowHeight, beatsPerBar);
    return rectsOverlap(rect, noteRect);
  });
}

Shift+drag adds to the existing selection. Plain drag replaces it.

The Piano Keyboard (Left Sidebar)

The left sidebar shows piano key labels. It scrolls vertically with the grid but stays fixed horizontally:

<div style={{ 
  position: 'sticky', 
  left: 0, 
  zIndex: 10,
  width: PIANO_WIDTH 
}}>
  {Array.from({ length: maxMidi - minMidi + 1 }, (_, i) => {
    const midi = maxMidi - i;
    const isBlack = isBlackKey(midi);
    const label = midiToLabel(midi); // "C4", "F#5", etc.

    return (
      <div
        key={midi}
        style={{
          height: rowHeight,
          background: isBlack 
            ? 'linear-gradient(to bottom, #111827, #020617)'
            : 'linear-gradient(to bottom, #f9fafb, #e5e7eb)',
          display: 'flex',
          alignItems: 'center',
          justifyContent: 'flex-end',
          paddingRight: 4,
          fontSize: 10,
          fontWeight: label.startsWith('C') ? 700 : 400,
          color: isBlack ? '#e5e7eb' : '#111827',
        }}
      >
        {label}
      </div>
    );
  })}
</div>

C notes are bold — they mark octave boundaries and help with visual orientation. It's a tiny detail but every DAW does it for a reason.

Playhead Synchronization

During playback, a vertical line sweeps across the grid, synchronized to Tone.js:

useEffect(() => {
  if (!isPlaying) return;

  const playheadX = PIANO_WIDTH + playBeat * PX_PER_BEAT;

  // Auto-scroll to keep playhead visible
  const viewport = viewportRef.current;
  if (viewport) {
    const viewLeft = viewport.scrollLeft;
    const viewRight = viewLeft + viewport.clientWidth;

    if (playheadX > viewRight - 100 || playheadX < viewLeft) {
      viewport.scrollLeft = playheadX - 200;
    }
  }
}, [playBeat, isPlaying]);

The playBeat value comes from the parent component, which uses Tone.Transport.position converted to beats. The piano roll doesn't know about audio — it just receives a number and draws a line.

{isPlaying && (
  <div style={{
    position: 'absolute',
    left: PIANO_WIDTH + playBeat * PX_PER_BEAT,
    top: 0,
    width: 2,
    height: fullHeight,
    background: 'gold',
    zIndex: 20,
    pointerEvents: 'none',
  }} />
)}

Scrolling: The Performance Trap

With 16+ bars and a 3-octave range, the grid can be thousands of pixels wide. Scrolling must be smooth.

My first approach: a giant container with all notes rendered. This worked until about 200 notes, then React's reconciliation got slow.

The fix: viewport culling. Only render notes that are visible:

const visibleNotes = local.filter((note) => {
  const px = noteToPixel(note, rowHeight, beatsPerBar);
  return (
    px.left + px.width > scrollLeft - 100 &&
    px.left < scrollLeft + viewportWidth + 100
  );
});

The 100px buffer prevents pop-in at the edges during fast scrolling. Grid lines still render for the full width (they're cheap), but notes only render when visible.

I also switched from scroll events to tracking scrollLeft via a ref:

const [scrollLeft, setScrollLeft] = useState(0);

const onScroll = useCallback(() => {
  const el = viewportRef.current;
  if (el) setScrollLeft(el.scrollLeft);
}, []);

This avoids re-rendering on every pixel of scroll — the state only updates when React needs it for note culling.

Dynamic Grid Sizing

The grid should always be wide enough to show all notes plus room to add more:

const EXTRA_EMPTY_BARS = 8;

const maxBarFromNotes = local.reduce(
  (max, n) => Math.max(max, n.bar + Math.ceil(n.dur_beats / beatsPerBar)),
  0
);

const totalBars = Math.max(
  bars,                          // minimum from props
  maxBarFromNotes + EXTRA_EMPTY_BARS,  // extend past last note
  16                             // absolute minimum
);

const gridWidth = totalBars * beatsPerBar * PX_PER_BEAT;

The 8 extra empty bars mean you can always scroll past your last note and add more. As you add notes at the end, the grid grows automatically.

Row Height Auto-Scaling

The row height adapts to the container size and pitch range:

const rowsCount = maxMidi - minMidi + 1;
const availableHeight = containerHeight - HEADER_HEIGHT;
const rowHeight = Math.max(ROW_MIN_PX, availableHeight / rowsCount);

ROW_MIN_PX (22px) prevents rows from becoming too tiny when the pitch range is large. If there are too many rows to fit, the container scrolls vertically.

What I'd Do Differently

Use useReducer instead of useState for notes. The local state management got complex with undo/redo potential. A reducer with action types (MOVE_NOTE, RESIZE_NOTE, DELETE_NOTES, CREATE_NOTE) would be cleaner.

Implement virtual scrolling for grid lines too. With 64+ bars, rendering thousands of grid-line divs is wasteful. A canvas underlayer for the grid with DOM overlays for notes might be the best of both worlds.

Add touch support earlier. Pointer events mostly work on mobile, but pinch-to-zoom and two-finger scroll needed special handling that I bolted on late.

Consider position: sticky for the header bar. My current implementation manually tracks scroll position for the bar-number header. CSS sticky positioning would have been simpler.

The Numbers

The final component is about 800 lines of TypeScript. It handles:

Rendering 16-64 bars of music
3-5 octave pitch range
Click, drag, resize, create, delete, multi-select
Playhead sync with external audio engine
Keyboard shortcuts
Scroll-based viewport culling
Snap-to-grid quantization
Multiple selection with marquee

No external editor library. No canvas. No contentEditable. Just React, TypeScript, pointer events, and a lot of coordinate math.

The component is a controlled input — it receives notes and onChange, just like a text field. The parent component owns the data. The piano roll just renders it and reports edits.

If you want to see it in action, paste any AI-generated melody into melogen.app and start clicking around.

This is Part 3 of a series on building Melogen. Part 1: How I Built a Web Editor for AI Music. Part 2: Parsing Music JSON from 4 Different LLMs. Next: Using LLMs as a Music Mix Engineer — With Fallback Chains.

Tags: react typescript music webdev

I Asked ChatGPT, Claude, Gemini, and Grok to Write a Pop Song. Here's What Actually Happened.

Melogen — Sun, 01 Mar 2026 13:12:56 +0000

Same prompt. Same key. Same tempo. Four completely different ideas about what music should feel like.

Last month I built Melogen — a web editor that lets you import AI-generated melodies, play them back on a piano roll, edit them, and export to MIDI. The core idea is simple: LLMs can already write structured music data. What's been missing is a decent way to actually hear what they produced.
Once the editor was working, the obvious question became: which AI writes the best music?
So I ran the experiment properly. Same prompt, all four major models, zero human edits, imported straight into Melogen. What I found wasn't just a ranking — it was a surprisingly clear window into how each model thinks about creativity.

The Setup
The prompt was deliberately specific:
Compose a 16-bar melody in G major, 120 BPM, 4/4 time signature,
pop style, uplifting mood. Output as JSON with fields: tempo, key,
bars, notes array with bar, offset_beats, dur_beats, midi, vel.
Every model received this exact text. No system prompt. No examples. No follow-up nudges.
The output format — a JSON array of notes with bar position, beat offset, duration, MIDI pitch, and velocity — is precise enough to be musically unambiguous. There's nowhere to hide vague intent. Either the notes work or they don't.
I imported each response directly into Melogen without touching a single value. What you hear is the raw machine output.

The Results
ChatGPT — "The Textbook"
ChatGPT produced the most technically correct output of the four. The JSON was clean, the music theory was flawless, and there was a clear ascending arc from G4 all the way up to D6 across the 16 bars — a logical, well-structured build.
Here's a representative excerpt from its output:
json{ "bar": 1, "offset_beats": 0, "dur_beats": 1, "midi": 67, "vel": 96 },
{ "bar": 1, "offset_beats": 1, "dur_beats": 1, "midi": 71, "vel": 98 },
{ "bar": 1, "offset_beats": 2, "dur_beats": 1, "midi": 74, "vel": 102 },
{ "bar": 1, "offset_beats": 3, "dur_beats": 1, "midi": 76, "vel": 104 },
Notice anything? Every single note is dur_beats: 1 — a quarter note. This pattern holds for almost the entire melody. Occasionally you get a half note. Eighth notes — the engine of pop rhythm — are nearly absent.
The result sounds like a music theory exercise. Correct, logical, and rhythmically inert. Pop music lives in the spaces between the beats. ChatGPT stayed rigidly on them.
Verdict: Perfect for a schema validator. Not great for a dancefloor.

Claude — "The Songwriter"
Claude was the most surprising. Where ChatGPT treated rhythm as a formality, Claude leaned into it:
json{ "bar": 1, "offset_beats": 0, "dur_beats": 1, "midi": 74, "vel": 82 },
{ "bar": 1, "offset_beats": 0.5, "dur_beats": 0.5, "midi": 76, "vel": 80 },
{ "bar": 1, "offset_beats": 1, "dur_beats": 1, "midi": 79, "vel": 90 },
{ "bar": 1, "offset_beats": 2, "dur_beats": 0.5, "midi": 78, "vel": 84 },
{ "bar": 1, "offset_beats": 2.5, "dur_beats": 0.5, "midi": 76, "vel": 80 },
{ "bar": 1, "offset_beats": 3, "dur_beats": 1, "midi": 74, "vel": 86 },
Half-beat offsets. Syncopated pickups. Long-short-long phrasing. This is how a vocalist actually breathes. You can almost map words onto these notes without changing anything.
Claude also had the most natural velocity shaping — verse notes sitting around 78–88, chorus pushing into 90–100, with smooth transitions rather than sudden jumps.
The problem? The melodic ceiling is too low. The entire melody peaks at G5 (MIDI 79), barely an octave above the tonic. For a piece described as "uplifting," you need that moment where the pitch opens up and the chorus lifts. Claude never goes there.
There was also a format issue: Claude wrapped its JSON in inline // comments. Technically invalid JSON. If you're piping this into a strict parser, it fails immediately.
Verdict: The most musical output. Wrong style for the brief. Would excel on a different prompt.

Gemini — "The Architect"
Gemini produced the most structurally disciplined melody. Bars 4, 8, 12, and 16 all land on whole notes — clear cadence points that divide the piece into four balanced phrases. This is exactly what a human arranger would do to give a piece shape.
json{ "bar": 4, "offset_beats": 0, "dur_beats": 4, "midi": 74, "vel": 90 },
{ "bar": 8, "offset_beats": 0, "dur_beats": 4, "midi": 67, "vel": 100 },
{ "bar": 12, "offset_beats": 0, "dur_beats": 4, "midi": 74, "vel": 95 },
{ "bar": 16, "offset_beats": 0, "dur_beats": 4, "midi": 67, "vel": 110 },
The problem is that structural correctness isn't the same as emotional impact. The melody spends most of its time in the mid-to-low register, makes a single push upward in bar 11, and then retreats. There's no sustained climax, no energy arc. The velocity range is wide (80–120) but not attached to any meaningful musical shape — the loud moments don't land where you'd expect them.
Gemini also introduced a barline overflow bug in bar 13: offset_beats: 3.0 + dur_beats: 2 = 5 beats in a 4/4 bar. This breaks timeline-based editors. A small oversight, but a real one.
Verdict: The best skeleton. Needs a composer to fill it in.

Grok — "The Pop Star"
Grok's output was the most immediately engaging. From bar 9, the energy shifts register entirely — a clear verse-to-chorus transition that sounds deliberate, not accidental:
json{ "bar": 9, "offset_beats": 0, "dur_beats": 1, "midi": 81, "vel": 104 },
{ "bar": 9, "offset_beats": 1, "dur_beats": 1, "midi": 83, "vel": 105 },
{ "bar": 9, "offset_beats": 2, "dur_beats": 1, "midi": 86, "vel": 106 },
{ "bar": 9, "offset_beats": 3, "dur_beats": 1, "midi": 84, "vel": 104 },
MIDI 86 is D6 — nearly two octaves above the tonic G4. The arc from G4 in bar 1 to D6 in bar 9, sustained across bars 9–12, and then resolved back down is textbook pop structure. Verse establishes, chorus explodes, outro resolves.
The velocity progression tells the same story: 96 in bar 1, climbing to 108 by the chorus, never abruptly. The model understood that an "uplifting" piece should build.
There's one small issue: bar 13 has a note that exceeds the barline by a beat. In practice, this is a trivial fix in any editor — drag the note endpoint, adjust the duration, done. For a musician, it's a three-second correction. The underlying creative idea remains completely intact.
Verdict: The melody you'd actually want to finish producing.

What Each Model Gets Right
The most interesting thing about this experiment isn't the ranking — it's what each model's choices reveal about its internal model of "music."
ChatGPT treats music as a structured sequence with correct harmonic relationships. It optimizes for theoretical correctness. The output is exactly what you'd expect from a model trained on music theory textbooks.
Claude treats music as language — as something spoken by a human voice with natural rhythm and breath. It optimizes for phrasing. The result sounds singable because it was generated with the same attention to micro-timing that a vocalist would use.
Gemini treats music as architecture — as a system of phrases and cadences with clear macro-level organization. It optimizes for form. The output has a skeleton any composer would recognize, but no flesh.
Grok treats music as energy and emotional arc — as something that should feel like something. It optimizes for impact. The result is commercially viable in a way the others aren't.
None of these is wrong. A complete piece of music needs all four. The interesting question is which one you reach for first depending on what you're trying to make.

The Engineering Reality
Beyond musicality, there are practical concerns for anyone trying to use LLM-generated music in a real pipeline.
JSON validity: Claude's inline comments break standard parsers. A simple regex pre-processing step fixes this, but it's an extra step. The other three produce clean JSON.
Barline integrity: Both Gemini and Grok produced notes that overflow their bar boundaries (offset + duration > beats_per_bar). Any bar-based editor will either throw an error or silently misalign the timeline. Validation at import time is essential.
Velocity range: MIDI velocity maxes at 127. ChatGPT's output peaks at 115, which is technically fine but leaves little headroom. If you're layering multiple instruments, you'll clip.
Field naming: Claude used "key": "G major" where the others used "key": "G". Minor, but worth normalizing if you're building a parser that handles multiple models.
A minimal validation function before import saves a lot of downstream debugging:
javascriptfunction validateNotes(notes, beatsPerBar = 4) {
return notes.map(note => {
// Clamp velocity to MIDI spec
note.vel = Math.min(127, Math.max(0, note.vel));

// Flag barline overflows
if (note.offset_beats + note.dur_beats > beatsPerBar) {
  console.warn(`Bar ${note.bar}: note overflows barline`);
  note.dur_beats = beatsPerBar - note.offset_beats;
}

return note;

});
}

Final Rankings
For this specific task — uplifting pop, 16 bars, G major — here's how the models rank across two dimensions:
Musical quality (does it sound like a real pop song?):
Grok > Claude > ChatGPT > Gemini
Engineering reliability (can you pipe it directly into a parser?):
ChatGPT > Gemini > Claude > Grok
The ideal workflow, if you're building something production-ready, is to use Grok or Claude for the creative output and ChatGPT's format discipline as a validation target — or just run everything through a validation layer before import.

What This Means for AI Music Tools
We're at an interesting inflection point. LLMs can clearly generate musically coherent structured data. The gap isn't in the generation quality — it's in the tooling around it.
Most people who ask an AI to write music see a wall of JSON and stop there. They have no way to hear it, no way to edit it, no way to understand whether it's actually good. The creative output is trapped in a format that only makes sense to a parser.
That's the problem Melogen is trying to solve — not to replace the AI, but to make its output audible and editable. The models generate. You shape. The editor bridges the gap.
If you want to try any of the melodies from this article, they're all importable directly at melogen.app. Paste the JSON, hit play, and see what your ears think.

The full JSON for all four melodies is available on request. If you run the same experiment and get different results, I'd genuinely like to see them — the models update frequently and the outputs drift.

Tags: ai music chatgpt claude llm midi music-production generative-ai javascript web-audio

# How I Built a Web Editor That Turns AI-Generated Music Into Playable MIDI

Melogen — Wed, 25 Feb 2026 14:06:59 +0000

TL;DR: I asked ChatGPT to compose a melody. It gave me JSON. I had no way to play it. So I built Melogen — a free web editor that imports music data from any LLM, visualizes it on a piano roll, adds harmony and arrangement, and exports production-ready MIDI.

The Problem

If you ask ChatGPT, Claude, or Gemini to "compose a melody in C major, 120 BPM, output as JSON," you get something like this:

{
  "tempo": 120,
  "key": "C",
  "notes": [
    { "bar": 0, "offset_beats": 0, "dur_beats": 1, "midi": 60 },
    { "bar": 0, "offset_beats": 1, "dur_beats": 0.5, "midi": 64 },
    { "bar": 0, "offset_beats": 1.5, "dur_beats": 0.5, "midi": 67 }
  ]
}

Cool. Now what?

You can't drag this into GarageBand. Audacity won't open it. Your DAW has no idea what to do with it. The music is trapped inside a JSON blob.

I looked for a tool that could bridge this gap — something that takes structured AI music output and turns it into something you can hear, edit, and export. I couldn't find one. So I built it.

What I Built

Melogen is a web-based music editor designed specifically for AI-generated music. The workflow is:

Ask any LLM to compose music (structured JSON output)
Paste it into Melogen
See it on a piano roll, hear it instantly
Add harmony, bass, drums, and arrangement with one click
Export multi-track MIDI for any DAW

It's free at melogen.app.

Here's what the editor looks like in action:

(If you're reading this on Dev.to, imagine a dark-themed piano roll with colored note blocks, a 6-track mixer on the left, and playback controls at the top.)

Tech Stack

Layer	Technology
Framework	Next.js 14 (App Router)
Language	TypeScript
Styling	Tailwind CSS
Audio Engine	Tone.js + custom synth patches
MIDI Export	Custom encoder (no heavy libraries)
Auth	Magic Link (Resend + Supabase)
Payments	Lemon Squeezy
Hosting	Vercel
AI Mixing	Multi-LLM with fallback (Grok → Deepseek → Llama via OpenRouter)