Git Product home page Git Product logo

praat's Introduction

Praat: doing phonetics by computer

Welcome to Praat! Praat is a speech analysis tool used for doing phonetics by computer. Praat can analyse, synthesize, and manipulate speech, and create high-quality pictures for your publications. Praat was created by Paul Boersma and David Weenink of the Institute of Phonetics Sciences of the University of Amsterdam.

Some of Praat’s most prominent features are:

Speech analysis

Praat allows you to analyze different aspects of speech including pitch, formant, intensity, and voice quality. You have access to spectrograms (a visual representation of sound changing over time) and cochleagrams (a specific type of spectrogram more closely resembling how the inner ear receives sound).

Speech synthesis

Praat allows you to generate speech from a pitch curve and filters that you create (acoustic synthesis), or from muscle activities (articulatory synthesis).

Speech manipulation

Praat gives you the ability to modify existing speech utterances. You can alter pitch, intensity, and duration of speech.

Speech labelling

Praat allows you to custom-label your samples using the IPA (International Phonetics Alphabet), and annotate your sound segments based on the particular variables you are seeking to analyze. Multi-language text-to-speech facilities allow you to segment the sound into words and phonemes.

Grammar models

With Praat, you can try out Optimality-Theoretic and Harmonic-Grammar learning, as well as several kinds of neural-network models.

Statistical analysis

Praat allows you to perform several statistical techniques, among which multidimensional scaling, principal component analysis, and discriminant analysis.

For more information, consult the extensive manual in Praat (under Help), and the website praat.org, which has Praat tutorials in several languages.

1. Binary executables

While the Praat website contains the latest executable for all platforms that we support (or used to support), the releases on GitHub contain many older executables as well.

The meaning of the names of binary files available on GitHub is as follows (editions that currently receive updates are in bold):

1.1. Windows binaries

  • praatXXXX_win-arm64.zip: zipped executable for ARM64 Windows (11 and higher)
  • praatXXXX_win-intel64.zip: zipped executable for Intel64 Windows (7 and higher)
  • praatXXXX_win-intel32.zip: zipped executable for Intel32 Windows (7 and higher)
  • praatXXXX_win64.zip: zipped executable for 64-bit Intel Windows (XP and higher, or 7 and higher)
  • praatXXXX_win32.zip: zipped executable for 32-bit Intel Windows (XP and higher, or 7 and higher)
  • praatconXXXX_win64.zip: zipped executable for 64-bit Intel Windows, console edition
  • praatconXXXX_win32.zip: zipped executable for 32-bit Intel Windows, console edition
  • praatconXXXX_win32sit.exe: self-extracting StuffIt archive with executable for 32-bit Intel Windows, console edition
  • praatXXXX_win98.zip: zipped executable for Windows 98
  • praatXXXX_win98sit.exe: self-extracting StuffIt archive with executable for Windows 98

1.2. Mac binaries

  • praatXXXX_mac.dmg: disk image with universal executable for (64-bit) Intel and Apple Silicon Macs (Cocoa)
  • praatXXXX_xcodeproj.zip: zipped Xcode project file for the universal (64-bit) edition (Cocoa)
  • praatXXXX_mac64.dmg: disk image with executable for 64-bit Intel Macs (Cocoa)
  • praatXXXX_xcodeproj64.zip: zipped Xcode project file for the 64-bit edition (Cocoa)
  • praatXXXX_mac32.dmg: disk image with executable for 32-bit Intel Macs (Carbon)
  • praatXXXX_xcodeproj32.zip: zipped Xcode project file for the 32-bit edition (Carbon)
  • praatXXXX_macU.dmg: disk image with universal executable for (32-bit) PPC and Intel Macs (Carbon)
  • praatXXXX_macU.sit: StuffIt archive with universal executable for (32-bit) PPC and Intel Macs (Carbon)
  • praatXXXX_macU.zip: zipped universal executable for (32-bit) PPC and Intel Macs (Carbon)
  • praatXXXX_macX.zip: zipped executable for MacOS X (PPC)
  • praatXXXX_mac9.sit: StuffIt archive with executable for MacOS 9
  • praatXXXX_mac9.zip: zipped executable for MacOS 9
  • praatXXXX_mac7.sit: StuffIt archive with executable for MacOS 7

1.3. Linux binaries

  • praatXXXX_linux-arm64-barren.tar.gz: gzipped tarred executable for ARM64 Linux, without GUI, sound and graphics
  • praatXXXX_linux-arm64-nogui.tar.gz: gzipped tarred executable for ARM64 Linux, without GUI and sound but with graphics (Cairo and Pango)
  • praatXXXX_linux-arm64.tar.gz: gzipped tarred executable for ARM64 Linux (GTK 3)
  • praatXXXX_linux-intel64-barren.tar.gz: gzipped tarred executable for Intel64 Linux, without GUI, sound and graphics
  • praatXXXX_linux-intel64-nogui.tar.gz: gzipped tarred executable for Intel64 Linux, without GUI and sound but with graphics (Cairo and Pango)
  • praatXXXX_linux-intel64.tar.gz: gzipped tarred executable for Intel64 Linux (GTK 3)
  • praatXXXX_linux64barren.tar.gz: gzipped tarred executable for 64-bit Intel Linux, without GUI, sound and graphics
  • praatXXXX_linux64nogui.tar.gz: gzipped tarred executable for 64-bit Intel Linux, without GUI and sound but with graphics (Cairo and Pango)
  • praatXXXX_linux64.tar.gz: gzipped tarred executable for 64-bit Intel Linux (GTK 2 or 3)
  • praatXXXX_linux32.tar.gz: gzipped tarred executable for 32-bit Intel Linux (GTK 2)
  • praatXXXX_linux_motif64.tar.gz: gzipped tarred executable for 64-bit Intel Linux (Motif)
  • praatXXXX_linux_motif32.tar.gz: gzipped tarred executable for 32-bit Intel Linux (Motif)

1.4. Chromebook binaries

  • praatXXXX_chrome-arm64.tar.gz: gzipped tarred executable for Linux on ARM64 Chromebooks (GTK 3)
  • praatXXXX_chrome-intel64.tar.gz: gzipped tarred executable for Intel64 Linux on Intel64 Chromebooks (GTK 3)
  • praatXXXX_chrome64.tar.gz: gzipped tarred executable for 64-bit Linux on Intel64 Chromebooks (GTK 2 or 3)

1.5. Raspberry Pi binaries

  • praatXXXX_rpi-armv7.tar.gz: gzipped tarred executable for (32-bit) ARMv7 Linux on the Raspberry Pi 4B (GTK 3)
  • praatXXXX_rpi_armv7.tar.gz: gzipped tarred executable for (32-bit) ARMv7 Linux on the Raspberry Pi 4B (GTK 2 or 3)

1.6. Other Unix binaries (all obsolete)

  • praatXXXX_solaris.tar.gz: gzipped tarred executable for Solaris

2. Compiling the source code

You need the Praat source code only in the following cases:

  1. you want to extend Praat’s functionality by adding C or C++ code to it; or
  2. you want to understand or reuse Praat’s source code; or
  3. you want to compile Praat for a computer for which we do not provide binary executables, e.g. Linux for some non-Intel computers, FreeBSD, HP-UX, SGI, or SPARC Solaris.

Before trying to dive into Praat’s source code, you should be familiar with the working of the Praat program and with writing Praat scripts. The Praat program can be downloaded from https://praat.org.

2.1. License

All of the code is available on GitHub under the GNU General Public License. Of course, any improvements are welcomed by the authors.

2.2. Downloading the archive

To download the latest source code of Praat from GitHub, click on the zip or tar.gz archive at the latest release, or fork ("clone") the praat/praat repository at any later change.

2.3. Steps to take if you want to extend Praat

First make sure that the source code can be compiled as is. Then add your own buttons by editing main/main_Praat.cpp or fon/praat_Fon.cpp. Consult the manual page on Programming.

2.4. The programming language

Most of the source code is written in C++, but some parts are written in C. The code requires that your compiler supports C99 and C++17.

3. Developing Praat for one platform

Developing Praat means two things: building the Praat executable from the Praat source code, and testing the correctness of the Praat executable.

Building is largely automated:

  • On the Mac, you use an existing Xcode project (these files are included in the releases).
  • On other platforms (Windows and Unixes), you use existing makefiles (these files are included in the source tree).

Testing on a platform can be done by starting up Praat on that platform, and then go through to types of tests. Basic GUI functionality is tested as follows:

  1. record a sound (New -> Record mono Sound...)
  2. open the sound (View & Edit)
  3. select a part of the sound (drag the mouse across the waveform)
  4. play the sound (click on the rectangle below or above the selection)

The integrity of Praats’s algorithms (e.g. signal processing) and of the Praat scripting language is tested as follows:

  1. open the script test/runAlltests.praat (Praat -> Open Praat script...)
  2. run the script (Run -> Run)
  3. after 2 to 10 minutes, the Info window should contain a big “OK” graph
  4. go through steps 1 through 3 for dwtest/runAllTests.praat
  5. if you feel adventurous, try some tests in the folder test/manually

3.1. Developing Praat for Windows

On Windows, Praat is built through the makefiles provided in Praat’s source tree.

One could use Cygwin or MSYS2. As we like to provide not only an Intel64 and Intel32 edition, but an ARM64 edition as well, and Cygwin has no toolchains for ARM64, we work with MSYS2 instead.

After installing MSYS2, we see that a mingw64 toolchain (for Praat’s Intel64 edition) and a mingw32 toolchain (for Praat’s Intel32 edition) are already available. To also install a clangarm64 toolchain (for Praat’s ARM64 edition), run clangarm64.exe to get a clangarm64 shell. In that shell, run pacman -Suy to update and pacman -S mingw-w64-clang-aarch64-clang to install the build tools package.

Move the Praat sources folders somewhere in your /home/yourname tree, perhaps even in three places, e.g. as /home/yourname/praats-arm64, /home/yourname/praats-intel64 and /home/yourname/praats-intel32; the folders fon and sys should be visible within each of these folders.

If you now want to build Praat’s ARM64 edition, start the shell clangarm64 and type

cd ~/praats-arm64
cp makefiles/makefile.defs.msys-arm64 ./makefile.defs
make -j12

If you want to build Praat’s Intel64 edition, start the shell mingw64 and type

cd ~/praats-intel64
cp makefiles/makefile.defs.msys-mingw64 ./makefile.defs
make -j12

If you want to build Praat’s Intel32 edition, start the shell mingw32 and type

cd ~/praats-intel32
cp makefiles/makefile.defs.msys-mingw32 ./makefile.defs
make -j12

(With Cygwin, you would install the Devel package mingw64-x86_64-gcc-g++ for Praat’s Intel64 edition and mingw64-i686-gcc-g++ for Praat’s Intel32 edition.)

Testing on multiple platform versions can be done with virtual machines for Windows 7 (64-bit), Windows 8.1 (64-bit), 64-bit Windows 10 (1507, 1803, 22H2) and Windows 11, for instance on an Intel64 Mac with Parallels Desktop. On an ARM64 Mac with Parallels Desktop, you can test only on Windows 11.

3.2. Compiling for Macintosh

To build Praat on the Mac, extract the praatXXXX_xcodeproj.zip file from Praat’s latest release into the folder that contains sys, fon, dwtools and so on (e.g. ~/Dropbox/Praats/src). Then open the project praat.xcodeproj in Xcode 15.1 (or perhaps later, but not in Xcode 15.0), and edit the Intermediate and Product build paths to something that suits you (Xcode -> Settings... -> Locations -> Derived Data -> Advanced... -> Custom -> Absolute, then type something after Products, e.g. ~/Dropbox/Praats/bin/macos, as well as something after Intermediates, e.g. ~/builds/mac_intermediates, then click Done). After this preliminary work, choose Build or Run for the target praat_mac. You can compile with the 14.2 SDK, which will work as far back as macOS 10.11 El Capitan, which is our deployment target, and will look good even on macOS 14 Sonoma.

If you get an error message like “Code Signing Identity xxx does not match any valid, non-expired, code-signing certificate in your keychain”, then select the target praat_mac, go to Info → Build, and switch “Code Signing Identity” to “Don’t Code Sign”, or sign with your own certificate if you have one as a registered Apple developer.

If you get lots of errors saying “Expected unqualified-id” or “Unknown type name NSString”, then you may have to switch the Type of some .cpp file from “C++ Source” to “Objective-C++ Source” (under “Identity and Type” in the righthand sidebar).

If you want to build Praat as a library instead of as an executable, try the target praat_mac_a (static) or praat_mac_so (dynamic).

Notarization. If you want others to be able to use your Mac app, you will probably have to not only sign the executable, but also notarize it. To this end, do Xcode (version 15) -> Product -> Archive -> Distribute App -> Developer ID -> Upload -> Automatically manage signing -> Upload -> ...wait... (“Package Approved”) ...wait... (“Ready to distribute”) -> Export Notarized App). If your Praat.app was built into ~/Dropbox/Praats/bin/macos/Configuration64, then you can save the notarized Praat.app in ~/Dropbox/Praats/bin/macos, then drag it in the Finder to ~/Dropbox/Praats/bin/macos/Configuration64, overwriting the non-notarized Praat.app that was already there. If on the way you receive an error “App Store Connect Operation Error -- You must first sign the relevant contracts online”, or “Couldn’t communicate with a helper application“, or just a crash (happens with Xcode 15.0), you will have to log in to developer.apple.com and do Review Agreement -> Agree; you may then also have to go (or log in) to App Store Connect, then Agreements, Tax, and Banking -> Paid Apps -> View or Terms (even if you have no paid apps).

Testing on multiple Intel64 platform versions can be done on older Intel64 Macs, using virtual machines with Parallels Desktop. For instance, a 2013 Macbook Pro can handle OS X 10.11 El Capitan, 10.12 Sierra, 10.13 High Sierra, macOS 10.14 Mojave, 10.15 Catalina, and macOS 11 Big Sur, while a 2018 Macbook Pro can handle macOS 10.14 Mojave, 10.15 Catalina, macOS 11 Big Sur, macOS 12 Monterey, and macOS 13 Ventura (and macOS 14 Sonoma natively). Testing on multiple ARM64 platform versions can be done on an older ARM64 Mac, using virtual machines with Parallels Desktop. For instance, a 2020 Mac Mini could handle macOS 11 Big Sur, macOS 12 Monterey, and macOS 13 Ventura (and macOS 14 Sonoma natively).

3.3. Compiling on Linux and other Unixes

To set up the system libraries required for building, install the necessary build tools as well as some graphics and sound packages:

sudo apt install make gcc g++ rsync pkg-config
sudo apt install libgtk-3-dev
sudo apt install libasound2-dev
sudo apt install libpulse-dev
sudo apt install libjack-dev

To set up your source tree for Linux, go to Praat's sources directory (where the folders fon and sys are) and type one of the four following commands:

# on Ubuntu command line
cp makefiles/makefile.defs.linux.pulse ./makefile.defs

# on Chromebook command line
cp makefiles/makefile.defs.chrome64 ./makefile.defs

# on Raspberry Pi command line
cp makefiles/makefile.defs.linux.rpi ./makefile.defs

# on FreeBSD command line
cp makefiles/makefile.defs.freebsd.alsa ./makefile.defs

To build the Praat executable, type make -j12 or so. If your Unix isn’t Linux, you may have to edit the library names in the makefile (you may need pthread, gtk-3, gdk-3, atk-1.0, pangoft2-1.0, gdk_pixbuf-2.0, m, pangocairo-1.0, cairo-gobject, cairo, gio-2.0, pango-1.0, freetype, fontconfig, gobject-2.0, gmodule-2.0, gthread-2.0, rt, glib-2.0, asound, jack).

When compiling Praat on an external supercomputer or so, you will not have sound. If you do have libgtk-3-dev (and its dependencies), do

cp makefiles/makefile.defs.linux.silent ./makefile.defs

Then type make -j12 or so to build the program. If your Unix isn’t Linux, you may have to edit the library names in the makefile (you may need pthread, gtk-3, gdk-3, atk-1.0, pangoft2-1.0, gdk_pixbuf-2.0, m, pangocairo-1.0, cairo-gobject, cairo, gio-2.0, pango-1.0, freetype, fontconfig, gobject-2.0, gmodule-2.0, gthread-2.0, rt, glib-2.0).

When compiling Praat for use as a server for commands from your web pages, you may not need sound or a GUI. Do

cp makefiles/makefile.defs.linux.nogui ./makefile.defs

which creates the executable praat_nogui. If you don't need graphics (e.g. PNG files) either (i.e. you need only Praat's computation), you can create an even lighter edition:

cp makefiles/makefile.defs.linux.barren ./makefile.defs

which creates the executable praat_barren. Then type make or make -j12 to build the program. If your Unix isn’t Linux, you may have to edit the library names in the makefile.

The above works exactly the same for Intel64 and ARM64 processors, with the same makefiles.

Testing on multiple platform versions can be done with virtual machines for e.g. Ubuntu 20.04, Ubuntu 22.04, Fedora 35, Fedora 37, Mint 20.2, Debian GNU Linux 10.10, CentOS 8.4, and CentOS Stream 9, for instance on an Intel64 with Parallels Desktop. On an ARM64 Mac, we test with virtual machines for Ubuntu 22.04, Fedora 38, and Debian GNU Linux 12 ARM64.

4. Developing Praat on all platforms simultaneously

At the time of writing (5 January 2024), we develop 12 of the 13 Praat editions on a single computer, which is a 2023 M3 Macbook Pro. The Mac edition is built natively with Xcode, the three Windows editions are built via Parallels Desktop 19, and the six Linux editions and the two Chromebook editions are built via OrbStack; only the Raspberry Pi edition is built separately (on a Raspberry Pi). We put all 13 editions into a bin folder on Dropbox, so that it is easy to test the Windows and Linux editions on other computers.

In the following we assume that you want to create all of those editions as well. We hope that our example will be useful to you.

4.1. MacOS development set-up

Your source code folders, such as fon and sys, will reside in a folder like ~/Dropbox/Praats/src, where you also put praat.xcodeproj, as described above in 3.2. On our 2023 Mac with Xcode 15.1, building Praat with Command-B or Command-R, after cleaning the build folder with Shift-Command-K, takes only 56 seconds for the ARM64 part and Intel64 part together (optimization level O3).

4.2. Windows development set-up

On a Windows 10 or Windows 11 computer, you can install MSYS2 or Cygwin, and create some praats folders, as described above in 3.1.

If you work under Parallels Desktop on an ARM64 Mac, you will want MSYS2, because it has an edition for ARM64. Your source tree will reside on the Windows disk, which can be much faster than building directly on the MacOS disk. To move the source from the MacOS disk to the Windows disk, you “mount” the MacOS disk from MSYS2 or Cygwin; this is easy: in Parallels Desktop, choose Windows 11 ARM -> Configure, then Options, then Sharing, then Share Mac, and set Share folders to Home folder only (if this scares you, then use Custom Folders instead). Your MacOS home folder (i.e. /Users/yourname) is now visible anywhere on Windows as the Z drive (or so); from any of the three MSYS shells you can access it as /z, and from the Cygwin terminal you can access it as /cygdrive/z.

When developing Praat for Windows, you just edit your files in Xcode; do not forget to save them (as you do e.g. by building in Xcode). Then, just as you use Command-B and Command-R in Xcode, you will be able to type praat-build (which only builds) or praat-run (which builds and runs) into your MSYS2 shell. To accomplish this, add the following definitions into /home/yourname/.bashrc (i.e. in your MSYS2 Shell home folder), so that bash will automatically execute them whenever you start your MSYS shell or Cygwin terminal (you will need to have installed rsync and make). On our 2023 Mac, the ARM64 edition will be the default, but the Intel64 and Intel32 versions will also be available; as the same .bashrc file is shared among all three editions, we use the environment variable MSYSTEM to differentiate between the three:

# in MSYS2:~/.bashrc
if [[ "$MSYSTEM" == "CLANGARM64" ]]; then
    BUILD_FOLDER="~/praats-arm64"
    MAKEFILE_DEFS="makefiles/makefile.defs.msys-arm64"
elif [[ "$MSYSTEM" == "MINGW64" ]]; then
    BUILD_FOLDER="~/praats-intel64"
    MAKEFILE_DEFS="makefiles/makefile.defs.msys-mingw64"
elif [[ "$MSYSTEM" == "MINGW32" ]]; then
    BUILD_FOLDER="~/praats-intel32"
    MAKEFILE_DEFS="makefiles/makefile.defs.msys-mingw32"
fi
ORIGINAL_SOURCES="/z/Dropbox/Praats/src"
EXCLUDES='--exclude="*.xcodeproj" --exclude="Icon*" --exclude=".*" --exclude="*kanweg*"'
alias praat-build="( cd $BUILD_FOLDER &&\
    rsync -rptvz $ORIGINAL_SOURCES/ $EXCLUDES . &&\
    cp $MAKEFILE_DEFS ./makefile.defs &&\
    make -j12 )"
alias praat="$BUILD_FOLDER/Praat.exe"
alias praat-run="praat-build && praat"

This also defines praat for running Praat without first rebuilding it. The cycle from editing Praat on the Mac to running the new version on Windows therefore takes only two steps:

  1. edit and save the source code in Xcode on your Mac;
  2. type praat-run on your Windows 11 (under Parallels Desktop on your Mac) in one of the three MSYS2 shells.

On our 2023 Mac, the three builds cost 86 seconds for ARM64, 212 seconds for Intel64 (under emulation), and 390 seconds for Intel32 (also under emulation).

4.3. Linux development set-up

On an Ubuntu 20.04 or 22.04 computer, create a folder praats in your home folder, as described above in 3.3.

If you work under Parallels Desktop (19 or later) on an Intel64 Mac, choose Ubuntu 20.04 or 22.04 -> Configure, then Options, then Sharing, then Share Mac, and set Share folders to Home folder only (or use Custom Folders instead). Your MacOS home folder (i.e. /Users/yourname) is now visible on the Ubuntu desktop as Home, and from the Terminal you can access it as /media/psf/Home.

However, on an ARM64 Mac this procedure with Parallels Desktop works only for the ARM64 edition. With OrbStack we can instead create the Intel64 edition as well (and building the ARM64 edition is also faster). Your Mac home folder is known simply as /Users/yourname or so.

When developing Praat for Linux, you just edit and save your files in Xcode. You will be able to type praat-build (which only builds) or praat-run (which builds and runs) into your Terminal after you add the following definitions into /home/yourname/.bash_aliases in your Ubuntu home folder (this will be run automatically by .bashrc whenever you start a Terminal window, assuming that it uses the bash shell; please note the subtle but crucial difference between /Users/yourname and /home/yourname):

# in Ubuntu:/home/yourname/.bash_aliases
ORIGINAL_SOURCES="/Users/yourname/Dropbox/Praats/src"
EXCLUDES='--exclude="*.xcodeproj" --exclude="Icon*" --exclude=".*" --exclude="*kanweg*"'
alias praat-build="( cd ~/praats &&\
    rsync -rptvz $ORIGINAL_SOURCES/ $EXCLUDES . &&\
    cp makefiles/makefile.defs.linux.pulse makefile.defs &&\
    make -j15 )"
alias praat="~/praats/praat"
alias praat-run="praat-build && praat"

(In OrbStack, Praat will not have a GUI, so try praat-run --version instead, and test later on a Linux computer or Linux virtual machine.)

On our 2023 Mac, building Praat this way takes 63 seconds for the ARM64 edition and 150 seconds (under emulation) for the Intel64 edition (optimization level O3).

To build praat_barren, create a folder praatsb, and define

# in Ubuntu:~/.bash_aliases
alias praatb-build="( cd ~/praatsb &&\
    rsync -rptvz $ORIGINAL_SOURCES/ $EXCLUDES . &&\
    cp makefiles/makefile.defs.linux.barren makefile.defs &&\
    make -j15 )"
alias praatb="~/praatsb/praat_barren"
alias praatb-run="praatb-build && praatb"

You test praat_barren briefly by typing

# on Ubuntu command line
praatb --version

To build praat_nogui, create a folder praatsn, and define

# in Ubuntu:~/.bash_aliases
alias praatn-build="( cd ~/praatsn &&\
    rsync -rptvz $ORIGINAL_SOURCES/ $EXCLUDES . &&\
    cp makefiles/makefile.defs.linux.nogui makefile.defs &&\
    make -j15 )"
alias praatn="~/praatsn/praat_nogui"
alias praatn-run="praatn-build && praatn"

You test praat_nogui briefly by typing

# on Ubuntu command line
praatn --version

To build Praat for Chrome64 (64-bit Intel Chromebooks only), create a folder praatc, and define

# in Ubuntu:~/.bash_aliases
alias praatc-build="( cd ~/praatsc &&\
    rsync -rptvz $ORIGINAL_SOURCES/ EXCLUDES . &&\
    cp makefiles/makefile.defs.chrome64 makefile.defs &&\
    make -j15 )"
alias praatc="~/praatsc/praat"
alias praatc-run="praatc-build && praat"

To test Praat for Chrome64, you can just run it on Ubuntu by typing praatc, or you transfer it to a Chromebook for the real test.

4.4. Chromebook development set-up

Parallels Desktop 19 has no emulator for Chrome, so the choice is between building Praat on a Chromebook directly or building Praat on Ubuntu 20.04 or 22.04. On a 2019 HP Chromebook with Intel processor, building Praat takes a forbidding 27 minutes.

So we choose to build Praat on Ubuntu (under Parallels Desktop on an Intel64 Mac), because building the Intel Chrome64 edition on OrbStack Ubuntu 20.04 takes only 63 seconds (ARM64) or 215 seconds (Intel64). If you have the Linux set-up described in 4.3, you can do this with the praatc-build command.

Next, you need a way to get the executable praat from Mac/Ubuntu to your Chromebook. The distributors of Praat do this via an intermediary university computer; let’s call this computer-in-the-middle fon.hum.uva.nl (not coincidentally, that’s the name of the computer that hosts praat.org). If you have an account on that computer (say it’s called yourname), then you can access that account with ssh, and it is best to do that without typing your password each time. To accomplish this, type

# on Ubuntu command line
ssh-keygen

on your Ubuntu. This gives you a file ~/.ssh/id_rsa.pub on your Ubuntu, which contains your public ssh key. You should append the contents of this id_rsa.pub to the file ~/.ssh/authorized_keys on your intermediary computer. From that moment on, your intermediary computer will accept rsync -e ssh calls from your Ubuntu. On the intermediary computer, create a folder ~/builds, and a folder chrome64 inside that. If you now define

# in Ubuntu:~/.bash_aliases
praatc-put="rsync -tpvz ~/praatsc/praat [email protected]:~/builds/chrome64"
praatc-mid="praatc-build && praatc-put"

you can build and send Praat for Chrome to the intermediary computer by just typing

# on Ubuntu command line
praatc-mid

On your Chromebook, start up Linux (see the Chromebook download page for details), create a directory ~/praats there, and define the following:

# in Chromebook:~/.bash_aliases
alias praat-get="( cd ~/praats &&\
    rsync -tpvz [email protected]:~/builds/chrome64/praat . )"
alias praat="~/praats/praat"
alias praat-run="praat-get && praat"

From then on, you can use

# on Chromebook command line
praat-run

to fetch Praat from the intermediary computer and run it.

The cycle from editing Praat on the Mac to running it on your Chromebook therefore takes only three steps:

  1. edit and save the source code in Xcode on your Mac;
  2. type praatc-mid on your Ubuntu (under Parallels Desktop on your Mac);
  3. type praat-run on your Chromebook.

For edits in a cpp file (no changes in header files), this whole cycle can be performed within 15 seconds.

4.5. Raspberry Pi development set-up

One could perhaps create the Raspberry Pi edition by cross-compiling on Ubuntu 20.04 or 22.04. If any reader of these lines has precise instructions, we would like to know about it (the main problem is how to install the GTK etc libraries in the Raspberry Pi toolchain, or how to get dpkg under Ubuntu-buster to actually find armhf libraries).

Till then, you build on the Raspberry Pi itself. Your could do that via an intermediary computer (analogously to what we described above for Chromebook), but you can also do it directly if you include your Raspberry Pi in the same local network as your Mac and switch on SSH on your Raspberry Pi (via Raspberry -> Preferences -> Raspberry Pi Configuration -> Interfaces -> SSH -> Enable. You add your Mac’s public SSH key to your Raspberry Pi with

# on Mac command line
ssh-keygen   # only if you have no SSH key yet
ssh-copy-id [email protected]   # or whatever your Pi’s static IP address is

On your Raspberry Pi, you create a folder ~/praats, after which you can push the sources from your Mac to your Raspberry Pi with

# in Mac:~/.bash_profile
ORIGINAL_SOURCES="~/Praats/src"
EXCLUDES='--exclude="*.xcodeproj" --exclude="Icon*" --exclude=".*" --exclude="*kanweg*"'
alias praats-putpi="rsync -rptvz -e ssh $EXCLUDES \
    $ORIGINAL_SOURCES/ [email protected]:~/praats"

On the Raspberry Pi, you define

# in RaspberryPi:~/.bash_aliases
alias praat-build="( cd ~/praats &&\
    cp makefiles/makefile.defs.linux.rpi makefile.defs &&\
    make -j4 )"
alias praat="~/praats/praat"
alias praat-run="praat-build && praat"

after which you can build and run Praat with

# on Raspberry Pi command line
praat-run

Thus, the cycle from editing Praat on the Mac to running it on your Raspberry Pi therefore takes three steps:

  1. edit and save the source code in Xcode on your Mac;
  2. type praats-putpi on your Mac;
  3. type praat-run on your Raspberry Pi, perhaps via ssh -X [email protected] in your Mac terminal.

From clean sources this takes around 19 minutes (on a Raspberry Pi 4B), but if no header files change, then it can be done in approximately 20 seconds.

4.6. Distributing Praat

If you want to distribute your version of Praat, you can do so on GitHub and/or on a website (at least, that’s how the main authors do it). Both of these venues require that you have all the executables in one place. The guide below refers to the creation of packages for all platforms for Praat version 9.9.99, although your version number will be different. The packages will be collected in the directory ~/Praats/www on the Mac.

If you follow the location mentioned in the .xcodeproj file, the Mac binary will reside in a place like ~/Dropbox/Praats/bin/Configuration64.

After notarizing the Mac binary (see above under 3.2), you include the executable in a .dmg disk image, with the following commands:

# on Mac command line
PRAAT_WWW="~/Dropbox/Praats/www"
PRAAT_VERSION=9999
cd ~/Dropbox/Praats/bin/macos/Configuration64
hdiutil create -fs HFS+ -ov -srcfolder Praat.app -volname Praat_${PRAAT_VERSION} praat_${PRAAT_VERSION}.dmg
hdiutil convert -ov -format UDZO -o ${PRAAT_WWW}/praat${PRAAT_VERSION}_mac.dmg praat_${PRAAT_VERSION}.dmg
rm praat_${PRAAT_VERSION}.dmg

You also need to distribute the .xcodeproj file, which is actually a folder, so that you have to zip it:

# on Mac command line
ORIGINAL_SOURCES="~/Dropbox/Praats/src"
cd $ORIGINAL_SOURCES
zip -r $PRAAT_WWW/praat${PRAAT_VERSION}_xcodeproj.zip praat.xcodeproj

The Windows executables have to be sent from your Cygwin terminal or MSYS shell to your Mac. It is easiest to do this without a version number (so that you have to supply the number only once), so you send them to the intermediate Mac folders ~/Dropbox/Praats/bin/win-intel64 and ~/Dropbox/Praats/bin/win-intel32 and ~/Dropbox/Praats/bin/win-arm64. On MSYS you can define:

# in MSYS:~/.bashrc
alias praat-dist="praat-build && rsync -t ~/praats/Praat.exe /z/Dropbox/Praats/bin/win-arm64"
alias praat64-dist="praat64-build && rsync -t ~/praats64/Praat.exe /z/Dropbox/Praats/bin/win-intel64"
alias praat32-dist="praat32-build && rsync -t ~/praats32/Praat.exe /z/Dropbox/Praats/bin/win-intel32"

so that you can “upload” the two executables to the Mac with

# on MSYS command line
praat-dist
praat64-dist
praat32-dist

The four Linux executables have to be sent from your Ubuntu terminal to your Mac, namely to the folder ~/Dropbox/Praats/bin/linux_intel64 or ~/Dropbox/Praats/bin/linux_arm64 (each of which will contain praat, praat_barren and praat_nogui), and to the folder ~/Dropbox/Praats/bin/chrome_intel64 or ~/Dropbox/Praats/bin/chrome_arm64 (which will contain only praat). On Ubuntu you can define

# in MSYS2 Intel64 Ubuntu:~/.bash_aliases
alias praat-dist="praat-build && rsync -t ~/praats/praat /Users/yourname/Dropbox/Praats/bin/linux-intel64"
alias praatb-dist="praatb-build && rsync -t ~/praatsb/praat_barren /Users/yourname/Dropbox/Praats/bin/linux-intel64"
alias praatn-dist="praatn-build && rsync -t ~/praatsn/praat_nogui /Users/yourname/Dropbox/Praats/bin/linux-intel64"
alias praatc-dist="praatc-build && rsync -t ~/praatsc/praat /Users/yourname/Dropbox/Praats/bin/chrome-intel64"

# in MSYS2 ARM64 Ubuntu:~/.bash_aliases
alias praat-dist="praat-build && rsync -t ~/praats/praat /Users/yourname/Dropbox/Praats/bin/linux-arm64"
alias praatb-dist="praatb-build && rsync -t ~/praatsb/praat_barren /Users/yourname/Dropbox/Praats/bin/linux-arm64"
alias praatn-dist="praatn-build && rsync -t ~/praatsn/praat_nogui /Users/yourname/Dropbox/Praats/bin/linux-arm64"
alias praatc-dist="praatc-build && rsync -t ~/praatsc/praat /Users/yourname/Dropbox/Praats/bin/chrome-arm64"

so that you can “upload” the four executables to the Mac with

# on Ubuntu command line
praat-dist
praatb-dist
praatn-dist
praatc-dist

You can fetch the Raspberry Pi edition directly from your Raspberry Pi:

# on Mac command line
rsync -tpvz [email protected]:~/praats/praat ~/Dropbox/Praats/bin/rpi-armv7

When the folders under ~/Dropbox/Praats/bin, namely win-intel64, win-intel32, win-arm64, linux-intel64, linux-arm64, chrome-intel64, chrome-arm64 and rpi-armv7 all contain enough new executables (there should be 1, 1, 1, 3, 3, 1, 1 and 1, respectively), you can issue the following commands to create the packages and install them in ~/Dropbox/Praats/www:

# on Mac command line
zip $PRAAT_WWW/praat${PRAAT_VERSION}_win-intel64.zip ~/Dropbox/Praats/bin/win-intel64/Praat.exe
zip $PRAAT_WWW/praat${PRAAT_VERSION}_win-intel32.zip ~/Dropbox/Praats/bin/win-intel32/Praat.exe
zip $PRAAT_WWW/praat${PRAAT_VERSION}_win-arm64.zip ~/Dropbox/Praats/bin/win-arm64/Praat.exe
( cd ~/Dropbox/Praats/bin/linux-intel64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-intel64.tar praat &&\
  gzip praat${PRAAT_VERSION}_linux-intel64.tar &&\
  mv praat${PRAAT_VERSION}_linux-intel64.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/linux-intel64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-intel64-barren.tar praat_barren &&\
  gzip praat${PRAAT_VERSION}_linux-intel64-barren.tar &&\
  mv praat${PRAAT_VERSION}_linux-intel64-barren.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/linux-intel64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-intel64-nogui.tar praat_nogui &&\
  gzip praat${PRAAT_VERSION}_linux-intel64-nogui.tar &&\
  mv praat${PRAAT_VERSION}_linux-intel64-nogui.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/chrome-intel64 &&\
  tar cvf praat${PRAAT_VERSION}_chrome-intel64.tar praat &&\
  gzip praat${PRAAT_VERSION}_chrome-intel64.tar &&\
  mv praat${PRAAT_VERSION}_chrome-intel64.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/linux-arm64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-arm64.tar praat &&\
  gzip praat${PRAAT_VERSION}_linux-arm64.tar &&\
  mv praat${PRAAT_VERSION}_linux-arm64.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/linux-arm64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-arm64-barren.tar praat_barren &&\
  gzip praat${PRAAT_VERSION}_linux-arm64-barren.tar &&\
  mv praat${PRAAT_VERSION}_linux-arm64-barren.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/linux-arm64 &&\
  tar cvf praat${PRAAT_VERSION}_linux-arm64-nogui.tar praat_nogui &&\
  gzip praat${PRAAT_VERSION}_linux-arm64-nogui.tar &&\
  mv praat${PRAAT_VERSION}_linux-arm64-nogui.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/chrome-arm64 &&\
  tar cvf praat${PRAAT_VERSION}_chrome-arm64.tar praat &&\
  gzip praat${PRAAT_VERSION}_chrome-arm64.tar &&\
  mv praat${PRAAT_VERSION}_chrome-arm64.tar.gz $PRAAT_WWW )
( cd ~/Dropbox/Praats/bin/rpi-armv7 &&\
  tar cvf praat${PRAAT_VERSION}_rpi-armv7.tar praat &&\
  gzip praat${PRAAT_VERSION}_rpi-armv7.tar &&\
  mv praat${PRAAT_VERSION}_rpi-armv7.tar.gz $PRAAT_WWW )

Finally, you can update your website and/or create a new release on GitHub.

praat's People

Contributors

adriaandegroot avatar davidweenink avatar dlukes avatar newbluemoon avatar noellesage avatar paulboersma avatar pineking avatar psibre avatar rlaboiss avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

praat's Issues

Table: Line graph where... does not work properly if nrow < ncol

The command Line graph where... for Tables will not work if the column that is set to be the "vertical column" is the final one (=rightmost) in the Table object, and the Table object has fewer rows than columns.

This script exemplifies the problem:

# Generate sample Tables
columns$ = "a b c d e f g h i j k l m n o p q r s t u v w x y z"
Erase all
for rows from 3 to 5
  for cols from 3 to 5
    table = Create Table with column names: if rows < cols then "bad" else "good" fi,
      ... rows, left$(columns$, (2 * cols) - 1)

    # Populate Table
    for y to rows
      for x to cols
        Set numeric value: y, mid$(columns$, (2 * x) - 1), y
      endfor
    endfor

    # Problem only exists when drawing the final (=rightmost) column
    last_column$ = mid$(columns$, (2 * cols) - 1)

    # The problematic command
    Line graph where: last_column$, 0, 0, "", 0, 0, "+", 0, "yes", "1; (= everything)"

    # Problem only exists with Tables where nrow < ncol
    pauseScript: "Did ",
      ... if rows < cols then "not " else "" fi,
      ... "draw (", rows, ", ", cols, ")"
    removeObject: table
    Erase all
  endfor
endfor

The problem exists up to and including 5.4.19, in Linux and Mac at least.

Audio playback problems in Linux

With recent versions of Praat, I cannot play audio on Kubuntu 14.04 (32 bit). Reverting back to 5.4.22 I encounter no such problem. The problem exists in Praat 6.0 and above (6.0.04 included).

The error that pops up tells me to turn on PulseAudio in the Sound Playing Preferences window, but PulseAudio is already selected. Selecting "Alsa via PulseAudio" fixes the problem during the session, but that preference is reverted when restarting Praat, so it needs to be set again each time.

error

Two very minor issues

as reported by rpmlint:

praat.x86_64: W: incorrect-fsf-address /usr/share/doc/packages/praat/GNU_General_Public_License.txt
The Free Software Foundation address in this file seems to be outdated or
misspelled.  Ask upstream to update the address, or if this is a license file,
possibly the entire file with a new copy available from the FSF.

praat.x86_64: I: binary-or-shlib-calls-gethostbyname /usr/bin/praat
The binary calls gethostbyname(). Please port the code to use getaddrinfo().

OSX: keyboard interaction broken

I'm used to confirming the quit dialog by just hitting the enter key.
quit
This worked on OSX right up until v6.0.11.
However, from v6.0.12 onwards, hitting enter no longer works.

More critically however, any keyboard interaction, such as tabbing through elements in a form or dialog, is broken and causes Praat to crash (at least on 10.9.5).

Praat doesn't have a menu bar on ubuntu 16.04

I've installed Praat on my ubuntu 16.04LTS using "sudo apt-get install praat".
After starting the programme two windows appear: "Pratt objects" and "Praat picture", but both of them don't have menu bars.
2017-05-15 12-31-59

Feature request (with implementation): Additional Keyboard Shortcut for scripting window

Hello! I hope that it is socially acceptable to post something like this here, I'm not yet a frequent user of GitHub.

I love using an external editor for scripting, and see no harm in adding a keyboard shortcut to the "Reopen from disk" command in the File menu of the Scripting editor. I cloned the repo, added this line, compiled, and it's working great for me. I hope you think it's a good idea to add this to the master branch? It's makes a keyboard shortcut of Shift + (command key/control key) + R.

sys/TextEditor.cpp line 606 is:

Editor_addCommand` (this, U"File", U"Reopen from disk", 0, menu_cb_reopen);

I suggest that it be:

Editor_addCommand (this, U"File", U"Reopen from disk", GuiMenu_SHIFT + 'R', menu_cb_reopen);

Again, I apologize if this isn't the place for this, but the change is so trivial I thought it wouldn't hurt to ask.

Dan

Duration Manupulation Out of Buffer Bug

Praat doesn't play the manipulation of the sound completely when the duration is manipulated to be above 3.

Steps to reproduce:

  1. Get a Sound by whatever mean
  2. Select the sound. Click "Manipulate - To manipulation"
  3. Change the maximum value of range of duration to any value above 3 (e.g. 5)
  4. Create a Duration point. Set the point to as high as possible so that the average duration becomes any length above 3.

Result:

  • The audio isn't completely played in preview, and it doesn't completely exported after resynth.

Variables with initial underscores

When writing procedures, I often find it useful to differentiate between procedures for internal use, and procedures for general use. Taking a hint from Perl and others, I like to preppend internal procedures with an initial underscore (_).

Variables in Praat are not allowed to begin with an underscore. But since "local" variables in procedures take their name from the name of the procedure they belong to, and procedures can be named with an initial underscore, this results in all sorts of fun with Praat variables:

procedure _test ()
  .local = 1
endproc
@_test()

# Works
a = '_test.local'
appendInfoLine: a

# Doesn't
asserterror Unknown symbol:'newline$'« _
a = _test.local

Is this desired behaviour? I've learned now to navigate around the problem as illustrated above, but it feels a bit inconsistent. This is one of the reasons I sometimes still use variable substitution.

Licensing terms

I'm trying to get praat accepted into a linux distribution but the licensing terms are unclear.

main/GNU_General_Public_License.txt is version 2.0, but under external there are several files with a gpl 3.0+ header.

Since I couldn't find anywhere a notice about the former being gpl 2.0 "or any later version", there are distributability issues with it being linked to the latter.

So, could you please clarify the question?

Praat interactive shell broken

According to the Manual (Scripting 6.9), running praat - should enter an interactive shell, or allow praat to accept commands from STDIN.
This worked up to v5.4.14:

$ /Volumes/Praat64_5414/Praat.app/Contents/MacOS/Praat -
Praat > echo Hello
Hello
Praat > Quit
$ 

However, from v5.4.15 onwards, this no longer works:

$ /Volumes/Praat64_5415/Praat.app/Contents/MacOS/Praat -
^C

It just hangs, and the Praat prompt never appears.

Erratic behaviour: only indexed variables can't share function names

Normally, it's not a problem that variables and functions have the same names (which is definitely a good thing):

string$ = "hello"
appendInfoLine: string$

index = 1
appendInfoLine: index

But indexed variables seem to be an exception:

string$[1] = "hello"
asserterror Expected the end of the formula, but found "["
appendInfoLine: string$[1]

right$[1] = "hello"
asserterror Unknown variable:
appendInfoLine: right$[1]

# Same with numeric functions
index[1] = 1
asserterror Unknown variable:
appendInfoLine: index[1]

Is this a desired behaviour? I would understand if variables could never be named like functions. But the fact that some of them can, and some of them cannot, is confusing.

It's also confusing that the error is raised when the variable is used, and not when it is assigned. If those variable names are invalid, then surely the error should be caught sooner?

Incorrect font kerning in man pages

I feel this has been a long lasting bug, but seeing that the display of man pages seems to have been improved recently, I figured it made sense to add this in.

At least in Linux (tested on other systems, but confirmed in Kubuntu 14.04 with Praat 5.4.15), switching in the manual from a standard font to an italic font causes the italic to be printed on top of the end of the string in a normal font. Sample image below:

manual

At its most serious, this can make some change-heavy passages impossible to understand, meaning users need to refer to the HTML documentation.

null flush option for executable

Instead of using --run, it would be nice to have a way to directly feed scripts to a running console-mode version of the executable. Using such an approach, a script could open the executable once, pipe commands to it, and send a null character to flush the buffer. This would make using Praat from an external script (such as with PraatR) much faster.

Incompatible changes in text versions of FFNet objects

Praat 5.4.22 and 6.0.03 generate different text versions of FFNet objects, and at least Praat 6.0.03 complains when opening an FFNet object saved by 5.4.22.

The old objects looked like this:

File type = "ooTextFile"
Object class = "FFNet"

nLayers = 1 
nUnitsInLayer []: 
    nUnitsInLayer [0] = 4 
    nUnitsInLayer [1] = 3 
outputsAreLinear = 0 
nonLinearityType = 1 
costFunctionType = 1 
outputCategories: size = 0 
nWeights = 15 
w []: 
    w [1] = -0.07111157301884496 
    w [2] = -0.007799936451578726 
    w [3] = -0.0736766578690795 
    w [4] = -0.05769455299999926 
    w [5] = -0.0038267067826605497 
    w [6] = 0.056617462520272915 
    w [7] = -0.06044512424540989 
    w [8] = -0.04086647532466166 
    w [9] = -0.030626591089634614 
    w [10] = 0.01798069280191066 
    w [11] = 0.03951275934685821 
    w [12] = 0.06319214749062219 
    w [13] = 0.06850375664532089 
    w [14] = -0.052898212612844664 
    w [15] = 0.04948936042643251 

The objects saved by Praat 6.0.03 replace the line that says outputCategories with this:

outputCategories? <absent> 

and Praat complains saying

Found a number while looking for an enumerated value in text (line 11).
FFNet not read.

Access to object attributes

Is there any reason to limit the number of accessible object attributes to the ones listed in the manual? It seems to me that in that list there is at least one omission, which is the time of the first sample (for sampled objects).

This was a (small) issue I bumped into while making a "To Table..." command for Pitch objects:

pitch = selected("Pitch")
# Is there any other way to obtain this value?
first = Get time from frame number: 1

matrix = To Matrix
transposed = Transpose
realtable = To TableOfReal

Insert column (index): 1
Set column label (index): 1, "time"
Set column label (index): 2, "f0"

# The time of the first sample is needed for this formula
Formula: "if col = 1 then row * Object_'pitch'.dx + 'first' else self fi"
table = To Table: "delete"
Remove column: "delete"
Rename: selected$("Table") - "_transposed"
removeObject: matrix, transposed, realtable
Formula (column range): "f0", "f0", "if !self then undefined else self fi"

I did the conversion almost entirely by using internal object casting commands, which I believe to be more efficient. But in order to turn the frame values of the Pitch object to seconds, the time of the first frame is needed.

In this case I could do this by getting that value with Get time from frame number... and then simply interpolating that value into the formula. But what I would have wanted to do was to make the formula

if col = 1 then row * Object_'pitch'.dx + Object_'pitch'.x1 else self fi

which is more transparent and easier to use in a formula that is not on a script. But this doesn't work, since x1 is not available as an attribute. In this case there was a workaround, but sice there is no command to obtain eg. the strength of each candidate in a Pitch object, the only way to read those is to write to text and parse the file externally, which seems silly.

In that case, what I would like to be able to write is

pitch = selected("Pitch")
frames = Get number of frames
for i to frames
  n = Object_'pitch'.frame[i].nCandidates
  for j to n
    strength[i][j] = Object_'pitch'.frame[i].candidate[j].strength
  endfor
endfor

What's the rationale for not allowing this?

use python call doubt

python:

import subprocess
subprocess.call(['D:\\Praat.exe', '--run', 'D:\\getInfo.praat', r'D:\a.wav'])

praat script:

form cmd_get_sound_info
    sentence file_path a.wav
endform
s = Read from file: file_path$
.....
.....
test1 View & Edit ----->not performed or completed
test2 Edit ----->not performed or completed
test3 editor:s ----->not performed or completed
.....
.....

Select... 0 2
startTime = Get start of selection
endTime = Get end of selection
name$ = selected$ ("Sound")

numberOfTimeSteps = (endTime - startTime) / 0.01
for step to numberOfTimeSteps
    time = startTime + (step - 1) * 0.01
    Move cursor to... time
    pitch = Get pitch
    intensity = Get intensity
    f1 = Get formant... 1
    f2 = Get formant... 2
    f3 = Get formant... 3
    f4 = Get formant... 4
    f5 = Get formant... 5

    appendInfoLine: fixed$ (time, 6), " ", fixed$ (pitch, 6)," ", fixed$ (intensity, 6)," ", fixed$ (f1, 6)," ", fixed$ (f2, 6)," ", fixed$ (f3, 6)," ", fixed$ (f4, 6)," ", fixed$ (f5, 6)
endfor

appendFile: name$+".txt", info$()

64-bit edition: praat6028_win64.zip
hope to get help,tks

Why a new executable name for "barren" praat?

a0b9da5 introduced a new default executable name for Praat when compiled as barren.

What is the rationale behind this? This change means that computers that currently use automated build systems using a barren praat (including the ones I maintain), will either have to be modified to change the name of the executable, or will have to use a version of scripts that is specifically written to use that executable.

As an aside, is there any reason why a change like this, which will most likely result in breakage, is introduced without any warning or notification whatsoever?

Sound editor redraw fails occasionally

With Praat 6.0.14 (64 bit, Xubuntu), I hit an issue this morning where the sound editor was not responding to mouse (click-drag to make selections) or keyboard (zooming commands like Ctrl+i, Ctrl+a, etc) commands. The commands were clearly registering, but the redraw to reflect the commands would not occur until I clicked outside the editor window (or pressed Alt+Tab) such that the editor window lost system focus (at which point if I had, say, click-dragged a selection and pressed Ctrl+n, the window would correctly show the waveform zoomed in to the selection I had made). The redraw would occur when the editor lost focus, not when focus returned to the editor. This happened only in one out of several sound editor windows this morning; closing that editor and re-opening from the same object in the list failed to reproduce. If it happens again, is there anything I should do / try to help narrow down the cause?

Compiling on Macintosh

I would like to build Praat on OS X, but I'm falling at the first hurdle.
The instructions in README.md start with

Extract the *xcodeproj64.zip* file from the latest release

but where do I find this xcodeproj64.zip file? It's not in the praat-master.zip file that I downloaded, and I don't see it when I do a git clone either.

PATH for system calls in scripts?

I notice that the PATH for system calls in praat scripts is this

/usr/bin:/bin:/usr/sbin:/sbin

on my system (OSX 10.9.5).

Is there a way to override/customize/extend the PATH for a system call? I would like to avoid having to specify the absolute path to the executable I want to run, to preserve cross-platform portability of the praat script.

More generally, can environment variables be modified (non-globally, one would hope) from within praat?

I can't find the xcode project file

Hi, as I stated in the title, I can't find the xcode project file or any zip file containing it like you said in the compiling guide.
So please guide me what I should do if I want to compile Praat in mac os. Sorry for my bad English anyway.

Refuse to open all corrupt objects

Praat is very strict about the data it handles, and will often refuse to open an object that is corrupt: if a string is expected and a number is found, for example.

However, this is not the case with all types of corruption. In particular, TextGrid files are very sensitive about their timestamps: the end of an interval must be the beginning of the interval that follows. And yet Praat will happily open a TextGrid in which this is not the case.

This leads to bugs that are difficult to track down. It would be better if Praat refused to open these files, maybe specifying where the error lies. Otherwise, opening any TextGrid leaves you with the possibility that Praat will behave unexpectedly under correct operation by the user, and there is no way to know this until it does.

errors in praat_sound_init.cpp

I tried to build the program using make and I got this.
I'm using Ubuntu 16.04

praat_Sound_init.cpp: In function ‘void INFO_Praat_reportSoundServerProperties(UiForm, int, Stackel, const char32_, Interpreter, const char32_, bool, void_)’:
praat_Sound_init.cpp:2156:1: error: ‘END’ was not declared in this scope
END
^
In file included from praat_Sound_init.cpp:19:0:
../sys/praat.h:484:157: error: a function-definition is not allowed here before ‘{’ token
rm sendingForm, int narg, Stackel args, const char32 *sendingString, Interpreter, const char32 *invokingButtonTitle, bool, void *okClosure) {
^
praat_Sound_init.cpp:2159:1: note: in expansion of macro ‘FORM_WRITE3’
FORM_WRITE3 (SAVE_Sound_saveAsAifcFile, U"Save as AIFC file", nullptr, U"aifc") {
^
praat_Sound_init.cpp:2770:1: error: expected ‘}’ at end of input
}
^
praat_Sound_init.cpp:2770:1: error: expected ‘catch’ at end of input
praat_Sound_init.cpp:2770:1: error: expected ‘(’ at end of input
praat_Sound_init.cpp:2770:1: error: expected type-specifier at end of input
praat_Sound_init.cpp:2770:1: error: expected ‘)’ at end of input
praat_Sound_init.cpp:2770:1: error: expected ‘{’ at end of input
praat_Sound_init.cpp:2770:1: error: expected ‘}’ at end of input
praat_Sound_init.cpp:2770:1: error: expected ‘}’ at end of input
: recipe for target 'praat_Sound_init.o' failed
make[1]: *_* [praat_Sound_init.o] Error 1
make[1]: Leaving directory 'cppworkspace/praat/fon'
makefile:14: recipe for target 'all' failed
make: *** [all] Error 2

Praat is generating 0 byte waveform

I am generating the waveform from praat script. It's working great but only for attached audio file https://drive.google.com/file/d/0B820TayaGz1PUjhxUTlIVzZRQmM/view?usp=sharing for which I have a problem.

Below script generates the multiple waveform images based on its duration since there is a problem creating a single waveform for the longer audio so we have chosen this option to create waveforms for longer audio. This script generally working great for many audio files but we have got the problem for the audio https://drive.google.com/file/d/0B820TayaGz1PUjhxUTlIVzZRQmM/view?usp=sharing. It's generating 0 byte waveform that means no contents on waveform image while we are expecting the file size > 1 KB.

To test this audio please download the audio file from the above link and change the values for variables outputFolder$ (output location for waveform) and audioFile$ (source path of the audio file). After changing the values then please run the script from the praat application.

We have confirmed that there is a problem while saving waveform images whose responsible code is in bold text in the below script.

Below is the script which I am using.

outputFolder$ = "C:\Temp\ffmpeg\experiments"
audioFile$ = "D:\audio.mp3"

window_start = 0
full_window=3600;
divide=15;

if audioFile$ <> ""
Read from file... 'audioFile$'
audioName$ = selected$ ("Sound")
endif
To TextGrid... phrases
select TextGrid 'audioName$'
file_length = Get total duration

if file_length<=41*60
full_window=2460
divide=30;
endif

if file_length<=21*60
full_window=1260
divide=20;
endif

if file_length<=11*60
full_window=660
divide=15;
endif

if file_length>41*60
full_window=3600
divide=60;
endif

draw_num = floor(file_length/full_window)

last_draw = file_length - draw_num*full_window

if file_length<full_window
view_width = 4 * file_length/divide
else
view_width = 4 * full_window/divide
endif
view_width=view_width

for b from 1 to draw_num
select TextGrid 'audioName$'
window_end = window_start + full_window
start_int = Get interval at time... 1 window_start
end_int = Get interval at time... 1 window_end
select Sound 'audioName$'
Line width... 1
Viewport... 0 view_width 0 2
Colour... {110, 110, 10}
Draw... window_start window_end 0 0 no curve

select Sound 'audioName$'
To Intensity... 80 0
Down to IntensityTier

select Sound 'audioName$'
To Pitch (ac)... 0.0 80 15 no 0.03 0.3 0.2 0.9 0.14 300
Down to PitchTier

select Intensity 'audioName$'
Viewport... 0 view_width 1.25 2.25

Colour... lime
Line width... 2

select Pitch 'audioName$'
Viewport... 0 view_width 1.25 2.25

Colour... green

Line width... 1
Draw... window_start window_end 80 300 no
Line width... 2
Draw... window_start window_end 80 300 no

save_width = view_width - 0.60
Viewport... 0.60 save_width 0.40 2
Save as 300-dpi PNG file... 'outputFolder$'\waveform_'b'.png
Erase all
window_start = window_start + full_window
endfor

select TextGrid 'audioName$'
window_start = file_length - last_draw
window_end = file_length
start_int = Get interval at time... 1 window_start
end_int = Get interval at time... 1 window_end
view_width = 4 * (window_end-window_start)/divide
select Sound 'audioName$'
Line width... 1
Viewport... 0 view_width 0 2
Colour... {110, 110, 10}
Draw... window_start window_end 0 0 no curve

select Sound 'audioName$'
To Intensity... 80 0
Down to IntensityTier

select Sound 'audioName$'
To Pitch (ac)... 0.0 80 15 no 0.03 0.3 0.2 0.9 0.14 300
Down to PitchTier

select Intensity 'audioName$'
#Viewport... 0 view_width 1.25 2.75
Viewport... 0 view_width 1 2.75

Colour... lime
Line width... 2

select Pitch 'audioName$'
Viewport... 0 view_width 1.25 2.75
Colour... green

Line width... 1
Draw... window_start window_end 80 300 no
Line width... 2
Draw... window_start window_end 80 300 no

final_num = draw_num + 1
save_width = view_width - 0.60
Viewport... 0.60 save_width 0.40 2.75
Save as 300-dpi PNG file... 'outputFolder$'\waveform.png
Erase all
window_start = window_start + full_window

Command names take over inline comments

Currently (6.0.15), inline comments (marked by ;) in lines with command names are interpreted to be part of the command name:

Create TextGrid: 0, 1, "tier", "" ; Good
asserterror Command "Remove ; Bad!"
  ... not available for current selection.
Remove ; Bad!

As shown in the snippet, a comment next to the first command (after the argument list) is correctly ignored, but when used in a line with a command name without arguments, it is taken to be part of the command name, and raises an error.

Is this the correct behaviour?

6.0.30 no return in nonvoid function

rpmlint complains about this:

I: Program returns random data in a function
E: praat no-return-in-nonvoid-function TextGrid_extensions.cpp:817

This is my build command (on openSUSE linux):

cp makefiles/makefile.defs.linux.pulse ./makefile.defs
+ sed -e '/^CFLAGS/s/$/\ -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables/' -i makefile.defs
+ make -j4

CommandLine only version for Android

Hello,

Is it possible to cross compile Praat for Android ? I only need the command line version without any graphics and sound packages. I only want to execute basic praat script without user interaction.

Best regards,

Jimmy

Tab shortcut does not work when numlock is on

It seems like this issue was fixed back in 2011, but as of the latest release (and it's been a while since I've installed praat, so I don't know how far back it goes), the tab shortcut is broken on linux. There is no way to play sound except with view>play...>(manually type in start and endpoint). Praat is unusable in this state, please rollback or otherwise fix as soon as possible.

Crash when one script creates two forms

With a sample script like:

form Test...
  real Number 1
endform

hitting "Run" will open a dialog box. Clicking "OK" will apply the changes and dismiss the box. Clicking "apply" will apply the changes and keep the dialog box open. If while a dialog box is open the script is run again, a new dialog box will appear and (at least in Linux) the previous dialog box will become greyed out.

dialog

Normal use can continue with the second dialog box. But closing the first one (which looks unresponsive) will crash Praat with a segmentation fault.

This is a particularly likely scenario when rapidly prototyping scripts.

I propose that, when the script is run, any existing forms are closed (as if by pressing "Cancel") before any new ones are open.

This happens systematically. I tested it with the Praat 6.0.15 binary from Github, running on a 32-bit machine under Kubuntu 15.10.

Incorrect mode detection while running with prove

Running Praat from the command line through prove results in Praat incorrectly trying to open the test scripts instead of running them.

prove is a Perl-based utility to run TAP tests. As such, it makes it possible to use any interpreter through its --exec option, and not just Perl itself. However, this does not work in Praat v6.0 at least.

Here's a test case:

# cpanm Test::Harness or sudo apt-get install libtest-harness-perl
# but prove should come with the standard Perl distribution
git clone http://gitlab.com/cpran/plugin_testsimple.git
cd plugin_testsimple
prove --exec "praat"

The last command runs the tests (which by default match ./t/*.t) through praat, and should result in the output of each of the scripts being parsed by prove for general statistics. Instead, each test script is read and opened in the Praat editor in turn.

The problem is not related to the extensions of the individual test scripts (in this case, t). It is probably related to the way in which prove calls Praat internally.

I guess this should be fixed by improving the detection of the environment under which Praat is called, but in the meantime it could be fixed by implementing an --exec or --run option in Praat itself (as once planned) to force execution mode (bypassing the detection altogether).

BTW: This was using Praat 6.0 under Kubuntu 14.04, with Perl 5.22 and TAP::Harness 3.35

Typo in paste history in script window

Hi,

When adding a point to a PitchTier through the interface and then pasting the action history in the script window, the action is erroneously pasted as
Add point at: 0.0, 120

However, this will not run: the working command is
Add point: 0.0, 120

Writing to Info window swallowed by nocheck runScript used in assignment

In the following code snippet, no text will be printed in the Info window:

clearinfo
file$ = temporaryDirectory$ + "/temp.praat"
writeFileLine: file$,
  ... "writeInfoLine: ""Hello"""
a = nocheck runScript: file$
deleteFile(file$)

However, if the nocheck directive is removed,

a = runScript: file$

or if the line with the call to runScript is no longer an assignment

nocheck runScript: file$

the Info window correctly displays the string "Hello". Is this intentional? If so, what's the rationale?

Opening editor from batch

I am trying to break audios into smaller parts on a linux server. But it requires opening an editor, which can't be done on batch. So is there a way to extract and save a specific portion of sound without opening the editor window, or a way to 'open' editor window while using praat from command line (batch)?

More rpmlint nitpicking

Since appending "-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables" to CFLAGS in makefile.defs.linux.pulse, I'm seeing this:

I: Program causes undefined operation
   (likely same variable used twiceand post/pre incremented in the same expression).
   e.g. x = x++; Split it in two operations.
W: praat sequence-point Eigen.cpp:398

I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
W: praat strict-aliasing-punning ../../sys/../num/../sys/melder.h:923
W: praat strict-aliasing-punning ../dwsys/../num/../sys/melder.h:923
W: praat strict-aliasing-punning ../num/../sys/melder.h:923
W: praat strict-aliasing-punning ../sys/../num/../sys/melder.h:923
W: praat strict-aliasing-punning Label.cpp:39

I: Statement is overflowing a buffer
E: praat bufferoverflow dictionary.cpp:3661:42

The last one is actually a problem with espeak, but since upstream hasn't fixed it yet (at least in stable), maybe you'll want to address it with this:

Index: praat-6.0.28/external/espeak/dictionary.cpp
===================================================================
--- praat-6.0.28.orig/external/espeak/dictionary.cpp
+++ praat-6.0.28/external/espeak/dictionary.cpp
@@ -3658,7 +3658,7 @@ int Lookup(Translator *tr, const char *w
                say_as = option_sayas;
                option_sayas = 0;   // don't speak replacement word as letter names
                text[0] = 0;
-               strncpy0(&text[1], word1, sizeof(text));
+               strncpy0(&text[1], word1, sizeof(text)-strlen(text)-1);
                found = TranslateWord(tr, &text[1], 0, NULL, NULL);
                strcpy(ph_out, word_phonemes);
                option_sayas = say_as;

Extract Intervals changes non-text interval labels to underscore

When extracting intervals (e.g. select audio file and corresponding TextGrid file -> Extract- -> Extract All Intervals...), labels such as '}', '@', and '@U' are changed to '', '', and '_U'.

Praat is absolutely my favourite speech analysis tool. I use it every day!

Memory issues with recursive script calls

I've been trying to write a script to make lists of all files and directories under a given path. I've been doing that using recursive calls to script files (with runScript), and it's been working well (although maybe the problem is with the recursive script calls and not the Strings objects).

I came across two odd errors throwing segmentation faults or core dumps. And both seem to be triggered by lines in my script that would otherwise be pretty innocuous tasks:

  1. Inserting a string with Insert string...
  2. Removing a Strings object, both through the GUI or with commands like Remove or removeObject

The problems will come up for specific directory structures, but it's hard to predict which ones will be problematic. I don't think the problem is with the script, though, since the same script that will work in a directory with 2 subdirectories, crashes in a directory with 3 subdirectories. And the problem I find when removing the Strings object happens after my script has otherwise successfully finished.

Among the errors I get:

*** Error in `praat': free(): invalid next size (fast): 0x0e705d28 ***
Aborted (core dumped)
*** Error in `praat': corrupted double-linked list: 0x10148d20 ***
Aborted (core dumped)
*** Error in `praat': double free or corruption (out): 0x0edcd830 ***
Aborted (core dumped)

Other times, I just get a segmentation fault.

The problems are erratic, in that they appear only when querying some directories (with specific sub-directory structures), and sometimes only when using specific values for the max_depth argument, which modifies how deep the recursion should be. In these cases, running the script with a max_depth of 0 throws no errors, but specifying a value of eg. 2 might give me the double free or corruption error above.

This I tested on a machine running Kubuntu 14.04 (32-bit) using Praat 5.4.22. The problems exist both from the command line and from the GUI.

Missing help pages

The help page is missing in 6.0.15, and has been missing since at least 5.4.22, at least for the Get shimmer (local)... command.

The help page is missing in at least 6.0.15 for all other versions of Get shimmer.

Console Praat crashes on save PNG instruction

Console Praat (praatcon.exe) 5.4.21 (September 29 Release) is crashing on Windows 8, and Windows 7 (those are the only ones I have checked with)

A sample script that generates the waveform and saves that as a PNG file is attached.

Unable to attach script due to some issue with Github interface, I am copy-pasting it below

#praat test file , Please change the following two paths
outputFolder$ = "C:\Temp\del\praat"
audioFile$ = "C:\Temp\del\praat\test.mp3"

if audioFile$ <> ""
    Read from file... 'audioFile$'
    audioName$ = selected$ ("Sound")
endif

Line width... 1
Viewport... 0 4 0 1
Colour... magenta
Draw... 0 0 0 0 no curve
Draw inner box

select Sound 'audioName$'
To Intensity... 80 0
Down to IntensityTier

select Sound 'audioName$'
To Pitch (ac)... 0.0 80 15 no 0.03 0.3 0.2 0.9 0.14 300
Down to PitchTier

select Intensity 'audioName$'
Viewport... 0 4 0.6 1.6

Colour... lime
Line width... 2
Draw... 0 0 0 0 no
#Text right... yes Intensity (dBs)

# Draw pitch track
select Pitch 'audioName$'
Viewport... 0 4 0.6 1.6

# Draw in either greyscale or color

Colour... blue

Line width... 1
Draw... 0 0 80 300 yes
Marks bottom every... 1 5 yes yes no
Line width... 2
Draw... 0 0 80 300 no

Viewport... 0 4 0 1.6
Save as 300-dpi PNG file... 'outputFolder$'\waveform.png

6.0.30 build fails

Formula.h:22:10: fatal error: tensor.h: No such file or directory
 #include "tensor.h"

I see a sys/Tensor.h, is it the one?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.