1. R Programming for Music Informatics
Donald Byrd
rev. 25 Feb. 2008
Copyright © , Donald Byrd

2. Intrroducing R
R is very interactive: instead of programming, can use as powerful graphing calculator
=> easier to experiment with & learn, & useful that way
R was originally designed for statistics
Why R?
easy to do simple things with it
easy to do many fairly complex things, incl. graphs & handling audio files
probably not good for really complex programs
free, & available for all popular operating systems
very interactive => easy to experiment
has good documentation
In use in other Music Informatics classes, & standardizing is good
30 Jan. 08

3. Getting started with R To get R
Web site:
Has lots of documentation (tutorials, manuals, etc.), too… though most isn’t for beginners
Versions for Linux, Mac OS X, Windows
On all(?) STC computers
Tutorial:
Can use R interactively as a powerful graphing, musicing, etc. calculator
…but it’s not perfect: sometimes very cryptic
30 Jan. 08

4. Programming in General (1)
Details are often vital (& errors are costly)
A great many details really are. Commonly:
Quote marks, including single vs. double
Capitalization
“Wav” & “wav” are different
TIP: “steal” as much as possible!
Via Copy & Paste is ideal: avoids typos
Programs tend to be very hard to understand
TIP: include useful, readable comments
TIP: choose variable names for clarity
“wavdata” isn’t good; how about “samples”?
TIP: consistency helps clarity and correctness
Don’t mix “v = expr”, “v <- expr”, and “expr -> v”
Use the same variable name for something in every prog.
Program defensively
27 Nov. 07

5. Programming in General (2)
Comments
Classic example of a bad comment
x <- x+1 # add 1 to x
Doesn’t explain anything!
Good commenting style (thanks to Ed Wolf)
# Using the Add Sines Demo, create and play a wave at G3,
# then do the same for a wave at 5/4 this frequency. Finally,
# normalize the sum of the two waves and listen to result. …
# create and play first sound wave
sndW <- sine(f, duration=secs, samp.rate=sr, bit=16, xunit="time")
play(sndW )
rev. 3 Apr. 07

6. Programming in General (3)
Block comments (w/ overall description) more important than comments on single stmts
Ideal: say just the right things: Not too much or too little
Basic principle of all human communication
…including this slide show & music notations (CMN, tablature, etc.)
…and comments in a program
Other aspects of formatting & style
Variable names
Choose variable names for clarity
camelCase is helpful
Space around operators
“v <- f(expr)”, not “v<-f(expr)”
3 April 2007

7. Programming in R (1) R offers to save workspace when you quit
Are you sure it’s what you want?
TIP: Just say no.
Can restore original with ‘load(".Rdata")’ or menu command
TIP: Use a text editor & files to save work
If real text editor (not word processor) file, can run with R “source” command
Regardless, can Copy & Paste, even just part of file
setwd() to correct path for your computer
Depends on where you have files
Can be tricky, esp. in Windows
Typical Windows ex.: setwd("C:/Documents and Settings/donbyrd.ADS/Teaching/N560")
On Mac (& Windows?), can use “~/Teaching/N560"
…or drag & drop
…or use R GUI “Change Working Directory” menu command!
rev. 30 Jan. 08

8. Programming in R (2) R has many useful built-in functions
Many of them handle vectors (no loop needed)
diff(v): vector of consecutive differences
sum(v): sum of vector elements
Random numbers with various distributions: runif (uniform), rnorm (normal), etc.
read.table, table (and related functions)
fft
tuneR adds sine, square, noise, bind, mono, etc.
R (and tuneR) have excellent on-line help
Type either ‘help(sine)’ (e.g.) or ‘?sine’
…but NB: sometimes need ‘help("sine")’
TIP: Copy & Paste from help window!
Caveat: terminology is statistics oriented
rev. 14 Jan. 08

9. Programming in R (3) Besides built-in, functions can be user-written
Hard for many beginners; why?
Probably mostly confusion about variables (including parameters & return values)
A simple but realistic example
# Convert MIDI note number to frequency in Hertz. MIDINum2Freq <- function(noteNum) {
freq <- 440*2^((noteNum-69)/12)
return(freq) }
Calling it
fr <- MIDINum2Freq(57) # Sets fr = 220
Inside function, parameter noteNum = 57, freq = 220; fr doesn’t exist (it’s out of scope)
Outside function, noteNum & freq don’t exist
rev. 30 Jan. 08

10. Programming in R (4) Introducing loops
Loops also hard for many beginners
Main reason is probably confusion re control variable
A very simple (though pointless) example
mnnV <- 1:6 # make mnV a 6-place vector
mnnV # see what mnnV is before loop
for (n in 1:6) {
mnnV[n] <- n+59 }
mnnV # ...and after
Instead of “in 1:6”, can use any vector!
n (control variable) doesn’t exist outside the loop
C, Perl, etc. users can put the vector in the “for”
for (n in seq(1, 6)) { …
Loop is a type of control statement
rev. 30 Jan. 08

11. Software Engineering & Debugging (1)
Experience: all complex programs have bugs
Judge in Florida e-voting case: claim that voting machine software was buggy is speculation
True, but… !
Disclaimer: I don’t know any hard evidence
Expect bugs & program defensively
True stories
The program that failed only on Wednesdays! Why?
Hint: “Wednesday” has 9 characters
Weeks of debugging to find a “1” that should have been “i”
27 Nov. 07

12. Software Engineering & Debugging (2)
Good engineering (design, coding, comments, etc.) => less debugging & more robust (reliable & flexible) programs
Don’t underengineer
…but don’t overengineer, either!
Underengineering is much bigger danger for inexperienced programmers
Main factors
Complexity of problem
Is program or code it includes likely to be used for very long?
If so, how expert are future programmers likely to be?
27 Nov. 07

13. Software Engineering & Debugging (3)
Standard technique: zero in on problem code
Debug on short/simple cases, not long/complex ones
Makes it practical to look at results of several print statements
Reduces or eliminates long delays to see results
“short/simple” often means simply not much data
Can easily reduce days of debugging to hours
Usually easy to do by turning lots of data into a little data
Real situation: nThemes <- 3500, or 20 sec. audio file
For testing: use nThemes <- 4 (say), or 1 sec. audio
Caveat! the “little” data may not show the bug
…and if bug results from a design problem, fixing it may be very hard
27 Nov. 07

14. Debugging in R (1) Basic technique: zero in on bug with print or cat
E.g., before & after doing something questionable
print(c("max before scaling=",
wNotes <- wNotes*2.5
cat("max after scaling=", “\n”)
cat merges its arguments, gets rid of the extra parens
…but doesn’t end the line => do it yourself with “\n”
If you use “source” (& inside loops?), just naming variable doesn’t work; must use print or cat
A variation: use plot instead of print/cat
The right picture is worth 10,000 words; the wrong one, zero (cf. Tufte on the Challenger disaster)
…but the right picture for debugging is often simple & obvious
31 Jan. 08

15. Debugging in R (2) More advanced technique: use a good debugger
Allows setting breakpoints, looking at variables, etc., while program is running
Especially helpful w/ complex programs
…or learning a new language
To some extent, R’s interactivity accomplishes same thing
R has a debugger
One student (an experienced programmer) tried & liked it! Anyone else?
8 Sept. 07

16. Dangers of R (1)
More danger of nasty bugs in R than many programming languages & environments
No explicit types => can’t warn of questionable usage
No variable declarations => catches fewer typos (only a problem in old versions of R?)
Both above like Perl (e.g.), but Java (e.g.) is great on both => Java programmers likely to be careless!
Defensive programming
E.g., add “sanity checks” as you work, use conventions for variable names, etc.
Always important: a subtle bug can waste a huge amount of time and/or money
Weeks of debugging to find a “1” that should have been “i”
Period instead of comma => missile had to be destroyed
…but especially in dangerous environments like R
1 Feb. 08

17. Dangers of R (2) “Gotchas” in R (all from real life)
Surprising operator precedence, esp. in “for” statement
In sets, need parentheses to get addition before “:”
E.g., say “start:(start+5)”, not “start:start+5” !
“;” is usually ignored, but not always
Line break sometimes starts a new statement, but not always
cf. “LineBreaksInRStatements.r” example
Referring to a column of a table different ways gives same data but can behave very differently
“noteTbl$Cum.time” & “noteTbl[,1]” are vectors of integers; “noteTbl[1]” is a list
rev. 23 Feb. 08

18. Dangers of R & tuneR Other real-life examples from Don’s classes
Undeclared variable: “allNotes” vs. “allnotes” (only a problem in old versions of R?)
Call a function that returns a value but ignore the value
Danger much worse because R & tuneR often gives lousy feedback for errors or likely errors
tuneR square & sawtooth functions fail w/o error message if frequency isn’t an integer—and the manual doesn’t say it has to be an integer!
Exception: tuneR play w/ unnormalized values => very helpful error message
Nonexistent named params. sometimes give error, not always
rev. 24 Feb. 08

19. Programming in R with tuneR
On OS X (and LINUX): play() problem
Must say what program to use to play Waves
Either setWavPlayer once, or add 2nd param. to each play()
OS X can use QuickTime Player
It’s on every OS X machine, & it works, but…
Usually gives scary error messages; must hit the escape key to get R to continue; leaves open more & more QuickTime Players. A serious nusiance.
OS X alternative: playRWave
Works fine, but…
Not pre-installed; you must get & install it
Available (with instructions) at:
rev. 30 Jan. 08