​One of the first things I did after passing my PhD confirmation exercise (like a qualifying exam in the USA) was to research the best way to write my thesis. As a side note, I use the word 'thesis' to refer to any large written work, including a PhD, while other English speakers might use the word 'dissertation' to refer specifically to the work that a PhD student produces. In any case, the relevant information here is the term "large", since I knew I was going to be writing a lot. I now consider the tools I'm writing about here to be essential for a productive workflow, and so this post continues the theme of an earlier post on linguistic tools.

In researching how to write my thesis, I asked friends and fellow linguists who had written grammatical descriptions. Most of them had used MS Word, and told me horror stories of lost work, un-editable documents due to the sheer size of their files, difficulties formatting and printing the thing, etc.. So that was out of the question for me, at least at the time (2011; I think more recent versions of MS Office may have fixed some of these issues). But one of them mentioned a program called LaTeX (the funny capitalization is actually part of the name), and that it made typesetting and organization a breeze. And it's free! Which is pretty important to students (if not everyone).

So I checked it out, and ended up spending the next few months learning how to set it up on my computer and how to use it (I use MacTeX as the backend). I am fortunate that I have a little background in coding, because LaTeX is essentially a markup language. You write the text of what you want, formatting parts of it by using special combinations of characters and commands (or 'tags') that tell a program how to format them. Then you run a 'compiler' that outputs everything in the correct layout in a PDF. This is pretty brilliant, because it lets you (the writer) worry mostly about the content rather than the format. But learning how to fiddle with the code is rather time-consuming, so if you're not a hardcore programmer (and I still don't really consider myself one of the hardcore types) there is quite a learning curve. Worth it, but steep.

This is where a visual editor like LyX comes in. LyX is, pretty much out of the box, a simple way of interacting with your LaTeX code. It hides most of the code and offers formatting options, similar to MS Word or other word processors. Unlike them, however, you choose the general formatting parameters and let the backend handle the layout. You can also fiddle directly with the code if you need to, or add code to the front of the document for particular use cases, like a PhD cover page, interlinearized glossed text (IGT) examples, and more. Basically anything you need to add has probably been coded or figured out by someone, and if you're a troubleshooter like me you can run a Google search and find forums (and contribute to some yourself) that deal with your particular problem or at least something similar. And the assistance you get can be pretty phenomenal.

LyX does take a bit of configuration, and I might write another post that explains how I set it up for my use case(s). But for now, I’ll just say that using LaTeX/LyX was one of the best decisions I made as a PhD student. It really simplified my writing process and allowed me to do so much more. Rather than spending the final month on formatting my thesis, I was writing and making final changes all the way up to the deadline. I probably wrote more, and re-organized the structure more, in the last month than I had in the previous three. And the text file that contains my 700+ pages of analysis, examples, and appendices is only ~6 MB. Possibly the greatest benefit was that LyX kept track of all my linked example sentences, and formatted them all properly. Once I got it set up this saved me days and weeks of man-hours. The learning curve was totally worth it.

In closing, if you are seriously considering using LaTeX/LyX, there’s lots of good articles about this online. Here’s one, and here’s a discussion on the topic, to get you started.

​My next post was intended to be about streamlining a workflow by using various LaTeX authoring tools and a bibliography manager, but last week my Mac died. It is an older computer admittedly (from 2011), but it just had the graphics/motherboard replaced a year and a half ago due to a recall and I had high hopes that it would last at least until the end of the year. Unfortunately that didn’t happen - while at a conference over the weekend it gave up the ghost, leaving me with just a USB drive that had my presentation, and the last-minute changes to a Praat script that I had managed to upload to GitHub the night before.

Fortunately I have been saving up towards a new computer, since I knew this would probably happen. It’s had a good run, but when I got back to Singapore, replacing the mother/logic board turned out not to be worth it - I’d be better off putting the money I would spend fixing it towards a new computer.

What I find remarkable, however, is that I literally lost nothing except some emails that are stored on the email server anyhow, and maybe some intermediate changes to the Praat script. This is partly because I saw that the computer was starting to fail and backed up all my files with Time Machine on an external hard drive, but partly also because my workflow lends itself to backing up.

As per my previous post regarding Git, it is important to have a workflow that encourages you to snapshot changes. This is what the Git “commit” command does - fail to integrate it into your Git workflow at your peril. Another way to do ensure that your files are backed up is to use online cloud storage like Google Drive and Dropbox. Most likely, if you’re an academic you probably use both these services, but maybe your backup system is a bit ad-hoc. In my case, the death of my computer has suggested to me that I need to use multiple cloud storage services.

So here’s what I am currently doing using a temporary user account on my wife’s computer:

1. Copy my backed up Git repository (of files/documents/etc..) from Time Machine to Google Drive (I had to change the settings so that Google Drive didn’t automatically try to create duplicate Google docs).
2. Create an upstream repository in Dropbox, and push all changes in the Google Drive repository to the Dropbox repo.
3. Make changes in the Google Drive repository, committing/pushing as I go.

The main reason this works for me is that I generally don’t operate with Dropbox and Google Drive on - I only start these services manually when I want to sync with the online server. In some of my online research, it seems that there MAY be issues with running a Git repo or editing files when cloud storage is syncing, so I get around this potential issue by simply doing my offline edits, and then syncing cloud storage manually.

So as part of my workflow:

• A) Edit files
• B) Commit changes
• C) Push to Dropbox
• D) Open Google Drive and Dropbox apps to sync changes with the cloud.

As I go, I am also discovering more files that need to be in a cloud server to avoid data loss. This is mitigated to some extent by regular Time Machine backups, but I’m beginning to wonder if I also need to invest in expanded cloud storage. The only other drawback of this process is that since I’m backing up in multiple cloud services, the storage takes up twice as much space on my hard drive as it otherwise would. I’m still thinking about how to deal with that issue…

   ​Along the lines of some of my previous posts on tools for linguistic analysis, I thought I'd post a quick update on a Praat script I've been working on. While not part of the series of posts I've been working on describing my tools and workflow, this particular script is a recent tool that I've developed for analyzing and exploring tonal patterns.
   As I noted in my post on Praat scripting, the Praat program gives linguists a relatively easy way to investigate the properties of speech sounds, and scripts help to automate relatively mundane tasks. But regarding tone, while Praat can easily identify and measure tone, there are no comprehensive scripts that help a linguist to instrumentally investigate tones in a systematic way. Let me first explain a bit.

What is 'Tone'?
   In this post, I use the word 'tone' to refer specifically to pitch that is used in a language at the word or morpheme level to indicate a difference in meaning from another word (or words) that are otherwise segmentally identical. In linguistics, this is a "suprasegmental" feature, which essentially means that it occurs in parallel with the phonetic segments of speech created by the movement of articulators (tongue, mouth, etc..) of the human vocal apparatus.
   Tone has a lot of similarity to pitch as used in music, which is why tones often seem to 'disappear' or be relatively unimportant in songs sung in languages that otherwise have tone (like Mandarin). Another important piece of information to remember is that there are quite a few different kinds of tone languages. The major tone types are 'register' and 'contour' tones - often languages will be categorized as having one or the other, but some have both types. African languages tend to have register tone: this means that pitch height (measured in frequency, often by Hz) is the primary acoustic correlate of tone in these languages. Asian languages tend to have contour tone: this means that across the tone-bearing-unit (TBU) the pitch may rise or fall. 
   There are also languages for which the primary acoustic correlate of tone (or some tones) is not pitch, but rather voice quality: glottalization (i.e. Burmese), jitter, shimmer, creakiness, or length. Languages for which pitch is not the overall primary acoustic correlate of tone are often called 'register' languages. Register languages are found throughout South-East Asia.

Measuring tones
   The pitch correlates of tones are relatively easy for Praat to identify, as its instrumentally observable correspondence is the fundamental frequency (F0) of a sound. Praat can extract the fundamental frequency as well as other frequencies (formants) that are important for various vowels. Tone researchers often use a script to extract F0, and then apply various normalization techniques to the extracted data, plotting the results in a word-processing program like Excel or by using a more robust statistical tool like R (see this paper or this post for more details, and James Stanford has done some good work on this subject - see his presentation on Socio-tonetics here).
   One issue with this approach, however, is that often pitch tracks for each tone are time-normalized along with every other tone. So for example, in image #1 below of Cantonese tones (from this paper), all pitches are plotted across the same duration. This is fine if pitch is the primary acoustic correlate of all tones, but what if duration/length is an important correlate as well? How does a researcher begin to discover whether that is the case?

Script for analyzing tone
   ​The problem I tried to solve was basically this: I was investigating a language (Biate) for which no research had been done on tone, and I needed a way to quickly visualize the tonal (F0) properties of a large number of items. I also wanted to easily re-adjust the visualization parameters so that I could output a permanent image. Since I couldn't find an existing tool that could do this, and since I wanted it all to be done in a single program (rather than switching between two/several) I created the Praat script that you can find here at my GitHub page under the folder 'Analyze Tone'. If you look closely, you'll notice that this scripts incorporates several parts (or large chunks) of other people's work, and I'm indebted to their pioneering spirit.
   There is a good bit of documentation at the page itself, so I'll leave you to get the script and explore, and will give only a brief explanation and example below. I have so far only tested this script on a Mac, so if you have a PC and would like to test it, please do so and send me feedback. Or, if you're a GitHub user, feel free to branch the repo and submit corrections.

   The basic function of the script is to automate F0 extraction, normalization, and visualization using Praat in combination with annotated TextGrid/audio file pairs. Segments that are labeled the same in TextGrids belonging to the same audio file are treated the same. You can start out by plotting all tracks, in which case all tones labeled the same will be drawn with the same color. Or you can create normalized pitch traces, in which case a single F0 track will be plotted for all tones with the same label. This script creates audio files on your hard drive as one of its steps, so make sure you have enough free space (the size of each file is usually less than 50Kb, but if you have hundreds, they can add up).
   In order to start, simply open an audio file in Praat and annotate it with the help of a TextGrid (if you don't know how, try following this video tutorial). Create a label tier that only contains tone category labels, and add labels to boundaries that surround each tone-bearing-unit. Then save the textgrid file in the same directory as the audio file, and run the script.

   ​The kind of output you can get with this script is shown below. The first picture shows all the tones plotted for a single speaker, and the normalized F0 tracks for each tone are shown in the second picture. Importantly, F0 tracks are only length-normalized for each tone. You will also notice that the second image zooms in closer so that the relative differences between tones can be seen more easily.

Recently, I started to explore using Git to maintain and organize my data. This includes both the primary data I work from as a linguist and the various kinds of data I produce in the form of written material (books, papers, etc..). As a field linguist, I primarily work with text that is transcribed from audio and video recordings. Early on I developed an archiving system to preserve the original files in their raw form as much as possible, but I didn't develop a similar system for maintaining my working files, and ended up with lots of duplicates of files that I had copied various places for various purposes.

In this fifth post on Linguistic tools (the overview of which is here), I plan to describe the way I am trying to overcome this issue and become more organized by adopting a version control system. Mostly, though, I'll just try to explain what Git is and what I use it for. This is by no means a complete tutorial, since other people have done that better, but hopefully it will provide some direction for others who are interested in streamlining and organizing their workflow.

When I started learning to program in Python and was introduced to Git, I saw the benefits for coding, but began to wonder if it was possible/useful to use it for other organizational tasks in relation to other kinds of writing and data structures.  There are a few blog posts about using git for paper writing here and here and here, but they are written primarily for coders who also write papers (I'm looking at you, academic comp-sci folks!) and don't translate super well for my use case.

What is Git?
  First, what is Git? Git is a version control system, which means it tracks changes in a repository (or 'repo'), basically serving as a series of backups for your work. It also has tools that allow you to make a copy (or 'branch'), work on it separately, and then when you're ready, you can see the changes made to individual files and 'merge' them together into a new version. For a simple tutorial, see here, and here is a great visual walkthrough.

Most explanations of Git use the example of a tree or a river, which do help to understand the process, but for total newbies (and possibly to address the difficulty of finding a good metaphor) I came up with the following metaphor, and find it to be a bit more useful.

The Git Metaphor
  Imagine you have a drawing project. You have an empty piece of paper - this is your initial blank Git repository. Now you draw a picture on the piece of paper and decide it's an ok version - this is a snapshot that is your first 'commit'. You then decide you want to make some adjustments to the drawing, but you want to preserve the initial drawing, so you take out another piece of paper, lay it on top of the first, trace out the shape in pencil, and then begin to modify the edges of the drawing or the background by erasing or adding new bits. When you're happy with that you 'commit' it, and then every time you modify it, you repeat the process of first tracing it out on a piece of paper. Each of these pieces of paper stack, so if you want to go back to an earlier drawing, you can, without losing any of the other drawings.

  Now let's say your friend wants to work on the same drawing project. You can give him your latest drawing, he can copy it and work on it in the same way. Then when he's done he can give it back to you and you can choose which bits of his version you want to incorporate into your current version. This is super useful for projects with lots of collaborators, especially if you're writing code, which are basically text files and relatively easy to merge based on differences in lines.

[Note that this isn't exactly what the Git system does - it doesn't actually create a NEW version of the repository, like the tracing paper, but instead uses the most recently committed version as the new base/foundation for future modifications.]

The most important thing I've had to keep in mind is to write myself detailed commit messages, and to figure out a good protocol or format for these messages. This is because once you've committed something, you can go back and search through your commits (save states), but this is only easy IF YOU KNOW WHAT THE COMMIT CONTAINS!!! Using the full filename of the committed file, for example, is much better than writing out 'New version of Paper'. Giving more information, such as about what you changed in the file, is even better.

My Use Case
My use case, however (as opposed to collaborating on code with a large team), is for a single repository of data in which I will occasionally share a single paper with collaborators. What I want is a bit more like a backup system (think Apple's Time Machine or the versioning system in Mac OS) but with a lot more control. Git, for example, works on the command line and requires you to provide messages for each commit you make, which also requires you, the user, to be clear about what changes are and why they were made. This (ideally) means less clutter and assists with organization.

In thinking about my needs and doing research, I discovered a drawback of version control systems like Git. If I have a single repository but am working on multiple papers at once (like I often do), guess what happens when I save changes on document A and then checkout a previous version of paper B? Yup, everything reverts to the state it was before, and I 'lose' all the changes I just made to A. I put 'lose' in quotes here because I don't actually lose anything, as long as I had committed it properly, but I'd then have to checkout the commit, copy the file, and then revert... anyway it's annoying.

What I need
So what I REALLY need is a single Git repository with the ability to track individual folders/files separately with their own version histories (like embedding repositories). Git can do this in several ways, none of which are particularly intuitive: submodules, subtrees, subrepo, and simple embedding. The first two are designed for somewhat different use cases than mine, namely using (part of) someone else's code in your own project. They're not really meant to create sub-repositories in your local repo to track separate histories. The third, subrepo, looks quite promising but requires that you run everything from the root of your main repo, and since I have lots of organizational subfolders, typing the names every time just gets tedious. So, I use the strategy of simple embedding.

Simple Embedding
By simple embedding, I refer to navigating to a subfolder within my main repo that I want to track and running the command 'git init'. This does two things:

1. it allows me to track changes within this folder separately from the main git repo. 
2. it makes the changes in this folder somewhat opaque to the main repo.

This means that changes in the subfolder will propagate only at the intervals where I commit ALL to the main repo. Changes committed in the subfolder, however, will retain the history of the subfolder, before the most recent commit of the main repo. Metaphorically, making a separate repo of the subfolder allows me to return to the basement of a particular room in the structure and rummage around down there while retaining the fully built house around me.

This is probably a hack, and not the way Git was intended to be used, but it works for me. The only problem I foresee happening is making too many Git repositories, and not being able to keep track of the multiplicity. So I plan to use this sparingly. For the most part, I'm ok with committing changes across the whole repository, since one of the real benefits of using a VCS is the freedom to throw things away.

Some other great posts on version control systems include this one on the benefits of version control, this one on several different version control systems for writers, this post on the limitations of Github for writers - the last of a 6-part series worth reading if you are debating whether to start on the Git/version control journey. And finally, this one is about one person's suggestions for academic writing and Git.

In any case, Git or another VCS is definitely worth checking out. I also recently discovered that Git repos are supported 'out of the box' by LyX, my go-to LaTeX editor! More on that to come... I also recently discovered SRC (Simple Revision Control), which focuses on tracking revisions on single files. This might actually be what I need. I'm still exploring this, and it might not be necessary since my LaTeX editor supports Git. We'll see.

This is the fourth installment in a series of blog posts where I discuss some of the tools I use for linguistic analysis. In a previous post I described the tools I use for processing and converting video and audio. This is partly important for using the audio with Praat for acoustic analysis, but also because ultimately I want to transcribe the recordings and analyze the grammatical structure (using the transcriptions) while remaining linked to the recordings. Ideally, such a link would allow me to play back the recording from within the program that I use to analyze the grammatical structure of the language, so I'm not constantly having to open the sound files and scrub to the correct part of the WAV.

Fortunately, this IS possibile, and it currently involves using two larger programs, Transcriber and Toolbox, along with a small tool/script that I wrote for conversion (you can read more details about the script HERE). The original workflow, which my supervisor Alec Coupe taught me, depended on another script developed by Andrew Margetts, which was very useful but required internet access - possibly problematic if one was on fieldwork. Then a few years ago the site went down and conversion became a multi-step process involving emails. So I wrote my own script. But I'm getting ahead of myself.

The workflow:
The first step in this process is getting your audio file transcribed. It is possible to do this in Transcriber (thus the name), and the newly repackaged version for Mac works pretty well (as does 1.5.1 on Windows or in a Windows VirtualBox). You can also use another program to play back the audio (i.e. Audacity, which can slow down the audio for you and let you boost the signal, etc) while transcribing in a text editor. Then you copy/paste the text to Transcriber for time-alignment.

I use Transcriber for time-alignment because it's simple, it allows for extremely short time-stamped windows, and it produces text files (basically) as output. There are other tools such as SayMore (Windows only) that also allow you to transcribe and directly output files for use with Toolbox, but in using it I found that SayMore was a bit of a memory hog and wouldn't let me create time-stamped sections shorter than half a second, which could be problematic for short interjections. And it kept freezing, so that it took a really long time to transcribe a short example.

So with Transcriber I simply open the audio file that I want to time-align, copy the block of text that I've transcribed, and then listen to the audio file, follow along in the text, and insert timestamps ('enter' or 'return' key) at the correct points. Once this is done for the whole file (time-consuming, but not as time-consuming as the transcription) I save the file (a '.trs' format).

Once you have the 'TRS' file, you get to use this converter, which you download to your computer. The converter runs as either a Python script or a Windows executable file that you run in the folder that has your 'TRS' file. When you run it for the first time it asks you for the field names in your Toolbox settings, and creates a configuration file in the folder to store the settings. If it doesn't find the settings file the next time, it will ask again. When it has the settings, it outputs a 'TXT' file for each 'TRS' file in the folder.

Once you've got the 'TXT' file, you can open it up to view it. If you already work with Toolbox, you can see that it is already (mostly) in the correct format. If you don't work with Toolbox, try installing it and go through the tutorials with a new project. Then open the Toolbox-created text file and compare it to the one created by my script from the Transcriber file. You should be able to copy/paste the content of the newly-created text file into your Toolbox project text file with no issues. Now when you open your Toolbox project file in Toolbox, you should be able to see the timestamps and play the sound file (and portions of it) from within Toolbox, provided you put the audio file in the correct location.

Why Toolbox?
This may seem a bit cumbersome, begging the question "Why use Toolbox at all?"

• "Because Toolbox files are text files"
  This is the short answer. Text files are easy to store (archivable) and extract information from. They are easy to work with in Python when I want to search through the corpus or convert them into LaTeX for display as interlinearized glossed text (IGT) for other linguists.
• Toolbox is fast
  This program is quite small and not resource-heavy, making it extremely useful for small laptops. I have also used the more resource-heavy Fieldworks Language Explorer (FLEx), but there are some drawbacks.
• It doesn't make assumptions
  Toolbox treats clitics, affixes, and all other sorts of word types and word formations according to how the user defines them, rather than according to a pre-selected set of (theoretical) assumptions. Other programs such as FLEx seem to make unwarranted assumptions about a language and therefore actually get in the way of exploring how the language works. FLEx is great for wordlists and shared projects, but I find that Toolbox preserves the underlying format better and allows me more manual control. If I decide to change the way I represent things in Toolbox, I do have to manually go back and interlinearize things again, but that is arguably beneficial, as it forces me to get to know the language data better.

A final note (ELAN)
As I end this post, I should note that many linguists use ELAN for transcription and annotation of video/audio. In fact, that the suggestions made by the 'trs2txt' script are for start and end codes labeled ELANBegin and ELANEnd, respectively, and the code for participants is labeled ELANParticipant, which should facilitate importing into ELAN. Unfortunately, I haven't found ELAN to otherwise be particularly useful for my purposes, primarily because it doesn't have the dictionary linking functions that Toolbox has, at least the last time I looked at it. It does have a Toolbox import function, so I have seen people import a Toolbox file, re-link their video, and output an html web page with embedded video for display on a website (thus the code labels in the script). Maybe you could also transcribe in ELAN, export to Toolbox, do your analysis, and import back to ELAN. For now, though, I think I'll stick with the Transcriber-Toolbox workflow.

In this third post about linguistic tools, I'll be discussing software that I use for acoustic analysis. Praat is one of the premier acoustic analysis tools available for computers. While there are probably commercial software products out there that are more powerful and with more bells and whistles, Praat offers some of the best ways to visualize and manipulate sound while being free and cross-platform. While it's not completely intuitive, it is quite easy to explore the sound space of a recording, especially recorded speech, and I ran a workshop on the basics of how to use it, with online materials that you can practice with if you want to learn more. There are also other great tutorials online that you should search for.

One of the best features of Praat is the ability to segment sounds using TextGrids, which are basically text files that identify sections of a sound file using timestamps. The benefit of this is that once you have properly annotated a sound file you can use scripts to automate analyses, which saves a lot of time that would otherwise be spent taking individual measurements. When I first started my PhD I spent a good amount of time learning to write Praat scripts, which turned out to be a continuation of the programming I learned when I was younger (Basic, QBasic) and a worthy introduction to programming languages like Python.

Since this has turned out to be a post that discusses Praat scripting, I'm going to introduce/attach some of the scripts I wrote/use for acoustic analysis, and link to some of the many other places you can find scripts for your particular use case. In my case these scripts are mainly in service of documentation and description of endangered and unwritten languages, but maybe others will find them useful as well.

Automatically measuring sounds:

This script ("dur_f0_f1_f2_f3_intensity.praat") is one that I modified (originally from this script but more recently I based it on this script) to give automatic measurements of segmented sounds in a TextGrid. It is an updated version of the “msr&check…" file that I made available along with the workshop I linked to above. At the time, I had recorded several wordlists in Pnar, and I spent countless hours segmenting the sounds in each word. My thinking was that even if my segmentation wasn't precise, the sheer number of sounds and their tabulation would allow me to run valid quantitative analyses. As it worked out, this was mostly the case, and I was able to target the outliers for closer examination. I also got better at recognizing Pnar sounds from all the time I spent with the words. I have now updated this script to work nicely with the following script, which plots vowels for you in the Praat picture window, which can produce print-publication-friendly images.

Vowel plot for formants:

Another that I wrote/modified from other bits takes a comma-delimited CSV spreadsheet with formant values and plots them (in the standard vowel chart format) as a Praat drawing with an oval marking their standard deviation (“draw_formants_plot_std_dev.praat”). I wrote this primarily to produce a clearer image than the one produced by JPlotFormants for my PhD thesis. Thanks also to the Praat User Group for their help with getting the script right.
  I recently modified this script to work nicely with the automatic measurement script above. What this means is that you can segment all your words using TextGrids, run the script above to produce a CSV, and then just run this script to plot characters from that CSV. I implemented a 'Sequential' option for the plot so you can plot one vowel at a time, which means that you can leave all the segmented consonants (and VOT annotations) in the CSV file for later analysis. Or you can remove them, up to you. Just keep in mind that if you do have consonants in the CSV, it WILL try to plot them on the chart unless you choose the Sequential option.

Tone Analysis:

The third script linked here (“tone_analysis.praat”) I recently wrote in order to take continuous measurements of tones without normalization. This is more for exploration of tonal systems on a per-speaker basis, allowing the investigator to identify whether length is potentially a factor in the characteristics of a particular tone. I am planning to modify it to allow for percentage-based analysis (and thus normalization) of tones, which could be used by the investigator to create clearer plots once they identify the characteristics of the individual tones. But I haven’t gotten around to it yet. I'll write another blog post when I do.

As a final note, these scripts are really just the tip of the iceberg when it comes to the kind of analysis you can do in Praat. For more on Praat scripting, check out this great tutorial, Will Styler's excellent blog, the scripts he uses/maintains, these resources at UW and these from UCLA. You can also follow along with Bartlomiej Plichta as he leads you through some scripting lessons in his videos, which are very useful.

​When you discuss doing language documentation and description, one of the first things to know is that you have to collect language data. The primary source of language data is people who speak the language you're interested in, which then begs the question of how you record the data. There are some great books and papers on doing linguistic fieldwork of a documentary nature (more than what I've linked to here), but this post is focused more on the tools you use to process your data once it is recorded, as a continuation of my 'Linguistic Tools' post. I'll also plan to write a longer post on recording audio/video in the field, but for now I'll assume that you've recorded it already. I'll just briefly say that I like using a digital SLR like the Canon Rebel along with a unidirectional mic, in conjunction with a digital audio recorder like the Zoom H4N (ideally with a lapel mic of some kind).

Once you have your data recorded, the next step is to copy it to your computer for processing. Often the digital recordings will be rather large and cumbersome, and you may want to split them into smaller files, depending on how many stories/interactions you recorded. I find post-processing is important because it means you can focus on the interaction during the recording and then during processing you make notes of all the files, their content, and other metadata that will help later when you're not in the field and can't remember all the details.

In this processing stage you also want to do two very important things:

1. backup/archive your files with metadata
2. copy the files to a separate working directory for processing

The first step is extremely important for preserving the raw files that you recorded. I would also recommend backing up on an external drive or two in case your laptop crashes. In my case I have redundant backups, but you might also want to store them securely in 'the cloud' online. The second step listed above is important for ensuring that you don't overwrite your archived data. You should always work on a copy of your data, not on the data itself. Once you've created new versions (split/joined clips, audio stripping, etc..) you might then want to backup these versions with metadata.

I use two programs for converting video: Media Converter and MPEG Streamclip. You could use just MPEG Streamclip (which has a Windows version), but on a Mac I find that Media Converter is much simpler/easier for reducing the size of the file, stripping out the audio, or other purposes. MPEG Streamclip is great, though, for combining multiple clips or splitting one clip into several. In each conversion you want to ensure that the video/audio quality is not compromised, depending on what you want to use it for. In my case I am mostly doing acoustic analysis, so I'm more interested in preserving the audio at CD quality (16 bit, 44.1 khz) which is the standard for acoustic analysis and archiving. In any case, since I've backed up the raw files, I can always copy from them if I mess up my working files and need to restore the quality.

To process/convert and work with audio I use Audacity - this is primarily for processing audio, not for acoustic analysis. Audacity supports a large range of encodings and formats, and you can select portions of the sound file to do basic processing like boosting the signal, removing noise, etc. These are generally not the best things to do to an audio signal, but they can be useful. In my case, this is particularly for when I'm playing the audio back and need to hear what someone said in the background during a conversation, or do other kinds of manipulations.

I can't stress enough the importance of backing up data and copying your data files to a new (staging) folder. This really ensures that you can always rewind the clock and reset, while being confident in exploring the data itself in your working folder. This should become an important part of your workflow so that it is second nature. In some cases we will make mistakes, but understanding the importance of backing up and creating metadata for your backups will help to mitigate perhaps catastrophic events. Happy converting!

When I started my PhD program in Linguistics (language documentation and description), I had some experience with linguistic analysis, but not to the degree that I had to learn in order to complete my PhD. I had tuned my ear to be able to hear the sounds of the IPA, and had practice transcribing and learning a range of languages, but I had never analyzed an unwritten language completely by myself. During the course of my PhD I learned much more about how to analyze languages 'from the ground up', so to speak.

Along the way, I discovered that there were some excellent tools that made me much more effective and efficient at the task of documenting and describing an unwritten language. I was fortunate that I already had a good foundation in recording and processing audio from my experiences recording, mixing, and releasing my music, so the fact that the audio data I recorded would form the basis of my analysis didn't phase me. However, there were another whole set of tools that would allow me to investigate the details of the language I planned to work on.

Each of these programs is open source or free, though some are developed for Windows and others are developed for MacOS, which might be a problem for some people. Since I grew up with DOS and Windows but then later switched to a Mac, I'm comfortable with both systems. The Apple/Mac laptop build quality was my first choice for travel and portability combined with power. I say 'was' since some of Apple's recent design choices mean I might be switching back to Windows on my next laptop. But for now I run an old Windows version on my Mac via Virtualbox or bundle Windows software in a Wine port so I can run it as a native app in MacOS.

I'll plan to describe each of these tools in more detail in future posts, but for now here's

A list of the tools I currently use for my linguistic work:

• Media Converter and MPEG Streamclip: for converting video [READ MORE]
• Audacity: for importing/processing sound files
• Praat: for analysis of speech sounds (phonetics/phonology)
• Transcriber: for time-alignment of text/sound
• Toolbox: for analysis of grammatical/lexical structure
• Git: for versioning control
• LaTeX and LyX: for writing
• BibDesk: for managing references (or Zotero)
• Python: for text manipulation/investigation

Tools other linguists use, but that I don't use much:

• Elan: Many linguists use this for transcription of audio/video, but I have found it difficult to work with for grammatical analysis. I'd really like to learn more about it, but I haven't managed to attend a workshop yet, though if you live near Melbourne, Australia and are free on the 29th of March (2017), maybe you should check this one  out.
• FLEx (Fieldworks Language Explorer): I find this useful for dictionary searches and such, but the interlinearization options are not as flexible as Toolbox.

Just a quick blog post to mention that one of the tools I use in language documentation and description, Transcriber, is newly repackaged for use with OS X El Capitan! This is a big deal because previous versions (from 2013) failed to work, then the program was supposedly 'updated' (and didn't work), so I've been using the 2005 Windows version in a virtual box. But I just tested the new release (new as of 4 hours ago) and it works great on my Mac (just have to update the settings to default to UTF-8 for character encoding) and also with my trs2txt converter for Toolbox! Happy transcribing!

​Recently I've been thinking about what I wish I knew about PhD study before I began. When you start out to do a PhD, there are many things you have to learn that are not necessarily directly related to your proposed topic. This blog post isn’t intended to highlight all of them, since everyone who pursues a PhD has a slightly different situation: the location, institution, department, course of study, expected thesis format (and page length) are going to drastically affect the individual’s experience. There may be many other blog posts that target your particular context (some are linked below), but here are some practical considerations that I think apply to everyone.

1) Research your (potential) supervisor before starting a PhD.
  I was personally very fortunate to find a good supervisor. I didn’t do much research on my primary supervisor beforehand, but things really worked out. His teaching/mentoring style really matched my learning style, and I was able to get enough support from him that I learned a ton and became aware of how much more there was/is to learn. I was also fortunate to find a co-supervisor that I worked well with and learned a lot from, which meant I wasn't stuck when my primary supervisor was unavailable. I also received quite a bit of practical support and can say that both my supervisor and co-supervisor are still important friends and mentors. But I know of other people that received much less support, and in some cases it meant they were unable to finish their PhD. If you’re going to pursue a PhD, make sure that your potential supervisor isn’t someone who is likely to be a cause of difficulty along the way, either causing you to drop out of the program or give you a bad reference later. Of course some things cannot be predicted, and sometimes bad things happen, but do your best to research the person and their track record, or at least their character and interpersonal relationships with (former) students.

2) Learn/develop organizational skills.
  By the time I started my PhD I had learned organizational skills for keeping track of bills and projects as an independent musician. But in my first year of PhD study I had to learn how to keep drafts in folders, organize papers, and otherwise have a filing system that helped me find stuff. Even so, I occasionally find duplicate files in random folders on my hard drive. The digital organizational tools you use are only as good as the systems you have in place to help you manage your work. After my PhD I discovered that there was a much better way to organize my files, data, and workflow (more on that in another post), but I would have been even more productive if I had learned these things early on.

3) Get practical advice on finding a job after your PhD, and learn some skills/abilities outside of your main subject area.
  Fortunately I had mentors who had their own life experience and had done things in between academic jobs. In some cases they had worked odd jobs after their PhD while applying for everything and anything in their subject area. I learned that the basic post-PhD pattern is: complete PhD, apply for lots of jobs (postdocs, lectureships, professorships), get a few interviews, get a lot of rejections, keep applying, work odd jobs in the meantime, write/submit lots of papers (and receive lots of rejections), finally get a job. It’s a pretty rough deal, but if you’re willing to travel for jobs you have a decent chance. And secondary skills (like how to program or be a barista) can tide you over until you can get back to doing what you REALLY want.

4) Don’t sweat the small stuff.
  Doing a PhD is hard. Sometimes you’ll wonder if it’s worth it. For some people it’s probably not. But if you pursue it, realize that there are some things you should get really pissed off about, and there are some things that you’re better off letting go. Having people steal your work is worth getting pissed off about, but most other things aren't. For example:
 a) Let go of thinking that you’re better than the next guy. Accept instruction from your mentor(s) who really DO know better/more than you. Even the cleaner in your hall might have specialized knowledge that can help you out.
 b) Let go of thinking your thesis must be perfect. Your knowledge will never be perfect, and your thesis is only a snapshot of what you know at the beginning of your journey. Don't let this fact stop you from submitting it to your supervisor - let them be the final arbiters of whether it's acceptable or not.

These are just a few of the things I've learned in pursuing and completing a PhD. If you're interested in learning more, and you're actively thinking about graduate school, you might find this UK blog post helpful, or this Australian one. Some other practical advice, as this post notes, is to publish early and publish often, even during grad school. You should also consider searching more specific criteria related to your area of interest, but hopefully these four suggestions will get you started.