Setup your personal computer and install necessary software

You will need a terminal to work in, ssh (secure shell) for logging in to a remote machine, scp and/or rsync for copying files between your personal computer and a remote machine, Praat and/or Wavesurfer for inspecting audio

Apple OS X

• Terminal, ssh, scp, rsync – built-in, nothing to install
• Install Praat
• Install Wavesurfer
• Install a plain text editor such as Atom
• Optionally, if you want to use ssh keys, then
  • Install Homebrew
  • sudo brew install ssh-copy-id

Microsoft Windows

• Terminal and ssh client – install Putty
• scp client – install WinSCP
• Install a plain text editor such as Atom
• Install Praat
• Install Wavesurfer

Linux

• terminal, ssh, scp, rsync – built-in, nothing to install
• Install Praat
• Install Wavesurfer

Establish a connection to the University network

Do one of the following

• • Default choice: Connect to the University of Edinburgh VPN then open a terminal (Mac or linux) or Putty (Windows)
  • Alternative option: Open a terminal and ssh in to a DICE gateway machine (requires DICE account) such as student.ssh.inf.ed.ac.uk – this can be accessed without using the VPN, which may be faster when the VPN is in heavy use (experiment for yourself). You will be limited to workflows that either copy files to/from your personal computer, or work entirely on the lab computers.

Tip from a Windows user: “set up the VPN connection as a private network rather than public / allow filesharing by changing security settings”.

If using the VPN, note that all traffic from your computer to/from the internet now goes through the University network. That has several implications, such as

• it’s more secure than a direct connection, if on unsecured WiFi
• it will be slower than without the VPN
• avoid heavy traffic over the VPN (e.g., watching YouTube while working) because you may slow it down for everyone
• the University servers may log traffic, such as the names of any websites that you visit

Choose a lab machine and log in

Choose a server address from the ones here: https://resource.ppls.ed.ac.uk/whoson/atlab.php 

For this example, we’ll use ppls-atl-1079.ppls.ed.ac.uk, but you should choose a different one!

If you’re on Mac or Linux, you can quickly test if that machine is responding before attempting to log in (if not, it’s probably booted into Windows and cannot be used):

$ ping ppls-atl-1079.ppls.ed.ac.uk
64 bytes from ppls-atl-1079.ppls.ed.ac.uk (129.215.204.197): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from ppls-atl-1079.ppls.ed.ac.uk (129.215.204.197): icmp_seq=2 ttl=64 time=0.022 ms
[use ctrl-C to terminate ping]

Now attempt to log in. If using Putty on Windows, follow the instructions on how to start a session – it’s similar to the following, but using the Putty interface and not the command line.

$ ssh s1234567@ppls-atl-1079.ppls.ed.ac.uk

The authenticity of host 'ppls-atl-1079.ppls.ed.ac.uk (129.215.204.197)' can't be established.
ECDSA key fingerprint is SHA256:o5lK7XZUoJfF2IVanCfPbfguAxg6vYIoaoH1FjyTpr8.
Are you sure you want to continue connecting (yes/no)?

type “yes” and hit Enter

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'ppls-atl-1079.ppls.ed.ac.uk,129.215.204.197' (ECDSA) to the list of known hosts.
s1234567@ppls-atl-1079.ppls.ed.ac.uk's password: 
Last login: Fri Oct 18 07:33:02 2019
/usr/bin/id: cannot find name for group ID 12345
$

Your username is your UUN (e.g., s1234567) and your password is the same as you use in the lab (your Active Directory password). You are now logged in to a lab machine, which you can confirm like this:

$ hostname
ppls-atl-1079.ppls.ed.ac.uk
$

If you can’t log in, try another random machine. If you wish, you can check and update computer status on this spreadsheet

Optionally you can see if anyone else is using the machine, and if so whether it is busy. The machines are quite powerful, so there is no problem with multiple students using the same machine.

$ users
s1234567 s1234568 s1234569
$ top
[exit 'top' by pressing 'q']

For all of these methods, your username is your UUN (e.g., s1234567) and your password is the same as you use in the lab (your Active Directory password).

Option A: mount the remote filesystem

To avoid copying files back and forth, you can access your lab home directory directly from your personal computer.

• Advantages: direct access to files using your operating system’s graphical interface, in a terminal, or an editor, all running on your personal computer
• Disadvantages: can be slow over the network, especially when browsing through folders containing many files or deeply-nested folders

Start by connecting to the VPN. Then follow the instructions for your operating system:

Apple OS X

Open the Finder, press ⌘K then enter smb://fs1.ppls.ed.ac.uk, then navigate to your home directory.

Microsoft Windows

Type \\fs1.ppls.ed.ac.uk in the Windows Explorer address bar, then navigate to your home directory. Your username may need to be in the form s1234567@ed.ac.uk rather than just s1234567. This method has been reported as working for some, not for others. If it doesn’t work for you, use Option B instead, and try Option A again later.

Linux

There are several methods, but since you are smart enough to own a Linux machine, you surely know how to find out! Use the SMB protocol with the server mentioned above, fs1.ppls.ed.ac.uk.

Option B: copy files to/from the remote filesystem

If the above method isn’t working for you, or is very slow, then you can instead copy files between the lab computers and your personal computer (e.g., audio saved from Festival that you wish to listen to).

• Advantages: once files are copied to your personal computer, access is instant and doesn’t use the network
• Disadvantages: less convenient than Option A

Start by connecting to the VPN. Then follow the instructions for your operating system:

Apple OS X / Linux

For example, you have created a directory called output in your ss directory, into which you have saved output from Festival. Instead of using scp to copy files, we’ll use rsync which is smart about only copying changed or new files. Do the following on your personal computer (not on the remote lab computer):

$ rsync -avul s1234567@scp1.ppls.ed.ac.uk:/home/s1234567/Documents/ss/output ~/somewhere/on/your/personal/computer

Another example, this time you want a complete copy of your Documents folder on your personal computer:

$ mkdir ~/somewhere/you/choose/Documents/
$ rsync -avul s1234567@scp1.ppls.ed.ac.uk:/home/s1234567/Documents/ ~/somewhere/you/choose/Documents/

The trailing “/” in rsync are meaningful when working with folders – don’t omit them. Imagine we now changed a file and wanted to send it back to the lab. It’s a bit risky synchronising your entire Documents back, so let’s just do part of it:

$ rsync -avul ~/somewhere/you/choose/Documents/ss/ s1234567@scp1.ppls.ed.ac.uk:/home/s1234567/Documents/ss/ 

It is possible to run rsync without having to enter your password every time, if you set up ssh keys, which also allow you to log in without a password too.

Importantly, ssh keys only work for lab computers (e.g., ppls-atl-0020.ppls.ed.ac.uk) and do not currently work for scp1.ppls.ed.ac.uk. So, once you know a lab machine is running linux (e.g., you are logged in to it!) you can also rsync to it

$ rsync -avul s1234567@ppls-atl-0020.ppls.ed.ac.uk:/home/s1234567/Documents/ss/output ~/somewhere/on/your/personal/computer

Microsoft Windows

On Windows, you will need to use an scp client, such as WinSCP. The server name is scp1.ppls.ed.ac.uk . Using keys (as described above) is also possible on Windows with Putty and WinSCP.

Normally, Festival will try to play audio. When you are logged in remotely, it cannot do this and may actually crash when it is denied access to the audio device. You need to adjust the way audio is handled like this:

festival> (Parameter.set 'Audio_Method 'Audio_Command)
festival> (Parameter.set 'Audio_Required_Rate 16000)
festival> (Parameter.set 'Audio_Required_Format 'riff)
festival> (Parameter.set 'Audio_Command "cp $FILE ~/Documents/output.wav")
festival> (set! myutt (SayText "Example Sentence"))                

after which you will find the file output.wav in your Documents folder. You can access this file from your personal computer in order to listen to it. (Mac tip: select the file in the Finder and use the space bar to play it; no need to open any application.)

You may prefer to save the file somewhere other than your Documents folder. It may be best to make a special folder just for this purpose, which contains as few files as possible. Browsing folders with many files and sub-folders using your operating systems’ graphical interface can be slow over the network.

Choose one of the following workflows:

Recommended workflow: Use the lab computers for all computation; Edit files over the network on your personal computer

All files remain only on the lab computers. You directly work with them over the network, including such things as opening them in an editor, making changes, and saving. With a good network connection to the lab, this is the simplest option and feels most similar to sitting in the lab.

You will need to mount the remote filesystem (“Option A: mount the remote filesystem”) for this to be possible.

Use a plain text editor (e.g., Atom) running on your local computer to edit files, and run all scripts and programs in a terminal logged in to a lab computer.

Alternative workflow: Use the lab computers for all computation; Edit copies of files on your personal computer

The previous method might not work if your connection is slow, drops, or hangs frequently. In this case, you’ll need to copy files to your personal computer for editing, then copy back to the lab computers before running programs on them.

Here’s an example of how you would work in this way

1. Use rsync to copy the necessary files or folders from the lab to your personal machine – I suggest doing that for an entire ss folder or even your entire Documents folder
2. edit the local copy of a file (i.e., the one on your personal computer)
3. rsync back to the lab computers
4. run the scripts or program in a terminal logged in to a lab computer

You only need to do step 1 once, then iterate steps 2+3+4 as you work.

Do not combine “Recommended workflow” and “Alternative workflow” – you risk editing the wrong version of a file and generally getting confused.

Advanced workflow: Use the lab computers only for voice building and Festival

If you prefer to perform tasks such as running Python code (e.g., your script selection algorithm, or to analyse diphone coverage, etc) and shell scripts on your own computer, you might need to install additional software. If you want to do this, but don’t know how, ask on the forums.

Old-school workflow: Work entirely on the lab computers; Listen to audio on your personal computer

It is possible to work almost entirely in a terminal, including editing files (e.g., using nano). Those of you who choose this option probably will already know how to do it. If you want more details and suggestions, please ask.

You will still need to either mount the remote filesystem or copy files, in order to listen to audio on your personal computer.

Virtual AT 4.02 PPLS computing lab

In the “Labs & Recording Studio” section in Learn, you will find a link to a Blackboard Collaborate session. This session is always open, so you can use it to interact with other students at any time. You all have the role “presenter” to allow screen sharing etc.

Tips for using the virtual computing lab

• Chrome and Firefox are the recommended browsers (but Safari on iOS)
• Upload a profile image and use your full name – it really helps others to see who is present
• If there are more than 4 people in the room, mute your microphone (to reduce background noise) and optionally turn off video (to reduce bandwidth)
• Use the ‘raise hand’ and chat features to get attention
• You can use a shared whiteboard and also share your screen, or a single application (e.g., your terminal)

Forums

There is a new forum for help with remote working.

Live help

It is unclear whether live sessions at fixed times would be helpful, but we will try them to find out. See the weekly schedule for the schedule.

With students across a wide range of timezones, access to live sessions may be tricky. Please use the forums to tell us what you find most helpful.

under construction…