Hacking, disability, and inclusive pathways in music education
Hacking, disability, and music education
After making minor code adjustments on his computer and uploading them to an iPhone, Tim passes his device to Megan with the instruction: “Try pressing play.” This moment is crucial for a team of ten who have spent nearly eight hours working to make a cellphone vibrate in synchronization with a song's beat. Megan takes the phone silently as her teammates watch closely. Sarah, sitting beside Megan and unable to contain her anticipation, blurts out: “Is it done?” Beaming with satisfaction, Megan responds: “Yeah, it's really cool. It's really cool!”
The vibrating phone was created at Monthly Music Hackathon NYC, a non-competitive, community-driven gathering where participants — ranging from beginners to experts in music, education, coding, and hardware or software design — work together over a single day on projects proposed by stakeholders from their communities. At this particular event, themed “AccessAbility,” the group aimed to build a phone application that could generate meaningful sensory stimuli for people with hearing and visual impairments. The Monthly Music Hackathon frequently tackles themes related to social marginalization in music, such as disability and gender, and draws about 100 attendees per session. This makes it the largest music hackathon where participants regularly design projects that confront issues of disability in music.
Learners with disabilities are too often pushed to the margins of music education. Could the hacking practices demonstrated by Tim, Megan, Sarah, and their teammates open doors to a more accessible and inclusive music education for those who experience disability?
Review of literature: music education, hacking, and disability
This study set out to understand how hacking in music — as seen through the actions and discussions of hackathon participants — might point toward ways to make music education more accessible and inclusive for people with disabilities. This investigation requires some foundational context on two subjects: (1) hacking and hackathons, and (2) disability in music education.
Hacking and hackathons
Jordan (2017) notes that despite two decades of studying the phenomenon, “it remains unclear what hacking means.” The term now covers everything from election interference to minor lifehacks, such as tying colorful ribbon on luggage for easy identification at baggage claim. The focus here narrows to the kind of hacking found at hackathons. Lara and Lockwood (2016) define hackathons as intense, short events (one to two days) where participants form small groups at a central location and develop a project from concept to prototype. Projects typically respond to the event’s theme or challenge. By the end, groups present a “demo” and discuss next steps (Irani, 2015). Based on previous attendance at a different session, the “New Musical Instruments Hackathon” hosted by Monthly Music Hackathon NYC, these characteristics fit well: small teams coalesced around the non-competitive challenge of building new instruments, mostly software-based. Still, such a brief description captures only the surface of music hacking — a deeper, systematic study was required to address this project’s research questions.
Disability and music education
By examining how people experience disability in music, this study avoided any single definition of disability, instead letting participants define the term and decide how hacking might address it. That stance reverses typical music education research, which tends to treat disability as a fixed attribute (Dobbs, 2012).
This departure opens conceptual room for the field to reconsider what “disability” truly means in music education. In English-speaking countries like the United States, the United Kingdom, and Canada, the medical model — where disability is understood as an individual's problem — determines who qualifies for government-mandated supports (e.g., reserved parking, extended test time, specialized healthcare). Because music education in these nations is closely tied to public school systems, most research centers on school-age students whose disabilities are formally recognized by government agencies. Major textbooks in the field (e.g., Adamek & Darrow, 2010; Blair & McCord, 2016; Hammel & Hourigan, 2011; Jellison, 2015; Sobol, 2008) tend to treat disability as a personal trait and focus on helping these students participate in traditional music activities like concert band or choir. Lubet (2010) argues that music researchers have generally overlooked the experience of disability as a social matter.
More recently, some scholars have drawn on disability studies to critique the ableism — discrimination based on ability — embedded in music education (e.g., Abramo, 2012; Abramo & Pierce, 2013; Bell, 2017; Dobbs, 2012; Parker & Draves, 2017; Pickard, 2019; Rathgeber, 2019). While music education professes a commitment to diversity and inclusion, disability is often left out of these conversations (Laes & Westerlund, 2018), and people with disabilities regularly receive unequal treatment in music classrooms (Darrow, 2015). Churchill (2015), a music education researcher who identifies as “hard-of-hearing,” offers one example: perspectives of Deaf and hard-of-hearing musicians are routinely excluded from disability discourse. Consequently, the field’s understanding of these populations is shaped by “audiocentric” views that treat deafness as a shortcoming (Silvestri et al., 2018).
The social model — where disability is understood as a societal issue — has appeared frequently in music performance studies over the last decade (e.g., Howe et al., 2016; Lerner & Straus, 2006; Lubet, 2010; Straus, 2011) but less often in music education. Still, the social model’s influence can be seen in the pedagogical approaches of educators committed to Universal Design for Learning (UDL) (e.g., Darrow, 2016; McCord et al., 2014; Quaglia, 2015). Capp (2017) explains: “The philosophy of UDL is based on the idea that there are multiple ways of representing knowledge (principle one), multiple ways students can demonstrate their understanding (principle two), and multiple ways of engaging students (principle three).” UDL is built on anticipating students’ varied needs. Darrow (2016) writes that “Rather than designing instruction for students with a specific disability, the music educator employs UDL principles for students with a broad range of skills, reading levels, learning styles, and personal motivations.” Evidence of UDL’s effectiveness in music education includes cases from Yinger (2014) involving adults in choir and Smith (2018) studying elementary “students with special needs.”
Though UDL is a worthy goal, it is ultimately unattainable in certain music-making and learning settings, partly due to its roots in architectural universal design. Holmes (2018) points out that “universal design is strongest at describing the qualities of a final design. It is exceptionally good at describing the nature of physical objects.” Textbook explanations often invoke the wheelchair ramp as an example — it works for both wheelchair users and people who walk. Yet barriers in music learning, such as difficulties with musical interfaces, are far more complex and nuanced than simply accessing a building. The anticipatory design behind UDL cannot fully predict every obstacle an individual may face in any specific teaching or learning context.
UDL pioneers Anne Meyer and David Rose have acknowledged this limitation specifically for arts education: “Unpredictable variability may still occur and require responsive, differentiated instructional supports. For example, some learners may still need customized assistive technology or adaptive tools” (Glass et al., 2013, p. 101). In other words, hacking is necessary; it functions as UDL’s essential appendix. Though UDL and hacking appear opposed — UDL looks ahead while hacking reacts in the moment — both campaigns seek the same outcome: inclusion.
Hacking inherently assumes that the conditions surrounding disability in music can be changed. Over the past twenty years, researchers working at the intersection of music and other fields have engaged in hacking-like projects: adapting instruments for people with physical disabilities. Examples include adaptations for flute (Nabb, 2007), recorder (Dickeson, 2004; Kennedy, Kua-Walker, 2006; Peskin, 2004), saxophone (Cohen, 1987; Nabb & Balcetis, 2010), trumpet (Snedeker, 2005), and various percussion instruments (Crowe & Ratner, 2012). These studies share three underlying views: (1) disability is a physical trait of an individual, (2) the goal of adaptation is to enable a person to play a traditional instrument, and (3) instrument adaptation is a time-consuming and highly specialized job for experts. Monthly Music Hackathon NYC turns this paradigm upside down by: (1) avoiding standard disability language (organizers prefer “differently-abled”), (2) encouraging the creation of entirely new instruments and interfaces for diverse music-making settings, and (3) fostering an environment where projects are built in a single day by both novices and experts. By examining this alternative approach, the present study contributes a fresh perspective to the ongoing effort to make music education more accessible and inclusive.
Theoretical approach: the social model of disability and social confluence
This study builds on the social model of disability. Whereas the medical model sees disability as an individual defect, the social model holds that people are different; whether someone experiences disability depends on how society responds to those differences. Disability, from this perspective, is a societal challenge, not a personal one (Cameron, 2009), and categorizations of “able” or “disabled” are socially constructed (Stras, 2009). This outlook is especially relevant to education because it focuses on the student, in alignment with UDL principles; it questions existing systems and seeks to improve them. At the same time, educators must not downplay the real interplay of learners’ lives, including the complexity of physical embodiment (Siebers, 2008) and disability identities (Barnes, 2016). As Shakespeare (2013) argues, unwavering commitment to the “strong social model” can become problematic because it risks denying individual differences.
!
This investigation uses Lubet’s (2010) theory of social confluence in particular. Lubet posits that people do not have fixed, singular identities but that their sense of self shifts continually as their situation changes. Lubet also suggests that the experience of disability in music can stem from factors beyond standard definitions of disability — including gender, race, ethnicity, and age. Social confluence offers a framework for interpreting what counts as disability in music beyond the simple classifications of able or disabled as static conditions. Recognizing these seemingly unpredictable factors — and how hackathon participants identify and address them through hacking — provides music educators and researchers with fresh tools for confronting experiences of disability in their own teaching and learning contexts.
Purpose and method
Monthly Music Hackathon NYC served as an instrumental case study that enabled analysis of hacking practices in music and helped provide a window into this issue while shading generalizations (Stake, 2005, p. 445). The results point to ways music education could become more accessible and welcoming to learners who experience disability. The study investigated the following areas:
- How is hacking music performed by hackathon participants?
- What are the effective strategies — and the problematic patterns — observed during music hackathons that relate to designing more inclusive music-making experiences?
Before collecting data, the research team consulted with representatives from Monthly Music Hackathon NYC to confirm the methodology. The decision was made that nobody would be audio- or video-recorded without their explicit written consent. Crucially, a person’s choice to join or refuse the study had no effect on their ability to participate in the hackathon itself.
Event description and location
Member researchers entered the field as participant-observers at the Music AccessAbility hackathon held on March 10, 2018, in Brooklyn, New York. The event was run by Music Community Lab, the nonprofit group behind Monthly Music Hackathon NYC. According to the Monthly Music Hackathon website, the Music AccessAbility edition is described as follows:
…a day-long, non-competitive event celebrating and exploring new ways to increase access to music for people of all abilities. It’s for everyone, even if you've never composed any type of music before or tried programming … [It] is an event series for people with an interest in music and technology to create new projects from scratch, develop them throughout ~6 hours, then perform or present them in a concert in the evening. (Monthly Music Hackathon, 2018)
The hackathon was held at NYU MAGNET (Media And Games NETwork), a facility with a colorful contemporary layout featuring moveable plastic tables, chairs, couches, and several arcade games lining the walls. The space included an area for presentations fitted with chairs facing two large projector screens and a podium. On one side of the presentation space a collaborative area with chairs and mobile tables offered group work opportunities; on the other side, a hallway led to classrooms and a small kitchen.
Data collection and analysis
Video data collection procedures followed established guidelines for successful video ethnography described by Goldman-Segall (1998) and Pink (2007). In this approach, the videographer acts as a kind of narrator by documenting the processes of the participants. At this hackathon, three research assistants, each with their own camera, recorded the team development for three different groups throughout the whole session, producing between eight and ten hours of video footage per collaborator. Because transcribing all footage wasn’t viable, the educators narrowed dataset through salient episode selection, akin to documentary film editing: extensive raw footage captured initially subsequently trimmed back into a strong, coherent narrative during later stages. Salient episodes derived from video data identification adhered to Bell’s (2014) analysis procedure, beginning with the creation of content reports (Barron, 2007) during sequential playback for winnowing footage's additional mapping to concrete study or document questions. Post those evaluations, key short films segments received longer note passage and interviews (Figalli no full video capture can full sequence matching Silver manuscript and golden light), while digital cultural communication yielded numerous conference concepts drawing up event critical aspects often coming from time researchers needed complete record for representative design following authors fully disclosure due to earlier permission orientation result method. The five behavioral headings delineated in the methodology involve tracking operations: flows, physical motions, conversation details focused sequencing activity or momentary episodic unfolding events and works within given systems. Denzin (2001) prescribed strong parameters for meaning full note interpretation: revealing socio structures building condition immediately visible to sight itself not; interpretation approach adds identity desires underpinning course; consistent rewriting edits capture motion evolution shows varied stable perform temporal unfolding times step; interactive passage open analytic interconnecting explanatory construct materialized, all permitting personal commentary.
Clickable playback identification process via idea grouping systematic coding lens above described Galletta in another foundation publication moved for sign processing natural loops frequently adding into certain designated conceptual cells. Line codes none arrived early path avoidance push constructing interpretive prejudice within analysis cycle period order.
The themes derived from the video events were used to create the narrative presented in the findings. Writing narrative enlists ‘thick description’ to capture ‘lived experience’ (Denzin, 2001). Jorgensen (2007) advocates for ‘thickly describing music education’ to disseminate to the field detailed accounts of new musical practices.
Findings
Overview of the event
Talks and lunch. The event began at noon, and as it neared this time, people filed into the presentation space; however, it was not large enough to seat everyone (approximately 100 in attendance at this point), so some people stood at the back and on the sides while others perched themselves on the windowsills. Once everyone was settled, a set of presenters spoke to the group about their experiences of being disabled and their suggestions on how the projects undertaken during the hackathon could benefit them or other people with similar disabilities. The presenters each gave short talks about what they viewed as challenges to the accessibility of music and suggestions for ideas that the hackathon participants could take on. For example, Richard, a composer with hearing loss, offered a simulation of how he heard music with his hearing impairment and introduced some ideas about audio processing using smartphones. Other presentations included a demonstration of a device to enable a wheelchair user to play the pedals on a piano, and suggestions to improve the accessibility of the Spotify app for people with visual and hearing impairments. During the presentations, a professional stenographer typed real-time captioning for those in the audience with hearing impairments. Following the presentations, pizza was served in the kitchenette area. Attendees dispersed along the hallway, standing and mingling in small groups.
Brainstorming. The brainstorming session, which followed lunch, was attended by a small group of attendees (approximately 15). Some people had already formed their groups and began working on their project ideas immediately. The purpose of the brainstorming session was to generate ideas for the hackathon and form groups based on shared interests for attendees who did not already have a group. Each attendee introduced themselves and the hacks they were interested in. A volunteer clustered sticky notes of each person’s ideas on the wall according to area of interest. The attendees mingled near the front of the room for the next half an hour, discussing their ideas and forming groups. From the brainstorming session, two distinct groups formed and began working on their new project ideas.
Hacking and presentations. From approximately 2:00 pm to 8:30 pm, groups engaged in hacking. In the following section we present two different examples of hacking. At the conclusion of the hacking period, the remaining attendees (approximately 50) gathered at the presentation space to share their works-in-progress. The mood was lighter and more informal than it had been during the presentations earlier in the day. All of the groups spoke about their projects, with some groups presenting slides, showing their code, and/or demonstrating their proof of concept. At around 9:30 pm, the project presentations concluded, and some participants stayed to mingle afterward before the event was officially brought to a close around 10:00 pm.
Example of hacking 1: the SCND method
The group that created ‘the SCND Method’, a new form of music notation, was comprised of four engineering and computer science students named Claudia, Denise, Nicole, and Serena. It was obvious to any onlookers that they came together as a team for the day’s event; they wore matching uniforms of black t-shirts and leggings. They began working immediately, huddled with their laptops at one of the plastic folding tables. The team members were friends and classmates prior to attending and chose not to participate in the brainstorming session. They were ready to begin a long day of coding and creativity, but also to begin a day filled with playful camaraderie.
For most of the members of this group, this was the first hackathon they had ever attended. Their education in scientific fields and experience working together gave them a chance to flex their creative muscles, hacking problems related to music and disability. After some initial brainstorming about what to hack, the group decided to create a simplified notation system to aid new learners of music, which they named the SCND Method. Serena explained the process of coming up with their system: ‘It took us a really long time to actually come up with something. We sat there for an hour-and-a-half thinking about things. We started to really go in the direction of trying to think about how to take sounds and make it available to other people. So, after an hour-and-a-half of brainstorming, we started to go in a different direction, which was we tried to focus on how we could make actually creating music easier for people.’
Nicole mentioned that sight-reading posed difficulty when she was learning piano as a child. She felt that a notation system, such as the SCND Method, which uses bright colours and shapes, would attract children to music education: ‘I am pretty sure it is much easier to be able to read it (the SCND Method). I definitely wish that I learned how to read music like this. It just makes it so much easier.’ Denise explained the thinking behind their concept: ‘What we did was to take a more visual approach for kids to learn how to read sheet music. What we did was to associate each of the standard seven notes on the standard scale to different colours. I don’t know about you, but when I was a kid, I learned by looking at colours and numbers, so that is exactly what we did. […] So we identified the problem, which is when it comes to actually reading music, like sheet music, it is extremely difficult, you know, it is really overwhelming. Anything is just really compacted together; it is really cluttered. It is just black and white, and it is just overall really hard to read, you know, all the symbols look alike. They are not really symbols you can relate to, so what we thought about is: how could we make reading music and playing music easier?’
The group tested their concept by converting the first two bars of ‘Twinkle Twinkle Little Star’ from standard musical notation to the SCND Method. The group explained the key concepts of their system as follows (see Figure 1):
• Musical notes are represented by coloured shapes; • Notes without accidentals are coloured circles; • Sharps are coloured squares; • Flats are coloured triangles; • The colour of the shape represents the pitch of the note with A being red through G being violet; • Chords are created by stacking shapes of decreasing size using a birds-eye view depiction.
The team wanted to implement software that would allow a user to create music notation using the SCND Method. They had discussed using software to translate pages of traditional sheet music, but Claudia, a computer science student, realized that the task was far too difficult to be completed within the span of a day. This realization led the group to decide that the best course of action would be to create a website that would take user-inputted keyboard presses and convert the letters A through G into the corresponding notes and chords for their notation system.
Once the team had a clear plan to create a website to implement their notation system concept, the tasks were divided among the group members based on the best fit of each task to a group member’s skills. The bulk of the work of building the website was placed on Claudia’s shoulders because she was the only group member with experience writing software. Claudia started to code the website by creating text boxes that would prompt a user’s input and translate the input to display the appropriate shapes and colours. Denise, Nicole, and Serena worked on creating the images for the shapes that the website would display by using the software programme Paint. The images they created were initially JPEG files, but the team encountered difficulty in having the images populated properly on the website and decided that the images needed to be PNG files instead. The team needed to use PNG instead of JPEG files as PNG files allow for transparent backgrounds. After the basic shapes were created, the team found images of treble and bass clefs that would be shown at the start of the measures by searching images on Google. Claudia ran into problems getting the PNG images to size properly as well as to have the images placed in a manner that a user could legibly read. Claudia was helped by Nefertiti, Nicole’s sister, who briefly joined the group later in the day to help with the coding issues they were having.
For most of the day Serena, Nicole, Denise, and Claudia had no intention of presenting the notation system they developed. It was only within the last half-an-hour that the group decided they would like to present. With time winding down, Denise quickly created PowerPoint slides as Claudia finished a working demonstration of the website with mere minutes to go. With all of the work completed, the group was ready to present what they had worked on all day. Despite their initial reluctance, Claudia, Denise, Nicole, and Serena presented to the 40-or-so people whom still remained in the dwindling hours of the event. The team started their presentation by discussing the difficulties they experienced during the hackathon. The team showed the ways in which the SCND Method made learning music easier for students and discussed how future aspects of their programme would allow a user to upload whole songs in standard notation and have these songs automatically translated. Claudia showed their current software that allowed her to type the letters A-B-C into a textbox and have three coloured circles and a treble clef to be populated onto the projector screen. This impressed the audience. The team finished their presentation by fielding questions from the crowd. They were asked about who the user of their system would be and gave this response: ‘It is supposed to be an easier way of seeing music, even for someone who is not visually impaired seeing sheet music is visually overwhelming. So, this was a way to just break it down and make everything a lot easier and more accessible to everyone overall.’
Example of hacking 2: colorblind-accessible album artwork (C3A)
Formed during the brainstorming session, the Colorblind-Accessible Album Artwork (C3A) group consisted of three previously unacquainted men in their 20s: Bryant, a graduate student, who did his undergraduate studies in political science; João, a software developer who had a background and interest in music; and, Isaac, who had recently graduated college studying music technology and had a job in IT. This group decided to create a programme that would be ‘tech-wise simple’: a prototype that could be generally applied to many different contexts. Though broad in scope, their programme would focus on accessibility, colorblindness, and music. The group’s concentration on colorblindness was inspired by another attendee who had shown them an app that processed images to present how they would look to a colorblind person. Their basic concept was to design an accessibility overlay that would replace existing inaccessible content for people with colorblindness. They wanted to prototype code that would take an existing piece of digital media, create a simulated colorblind version of the media, and use that simulated image to recolour the original media so that someone with colorblindness could see the composition of the image with greater clarity.
In their conversations regarding the purposes of this proposed programme, they identified album cover artwork on the Spotify platform as one of the central problematic areas to be addressed. Given that one of the opening talks centred on making the Spotify app more accessible, clearly the C3A group was responding to this challenge. Isaac remarked: ‘Album art and music videos are actually pretty huge parts of the musical experience, but you might not be getting as much contrast or as, like, vivid expression out of those parts of the musical experience if you’re colorblind’.
When brainstorming, the C3A group wrote their ideas regarding colorblindness and programme development on a whiteboard and discussed the purpose of their potential programme, as well as who it could help, and how they could create it. While most of this stage involved group discussion, some of it involved demonstrating relevant materials on their computers and phones. Following the first hour of brainstorming and planning, the group discussed their respective skills and realized that they only partially shared skillsets. While Isaac had experience with the Python and JavaScript languages, João only knew JavaScript and Bryant only knew Python. Thus, the group decided that they would work on a two-part product (one in Python and one in JavaScript),
with Isaac acting as an intermediary between Bryant and João. This solution, in Bryant’s words, was ‘about using our strengths’ to work as a team on the project. They gradually established what their product would look like by researching colorblindness and finding code that had already been written online.
Once they began to work, the C3A group generated multiple ideas for their programme, though the function of their product was still to create software that would take a ‘regular’ image and transform it into a ‘more expressive’ alternative version that would be more discernible for people with colorblindness. An additional idea that came out of this project was brought forward by Isaac who suggested that the programme could be a tool for web developers and front-end website designers. With their programme, designers could adjust their designs based on what colorblind people see and create a more inclusive product as a result. Bryant articulated the C3A group’s primary objective accordingly: ‘The objective really is, people with colorblindness, if they see album artwork, they want to still be able to see the true colours of the album artwork. So, how do we manipulate their vision with technology to give the true tone?’
Notably and first, Bryant assumed a set of ‘true colours’ exists, and second, that a person with colorblindness would have a desire to view these ‘true colours’. Bryant realized soon after that the problem they were trying to solve may not have a technological solution. Furthermore, the C3A group realized they were confounding the perception of a colorblind person with the output of a computer:
Bryant: We’re making the second image more expressive. We know it cannot look like that first image, but at least there will be a little more variance and distinction in that second image.
Isaac: I just want to make sure . . . when we talk about that second image, we’re talking about a file versus how it’s being perceived. We have to consider the difference between the data that’s coming in and out of the program and how it’s perceived by someone.
Bryant: […] I’m not even quite sure if what we’re creating, if there’s honestly a solution for that. It makes sense if we’re trying to make this for a content creator. It works for that assuming the content creator himself, or herself, has normal vision.
As this exchange evidences, Bryant realized their programme may not be useful for someone who is colorblind. Their product, which would transform an image to what a colorblind person would see and then offer suggestions for a ‘more expressive’ alternative was more of an accessibility tool for content creators who would want to make an inclusively-designed musical product.
The C3A group had noble intentions to improve the lives of people with colorblindness as exemplified by Isaac’s sentiment: ‘When you’re designing things, the default audience is able-bodied and can see colours and all these kinds of things. Tools that give you the feedback, immediate feedback, of other audiences, is a good thing to change that default.’ Bryant summarized this line of thinking, stating: ‘the user is not the content creator.’ Nevertheless, it is important to note how the lens of disability served as a source of inspiration for the ‘user story’ for the C3A group’s project; their understandings of colorblindness were not lived but instead informed by Googling. Rather than creating a product for people with disabilities, the C3A group was creating a product about people with disabilities, based on their constructed notions of what they believed colorblindness to be. As the C3A group continued to work, many stages occurred concurrently. For instance, they found a JavaScript programme that did the ‘hard work’ for them: it transformed images into
what a colorblind person would see. After discovering this programme, the group resumed brainstorming to find how they could make an original product with this existing material.
In the later hours of the hackathon, the C3A group worked quietly at their computers. Even though they appeared to be passively staring at their screens during these times, they were actively moving between windows, searching for solutions online, and chipping away on their code. As the day progressed, the C3A group spent more time working and problem solving and less time discussing and brainstorming. This work became more frenzied in the last hour despite the onset of fatigue. As the end of the event neared, the group realized they were not going to have a finished product to show at the presentations. Because of this, they decided to talk about their ideas and use their brainstorming on the whiteboard as a guide for their talk. Bryant had to leave early and João was too shy to present, so only Isaac presented. When the presentations started around 8:00 p.m., many groups had finished prototypes to demonstrate or had prepared slides to show their progress. After a few presentations, Isaac stood up to present his group’s project-in-progress. He spoke about their original idea and inspiration and shared their process and the challenges that they encountered:
‘So there were a few musical interfaces that we could identify that could benefit from a redesign […] examples being […] musical album art and music videos are actually pretty huge parts of the musical experience but you might not be getting as much contrast or as, like, vivid expression out of those parts of musical experience if you’re colorblind […] So, we were, like, fully unable to do this […] but I think we had some good insights into just this whole process.[…] We were thinking about how can translation be expressive, not just functional. […] how is the creative intent of the original being transmitted? But all these things were definitely not in the scope of, like, a four- to five-hour session. So, I think coming to terms with that a little earlier might have helped us come up with a better product in the end.’
For this group, in the allotted 4.5 hr, the ‘problem’ of colorblindness had proved unsolvable, but they were still enthusiastic about the progress they had made and expressed that they would like to continue with their project or attend the next hackathon.
Discussion
At the Monthly Music Hackathon NYC “AccessAbility” event, the groups we observed generally passed through the following successive stages during the day: establishing what they already had to work with; planning and brainstorming; making decisions and dividing tasks; coding and quiet work; testing; problem-solving through trial and error; realizing goals fully or partially; building on initial ideas and progress to redesign; and presenting works-in-progress. These activities were interspersed with breaks, socializing, making friends, learning, teaching, and being inspired by presentations or workshops. This broad overview of observable stages matches earlier research on non-music hackathons (Irani, 2015; Lara & Lockwood, 2016).
In addition, analysis of aggregated video data from the groups revealed that the following actions were particularly common: social networking, discussing, collaborating, sharing knowledge, teaching/helping/mentoring, designing, creating, coding, and iterative prototyping. When considering what constitutes hacking music at this event, technological acts like coding—typically associated with hacking (Trainer et al., 2016)—mattered, but social acts mattered equally, a finding consistent with Briscoe and Mulligan (2014). Hacking here cannot be reduced to the technological alone; it is far more. As the case studies show, achieving a result requires a group with complementary skills who work collaboratively and interdependently. Teams often spent more than half their time generating an idea and evaluating whether it was worth pursuing further. Both groups expressed a commendable desire to use their skills to foster a more inclusive society by creating more accessible music experiences. They identified problems that hacking might solve and assessed whether their skills suited the proposed tasks. By the time groups were ready to work on a solution, little time remained to finish their hack. Aware that time constraints made a fully realized prototype unlikely, participants valued the process at least as much as the final product, as shown by groups like SCND Method presenting works-in-progress or the C3A group sharing their ideas and reporting on progress.
What best practices—and conversely, problems—appeared at the music hackathons with respect to designing for more inclusive music-making?
Given the potential applications of music hacking for music education, it is vital to recognize the need for fostering an environment where students’ strengths are identified to form complementary hacking groups. Anyone can contribute to a hack, and this mindset can empower many learners. Such thinking embodies the social model in action: learners are challenged to consider how they might contribute to meaningful, immediate changes that improve the lives of others in their local context. Responsibility is not deferred or evaded; it is embraced. More broadly, situating learners in scenarios where real-world musical needs are expressed by community members would underscore the need for ingenuity and immediacy. Taken together, the type of hacking events hosted by Monthly Music Hackathon NYC have much to teach music education about harnessing technologies to make music-making more accessible and inclusive.
People setting aside a Saturday and gathering in goodwill to help others gain better access to music is a laudable model of teaching and learning. Yet, despite its promise, the hacking that occurs at Monthly Music Hackathon NYC has flaws that music educators should keep in mind. As the AccessAbility event ended, a research team member was approached by a participant who expressed discontent that his perspective as a neurodivergent individual had been excluded. He commended the organizers for inviting guest speakers with disabilities to start the day, but objected that none of the hacking groups appeared to include people with disabilities.
Although the event included many accessibility features—a quiet room, accessible building entry, and jazz hands during presentations instead of clapping due to some people’s sound sensitivities—none of the groups we observed sought to collaborate with the very people for whom they were designing. Members of the C3A group, for example, wondered aloud whether their hack would be useful, a question best answered by a colorblind person. The SCND Method group also illustrates this problem. Initially, their hack targeted children or new music learners, but later they suggested their program could aid music reading for people with visual impairments:
“We were gearing it towards children and the more visually-impaired children, I think. It was just supposed to be an easier way of seeing music because even for someone who’s not visually impaired, seeing sheet music is really overwhelming. So, this was just kind of a way to break it down and just make everything a lot easier and more accessible to everyone overall.”
Here, the target population was not identified until after the hack was completed; in other words, the solution came first, followed by the problem. This out-of-order design thinking is not unique to this case—it appears in music education as well. Music education researchers drawing on disability studies literature repeatedly note that the field has failed to grasp nuanced understandings of disability, a failure linked to a lack of meaningful engagement with people with disabilities. Imagining how disability is experienced from an able-bodied perspective, rather than being informed by those who live with disability, is what Holmes (2018) calls “ability bias.” Darrow (2015) offers four strategies for music educators to address this shortcoming: develop ability awareness, include disability content in the curriculum, use role models representing disability in music educational contexts, and hire teachers with disabilities. Beyond these practical suggestions, Rathgeber (2019) stresses the need to “complexify” disability and to “challenge and problematize essentializing and totalizing conceptions of disability” that inform research on music education and disability.
Holmes (2018) emphasizes considering, examining, and adopting inclusive design practices because over 6 billion people worldwide are “temporarily able-bodied”; all people have “ever-changing bodies,” and we will all experience mismatches between our bodies and the built environments we inhabit. Countering a “one-size-fits-all” mentality, Holmes champions personalized “one-size-fits-one” designs and extending these solutions to more people. Saxophonist David Nabb (2018) observed this phenomenon in his own experience: after a stroke that impaired his arm, he thought he was alone in wanting to play the saxophone with one hand, but soon encountered others with similar impairments also wanting to acquire and play a one-handed saxophone. Hacking presents prime opportunities for empowerment in and through music for people with disabilities—but only if the navigators enlisted for these instrument inventions or modifications are the people who will use them.
Hope and hazards of hacking
Music education can encompass many ways of music-making, and we propose that hacking has potential as a beneficial practice in both community and school contexts. The hope is that hacking could become a transformative practice, with teachers and learners adopting social model thinking and working collaboratively to create bespoke solutions to problems faced by members of their communities. In a tech-centric world where software companies wield significant power over pedagogy (e.g., Google Certified Educator, Apple Distinguished Educator, Certified Soundtrap Educator), hacking offers a do-it-yourself, hands-on means to reject one-size-fits-all solutions and pursue more meaningful one-size-fits-one solutions that can be extended to many (Holmes, 2018). One example is the “Kellycaster,” an adapted guitar created at Drake Music Lab under the guidance of disabled musician John Kelly (Drake Music, n.d.). Music educators can facilitate impactful hacking in their own contexts, led by people with disabilities in their communities. Through hacking, teachers and learners can transition from technology end-users to designers. In music education, hacking holds great potential for developing new instrument designs and modifications to include a broader spectrum of people, especially with regard to bodily differences.
Hacking brings much hope for music education, but hazards lurk on many paths toward a more accessible and inclusive field. The good intentions of nondisabled people hacking for or on behalf of people with disabilities are commendable on one hand, but misguided on the other. As the disability rights slogan “nothing about us without us” reminds us, a genuinely social-model-informed pedagogy seeks to be led by people with disabilities. While the difference between hacking “for” and hacking “with” may seem minor on the page, in practice it is monumental. If the field strays from this fundamental guiding principle, it makes the misstep of “making up” disability (Hacking, 2007), imagining rather than being informed about what disability is. For hacking to be meaningful and emancipatory in music education with respect to accessibility and inclusivity, it must be disability-led.
Declaration of conflicting interests: The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding: The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The authors received financial support from the Social Sciences and Humanities Research Council of Canada (SSHRC).
Understandably, these circumstances necessitate careful scheduling and economic planning for musicians, whose primary connection to their craft may feel diluted when their incomes are uncertain. Additionally, repeat engagement at scattered teaching establishments necessitates conscientious negotiation regarding fair payment, and while many choral organizations budget according to ensemble size and repertoire complexity, finite funding often strains creative ambitions.
As competition in the field persists, these economic realities directly influence how a conductor conceptualizes projects; every season becomes an exercise in balancing cost, artistic gains, and performer welfare. Decisions that uphold artistry often run headlong into budgetary ceilings, forcing strategic prioritization — values that find a clear, modern expression in works defined by minimal instrumentation and cross sector cooperation.
Renán underscores the monetary strains incumbent on directors operating as independent artists without institutional under writing: > Freelance conductors in this environment continually reconcile between the avant garde and the accessible, precisely because larger funding insists on specific community reach. So the portfolio pathway, far from liberating, demands extreme discipline about time and resources; one cannot experiment without a safety net.