fLMCP turns FL Studio into a programmable MCP environment.

fLMCP started from a practical problem: FL Studio is powerful, but it was never designed to be driven by a language-model client. If we wanted reliable control, we needed more than hotkeys and screen scraping. We needed a bridge that understands the DAW's state model, timing model, threading constraints, and API boundaries.

The result is a local MCP server for FL Studio with 159 MCP tools and 7 live resources. It covers the parts producers actually touch: transport, patterns, channels, mixer, plugins, piano roll, playlist, arrangement, automation, project operations, high-level generators, microphone transcription, and audio-file analysis.

The hard problem is not "send a command to FL Studio."

Desktop music production software is not shaped like a normal web API. FL Studio has public Python modules, but those modules are loaded in different script contexts, not every operation is exposed, and the host application remains an interactive real-time program with a UI thread. A bridge that writes notes, moves mixer faders, queries plugin parameters, and records automation has to respect those constraints.

That makes fLMCP interesting for reasons beyond music. It is an example of turning a stateful GUI application into a structured agent environment without pretending the GUI has become a server. The system succeeds because it separates concerns that are often collapsed in automation projects:

• Observation is handled through resources such as `fl://project`, `fl://transport`, `fl://channels`, and `fl://mixer`.
• Mutation is handled through typed tools with explicit parameters and structured errors.
• Host safety is handled by running FL API calls on FL Studio's main thread, not in the socket worker.
• Piano-roll edits are routed through a dedicated piano-roll script because note insertion is only available there.
• Heavy audio dependencies are imported lazily so the core control plane remains lightweight.

The architecture is a bridge, not a bot.

fLMCP has three primary runtime pieces. The MCP server runs outside FL Studio and speaks stdio to the host. The FL-side controller script runs inside FL Studio as a MIDI controller script and opens a local TCP listener. The companion piano-roll script runs inside the piano-roll scripting environment, where FL exposes note-level editing APIs.

# conceptual request frame
request = {
    "id": 42,
    "action": "transport.setTempo",
    "params": {"bpm": 174.0}
}

# encoded as:
# uint32_be(len(json_payload)) + utf8_json_payload

This is a small design choice with large consequences. Length-prefixed JSON avoids delimiter ambiguity, supports binary-safe reads, and lets both sides reject oversized frames. Request ids let the client ignore asynchronous notifications until the matching response arrives. Push events make it possible to observe FL activity, such as transport ticks or project refreshes, without constant polling.

Why it works: fLMCP respects the host application's real constraints.

The important research move is that fLMCP does not model FL Studio as a text editor with hotkeys. It models it as a live, partially exposed system: some state is readable, some state is mutable, some APIs are context-gated, and some operations require user-visible UI interaction.

The piano-roll bridge is the key technical pivot.

The most fragile part of many DAW automation attempts is note-level writing. Step sequencers and transport controls are useful, but music composition requires adding notes, chords, arpeggios, humanization, quantization, and transposition. In FL Studio, the piano-roll note API is only available in piano-roll scripts.

fLMCP handles this by treating the piano-roll script as a specialized execution environment. The MCP side writes a request queue, opens the relevant channel's piano roll when possible, sends the configured hotkey, then waits for a state file written by the piano-roll script. The method is intentionally simple: file-based staging gives both sides an inspectable handoff and keeps the FL-only note API inside the place where it is valid.

# conceptual piano-roll operation
piano_roll_add_notes(
    channel=4,
    pattern=2,
    clear_first=True,
    notes=[
        {"midi": 48, "time_bars": 0.0, "duration_bars": 1.0, "velocity": 0.78},
        {"midi": 55, "time_bars": 0.0, "duration_bars": 1.0, "velocity": 0.78},
        {"midi": 60, "time_bars": 0.0, "duration_bars": 1.0, "velocity": 0.78},
    ],
)

# internally:
# 1. select channel and pattern
# 2. stage note edits as JSON
# 3. trigger the active piano-roll script
# 4. return exported note state

The tool surface is broad, but it is organized by musical intent.

A large tool catalogue is only useful if the model can reason about it. fLMCP groups tools by the same boundaries a producer already understands: transport, patterns, channel rack, mixer, plugins, piano roll, playlist, arrangement, automation, project state, generators, voice, and audio.

The companion resource layer gives the model a read path that does not mutate anything. That matters for agent reliability: before editing a session, an MCP client can inspect what is currently loaded and choose tool calls with more context.

Examples: from DAW operations to musical workflows.

The most useful fLMCP calls are not isolated button presses. They combine low-level state control with high-level musical primitives. A model can create structure, write notes, inspect the mixer, adjust routing, and iterate on the result while staying inside typed tool calls.

Create a pattern with drums, bass, and harmony.

pattern_create(name="Verse - 174 DnB sketch")
transport_set_tempo(bpm=174)

gen_emit_drum_pattern_step_seq(
    channel_map={"kick": 0, "snare": 1, "clhat": 2, "ophat": 3},
    style="drum_and_bass",
    repeats=2,
)

gen_emit_bassline(
    channel=4,
    root="C2",
    scale="minor",
    progression="i-VII-VI-V",
    pattern_style="octaves",
)

gen_emit_chord_progression(
    channel=5,
    root="C4",
    scale="minor",
    progression="i-VII-VI-V",
    chord_length_bars=1.0,
)

Use state resources before editing.

# conceptual agent loop
project = read_resource("fl://project")
mixer = read_resource("fl://mixer")
channels = read_resource("fl://channels")

target = find_channel(channels, name_contains="Sub")
if target is not None:
    channel_route_to_mixer(index=target.index, mixer_track=12)
    mixer_set_eq_band(track=12, band=1, gain=-0.2, frequency=180)

Turn a hummed idea into piano-roll data.

voice_to_piano_roll(
    duration_sec=8,
    bpm=120,
    scale_root="C",
    scale="minor",
    quantize_grid_sec=0.125,
    min_confidence=0.35,
    clear_first=True,
)

Analyze an audio file and generate a sketch from it.

analysis = audio_analyze(
    path="C:/samples/source_loop.wav",
    extract_melody=True,
    polyphonic=False,
)

song_to_dnb_flip(
    audio_path="C:/samples/source_loop.wav",
    target_bpm=174,
    dnb_style="amen",
    dnb_bars=4,
    include_melody=True,
    include_bass=True,
)

Voice and audio analysis make it more than a DAW remote.

The audio layer is intentionally optional. The core MCP server can start without `numpy`, `librosa`, `sounddevice`, `soundfile`, GUI libraries, or polyphonic transcription packages installed. Those dependencies are loaded only when a voice or audio tool is invoked. That keeps the base bridge usable for control and project automation, while still enabling richer workflows when the audio stack is present.

The monophonic voice path uses pitch tracking for humming and single-line melodies, then applies post-processing: confidence filtering, optional scale snapping, transposition, quantization, and conversion from seconds into bars at the selected BPM. Polyphonic mode uses a heavier transcription path for chords and overlapping notes when the extra runtime is available.

Useful applications beyond "AI makes a beat."

The obvious demo is generative composition, but the broader value is a programmable interface to a professional creative environment. fLMCP can support practical workflows where deterministic control matters.

Boundaries are part of the engineering.

fLMCP does not erase the limits of FL Studio's public Python API. It documents them and turns them into predictable behavior. That is why unsupported playlist clip placement, direct project rendering, some arrangement operations, and some plugin preset operations return explicit structured limitations instead of false success.

Quality model: test the bridge without requiring the DAW.

The repository is structured so much of the system can be validated offline. The protocol and bridge client can round-trip against a fake TCP bridge. Server construction can assert that expected tools and resources are registered. Pure helpers for audio key estimation, polyphonic note conversion, generators, and bridge helpers can be exercised without launching FL Studio.

This matters because desktop automation projects are often difficult to test. fLMCP keeps the FL-dependent boundary narrow enough that the surrounding protocol, schemas, conversion logic, optional dependency behavior, and musical helper functions can be validated in ordinary Python tests.

Future outlook.

The current architecture makes FL Studio addressable through MCP. The next work is less about adding one more button and more about trust: better state caching around push events, stronger verification after edits, safer multi-step composition plans, explicit undo checkpoints, and cleaner handling for DAW operations that still require UI interaction.

Longer term, fLMCP points at a broader pattern: professional desktop applications can become useful model-operated environments when we respect their runtime model. The lesson is not specific to music. Typed tools, read-only resources, local protocols, context-aware execution, and honest error surfaces are what make this feel like engineering instead of a screen-scraping trick.