Who is david huron

Among other interests, Prof. Huron is especially interested in how music evokes emotion in listeners. In addressing such questions, Huron's research employs a range of methods, including perceptual and cognitive experiments, computer-based corpus studies, simulation and modeling, interviews and surveys, and physiological and endocrine studies.

In addition, his research has drawn on traditional historical and analytic methods. Huron's research has been communicated in some publications, including three books. Huron has delivered over lectures in 25 countries, including 28 keynote conference addresses.

For more details on the other talk of Prof. Show navigation. But I was sobered by the magnitude of the practical programming problems. Most of the questions we have about the organization of music pertain to vertical sonorities and horizontal musical lines. If you want to make programming straightforward, you need to preserve both the vertical and the horizontal structure in the representation itself. DARMS represented musical scores as a linear string of characters.

You had a choice as to whether the encoding was line by line, or sonority by sonority. Unfortunately, there was no way to automatically translate from one form to the other. So simply extracting a single instrument from a vertical encoding, or identifying a chord in a horizontal encoding were major programming challenges. The failure of DARMS taught me that a better representation would preserve this two-dimensional format. That was the beginning of Humdrum. I also learned that it's useful to parse the representation problem into smaller pieces.

Don't try to represent guitar tablatures or square notation in a single all-embracing representation. Deal with them separately, but ensure that they're easy to coordinate. DH: When it came time to giving the toolkit a name, I didn't have any money to register or trade-mark a name. In order to avoid possible conflict with some later business product, I knew it was essential to choose a name that had no commercial value. I chose "humdrum" because I thought no commercial enterprise would ever name a product "humdrum.

DS: I think the simplicity of the kern notation, and its readability, has contributed to its longevity. Many other toolkits such as music21 include kern parsers, as the data is fairly easy to encode and understand. It hasn't really suffered the same fate as DARMS, possibly because you were cognizant of making a format that was easily parsed from the outset.

DH: With a little experience, you can sight-read a four-part hymn from the kern code. DS: What were some of the early reasons for constructing the Humdrum toolkit? DH: I never set out to develop a software system for music analysis. Instead, I started out with some questions about voice leading.

I heard Al Bregman give a talk on auditory scene analysis at a conference in and was really inspired. It was one of those seminal "ah-ha" moments.

I recall immediately after his talk leaving the session. I spent an hour or two in a quiet lounge simply thinking about the repercussions and essentially outlining a series of studies that would ultimately take me the next decade to do. I wanted to test the extent to which traditional part-writing conformed to principles in auditory scene analysis. I wanted to look in detail at more than just a few musical works, so I was convinced that using a computer was the way to go. It's interesting that this question that sparked a lot of your earlier work is still present in your work.

DH: Actually, some of these were questions I was thinking about when I worked as an oven tender as a teenager. Some things don't change. DS: Am I right in thinking that you started work on Humdrum as a graduate student? I think it was the summer of when I started working in earnest on what became Humdrum. In retrospect, I benefitted from four pieces of luck. Two of the pieces had happened years earlier. The first, as I mentioned, was attending the DARMS workshop at Binghamton where I learned the importance of avoiding representing music with a one-dimensional linear string of characters.

The second was my experience with the UNIX operating system. Somehow, I ended up with the UNIX crowd and that exposed me to the "software tools" approach to applications software. The first rule of thumb in programming is "don't write software to carry out functions for which software already exists. The trick is to create applications in which software tools can be linked seamlessly together. Two further pieces of luck were specific to the mid s.

The first was the advent of relatively inexpensive "clone" PC desktop computers. It was finally possible for ordinary mortals to purchase their own machines. Before that, personal computers were really the domain of electronic hobbyists. The second was learning a new programming language. A friend of mine was a computer programmer named Randall Howard. I'd composed and conducted the music for his wedding.

I knew that if I wanted to manipulate text representing musical scores, it would make sense to use a high-level text-processing language. At the time, the most powerful text-related language was SNOBOL, but that was a language that only ran on big mainframes. In the mid s, there were no text-processing languages available for the DOS operating system used by PCs. It was a godsend. AWK is easy to use and very well-suited for text processing.

AWK has a similar syntax to C but is a lot easier to use. DS: Humdrum would have looked completely different had your friend not written an early interpreter for AWK. That's just fortuitous. You then took that and worked on tools from Nottingham? DH: That's right. The tools that ultimately became the Humdrum Toolkit I wrote mostly over a three-year period from to Each tool began as a specialized program intended to address a particular musical question.

As I continued to work on different problems, I'd find that I could modify previous programs I'd written and make them more general. Over time, some programs were amalgamated and each tool became functionally more powerful. Also, I was able to generalize the representation so it wasn't limited to Western musical notation.

You could use the same tools to process lute tablatures, white mensural notation, Indonesian number notations, even physiological measures. For example, an orchestral score could code a listener's heart rate as though it was an additional instrumental part.

In Humdrum, the user can concoct their own representation so that it's tailored to their own specific musical interests. DS: This idea of using a series of different command-line tools that play nicely together is really central to the Humdrum toolkit. Do you think that there is some sort of Sapir-Whorf element to this?

Put another way, do you think your musical questions are ever influenced by this tool-based approach? DH: That's an interesting question. I would think that the representation has a much greater impact on the questions a user can pose than the processing tools. But I might think this because I have more experience using the tools than a typical user.

DS: Are there any tools that you're particularly proud of? When I teach a class on Humdrum, I think deg, mint , and hint , excite students the most, but when they learn about how to combine those with metpos and timebase they really begin to understand the flexibility of the tools. DH: I have a soft spot for the context tool, especially when you understand the power of using regular expressions to define the start or end of a context.

Also, I'm partial to the humsed stream editor. It's under-utilized, mostly because users have little experience with general stream editors like the UNIX sed command. I once recall reading that sed is Turing complete—and since humsed piggybacks on sed , it is far more powerful than one might suppose. DS: You encoded many of the datasets that are commonly used, including the Bach Chorales and the Barlow and Morgenstern dataset. Can you discuss why you chose to encode these datasets, how the process worked, etc.

DH: Let me say something about the process first, and then I'll say something about the repertoires I chose to encode. In the s a number of people were interested in the possibilities of processing musical databases. Only later did people really think of it as a representation for storing score data.

You have to realize that in the early days of computing, the optimism was way ahead of the reality. People thought we'd soon be talking to computers, that computers would do automatic language translation, we'd all have robots to do housework, and so on. Of course, computers can do a lot of that now, but it took almost half a century for the reality to catch up with the expectations.

In the case of musical databases, almost everyone I knew thought that optical music recognition was just around the corner. The idea was that you'd simply scan a score and the musical data would automatically be converted.

Of course, decent optical music recognition didn't really appear until the early s with products like SharpEye. But the idea that scanning would soon be possible discouraged people from bothering to encode any music at all. I didn't know anyone, apart from me, who was encoding musical scores in the mid s. Later I learned of others, like Helmut Schaffrath in Essen, but there was no community and no interchange. It was my experience as a programmer that made me skeptical that OMR [Optical Music Recognition] would soon make encoding databases easy.

I thought OMR was at least a decade away. In any event, I wanted to address research questions right away rather than waiting around for some future that may or may not come, so I started encoding music manually around or I was simply typing-in alphanumeric codes. DS: I think this is still the case, to some extent. OMR is better, but not perfect, and I've spoken with many people who just don't want to spend the time doing the manual encoding.

DH: I'm often struck by people's reluctance to do some manual labor. And that applies beyond a reluctance to do manual encoding of scores. You can answer that question by simply spending half an hour in a music library looking at a large number of scores. You'd be surprised how many students or scholars would never consider doing something like that.

DS: Returning to the question of the choice of repertoires …. DH: Yeah, with regard to the choice of repertoire to encode, remember that my motivation for using computers was my interest in voice leading. I thought a good place to start was with the music of J. So my first encoding project was the Bach two-part inventions. I then coded the three-part sinfonias, followed by all 48 fugues in the Well-tempered Clavier.

Of course, J. Bach is a single composer, so you can't really think of these repertoires as representative of even late Baroque part-writing. I encoded this material at a time before I'd read anything about statistics or inferential hypothesis testing. I had an intuition that I should expand beyond Bach if I wanted to be able to make more general statements about voice leading. But that's not how musicologists are trained. My graduate advisor wanted me to focus on a single composer. So I continued my encoding with a number of Bach organ works, and finally I tackled the chorale harmonizations.

Over the years I got quite proficient at manual encoding. For several years I encoded music every night for an hour or so. I used to listen to classical radio broadcasts on BBC Radio 3 while encoding music. After a couple of years, I was good enough that I could watch television and encode music at the same time.

When MIDI allowed me to hear the files I'd encoded I discovered that proof listening was remarkably effective in detecting errors. It's pretty obvious when a pitch is wrong. My biggest project was encoding the ten thousand themes from the Barlow and Morgenstern Dictionary of Musical Themes. That took about a month. DH: I'm glad you mentioned that. They began publishing an annual directory of projects related to computational musicology.

The directory was useful, since you could see what other folks around the world were up to. The Center was founded and supported by Walter Hewlett who's one of the unsung heroes in the world of musical databases. At some point, Walter hired Craig Sapp, and Craig has been instrumental in developing and promoting Humdrum. As you mentioned earlier, he's written a valuable suite of supplementary tools; but in addition he's been the catalyst for some big projects like the Josquin Project at Stanford and the massive encoding project at the Chopin Institute in Warsaw.

Craig's work with Humdrum Verovio has been outstanding. He's really done a fabulous job of making Humdrum more accessible, more powerful, and easier to use. Anyway, over several decades, CCARH which is now part of the Packard Humanities Institute has been encoding a growing catalogue of music, much of which has been released in the Humdrum format. He interviews the great jazz bassist Steve Swallow, who argues that the collation of the Real Book in effect canonized certain songs at the expense of many others, and it's been strange to see how those specific tunes came to reflect what jazz is, mainly as a result of being included in the book.

I think you're in a similar position. The corpora that you encoded became the datasets that everyone used and for those doing corpus studies, they were at one point taken to be representative of music as a whole. For example, much of the discussions surrounding tonality have centered around the Bach Chorales, which are actually pretty atypical, actually. How do you feel about this de facto canonization that has occurred?

DH: It's unfortunate but understandable. It's not good that a canon gets defined as what David Huron is interested in. The problem, of course, is that hardly anyone wants to encode music.

It's a task that seems more appropriate for monkeys at typewriters. And there's not a lot of recognition for doing the work. After you've done all the encoding work, everyone wants your data, and hardly anyone cites the source of who encoded it.

Over the years I tried to expand beyond Western classical music. First there was also the Humdrum translation of the Essen Folksong collection, then the Native American database which I started but you and Eva did the vast majority of the work. Now we have databases representing several hundred styles and cultures from around the world. Unfortunately, many of these materials are from copyrighted sources so we can't distribute them. With the exception of the Barlow and Morgenstern dictionary of themes, everything was encoded manually, simply typing on a keyboard.

Around or so, we started encoding using optical music recognition. That's especially effective for string quartets and orchestral scores. Piano music is still cumbersome when using OMR. DS: You mention copyright, and Stefan Bauer-Mengelberg, whom you mentioned earlier, actually wrote about this in , specifically asking "What copyright problems is a music scholar likely to encounter if, in making an analysis of a copyrighted work, he creates a machine-readable version of it and enters it into a computer?

Apollo, a Supreme Court verdict that found that the transformation of the musical idea into data for a player piano was not copyright infringement. This, however, seems to have been overruled by a more recent case in two decades after Bauer-Mengelberg's death. These decisions about encoding copyrighted works require an incredible amount of foresight. When encoding these databases, how do you deal with copyright issues? DH: I didn't know about the connection with Bauer-Mengelberg.

That's very interesting. We get criticism all the time for encoding old sources and not encoding the best available critical editions. Of course, we can only distribute materials that are in the public domain. This is a topic I wish musicologists would pay attention to. Right now, we have lots of well-intentioned musicologists beavering away on various critical editions unaware of the long-term copyright repercussions.

These are important labor-intensive projects that can take decades to complete. Now suppose that the youngest member of a critical edition team is 40 years old in And let's imagine that this person lives to the modest age of 80—that would be Under current copyright law, the resulting critical edition won't enter the public domain until 60 years later, which would make it That's a century from now.

Musicologists are just giving away the copyright to publishers, and in the process, they are hamstringing their current and future colleagues. In the old days, publishers were essential because everything needed to be printed. Does anyone doubt that the future is entirely digital?

In the near future, publishers won't be bringing anything at all to the table. All they'll do is collect royalties for the next century, and they'll effectively own a monopoly on the best editions of works by particular composers.

I think the situation is dire. Future scholars will be paying and paying and paying in order to access the hard work of current scholars. It just doesn't make sense. DS: You were doing "corpus studies" long before it was called that.

Could you discuss how the field has grown throughout your career, what are some aspects of its growth that you've found surprising, and in what directions do you see the field going? DH: Corpus studies go back a long way. There was the work of Bertrand Bronson way back in the s who tried to use an IBM card sorter to better understand British folk ballads. There was the Princeton Josquin project in the early s—which spent a lot of money and sadly failed to achieve much.

Then there were people like Stephen Smoliar who made a concerted effort over many years to create a computer implementation of Schenkerian analysis. Unfortunately, none of these projects led to any useful musical insights; they were primary efforts to explore the technical possibilities.

I suppose if I've made a mark it was that the Humdrum Toolkit was the first general-purpose music analytic software that was documented and distributed.

And I suppose I've published more studies that actually employ computational methods than other folks. If there's one thing I've found surprising, it's that I thought computational musicology would have become much more widespread. There are very few music scholars who do what you and I do. A complementary surprise is how much of music computation has been embraced by engineers and computer scientists. The best computational work in music is being done by engineers and computer scientists.

Of course, they have different goals than music scholars. First, they're typically interested in processing audio data rather than symbolic data like notation. Huron explains how and why Baroque voice leading continues to warrant its central pedagogical status. Expanding beyond choral-style writing, Huron shows how established perceptual principles can be used to compose, analyze, and critically understand any kind of acoustical texture from tune-and-accompaniment songs and symphonic orchestration to jazz combo arranging and abstract electroacoustic music.

Finally, he offers a psychological explanation for why certain kinds of musical textures are more likely to be experienced by listeners as pleasing. The psychological theory of expectation that David Huron proposes in Sweet Anticipation grew out of the author's experimental efforts to understand how music evokes emotions.

These efforts evolved into a general theory of expectation that will prove informative to readers interested in cognitive science and evolutionary psychology as well as those interested in music.

The book describes a set of psychological mechanisms and illustrates how these mechanisms work in the case of music. All examples of notated music can be heard on the Web. Huron proposes that emotions evoked by expectation involve five functionally distinct response systems: reaction responses which engage defensive reflexes ; tension responses where uncertainty leads to stress ; prediction responses which reward accurate prediction ; imagination responses which facilitate deferred gratification ; and appraisal responses which occur after conscious thought is engaged.

For real-world events, these five response systems typically produce a complex mixture of feelings. The book identifies some of the aesthetic possibilities afforded by expectation, and shows how common musical devices such as syncopation, cadence, meter, tonality, and climax exploit the psychological opportunities.