Thanks for putting this panel together, Shawna. And thanks, all of you, for your thoughts - I’ve learned a lot from our exchanges leading up to this panel.
I’m the Head of Graduate Programs in the Scholars’ Lab, a digital humanities center at the UVA Library. I want to come at the question of anxious pedagogies from the perspective of my role in the lab, where I often teach programming and DH skills and methods in addition to my primary duties, which are developing and administering the lab’s educational and professional development programs for graduate students. I work with students very self-consciously trying to step outside of their comfort zones, and I’d like to think about the anxieties associated with these cases in particular.
I want to ask what, exactly, it is that we’re teaching our students. If you’re a sighted reader of English, your skin has probably been crawling due to the grammatical error in my slide here. And that’s part of the point - this error is the subject of memes (but it’s one I constantly make in emails). You might be embarrassed for me and wish someone had pointed it out to me ahead of time. Let’s explore that.
There’s a Python error of a similar kind in this slide. In programming, such small mistakes are major issues that can cause a project to fail. They’re also common for beginning programmers and DHers. A student has an error like this, and, quite understandably, they ask for help from the teacher. The instructor, as a human being, quite understandably wants to help. I want to talk about that moment - the point at which a student needs help and the nature of the contribution that we as colleagues and mentors are prepared to give.
The ability to identify the kinds of problems I’m pointing out depends a lot on background and training. To expect such problems to be immediately identifiable makes a lot of assumptions about education, literacy, and background that no instructor should make. This is as true of the first example as in the second, which expects that someone has a background in programming and so knows that a computer would not be able to infer a relationship between the variables ‘fruit’ and ‘fruits’ - adding the extra ‘s’ in that last line by accident causes problems.
I have seen so many students stare, with mounting frustration, at chunks of code, feeling that they are beyond them, that issues in code represent some failing on their own part rather than a natural part of programming (we all make mistakes). Sure, my job is to teach them the skills with which they can solve these problems - the syntax that will prevent such errors in the future. But it’s also to help them recognize that no one is born knowing this stuff. Born knowing anything. And that such anxieties and frustrations are part of what all of us all deal with on a regular basis.
I am not suggesting that we should approach such student frustration as feelings to be worked past or to be toughed out. Instead I want to suggest that the most important, radical act that we can make as teachers is to center frustration and anxiety in our teaching. This feeling, that of knowing something is there but not seeing it, or of knowing something is wrong but not how to address it, are central to the very idea of what it means to learn and to teach. Sianne Ngai might call these “ugly feelings” - those feelings that lead to no cathartic action and that are associated, instead, with pause, frustration, and paralysis.
I’d suggest that our primary role as teachers is not to teach any particular content. Nor is our primary role to teach methods. Our ultimate aim should be to help students learn how to learn, how to keep going with the material outside the context of our courses. And, importantly, how to do this work with, through, and alongside such difficult emotions.
In DH we often valorize failure and what can be learned from it, but it can be difficult to know how to deal with the feelings associated with it. I’ve tried to develop exercises (drawing upon the work of Wayne Graham, Jeremy Boggs, Amanda Visconti, and Bethany Nowviskie) that help students sit with and think through the frustration and anxiety associated with failure. To teach web design, I ask students to draw a series of prototypes for websites using pencil and paper, some explicitly designed to fail, so as to develop a better sense of what it might mean for a website to succeed. Or I ask students to explore a set of programming exercises that have bugs artificially introduced to them as a way of helping them learn concrete steps for exploring problems in the face of mounting anxiety.
I’d love to hear from all of you if you have any thoughts for how to center, rather than expel, frustration and anxiety from teaching, learning, and the classroom. These issues are especially salient while teaching programming to humanists, as the interdisciplinary nature of it requires people step out of their comfort zone. But as others on this panel have articulated so well, these issues extend to the whole person. Beyond the content we teach and the act of learning it - our students are living in states of continual anxiety. To say nothing of the personal, social, or systemic traumas to which many of them have been subjected about which we may never know.
Most of what we do in the Scholars’ Lab is help students navigate these situations in a professional context. Most of what I do tends to revolve around convincing students that they are good enough. That they are qualified enough to teach a workshops on DH or to apply for any number of DH or alt-ac jobs. That a little goes a long way. That imposter syndrome is something felt by everyone. That their work has worth.
There are a number of things we can do as administrators to help mitigate the anxieties of our students. Advocate for them by actively campaigning for the bureaucratic status to serve on committees, teach courses, and offer them the support that they need. Petition our legislatures and administrations for more just labor relations. Figure out the small bureaucratic things that translate to big pains for our students - things like delayed payments, long turnarounds on applications, gatekeeping practices.
My point, our point, really, is that our students and colleagues are consistently in positions of anxiety and frustration - in and out of the classroom. So I’d ask what can we do to make our institutions, our classrooms, and our one-on-one interactions with our students more empathetic, but also more consciously aware of and engaged in the negative emotions they might bring out. Because as the title of this short talk suggests - frustration and anxiety are not pedagogical bugs. They are features. Woven into the very texture of what it means to be human and to be a learner. The question is - what are we prepared to do about it?
[The following is the rough text of my short paper given at the 2017 Digital Humanities conference in Montréal.]
Thanks very much for having me today! I’m Brandon Walsh, Head of Graduate Programs in the Scholars’ Lab at the University of Virginia Library. I’ll be talking a bit today about “Collaborative Writing to Build Digital Humanities Praxis.” Since the subject here is collaboration I wanted to spend a few minutes here on my collaborators.
This work was begun at my previous position at Washington and Lee University’s library. My principal collaborator here is and was Professor Sarah Horowitz, from Washington and Lee University. We conceived the project together, co-taught the associated course, and her writing figures prominently on the project I will describe. The other names here are individuals, institutions, or projects who figure explicitly in the talk, whether they know it or not. You can find a Zotero collection with the resources mentioned during the talk here.
So. To begin. Emergent programs like those associated with the Praxis Network have redefined the possibilities for digital humanities training by offering models for project-based pedagogy. These efforts provide innovative institutional frameworks for building up and sharing digital skills, but they primarily focus on graduate or undergraduate education. They tend to think in terms of students. The long-term commitments that programs like these require can make them difficult to adapt for the professional development of other librarians, staff, and faculty collaborators. While members of these groups might share deep interests in undertaking such programs themselves, their institutional commitments often prevent them from committing the time to such professional development, particularly if the outcomes are not immediately legible for their own structures of reporting. I argue that we can make such praxis programs viable for broader communities by expanding the range of their potential outcomes and forms. In particular, I want to explore the potential for collaborative writing projects to develop individual skillsets and, by extension, the capacity of digital humanities programs.
While the example here focuses on a coursebook written for an undergraduate audience, I believe the model and set of pedagogical issues can be extrapolated to other circumstances. By considering writing projects as potential opportunities for project-based development, I argue that we can produce professionally legible outcomes that both serve institutional priorities and prove useful beyond local contexts.
The particular case study for this talk is an open coursebook written for a course on digital text analysis (Walsh and Horowitz, 2016). In fall of 2015, Professor Sarah Horowitz, a colleague in the history department at Washington and Lee University, approached the University Library with an interest in digital text analysis and a desire to incorporate these methods in her upcoming class. She had a growing interest in the topic, and she wanted support to help her take these ideas and make them a reality in her research and teaching. As the Mellon Digital Humanities Fellow working in the University Library, I was asked to support Professor Horowitz’s requests because of my own background working with and teaching text analysis. Professor Horowitz and I conceived of writing the coursebook as a means by which the Library could meet her needs while also building the capacity of the University’s digital humanities resources. The idea was that, rather than offer her a handful of workshops, the two of us would co-author materials together that could then be used by Professor Horowitz later on. The writing of these materials would be the scene of the teaching and learning. Our model in this regard was as an initiative undertaken by the Digital Fellows at the CUNY Graduate Center, where their Graduate Fellows produce documentation and shared digital resources for the wider community. We aimed to expand upon their example, however, by making collaborative writing a centerpiece of our pedagogical experiment.
We included Professor Horowitz directly in the creation of the course materials, a process that required her to engage in a variety of technologies central to a certain kind of web publishing workflow: command line, Markdown, Git, and GitHub. We produced the materials on a platform called GitBook, which provides a handy interface for writing that invokes many elements of this tech stack in a non-obtrusive way. Their editor allows you to write in markdown and previews the resultant text for you, but it also responds to the standard slew of MS Word keyboard shortcuts that many writers are familiar with. In this way we were able to keep the focus on the writing even as we slowly expanded Professor Horowitz’s ability to work directly with these technologies. From a writing standpoint, the process also required synthesis of both text analysis techniques and disciplinary material relevant to a course in nineteenth-century history. I provided the former, Professor Horowitz would review and critique as she added the latter, then I would review, etc. The result, I think, is more than either of us could have produced on our own, and we each learned a lot about the other’s subject matter. The result of the collaboration is that, after co-writing the materials and teaching the course together, Professor Horowitz is prepared to offer the course herself in the future without the support of the library. We now also possess course materials that, through careful structuring and selection of platforms, could be reusable in other courses at our own institutions and beyond. In this case, we tried to take special care to make each lesson stand on its own and to compartmentalize each topic according to the various parts of each class workshop. One section would introduce a topic from a theoretical standpoint, the next would offer a case study using a particular tool, and the last would offer course exercises that were particular to our course. We hoped this structuring would make it easy for the work to be excerpted and built upon by others for their own unique needs.
Writing collaborations such as these can fit the professional needs of people in a variety of spaces in the university. Course preparation, for example, often takes place behind the scenes and away from the eyes of students and other scholars. You tend to only see the final result as it is performed with students in a workshop or participants in a class. With a little effort, this hidden teaching labor can be transformed into openly available resources capable of being remixed into other contexts. We are following here on the example of Shawn Graham (2016), who has illustrated through his own resources for a class on Crafting Digital History that course materials can be effectively leveraged to serve a wider good in ways that still parse in a professional context. In our case, the collaboration produced public-facing web writing in the form of an open educational resource. The history department regarded the project as a success for its potential to bring new courses, skills, and students into the major as a result of Professor Horowitz’s training. The University Library valued the collaboration for its production of open access materials, development of faculty skills, and exploration of workflows and platforms for faculty collaboration. We documented and managed the writing process in a GitHub repository.
This versioned workflow was key to our conception of the project, as we hoped to structure the project in such a way that others could copy down and spin up their own versions of the course materials for their own needs. We were careful to compartmentalize the lessons according to their focus on theory, application, or course exercises, and we provided documentation to walk readers through the technical process of adapting the book to reflect their own disciplinary content. We wrote reasonably detailed directions aimed at two different audiences - those with a tech background and those without. We wanted people to be able to pull down, tear apart, and reuse those pieces that were relevant for them. We hoped to create a mechanism by which readers and teachers could iterate using our materials to create their own versions.
Writing projects like this one provide spaces for shared learning experiences that position student and teacher as equals. By writing in public and asking students and faculty collaborators to discuss, produce, and revise open educational resources, we can break down distinctions between writer and audience, teacher and student, programmer and non-programmer. In this spirit, work by Robin DeRosa (2016) with the Open Anthology of Earlier American Literature and Cathy Davidson with HASTAC has shown that students can make productive contributions to digital humanities research at the same time that they learn themselves. These contributions offer a more intimate form of pedagogy – a more caring and inviting form of building that can draw newcomers into the field by way of non-hierarchical peer mentoring. It is no secret that academia contains “severe power imbalances” that adversely affect teaching and the lives of instructors, students, and peers (McGill, 2016). I see collaborative writing as helping to create shared spaces of exploration that work against such structures of power. They can help to generate what Bethany Nowviskie (2016) has recently advocated as a turn towards a “feminist ethics of care” to “illuminate the relationships of small components, one to another, within great systems.” By writing together, teams engage in what Nowviskie (2011) calls the “perpetual peer review” of collaborative work. Through conversations about ethical collaboration and shared credit early in the process, we can privilege the voice of the learner as a valued contributor to a wider community of practitioners even before they might know the technical details of the tools or skills under discussion.
Collaborative writing projects can thus serve as training in digital humanities praxis: they can help introduce the skills, tools, and theories associated with the field, and projects like ours do so in public. Productive failure in this space has long been a hallmark of work in the digital humanities, so much so that “Failure” was listed as a keyword in the new anthology Digital Pedagogy in the Humanities (Croxall and Warnick, 2016). Writing in public carries many of the same rewards – and risks. Many of those new to digital work, in particular, rightfully fear putting their work online before it is published. The clearest way in which we can invite people into the rewards of public digital work is by sharing the burdens and risks of such work. In her recent work on generous thinking, Kathleen Fitzpatrick (2016) has advocated for “thinking with rather than reflexively against both the people and the materials with which we work.” By framing digital humanities praxis first and foremost as an activity whose successes and failures are shared, we can lower the stakes for newcomers. Centering this approach to digital humanities pedagogy in the practice of writing productively displaces the very digital tools and methodologies that it is meant to teach. Even if the ultimate goal is to develop a firm grounding in a particular digital topic, focusing on the writing invites students and collaborators into a space where anyone can contribute. By privileging the writing rather than technical skills as the means of engagement and ultimate outcome, we can shape a more inviting and generous introduction to digital humanities praxis.
Croxall, B. and Warnick, Q. (2016). “Failure.” In Digital Pedagogy in the Humanities: Concepts, Models, and Experiments. Modern Languages Association.
DeRosa, R. (2016). “The Open Anthology of Earlier American Literature.” https://openamlit.pressbooks.com/.
Fitzpatrick, K. (2016). “Generous Thinking: The University and the Public Good.” Planned Obsolescence. http://www.plannedobsolescence.net/generous-thinking-the-university-and-the-public-good/.
Graham, S. (2016). “Crafting Digital History.” http://workbook.craftingdigitalhistory.ca/.
McGill, B. (2016). “Serial Bullies: An Academic Failing and the Need for Crowd-Sourced Truthtelling.” Dynamic Ecology. https://dynamicecology.wordpress.com/2016/10/18/serial-bullies-an-academic-failing-and-the-need-for-crowd-sourced-truthtelling/.
Nowviskie, B. (2011). “Where Credit Is Due.” http://nowviskie.org/2011/where-credit-is-due/.
———. 2016. “Capacity Through Care.” http://nowviskie.org/2016/capacity-through-care/.
Ramsay, S. (2010). “Learning to Program.” http://stephenramsay.us/2012/06/10/learning-to-program/.
———. 2014. “The Hermeneutics of Screwing Around; or What You Do with a Million Books.” In Pastplay: Teaching and Learning History with Technology, edited by Kevin Kee. University of Michigan Press. http://hdl.handle.net/2027/spo.12544152.0001.001.
The Praxis Network (2017). University of Virginia Library’s Scholars’ Lab. http://praxis-network.org/.
Walsh, Brandon, and Sarah Horowitz. 2016. “Introduction to Text Analysis: A Coursebook.” http://www.walshbr.com/textanalysiscoursebook
[Recently I spoke at NEMLA 2017 with Ken Sherwood and Chris Mustazza. The panel was on “Pedagogy and Poetry Audio: DH Approaches to Teaching Recorded Poetry/Archives,” and my own contribution extended some past experiments with using deformance as a mode of analysis for audio recordings. The talk was given from notes, but the following is a rough recreation of what took place.]
Robust public sound archives have made a wide variety of material accessible to students and researchers for the first time, and they provide helpful records of the history of poetic performance throughout the past century. But they can also appear overwhelming in their magnitude, particularly for students: where to begin listening? How to begin analyzing any recording, let alone multiple recordings in relation to each other? This talk argues that we can help students start to explore these archives if we think about them as more than just an account of past performances: sound collections can provide the materials for resonant experiments in audio composition. I want to think about new ways to explore these archives through automatic means, through the use of software that algorithmically explores the sound collection as an object of study by tampering with it, dismantling it, and reassembling it. In the process, we might just uncover new interpretive dimensions.
This talk thus models an approach to poetry recordings founded in the deformance theories of Jerome McGann and Lisa Samuels and the cut-up techniques of the Dadaists. I prototype a pair of class assignments that ask students to slice up audio recordings of a particular poet, reassemble them into their own compositions, and reflect on the process. These acts of playful destruction and reconstruction help students think about poems as constructed sound objects and about poets as sound artists. By diving deeply into the extant record for a particular poet, students might produce performative audio essays that enact a reading of that artist’s sonic patterns. By treating sound archives as the raw ingredients for poetic remixes, we can explore and remake sound objects while also gaining new critical insight into performance practices. In the process of remixing the sound archive, we can encourage students to engage more fully with it. And while I frame this in terms of student work and pedagogy given the topic of the panel, it should become clear that I think of this as a useful research practice in its own right.
I will frame the interventions and theoretical frameworks I am making before proposing two different models for how to approach such an assignment depending on the instructor’s own technical ability and pedagogical goals: one model that uses Audacity and another that uses Python to cut and reassemble poetry recordings. I will demonstrate example compositions from the latter. It will get weird.
There are two provocations at the center of my talk founded in an assumption about the way students hear poetry recordings. In my experience, they often hear recordings not as sound artifacts but as representations of text. They might come to these recordings looking to hear the poet herself speak, or they might be looking to get new perspectives on the poem. But they fundamentally are interested in hearing a new version of a printed text, in hearing these things as analogues to print. This is all well and good - the connection to a text is clearly a part of what makes poetry recordings special, but I think our challenge as teachers and thinkers of poetry is to help students surface the sounded quality of the artifacts, to learn to dig deeper into digital sound in particular.
My approach to this need - the need to get students to look beyond the text and towards the sound - is to get them working with these materials as heard objects. We are going to engage them in the medium. They are going to get their hands dirty. We are going to take sound - which might seem abstract and amorphous - and make it something they can touch, take apart, and reassemble. They are going to think about sound as something concrete and constructed by engaging in that very act of construction.
One approach to this might be to use a tool like Audacity. If you’re not familiar, Audacity is an open source tool that lets you input sound clips and then edit them in a pared down interface. If you have an MP3 on your computer, right click it to open it in Audacity, and you will get something like this:
A waveform. Already we are a bit alienated from the text because this visualization doesn not really allow you to access the text of the poem as such. Interacting with the poem becomes akin to touching a visual representation of sound waves. Now, you can’t do everything in Audacity, and that’s what I like about it. When I was a music student in college I remember getting introduced to some pretty beefy sound software - Pro Tools and Digital Performer. I also remember feeling pretty overwhelmed by what they had to offer. So many options! Hundreds and thousands of things to click on! What I like about Audacity is that it is a bit more stripped down. Instead of giving you all the potential options for working with sound, it does a smaller subset really well. Record, edit, mix, etc. Audacity is also open source, so it is free while the other ones are quite expensive.
I would suggest having your students engage with recordings using this software. Here is an example assignment you might put together that asks them to put together an audio essay. Using Audacity, I would have them assemble their own sound recording that mixes in examples from other poetry recordings under examination. You might frame the exercise by having them work through a tutorial on editing audio with audacity that I put together for The Programming Historian. The Programming Historian provides tutorials for a variety of digital humanities tools and methods, so this piece on Audacity is meant for absolute beginners. It coaches people through working with the interface, and, over the course of the lesson, readers produce a small podcast.
The lesson asks readers to use a stub Bach recording, but I would adapt it to have students assemble an essay that analyzes a poetic sound recording relevant to the course material. Instead of writing a paper on a recording, the students actually integrate their audible evidence into a new sound object, assembling the podcast by hand. Citation and description can join together in this model, and I can imagine having a student pay close attention to the audible qualities of the sounds they are discussing. The sky is the limit, but, personally, I like to imagine students analyzing TS Eliot’s voice by mimicking his style. Or you could imagine an analysis of his accent that tries to position his sense of locality, nation, and the globe by examining clips from a number of his recordings alongside clips of other speakers from around the world.
I see several benefits to having students work in this way. Students could learn a lot about Audacity producing these kinds of audio essays, and anyone planning to work with audio in the future should possess some experience with this fundamental tool. The wealth of resources for Audacity mean that it is well-suited for beginners. There are far more substantial tutorials for the software besides my own, so students would be well supported to take on this reasonably intuitive interface.
But there are also limitations here. For one, this type of engagement is a really slow process. Your students, after all, are engaging with a medium that they can only really experience in time. If you are working with four hours of recordings, you really have to have listened to all or most of that sound to work with it in a meaningful way. And to make anything useful, they will probably want to have listened to it multiple times and have made some notes. That is an extraordinary amount of time and energy, and we might be able to do better.
In addition, the assembling process is deliberate. You are asking students to put together clips bit by bit in accordance with a particular reading. And this is the real problem that I want to address - the medium here is unlikely to show you anything new. It is meant to illustrate a reading you already have. You want to produce an interpretation, so you illustrate it with sound. The theory comes first - the praxis second.
So I want to ask: what are some other ways we can work with audio that might show us truly new things? And how can we get around the need to listen slowly? The work by Tanya Clement and HiPSTAS offer compelling examples for distant listening and audio machine learning as answers to these questions. I want to offer an approach based on creativity and play. By embracing chance-based composition techniques at scale, we can start to develop more useful classroom assignments for audio.
In shifting the interpretative dimensions in this way, I am drawing on an idea that comes from Jerome McGann and Lisa Samuels: deformance. At the heart of their essay on “Deformance and Interpretation” is a quote from Emily Dickinson:
“Did you ever read one of her Poems backward, because the plunge from the front overturned you? I sometimes (often have, many times) have — a Something overtakes the Mind –”
McGann and Samuels take her very literally, and they proceed to model how reading a poem backwards, line by line, can offer generative readings. This process illustrated two main ideas. The first was that reading destructively and deformatively in this way exposes new parts of the poetry that you might not otherwise notice. You get a renewed sense of the constructedness of a poem, and the materiality of it rises to the surface. By reshaping, warping, or demolishing a poem, you actually learned something about its material components and, thus, the original poem itself. The second idea was that all acts of interpretation remade their objects of study in this way. By interpreting, the poem and our sense of it changed. So destructive reading performs this process in the fullest sense by enacting an interpretation that literally changes the shape or nature of the object. For a fuller history and more satisfying explanation of the interpretive dimensions of audio deformance for research, check out “Vocal Deformance and Performative Speech, or In Different Voices!” posted by Marit J. MacArthurt and Lee M. Miller over at Sounding Out. They also work with T.S. Eliot, though they they are working with recordings by him rather than those done by amateur readers.
In thinking about this performative form of reading, I was struck at how similar it sounded to cut-up poetry, the practice of slicing apart and rearranging the text of a poem so as to create new materials as popularized by the Dadaists and William S. Burroughs. To make the link to the Audacity assignments I was discussing earlier, I became interested in how this kind of performative, random, and destructive form of reading might extend the experiments in listening that I discussed with Audacity. Rather than having students purposefully rearrange a sound recording themselves, perhaps we could release our control over the audio artifact. We would still engage students in the texture of the medium, but we would ask them to let their analysis and their manifestation of that thinking grow a little closer together. We would invite play and the unknown into the process.
So we will ask them to engage in the material aspects of poetry by interacting with it as a physical, constructed thing. But the engagement will be different. We will have them engage. We will have them warp. We will have them cut up. Rather than using scissors, we will let a computer program do the slicing for us. The algorithm that goes into that program will offer our interpretive intervention, and we will surrender control over it just a bit, with the understanding that doing so will offer up new interpretive dimensions later on.
My approach to this was to use computer programs written in Python - a tool that allowed ways around some of the limitations that I already noted for working with Audacity. By working with a computer program I was able to produce something that could read hours of audio far quicker than I could. Python also allowed me to repurpose extant audio software packages to manipulate the audio according to my own algorithms/interpretations. In this case, I was working with Audiogrep and Pydub. I did not need to reinvent the wheel, as I could let these packages do the heavy lifting for me. In fact, a lot of what I did here was just manipulate the extant documentation and code examples for the tools in ways that felt intellectually satisfying. The programming became an interpretive intervention in its own right that, as I will show, brought with it all sorts of serendipitous problems. All the code I used is available as a gist – it took some tinkering to get running, and it will not run for you out of the box without some manipulation. So feel free to get in touch if you wanted to try these things yourself. I can offer lessons learned!
In working with these tools, it quickly became clear that I needed to spend time exploring their possibilities, playing with to see what I could do. In that spirit, I will do something a bit different for the remainder of this piece. Rather than give an assignment example up front, I will share some of the things you can do to audio with Python and why they might be meaningful from an interpretive standpoint. Then I will offer reflections at the end. My workflow was as follows:
I assembled a small corpus of sound artifacts – in this case, all the recordings of The Waste Land recorded by amateur readers on LibriVox.
I installed and configured the packages to get my Python scripts running.
Then I started playing, exploring all the options these Python packages had.
The first step of this process involves having the script read in all the recordings so that they can be transcribed. To do so, Audiogrep calls another piece of software called Pocketsphinx behind the scenes. The resulting transcriptions look like this:
if it is a litter box recording
<s> 4.570 4.590 0.999800
if 4.600 4.810 0.489886
it 4.820 4.870 0.127322
is 4.880 4.960 0.662690
a 4.970 5.000 0.372315
litter 5.010 5.340 0.939406
box 5.350 5.740 0.992825
recording(2) 5.750 6.360 0.551414
The results show us that audio transcription, obviously, is a vexed process, just as OCR is a troubled way of interacting with print text. What you see here is a segment from the transcription along with a series of words that the program thinks it heard. In this case, the actual audio “This is a librivox recording” becomes heard by the computer as “If it is a litter box recording” Although my cat might be proud, this shows pretty clearly that the process of working algorithmically is inaccurate. In this case, listening with Python exposes what Ryan Cordell or Matthew Kirschenbaum might describe as the traces that the digital methods leave on the artifacts as we work with them. Here is the longer excerpt of the Audiogrep transcription for this particular recording of The Wasteland:
i t. s. eliot
if it is a litter box recording
oliver box recordings are in the public domain
for more information or to volunteer
these visits litter box dot org
according my elizabeth client
i t. s. eliot
ariel of the dead
april is the cruelest month
reading lie lacks out of the dead land mixing memory and designer
staring down roots with spring rain
winter kept us warm
having earth and forgetful snow
feeding a little life with tribes two birds
Lots of problems here. We could say that to listen algorithmically is to do entwine signal with noise, and, personally, I think this is great! From an interpretive standpoint, this exposes artifacts from the remaking process and shows how each intervention in the text remakes it. In a deformance theory of interpretation, you cannot work with a text without changing it, and the same is true of audio. In this case, the object literally transforms. Also note that multiple recordings will be transcribed differently. Every attempt to read the text through Python produces a new text, right in line with the performative interpretations that McGann and Samuels describe. Regional accents would produce new and different texts depending on the program’s ability to map them onto recognized words.
But you can do much more than just transcribe things with Python. When this package transcribes words, it tags each of the words with a timestamp. So you can disassemble and reassemble the text at will, using these timestamps as hooks for guiding the program. Rather than painstakingly assembling readings by hand, you could search across the recording in the same way that you might a text file. Here is an example of what you can do with one of Audiogrep’s baked in functions - you can create supercuts of a single word or cluster of related words:
Sam Lavigne has other examples of similar audio mashups on his site describing what you can do with Audiogrep. In this case, I’ve searched across all the recordings for instances of “sound” and “voice” and mashed up all those instances. You can also use regular expressions to search, allowing for pretty complicated ways of navigating a recording. Keep in mind that this is only searching across the transcriptions, which we already noted were inaccurate. So it is proper to say that this method is not telling you something about the text so much as about the recordings themselves. The program is producing a performative reading of what it understands the texts behind the audio to be. The script allows you to compare multiple recordings in a particular way that would be pretty painstaking to do by hand, but the process is imperfect and prone to error. Still, I find this to be a useful tool for collating the intonations and cadences of different readers. I am particularly interested in how amateur readers perform and re-perform the text in their own unique ways. This method allows me to ask, for example, whether all readers sonically interpret a particular line in the same or different ways.
You can also have the program create your own, new sound artifacts drawing upon the elements of the originals. Since we have all the transcriptions, we can also create performative readings of our own. Rather than getting all instances of one word, we can put together a new text and have it spoken through the individual sound clips drawn from our input. Before playing the result, read through what I wrote.
Approaching sound in this way is a way for our students to reconstitute their own ideas through the very sound artifacts that they are studying. In so doing, they learn to consider them as sound, as material objects that can be turned over, re-examined, disrupted, and reassembled. But look at how much is gone. How much gets lost. The recording is notable for its absences, its gaps.
That should give you a hint about what kind of recording is about to come out. What follows is the program’s best attempt to recreate my passage using only words spoken by LibriVox readers as they perform Eliot’s text.
The recording itself performs the idea, which is that working in Python in this way produces a reading that is somewhat out of control of the user. You cannot really account ahead of time for what will be warped and misshaped, but some distortion is inevitable. By passing the program the passage, it will search through for instances of each word and try to reassemble them into a whole. The reading becomes the recording. But we are asking the computer to do something when it does not have all the elements it needs to complete the task - we have asked it build a house, but we have given it no material for doors or windows. The result is a garbled mess, but you can still make out a few words here and there that are familiar. We hear a few things that are recognizable, but we also get a lot of silences and noise, what we might think of as the frictions produced by the gaps between what the script recognizes correctly and what it does not. The result is sound art as much as sound interpretation.
One last one. This one is a bit frightening.
While trying to mash up all the silences in the recording to get a supercut of people breathing, I made a conversion error. Because of my mistake, I accidentally dropped a millisecond every five or six milliseconds in the recording rather than dropping only the pieces of spoken word. From this I learned how to make any recording sound like a demon. I think moments of serendipity like this are crucial, because they expose the recording as a recording. This effect almost sounds analogous to the sort of artifacts that might get accidentally created in the recording process. The process of approaching the recording leaves nothing unchanged, but, if we are mindful of these transformations, we can use them in the service of discovery.
So, to review: you can use Python to create supercuts of particular words, to perform readings of a text, to expose artifacts from the recording and transcription process, or to create demons. So my assignment for python might go something like this.
Take some recordings and play around. I think you get the most out of a research method like this by letting the praxis generate the theory. Then let the outcomes reflect and revise the theory. Your students can serendipitously learn new things from these sorts of experiments, even if they might seem silly. Instead of shying away from the failures involved in transforming sound recordings into transcriptions and back again, I propose that we instead take a Joycean approach that “errors are volitional and are the portals of discovery.” The exercise could ask you to consider the traces of digital remediation that are present in the artifacts themselves. Or, it could generate a discussion of regionalism and accents of the Librivox participants that threw the transcriber off. To go further (on the excellent question/suggestion of a NEMLA audience member), this process could expose the fact that, in transcribing audio, the program favors particular pronunciations and silences those voices who do not accord with its linguistic sense of “proper” English. You might get a new sense of the particular vocabulary of recorded words in a text, and what it leaves out. Or you might get a renewed sense of how interpretation is a two-way street that changes our texts as we take them in.
So Python offers some robust ways of working with audio through some packages that are ready to go. This lets you scale up quickly and try new things, but it is worth noting that these methods require far more technical overhead than using Audacity. For this reason, I mentioned training wheels above. Depending on your course, it might be too much to ask students to program in Python from scratch for an assignment like this. So you might offer them starter functions or detailed guides so they do not need to implement the whole thing themselves. The hands-off approach here might be more than some instructors or researchers are willing to allow. Furthermore, while I do think these methods are appropriate for scaling up an examination of audio recordings to compare many different audio artifacts, there are important limitations in the Python audio packages that, without significant tinkering, limit the size of the audio corpus you can work with.
For me, though, the possibilities of these approaches are generative enough to work around these limitations. Methods like these are useful for exposing students to sound archives as more than just pieces of cultural history but also as materials to be used, re-used, and remixed into their own work. I have deliberately chosen as my examples here only recordings of texts as given by amateur readers to suggest that these materials have always been performed and re-preformed. The assignments above ask students to place themselves in this tradition of recreation, and the approach invites them to view these interventions with a sense of exploration and humor.
For the past several years, I’ve taught a Humanities Programming course at HILT. The course was piloted by Wayne Graham and Jeremy Boggs, but, these days, I co-teach the course with Ethan Reed, one of our DH fellows in the Scholars’ Lab. The course is a soup-to-nuts introduction to the kinds of methods and technologies that are useful for humanities programming. We’re changing the course a fair amount this year, so I thought I’d offer a few notes on what we’re doing and the pedagogical motivations for doing so. You can find our syllabus, slides, resources, and more on the site.
We broke the course down into two halves:
Basics: command line, Git, GitHub, HTML/CSS
Project: personal website
Programming concepts: Ruby
Project: Rails application deployed through Heroku and up on GitHub
In the first half, people learned the basic stack necessary to work towards a personal website, then deploying that site through GitHub pages. In the second half, students took in a series of lessons about Ruby syntax, but the underlying goal was to teach them the programming concepts common to a number of programming languages. Then, we shifted gears and had them work through a series of Rails tutorials that pushed them towards a real-life situation where they’re working through and on a thing (in this case a sort of platform for crowdsourcing transcriptions of images).
I really enjoyed teaching the Rails course, and I think there was a lot of good in it. But over the past few years it has raised a number of pedagogical questions for me:
What can you reasonably hope to teach in a week-long workshop?
Is it better to do more with less or less with more?
What is the upper-limit on the amount of new information students can take in during the week?
What will students actually use/remember from the course once the week is over?
To be fair, week-long workshops like this one often raise similar concerns for me. I had two main concerns about our course in particular.
The first was a question of audience. We got people of all different skill levels in the course. Some people were there to get going with programming for the first time. These newcomers often seemed really comfortable with the course during the first half, while the second half of the course could result in a lot of frustration when the difficulty of the material suddenly seemed to skyrocket. Other students were experienced developers with several languages under their belt who were there specifically to learn Rails. The first half of the course seemed to be largely review for this experienced group, while the second half was really what they were there to take on. It’s great that we were able to pull in students with such diverse experiences, but I was especially concerned for the people new to programming who felt lost during the second half of the course. Those experienced folks looking to learn Rails? I think they can probably find their way into the framework some other way. But I didn’t want our course to turn people off from programming because the presentation of the material felt frustrating. We can fix that. I always feel as though we should be able to explain these methods to anyone, and I wanted our alumni to feel that they were empowered by their new experiences, not frustrated. I wanted our course to reflect that principle by focusing on this audience of people looking for an introduction, not an advanced tutorial.
I also wondered a lot about the outcomes of the course. I wondered how many of the students really did anything with web applications after the course was over. Those advanced students there specifically for Rails probably did, and I’m glad that they had tangible skills to walk away with. But, for the average person just getting into digital humanities programming, I imagine that Rails wasn’t something they were going to use right away. After all, you use what you need to do what you need. And, while Rails gives you a lot of options, it’s not necessarily the tool you need for the thing in front of you - specially when you’re starting out.
So we set about redesigning the course with some of these thoughts in mind and with a few principles:
Less is more.
A single audience is better than many.
If you won’t use it, you’ll lose it.
I wondered how we might redesign the course to better reflect the kinds of work that are most common to humanists using programming for their work. I sat down and thought about common tasks that I use programming for beyond building apps/web services. I made a list of some common tasks that, when they confront me, I go, “I can write a script for that!” The resulting syllabus is on the site, but I’ll reiterate it here. The main changes took place in the second half of the course:
Basics: command line, git, GitHub, HTML/CSS
Project: personal website
Programming concepts: Python
Project(s): Applied Python for acquiring, processing, and analyzing humanities data
The switch from Python to Ruby reflects, in part, my own changing practices, but I also find that the Pythonic syntax enforces good stylistic practices in learners. In place of working on a large Rails app, we keep the second half of the course focused on daily tasks that programming is good for. After learning the basic concepts from Python, we introduce a few case studies for applied Python. Like all our materials, these are available on our site. But I’d encourage interested folks to check out the Jupyter notebooks for these units if you’re interested. These are the new units on applications of Python to typical situations:
In the process of working through these materials, the students work with real, live humanities data drawn from Project Gutenberg, the DPLA, and the Jack the Ripper Casebook. We walk the students through a few different options for building a corpus of data and working with it. After gathering data, we talk about problems with it and how to use it. Of course, you could run an entire course on such things. Our goal here is not to cover everything. In fact, I erred on the side of keeping the lessons relatively lightweight, with the assumption that the jump in difficulty level would require us to move pretty slowly. The main goal is to show how situations that appear to be much more complicated still boil down to the same basic concepts the students have just learned. We want to shrink the perceived gap between those beginning exercises and the kinds of scripts that are actually useful for your own day-to-day work. We introduce some slightly more advanced concepts along the way, but hopefully enough of the material will remain familiar that the students can excel. Ideally, the concepts we work through in these case studies will be more immediately useful to someone trying to introduce programming into their workflow for the first time. And, in being more immediately useful, the exercises might be more likely to give a lasting foundation for them to keep building on into the future.
We’ve also rebranded the course slightly. The course description has changed, as we’ve attempted to soften jargon and make it clear that students are meant to come to the course not knowing the terms or technologies in the description (they’re going to learn them with us!). The course name has changed as well, first as a joke but then in a serious way. Instead of simply being called “Humanities Programming,” the course is now “Help! I’m a Humanist! - Programming for Humanists with Python.” The goal there is to expose the human aspect of the course - no one is born knowing this stuff, and learning it means dealing with a load of tough feelings: anxiety, frustration, imposter syndrome, etc. I wanted to foreground all of this right away by making my own internal monologue part of the course title. The course can’t alleviate all those feelings, but I hoped to make it clear that we’re taking them into account and thinking about the human side of what it means to teach and learn this material. We’re in it together.
So. What can you do in a week? Quite a lot. What should you do - that’s a much tougher question. I’ve timed this post to go out right around when HILT starts. If I figure it out in the next week I’ll let you know.
For me, co-teaching is the ultimate teaching experience. I’ve been fortunate to find several opportunities for it over the years. During graduate school, I co-taught a number of short courses, several DH classes, and a couple workshops. Here at W&L I’ve been able to teach alongside faculty from the history department and the Library. Each experience has been deeply rewarding. These days I’m spending more time thinking about digital humanities from a curricular and pedagogical standpoint, so I wanted to offer a few quick notes on how co-teaching might play a role in those discussions.
I’m sympathetic to arguments against putting two or more people at the front of the classroom. It’s expensive to use two faculty members to teach a single course when one might do, so I can understand how, in a certain logic, the format seems profoundly inefficient. You have a set number of courses that need to be taught, and you need people to teach them. And I have also heard people say that co-teaching is a lot more work than teaching a course solo. I understand these objections. But I wanted to offer just a few notes on the benefits of co-teaching - why you might want to consider it as a path for growing your digital humanities program even in the face of such hesitations. I’ve found that the co-teaching experience fully compliments the work that we do as digital humanists for a number of reasons. I think of co-teaching as a way to make the teaching of digital humanities more fully reflect the ways we tend to practice it.
Co-teaching allows for more interdisciplinary courses.
Interdisciplinarity is hard. By its very nature, it assumes research, thinking, and teaching that lie at the intersections of at least two fields, usually more. In the case of digital humanities, this is exacerbated because the methodologies of the combined fields often seem to be so distinct from one another. Literary criticism and statistical methods, archival research and computer science, literary theory and web design. These binaries are flawed, of course, and these fields have a lot to say to and about each other. But, in the context of teaching digital humanities, sometimes bringing these fields together requires expertise that one teacher alone might not possess. A second instructor makes it easier to bridge perceived gaps in skills or training. And those skills, if they are meant to be taught, require time and energy from the instructors. On a more practical level, it can be profoundly helpful to have one instructor float in the classroom to offer technical assistance while the other leads discussion so as to prevent troubleshooting from breaking up the class. It is not enough to say that interdisciplinary courses need a second instructor. They often require additional hands on deck.
Co-teaching models collaboration for students.
Digital humanities work often requires multiple people to work together, but I’d wager that students often expect there to be a single person in charge of a class. Students might come into the class expecting a lecture model. Or, at the very least, they might expect the teacher to be an expert on the material. Or, they might expect the instructor to lead discussion. These formats are all well and good, and many instructors thrive on these models. I prefer to position my students as equal collaborators with me in the material of the course. We explore the material together, and, even if I might serve as a guiding hand, their observations are just as important as my own. I try to give my students space to assert themselves as experts, as real collaborators in the course. Co-teaching helps to set the stage for this kind of approach, because the baseline assumption is that no one person knows everything. If that were the case, you would not need a second instructor. There is always a second voice in the room. By unsettling the top-down hierarchy of the classroom, co-teaching helps to disperse authority out into other parts of the group. The co-teacher not in charge on a particular day might even be seated alongside the students, learning with them. This approach to teaching works especially well as a vehicle for digital humanities. After all, most digital humanities projects have many collaborators, each of whom brings a different set of skills to the table. No person operates as an expert in all parts of a collaborative project - not even the project manager. Digital humanities work is, by its nature, collaborative. Students should know this, see this, and feel this, and it can start at the front of the classroom.
Co-teaching transfers skills from one instructor to another.
Digital humanities faculty and staff are often brought in to support courses and projects by teaching particular methods or tools. This kind of training can sometimes happen in one-off workshops or in external labs, but the co-teaching model can offer a deeper, more immersive mentoring experience. Co-teaching can be as much for the instruction of the students as it is for the professional development of the teachers. For the willing faculty member, a semester-long engagement with material that stretches their own technical abilities can set them up to teach the material by themselves in the future. They can learn alongside the students and expand their portfolio of skills. At W&L we have had successes in a number of disciplines with this approach - faculty in history, journalism, and French have expanded their skills with text analysis, multimedia design and storytelling, and textual encoding all while developing and teaching new courses. We’ve even managed, at times, to document this process so that we have demonstrable, professionally legible evidence of the kinds of work possible when two people work together. When both instructors share course time for the entire semester it can help to expand the capacity of a digital humanities program by spreading expertise among many collaborators.
Of course, all of this requires a lot of buy-in, both from the faculty teaching together and from the administration overseeing the development of such courses. You need a lot of people ready to see the value in this process. The particulars of your campus might provide their own limitations or opportunities. Putting together collaborations like these takes time and energy, but it’s worth it. I think of co-teaching as an investment - in the future of the program, the students, and the instructors. What requires two instructors today might, with the right preparation and participation, only require one tomorrow.
In case you want to read more, here are some other pieces on co-teaching from myself and past collaborators (happy to be pointed to others!):