# alphaTab: one tablature renderer compiled to TypeScript, C# and Kotlin from a single source > A rendering library that turns Guitar Pro files, MusicXML and its own alphaTex markup into notation with optional audio playback, shipped as browser, Node, .NET and Kotlin targets generated from the TypeScript package. Suited to applications that must display and play existing scores, and constrained by the fact that several platform targets stopped receiving releases at 1.2.2. **CoderLine/alphaTab** — alphaTab is a cross platform music notation and guitar tablature rendering library. - Repository: https://github.com/CoderLine/alphaTab - Website: http://www.alphatab.net - Stars: 1,907 · Forks: 302 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/coderline-alphatab ## What it reads and what it produces alphaTab is described as a cross platform music notation and guitar tablature rendering library. You embed it in a website or application, and it loads music from data sources and displays it as a score. The input formats are enumerated explicitly: Guitar Pro 3-5, Guitar Pro 6, Guitar Pro 7, AlphaTex and MusicXML. AlphaTex is the built in markup language, which means you are not restricted to converting existing files, you can author notation in text. The output side is vector or raster. Rendering produces SVG, and raster graphics depend on the platform, with HTML5 canvas, GDI+, SkiaSharp and Android Canvas named as the options. Audio is a separate concern handled by a built in MIDI synthesizer named alphaSynth, whose output is HTML5 Web Audio, NAudio or Android AudioTrack depending on where you run. That combination is the actual product: display plus playback of a score, which is why the feature list is so long. It covers single or multiple instruments, standard notation and tablature, song information, repeats, alternate endings, guitar tunings, clefs, key signatures, time signatures, notes, rests, accidentals, drum tabs, piano grand staff, tied notes, grace notes, dead and ghost notes, markers, tempos, lyrics, chords, vibratos, dynamics, tap, slap and pop, palm mute, string bends, whammy bar, tremolo picking, strokes, slides, trills, tuplets and fingering. ## The support table stops .NET Core 3.1 at 1.2.2, and that is the first thing to check The platform table is the most decision-relevant part of the README, and it has two columns that matter: what the platform supports, and which versions it is available from. Browsers using script includes (UMD) get the full experience including low level APIs, Background Workers, audio playback, SVG and HTML5 rendering, plus UI level integration for user interaction and automatic resizing, from 1.0 through latest. Browsers using ES6 Modules are listed at 1.3 with the same full feature set. Node.js gets access to all low level APIs and SVG rendering, under both require (UMD, from 1.0) and import (ESM, from 1.3), but not audio playback. The two rows that will stop a migration are .netcoreapp3.1 WPF and .netcoreapp3.1 WinForms. Both are marked as the full experience with NAudio audio and reduced UI level integration related to transparency and animations, and both carry an availability range of 1.0 to 1.2.2. The current WPF and WinForms targets are .net8.0-windows, available from 1.3. So if you are on .NET Core 3.1 you are looking at a release line that stopped at 1.2.2. ## A monorepo where the TypeScript package is the source of the others The root package.json names itself @coderline/alphatab-monorepo at version 1.9.0, marked private, with type set to module and a workspaces array pointing at packages/*. That tells you the shape: this is an npm workspaces monorepo, and the version in the root manifest is ahead of the latest published tag, v1.8.4 from 2026-07-05. The build scripts show the derivation order more clearly than any prose would. The C# and Kotlin targets both begin by regenerating the TypeScript: ```bash npm run generate-typescript && npm run build --workspace=packages/csharp npm run generate-typescript && npm run build --workspace=packages/kotlin ``` and the same pattern appears for the bundler wrappers: ```bash npm run build --workspace=packages/vite npm run build --workspace=packages/webpack ``` So the TypeScript package under packages/alphatab is where the library lives, and the other language packages consume generated output from it. The playground package is the dev entry point, driven by npm run dev with an explicit workspace flag. ## Commands are per package, not per repository Most root scripts are thin fan outs. The lint, lint-ci, typecheck and clean scripts all run across workspaces with --if-present, so a package without a lint script is skipped rather than failing the run. build, test, test-csharp, test-kotlin, test-vite and test-webpack each target one workspace explicitly. The combined web build is the exception: ```bash npm run build && npm run build-webpack && npm run build-vite ``` which builds the core library first and then both bundler integrations in sequence. There are also language server scripts, build-language-server and dev-language-server, both scoped to packages/lsp, and a version maintenance script run through node scripts/update-version.mjs. Tooling is Biome, configured through biome.jsonc at the root, with a shared tsconfig.base.json. The repository also carries AGENTS.md and CLAUDE.md at the root, which is a signal about how the project expects automated coding assistants to work in this tree. ## Where alphaTab is the wrong tool The boundary is authoring. alphaTab loads and renders notation that already exists in one of its supported formats, and alphaTex is a markup language rather than a notation editor. If your requirement is for users to draw music with a mouse on a staff, this library gives you the rendering half of that problem and none of the input half. The second boundary is format coverage. Guitar Pro and MusicXML are covered; other interchange formats are not named. If your content arrives as LilyPond, ABC notation or a proprietary in house format, you are writing a converter before you can use anything here. The third is the audio engine's ceiling. Playback uses the built-in MIDI+SoundFont2 Synthesizer. That is a soundfont player, not a sampled instrument library, so timbres will sound like a soundfont rather than like a recorded piano or guitar. ## Licensing and project state The README badge states MPL-2.0, and GitHub itself classifies the LICENSE file as a custom licence it cannot categorise, so the file is the authority. MPL 2.0 is file level copyleft: modifying the library's own files requires publishing those changes, while an application that merely embeds it does not inherit that requirement. That is a different obligation model from MIT, and it matters if you plan to patch the renderer. The project is under active change. The last push was on 2026-10-15, the default branch is develop, and the release history shows a steady patch cadence in 2026: v1.8.2 on 2026-04-10, v1.8.3 on 2026-05-24 and v1.8.4 on 2026-07-05. The homepage is alphatab.net, with guides and tutorials hosted under /docs/introduction and /docs/tutorials rather than in the repository. ## Conclusion Adopt alphaTab if your application needs to display and play existing scores, especially guitar tablature, and you are prepared to target one of the platforms in the support table rather than an arbitrary one. Do not adopt it for .NET Core 3.1 WPF or WinForms on a current release line, because the README marks those two rows as available from 1.0 to 1.2.2. Verify first which input format your existing content is in, since Guitar Pro 3-5, Guitar Pro 6, Guitar Pro 7, AlphaTex and MusicXML are separate loaders, and check the rendering engine your platform offers because raster output depends on platform, with HTML5 canvas, GDI+, SkiaSharp and Android Canvas named separately. ## FAQ ### Which file formats can alphaTab load? The README lists Guitar Pro 3-5, Guitar Pro 6, Guitar Pro 7, AlphaTex and MusicXML. AlphaTex is the built in markup language, so scores can be authored as text as well as imported. ### Can alphaTab play the score it renders? Yes, through a built in MIDI synthesizer named alphaSynth. Output depends on the platform: HTML5 Web Audio in the browser, NAudio on .NET, or Android AudioTrack. Node.js is listed with SVG rendering and low level APIs rather than audio playback. ### Is .NET Core 3.1 still supported by alphaTab? The support table lists .netcoreapp3.1 WPF and WinForms with an availability range of 1.0 to 1.2.2. Current Windows desktop targets are .net8.0-windows, available from 1.3. ### Which rendering engines does alphaTab support? SVG rendering is available across the platforms, and raster graphics depends on the platform, with HTML5 canvas, GDI+, SkiaSharp and Android Canvas named in the README. ### How is alphaTab built from source? The repository is an npm workspaces monorepo. The C# and Kotlin builds first run npm run generate-typescript for packages/alphatab and then build the target workspace, while npm run dev starts the playground package. ## Sources - [CoderLine/alphaTab on GitHub](https://github.com/CoderLine/alphaTab) - [Issues](https://github.com/CoderLine/alphaTab/issues) - [Project website](http://www.alphatab.net) - [README](https://github.com/CoderLine/alphaTab/blob/develop/README.md) - [Releases](https://github.com/CoderLine/alphaTab/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/coderline-alphatab