Praat's C tree, forty-four download names and a Makefile that misses Chrome

A repository named after a website ships the program itself

`praat.github.io` sounds like the source for a website, but the tree is the program. The code is C, the root carries a `Makefile` and a `meson.build`, and the directories are `fon/`, `foned/`, `melder/`, `dwsys/`, `dwtools/`, `sys/`, `kar/`, `LPC/`, `FFNet/`, `artsynth/`, `gram/`, `stat/`, `sensors/`, `EEG/`, `test/`, `generate/`, `docs/`, `external/` and `main/`. Nothing here serves praat.org, so a clone gives you something to compile rather than a copy of the site. The README never maps those directory names onto features, which leaves the naming as the only guide for anyone starting out. Build notes sit next to the two build files in `HOW_TO_BUILD_ONE.md` and `HOW_TO_BUILD_ALL.md`, and the default branch is `master`. No licence identifier is recorded for the repository, so the terms for redistributing a binary or linking this code into a tool of your own stay unstated. One concrete date does sit in the tree: the Makefile header carries 19 July 2026.

Six short paragraphs, then four tables of file names

Everything descriptive in the README fits in six paragraphs: pitch, formant, intensity and voice quality analysis, spectrograms, cochleagrams, synthesis, manipulation of pitch, intensity and duration, IPA labelling, grammar models, statistics. After that come four tables for Windows, Mac, Linux and Chromebook holding more than forty names between them, and only fourteen of those are marked as still receiving updates. The three versions attached to the repository, 7.0.02, 7.0.01 and 7.0, are all dated August 2026. That gap matters, because the frozen rows include Windows 98, MacOS 7 and MacOS 9 builds, and a name such as `praatXXXX_win64.zip` reads as current to anyone who does not check the bold. The newest downloads are on praat.org, and the README points there instead of describing an installer. Nothing in the file names a package manager, a container image, or a distribution repository for Linux.

Every artefact is a zip, a disk image or a tarball

Praat does not install itself. You take a file, unpack it, and run what is inside. On macOS that file is a disk image holding a universal executable for Intel and Apple Silicon Macs; on Windows it is a zip. Pick the Windows archive by CPU level rather than by habit: `praatXXXX_win-x64v3.zip` covers Intel64/AMD64 at level v3 on Windows 10 and higher, `praatXXXX_win-arm64.zip` covers ARM64 Windows 11 and higher, and `praatXXXX_win-intel32.zip` still covers Windows 7, but only until 6.4.52. There is no current 64-bit build for Windows 7 at all, because `praatXXXX_win-intel64.zip` and `praatXXXX_win64.zip` both sit outside the updated set. These are the names the README marks as current.

praatXXXX_win-x64v3.zip
praatXXXX_win-x64v1.zip
praatXXXX_win-arm64.zip
praatXXXX_win-intel32.zip
praatXXXX_mac.dmg
praatXXXX_xcodeproj.zip
praatXXXX_linux-x64v3.tar.gz
praatXXXX_linux-x64v3-barren.tar.gz
praatXXXX_linux-s390x.tar.gz
praatXXXX_linux-arm64.tar.gz
praatXXXX_chrome-x64v1.tar.gz
praatXXXX_chrome-arm64.tar.gz

After unpacking there is nothing to configure and nothing to launch from a shell. The README documents no command line for Praat itself, no settings file, and no environment variable that changes how the running program behaves; the environment variables it does mention belong to the build. So a first session happens in the window that opens, with a sound file loaded, a pitch or formant track drawn, and segments labelled in IPA. The manual under Help is where that workflow is written down.

make PRAAT_OS=chrome is the only route to a Chromebook build

Building takes one command and, at most, two settings in front of it. Auto-detection is claimed for Windows, Linux, and for Raspberry Pi as a sub-OS, and the gap for Chrome is stated outright: only Linux gets detected as the OS, so a Chromebook target has to be requested by name. FreeBSD sits in the same position, with a note in the file that it does not count as Linux. The comment block is hand-maintained, complete with the typo `audo-detect` on the very line that sets out the default.

make
make PRAAT_OS=linux
make PRAAT_OS=chrome
make PRAAT_OS=raspberrypi
make PRAAT_OS=freebsd

`make PRAAT_OS=chrome` sets Linux as the OS and Chrome as the sub-OS. Raspberry Pi works the same way, and so does FreeBSD. Settings of this kind can go on the command line or be defined as an environment variable, which matters on a build machine whose shell differs from the one you develop in. Both of these switches belong to the compile, and neither one reaches the finished program.

PRAAT_ARCH follows the shell, not the processor you own

The architecture default is decided by whichever shell launched the compiler rather than by the chip in the machine. Under MSYS2-CLANGARM64 on Windows, or the OrbStack ARM64 shell on Linux, you get armv8-a, which the comment calls the simplest ARM64. MSYS2-CLANG64 and the OrbStack x64 shell give x86-64, equated there with x64-v1. MSYS2-MINGW32 gives pentium4, described as basic i686. Some Raspberry Pi computers give armv6+fp, and the comment points at `gcc -Q --help=target` for finding out which one you have. That MINGW32 pairing is the trap. The same source compiled in that shell produces a binary for a far older instruction set than one built under CLANG64, and the build prints nothing about it. The shipped Linux names show the same split, with v3, v1 and 32-bit archives sitting side by side, and only some of them current.

Barren builds drop sound and graphics along with the GUI

Headless use is handled by taking pieces out of the binary, and the stripping is graded. A barren Linux archive has no GUI, no sound and no graphics, which makes it a compute-only executable for batch analysis. A nogui archive keeps the drawing layer through Cairo and Pango but still has neither GUI nor sound. Windows gets its own console edition instead, and it appears only in the Windows table.

praatXXXX_linux-x64v3-barren.tar.gz
praatXXXX_linux-s390x-barren.tar.gz
praatXXXX_linux-arm64-barren.tar.gz
praatXXXX_linux-arm64-nogui.tar.gz
praatXXXX_linux-intel64-nogui.tar.gz
praatXXXX_linux64nogui.tar.gz
praatconXXXX_win64.zip
praatconXXXX_win32.zip

The current barren set covers x64v3, s390x and ARM64 Linux, while the v1 barren build and all three nogui builds sit outside it, so a headless job on an older x64 machine is served by a file the README no longer marks as updated. A pipeline that draws spectrograms cannot use a barren executable at all, because no drawing code is linked in. Mac is the hole in the table: it carries no console, barren or nogui entry, so a batch job on a Mac has no listed headless artefact. The older Linux rows keep a GTK 2 option alive at 32-bit only, which tells you how long those names have been parked.

The bold marker for current builds lands on the wrong rows

The README's rule is that editions still receiving updates are in bold, and the markers break in the Linux table. `praatXXXX_linux-x64v3.tar.gz` opens bold and never closes, `praatXXXX_linux-s390x-barren.tar.gz` carries a second opening plus its own closing on one line, and a few rows later `praatXXXX_linux-intel64-barren.tar.gz` ends with a stray closing pair. Pair those markers strictly in document order and the rendering lands on the wrong entries: the s390x and arm64 rows stay bold, `praatXXXX_linux-intel64-barren.tar.gz` gains a current label it should never have carried, and `praatXXXX_linux-x64v3.tar.gz`, which the surrounding text treats as live, loses its bold outright. Three lines, three entries mislabelled, and no other signal anywhere in the file to correct them. The Chromebook table has its own defect: `praatXXXX_chrome64.tar.gz` stops mid-word at Chromeboo, with no version requirement given. Take the name from praat.org and the CPU tag as gospel rather than the bold, since v1, v3, intel32 and arm64 are separate builds for separate machines.

Acoustic and articulatory synthesis take different inputs

For synthesis the program offers two routes that never meet. Acoustic synthesis starts from a pitch curve and filters that you build. Articulatory synthesis starts from muscle activities, so its input is a physical description of the tract rather than a recipe for a waveform. The tree keeps an `artsynth/` directory for that work, and the README says nothing about whether the two routes share code or hand files to each other. The pattern holds elsewhere too: multidimensional scaling, principal component analysis and discriminant analysis sit inside Praat instead of in a separate statistics package, while Optimality-Theoretic and Harmonic-Grammar learning live beside neural-network models with `gram/` and `FFNet/` at the top level. One caveat is worth stating plainly, because the README names no external tool to compare against. Any claim that Praat outruns a dedicated speech toolkit or a separate neural-network framework would need sources this repository does not carry. The comparison that holds from here is about scope rather than speed: analysis, labelling, synthesis and modelling share one program and one manual, under Help.

Editorial conclusion

Phonetics labs that need pitch, formant, intensity, cochleagrams, IPA labelling, scaling and principal component analysis in one program should start with Praat, because this tree carries all of them plus the Makefile and a console edition. Anyone after a Python API, a container image or a rollback procedure finds none of the three described here. The last push was on 2026-10-06, later than all three versions named above. Verify first that the archive you pick matches the CPU tag on your machine.

Frequently asked questions

Official sources

1. Issues
2. praat/praat.github.io on GitHub
3. Project website
4. README
5. Releases