Neothesia: A Cross-Platform MIDI Practice Visualizer

Why Neothesia Exists for Piano Learners

Neothesia addresses a specific learning need: connecting the symbolic contents of a MIDI file with the physical positions of piano keys. Its input is music data in a MIDI file, and its output is a virtual piano populated with colorful falling blocks. The project describes this as a way for people to learn how to play piano more quickly, although that wording should not be read as a measured guarantee of learning speed.

The project exists partly because the README says the open-source Synthesia implementation was abandoned in favor of a closed-source commercial product. Neothesia presents itself as an attempt to restore an open-source implementation of that concept and improve its appearance and behavior. That context explains both its design target and its most obvious comparison point. It is not attempting to be a general-purpose DAW or a piano performance workstation.

Its intended audience includes learners who want visual feedback while practicing from MIDI material. The repository includes `test.mid`, which gives developers a concrete MIDI fixture for the core use case, although the README does not provide a step-by-step lesson based on that file. People who need automatic accompaniment, notation editing, recording, or professional audio production should not assume that a MIDI visualizer covers those jobs. Neothesia's documented scope is narrower: loading MIDI notes and showing where they occur on a virtual keyboard.

Rust Workspace and MIDI-to-Screen Data Flow

The repository is a Cargo workspace with Rust edition 2024. Its default member is `neothesia`, while shared or specialized functions are separated into packages including `neothesia-core`, `midi-file`, `midi-io`, `piano-layout`, `wgpu-jumpstart`, `ffmpeg-encoder`, `neothesia-image`, `neothesia-cli`, `neothesia-ai`, and `nuon`. This layout indicates that file parsing, MIDI input or output, keyboard layout, graphics, encoding, and interfaces are separate concerns rather than one monolithic desktop binary.

The visible core flow is straightforward. MIDI notes enter through the `midi-file` package when a file is selected. `neothesia-core` represents the shared application logic, and `piano-layout` supplies keyboard-related layout logic. Rendering is connected to `wgpu`, with `wgpu-jumpstart` acting as the workspace's graphics abstraction. The README calls the result colorful falling blocks over a virtual piano, which turns timed note events into both visual motion and a key-position cue.

The dependency list adds evidence about supported capabilities but does not by itself prove that every feature is exposed in the default application. `winit` and `dpi` relate to the windowing layer, `rfd` to native file dialogs, and `cpal`, `fluidlite`, `oxisynth`, and `midir` to sound or MIDI facilities. `ffmpeg-encoder` and `neothesia-image` occupy separate workspace members, while `neothesia-ai` depends on tensor and audio decoding crates. The README does not explain the AI component's user-facing behavior, so its practical purpose should not be inferred from its name alone.

Rendering with wgpu and Windowing Primitives

The renderer is based on `wgpu`, which matters because this is a graphics-facing desktop application rather than a terminal MIDI viewer. The repository includes a dedicated `wgpu-jumpstart` member and declares `wgpu` version 30 in the workspace dependencies. The README's screenshots show settings, track selection, and the central falling-note display, but it does not document supported graphics backends, minimum graphics hardware, or behavior when hardware acceleration is unavailable.

The piano is more than decoration. `piano-layout` exists as a separate crate, which suggests that mapping notes to keyboard positions is an explicit part of the application architecture. That separation could help isolate layout logic from rendering and input handling. It also means a maintainer changing keyboard geometry has a defined package to inspect, although the repository files do not show whether users can load custom piano layouts.

Neothesia also contains an `ffmpeg-encoder` member and links the documentation to a video-encoding page. Those facts establish that encoding is part of the project structure, not that every release exposes a particular recording format, codec, or command-line option. The CLI is likewise represented by `neothesia-cli`, whose dependencies include `clap` and an FFmpeg binding. The README does not document the CLI syntax or identify which workspace members produce user-facing binaries. For adoption, the GUI is the only path described with enough clarity to state a direct first use.

Installing Neothesia and Opening a MIDI File

The README lists Flathub as the primary named download route, an unofficial AUR package for Arch Linux, and GitHub Releases for binary releases. It does not provide command-line installation instructions, package-manager commands, or portable archive names. Inventing a `flatpak install` command or release filename would go beyond the available documentation, so there is no command block in this tutorial.

For a first use on Linux, begin with the README's Flathub link and follow the installation instructions published there. A reader following that route should end with a discoverable desktop application named Neothesia. The repository's homepage also links to an installation FAQ, which is the relevant place to check for platform-specific instructions and troubleshooting.

After launching Neothesia, select a MIDI file through the application's file-selection flow. The README does not document the exact menu label, supported extension list, or file dialog sequence. Once a file is loaded, the documented behavior is to show its notes as colored falling blocks on the virtual piano. The included `test.mid` is the repository's most concrete first file to try. Users should check that the visible block pattern changes after selecting a different MIDI file and that the blocks align with the intended keys.

Windows and macOS users can start from the GitHub Releases page or consult the homepage installation FAQ. The README confirms cross-platform availability but does not enumerate the bundled formats or explain how the releases are signed. Those details must be checked in the relevant release assets and installation documentation rather than assumed from the project description.

GPL-3.0 Distribution and Workspace Maintenance

Neothesia is licensed under GPL-3.0. That matters for engineers who may redistribute a modified build or incorporate source into a distributed work, because the license carries source-availability and license obligations. This is a licensing note rather than legal advice. The repository contains a `LICENSE` file, and downstream packagers should use that text and the project's current licensing information as the controlling sources.

The repository is not archived. Its last push was on 2026-10-11. Release history includes `v0.5.0` on 2026-09-24, `v0.4.0` on 2026-01-31, and `v0.3.1` on 2025-05-25. These dates show recent project activity, but they do not establish how costly upgrades will be for a particular downstream distribution.

The workspace itself creates maintenance work for anyone patching only one part of the project. Changes may involve coordination among MIDI parsing, shared core logic, piano layout, graphics, and encoding packages. The presence of `Cargo.lock` fixes dependency resolution for the repository, while the workspace manifest uses edition 2024 and groups shared dependency versions centrally. Forks and packagers should also account for FFmpeg-related code, audio decoding, platform-specific MIDI and audio crates, and the need to test the desktop application after rebuilding workspace members.

Neothesia Compared with Synthesia and Linthesia

The closest product comparison named by Neothesia is Synthesia. The README states that the earlier open-source Synthesia work was abandoned in favor of a closed-source commercial project. Neothesia's distinction is therefore licensing and implementation: it is an open-source GPL-3.0 project built in Rust, whereas the commercial successor is closed source. The README does not provide a feature-by-feature comparison, so it cannot support claims about pricing, content availability, lesson support, or feature parity.

The repository also acknowledges Linthesia in its credits. Both projects occupy the MIDI learning software category, but the supplied Neothesia documentation does not describe Linthesia's installation model, current interface, platform support, or licensing terms. A useful architectural comparison can still be made at a limited level: Neothesia's repository exposes a Rust workspace with separate GUI, MIDI, layout, rendering, image, encoding, CLI, and AI members. That module layout tells an engineer where to inspect changes, while it says nothing conclusive about the maintainability of either product as a whole.

For a user, the practical distinction comes down to evidence. Neothesia offers named binary distribution routes, a GPL-3.0 license, and a visible cross-platform project structure. A closed-source commercial application may have different support and documentation, but those properties are not described here and therefore are not treated as facts. Users needing evidence about commercial features must consult that product's own documentation separately.

Editorial conclusion

Neothesia is a practical choice for learners seeking an open-source, cross-platform MIDI visualizer, while users who need a fully documented commercial workflow or verified media-recording behavior should investigate those areas first. Before adoption, check the platform installation page, confirm that the current release works with the intended MIDI files and piano setup, and review the GPL-3.0 obligations for any planned distribution.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. PolyMeilex/Neothesia on GitHub
3. Project website
4. README
5. Releases