Performous: an open source karaoke, band and dance game

One game that scores singing, instruments and dance

The README describes Performous as an open source karaoke, band and dancing game where one or more players perform a song and the game scores their performances. That single sentence covers three quite different performance styles, and the reason it can is that the scoring model is the same in each case: the game knows what the song should sound like, it listens to what it hears or what the player did, and it compares. For singing that means pitch, for the guitar and drums that means the instrument peripheral, and for dance that means the pad input. The audience is a group with a screen, a set of microphones or controllers and a collection of songs, in a living room, a bar, a rehearsal room or a community hall. The project topics describe the lineage as cross platform game, with references to dance dance revolution, guitar hero and karaoke, and the README notes that the game is multilingual, which matches a repository with a dedicated lang directory. What makes it interesting to a technically minded reader is not the game design but the compatibility surface, because the game is defined as much by the song files it reads and the hardware it recognises as by its own rules.

Reading UltraStar, Frets on Fire and StepMania song packs

The song format support is the most consequential feature in the README, and it is stated in one line: Performous supports songs in UltraStar, Frets on Fire and StepMania formats. Each of those is a community format with its own history, and each exists because the commercial games it came from are tied to particular platforms. UltraStar is the karaoke format, with the note timing that a microphone needs. Frets on Fire and StepMania are the guitar and drum game formats, with the chart structure that a guitar peripheral or a drum pad needs. By reading all three, Performous lets a group use one executable for a karaoke night and a band rehearsal, and it lets organisers reuse existing song packs rather than maintaining a proprietary library. That reuse is the practical reason the project has survived in a form that commercial titles have not, because the content is portable even when the game is not. The formats are also why the game can be multilingual in a practical way, since the on-screen text is separated from the song content by construction, and the song data itself carries the artist, title and lyric text that the game renders.

Autodetecting microphones, instruments and dance pads

The second compatibility surface is input hardware, and the README is specific about it: microphones and instruments from SingStar, Guitar Hero and Rock Band, as well as some dance pads, are autodetected. That is a bigger statement than it looks. Those devices are not supported by a driver in the usual sense, they present themselves as USB audio or USB HID devices with a particular protocol, and a game that claims to autodetect them is claiming to know which of the several near identical USB identifiers belongs to which instrument. Autodetection also matters for the karaoke case, because USB microphones are the normal way a home setup captures singing and the alternative is an audio interface with a mixing desk, which is a different kind of event entirely. The cost of that convenience is that the support is empirical, tied to the device behaviour at the time it was written, which is why the wiki and the discussion channels exist. The README points to a Discord server, and for a game with this many peripherals that is where the practical knowledge lives.

CMake, presets and a wide platform matrix

The build system is CMake, with a CMakeLists.txt at the root and a CMakePresets.json beside it, which is the modern way to describe build configurations and toolchain options in a form editors and CI can consume. The README points to the wiki page on building and installing from source rather than duplicating the instructions, which is a reasonable division of labour for a project with this many platforms. The pre-compiled build list is the more useful summary for most people, and it is long: Windows with both MSVC and MinGW-w64, macOS, and various versions of Ubuntu, Debian and Fedora, plus an AppImage build, with the AppImage configuration sitting in its own file at the root of the repository. The repository layout backs this up. There are platform specific directories for macOS utilities, for a Portage overlay, for Windows, and for a docker directory, alongside the data directory for game assets, the game directory for the source, a lang directory for translations, a testing directory and a documentation directory. The presence of a Portage overlay and a docker directory tells you the project is expected to be built and packaged in the ways Linux distributions and self hosted environments do it, not only through a desktop package.

Weekly beta builds, and the macOS microphone trap

Two operational details in the README are worth copying into your own plan. The first is the release channel. Alongside the latest release page, there are weekly BETA builds from the master branch, generated by a continuous integration workflow and linked through a nightly build service. For a game with as much hardware variance as this one, a weekly build that anyone can try is how device support gets tested, and it also means that a bug you hit may already be fixed in a build from three days ago. The second is a macOS specific trap that has bitten people for years and is still in the README: macOS users may need to launch Performous from the Terminal to get microphones working, and you must launch the binary inside the app bundle rather than the app itself.

Performous.app/Contents/MacOS/Performous

The reason is the way macOS treats an application bundle and the permissions attached to it, so the process that ends up asking for microphone access is not the one the user double clicked. If you are deploying Performous on macOS for an event, that is the launch command to put in a script or a dock alias, not the app. The README also gives a fallback website, a mirror, in case the main site at performous.org cannot be reached, which is a small but thoughtful detail for a project whose users are often behind restrictive networks.

What the layout says, and the licence you have to read

Two administrative points round out the picture. The first is the licence, and it is one of the cases where you have to open the file rather than trust a badge. The repository's licence is listed as a custom licence that GitHub cannot classify, with the terms in LICENSE.md, and the distinction matters for a game that people assemble on their own machines and share song packs and configurations between. The second is the shape of the codebase, which is visible in the directory names. The game source sits in game, the shared data in data, translations in lang, and the tests in testing, with the miscellaneous and documentation directories alongside. The win32 and osx-utils directories are the platform glue, the portage-overlay is the packaging metadata for Gentoo style installs, the docker directory is for containerised use, and the AppImageBuilder.yml at the root drives the single file Linux build. Taken together, this is a project that has been carried across a decade of distribution changes, which is a good sign for how its build is maintained and a caution about how much of the documentation lives in the wiki rather than in the repository. The release history supports that reading, with version 1.3.1 published on 2024-02-09 after a release candidate in December 2023 and 1.3.0 in September 2023, while the last push to the repository was on 2026-09-24, so the work continues on master while the tagged release line moves more slowly.

Editorial conclusion

Adopt Performous if you want a karaoke or band game that runs on Linux or macOS, that reads the song packs you already have in the UltraStar, Frets on Fire or StepMania formats, and that works with the USB microphones and game controllers people already own. It does not fit a project that needs a polished, commercially supported title on a specific console platform, and it does not fit anyone unwilling to read a wiki and compile from source when the prebuilt package does not cover their distribution. Before you install, check that a build exists for your distribution, and if you are on macOS, launch the binary inside the app bundle rather than the app itself, or the microphones will not work.

Frequently asked questions

Official sources

1. Issues
2. performous/performous on GitHub
3. Project website
4. README
5. Releases