H0mefile
The project takes a slightly different approach to creative research than my other compositions. Rather than make a performance or a sound walk, I was interested in how we might bring home based disabled musicians together using technology to perform from their homes. In this sense the work is more of a research and development project than a creative practice.
Oliver’s (1992) concept of rebuilding social relations in disability research shows that as researchers in this field we should be actively trying to improve the material circumstances of those that we write about. Rummery (2020) states that:
As an academic who embraces both feminism and disability studies as my key theoretical perspectives, the onus is on me to incorporate activism into my research: to not just observe and write about the social world in which women and disabled people are oppressed, but to actively engage in tackling that oppression.
Whilst making creative work can be seen as a political act in itself, I wondered if there might be something more I could do to help make changes for the better for other disabled musicians. As I had had some success in performing from home via a networked connection, I thought maybe this would be something that other disabled artists might be interested in using, so I set about researching what disabled musicians might need for accessibility and whether we could implement it into a networked music performance (NMP) environment.
The project was conceived of before the Covid Pandemic. As a result of this the ideas and application of creating a home based ensemble using live streaming should be seen in that context. At the time this was not something that many ensembles were doing, or that software developers were creating platforms for.
What is it? Aims and Dreams
H0mefile is a disabled led, online ensemble for home-based disabled musicians.
The research and development project focuses on creating an international online electronic ensemble for disabled and homebound people. H0mefile seeks to develop existing software and networking platforms to support disabled home based musicians to perform as an online ensemble.
The project takes a Universal Design approach to exploring the possibility of creating a software platform to facilitate a Networked (online) Ensemble for disabled musicians. In accordance with the Nothing About Us Without Us (Charlton, 1998) principle. I worked with a group of 15 professional musicians who are also disabled. The group gave interviews as to their perspectives and needs around networked music practices and this data was then analysed to look at how live coding software design could be developed to make it more accessible.
As Hamraie and Fritsch identify, disabled people are always having to navigate barriers, change the way they do things, find a loophole that they can use to get the services that they need, and adapt objects and instruments to suit their needs.
Disabled people are experts and designers of everyday life (Hamraie & Fritsch 2019:2).
With this in mind it makes sense to consult disabled people about how things might be done differently. Disabled people are able to spot issues and come up with solutions for how things could be improved both for themselves, and wider society in general. By treating disabled people as experts in their own lives we also position disability as a site of knowledge production and not a deficit.
This project takes a similar perspective, in that the disabled users will have the experience to be able to identify what the technological environment will need.
We also identified key messages for the wider design of digital musical instrument makers, live coders and performers to improve practice around working with and for disabled musicians.
H0mefile aims to use networked technology and develop an accessible live coding ensemble for disabled professional musicians. This software was developed in conjunction with home-based Disabled people to ensure their needs are built into the development of the project. H0mefile aims to create an online application which disabled home-based people can use to take part in live streamed performances, both online and in conjunction with musicians in a venue.
Why is this project needed?
I am a disabled artist who is often unable to undertake performances because my health does not support me in travelling away from home. I wish to develop new resources and tools to support other musicians in this position to be able to collaborate and perform together and with other ensembles.
Disabled people who are home-based very rarely have to opportunity to take part in music making with others. This could be for a range of reasons, including instruments and technology not being accessible, groups being unable to gather together, and live networking platforms not being suitably straightforwards for people to use without significant training (I will look at this later in the chapter). I aim to research the needs of homebased disabled musicians and find a platform which allows them to make music in a way that suits them. The technology will be influenced by their design and as such they will have the opportunity of influencing a product design and shaping it to fit their needs.
Disabled Access has often focused on bringing Disabled people into spaces, but this is not accessible for people who’s condition requires them to stay home for reasons of mobility, pain, fatigue, medication routine, the need for a carer to be present to help prepare someone to leave the house, the need for medical or mobility equipment, or caring responsibilities. As the networked art world develops we have seen a rise in live coding environments which are performed online (for example, I perform with OFFAL, the Orchestra for Females and Laptops – we are based worldwide and collaborate live online in performances). The home-based disabled community has used social media and life online to broadly develop their social lives and their campaigning reach.
For example, Katie Ellis talks about how the use of You Tube allows disabled people to form communities of interest online and use that power collectively.
New participatory media such as YouTube has seen a realisation of this vision. The platform has afforded people with disability a new voice, a way to tell their stories and force the nondisabled world to take responsibility for systemic ableism. (Ellis, in Brabazon, 2012)
In this way it creating a platform which supports home-based disabled musicians to collaborate live online becomes an extension of that community, and offers an extension that empowerment.
I also aim to reach and influence technologists who are making systems which could be adaptable to disabled musicians and artists. Much of our technological work could be designed accessibly but coders lack the sector knowledge and skills to make it accessible. These technologists will be hearing directly from disabled people about how their work could be made more accessible. For many this will be the first opportunity they have had to work with disabled people and to understand design from this point of view. This project is also about providing information and support to those making networked systems to encourage them to incorporate disabled access into their work.
Dreams and Possibilities – a manifesto
· We would like to see action from the Live Coding community to listen to the needs and concerns of disabled musicians around the making of live coding musics and platforms.
· We would also like to see the community provide learning opportunities for disabled musicians to learn live coding and software development.
· We would like to see disabled access built into the core of music technology software.
Disabled Access and Universal Design – Why disabled people must be at the heart of developing technology
The extension of the social model approach is the “nothing about us without us” concept (Charlton, 1998). which holds that those for whom a service, system or environment is designed, must have a contributing say as to its design. By incorporating diverse voices in the design of something, we can more reasonably design something which fits those it will serve. This work is explored by Jutta Treviranus in her work on Universal Design. (Treviranus et al., 1992).
The first principle of Universal Design, is Equitable Use, and is broken down into the following four categories.
- “Provide the same means of use for all users: identical whenever possible; equivalent when not.
- Avoid segregating or stigmatizing any users.
- Provisions for privacy, security, and safety should be equally available to all users.
- Make the design appealing to all users.” (Trevaranus et al., 1992)
The next logical step to Universal Design is the concept that everything that is made, should be made by a wide range of people for the full range of people. In this way we can ensure that we turn made for, into made by. By incorporating this into our design we can avoid cultural appropriation, perpetuating stereotypes, assumptions, supremacist perspectives, and oppression.
An example of where this was not the premise of the design is the recent development of the SignAloud gloves, made by students at the University of Washington, which claim to interpret sign language into spoken text has met with a negative reaction from some d/Deaf communities (Erard, 2017). Academics from the d/Deaf community criticised the gloves for a number of reasons. Firstly, that the gloves only interpreted alphabetic spelling, which is a tiny part of sign language, secondly that the hand and finger movements are just a small part of signing more widely, which uses facial movements, mouth movements, and eye movements as a part of the language. Thirdly, and most importantly, philosophically, the gloves reinforce a notion that d/Deaf people’s communication is a thing which needs to be solved for non signers, and puts the responsibility for that back onto the signer, to buy, train and use the gloves for the benefit of the non-signer. This was seen as cultural appropriation and an ableist supremacist approach[1] to technology and disability. If d/Deaf people had been included in the conceptualisation of the project, and if the makers had read disability studies literature, and understood disability culture and politics, this could have been averted. Something more equitable and useful could have been created.
From a development point of view then, it is vital that approaches to disabled technology come from the community, with an equitable approach, rather than to fix a problem perceived by the non-disabled community. By designing in collaboration with disabled people, we make ensure we make something which is actually desired, and in a way which does not ‘other’ the disabled experience. We can make something which is more flexible, and by default, also works for a broader range of non disabled people.
‘Technologies and innovations designed to improve access by the disabled actually enhance access for all users’. (Ellis & Kent, 2008)
One example of this kind of thinking comes from The Inclusive Design and Research Centre’s project Co-designing Inclusive Cities which
“…offers citizens a way to actively participate in the iterative design and growth of communities that meet their needs. Including the most unique and diverse needs—the “edges”—in the co-design process is an effective strategy to ensure our design stretches and responds to a broader range of needs. If we reach the edge, the design will also work better for the centre and will be more flexible and generous”. (IDRC 2019)
It is this co-design which we can import to music technology, and specifically Live Coding in order to make it more flexible, robust and inclusive.
The Plan
Stage 1
I began by reaching out to home-based disabled musicians worldwide using social media (disabled Twitter, Facebook, Instagram). I undertook 20 online interviews FIND THEM with home-based disabled musicians to explore their approach to making music, their requirements from a music making applications (How should it be laid out? What platform works best? What controller adaptations may be useful? etc.) their requirements for learning and work-shopping ideas (How long can they concentrate for? How long can they control the software for? How best to communicate during the workshops?), and their requirements for performance (Can they do real time? Would they need to pre-record aspects of the work? How long can they perform for? etc). [1]
Stage 2
I then took this data to the Networked Imagination Lab in Hamilton, Canada. This was the world leading centre at the time for creating networked (online) art collaborations. I worked with them to try to adapt their platform Estuary to make it accessible to the home based disabled musicians.
Estuary is
A browser-based collaborative projectional editing environment built on top of the popular TidalCycles language for the live coding of musical pattern. (Ogborn et al., 2017)
It was chosen for this project as it has
A server-based network collaboration system that can be used for many simultaneous collaborative live coding performances, as well as to present different views of the same live coding activity (ibid).
As Estuary has been designed to allow online collaboration, and also has various ways of visualising and creating the code, it seemed to fit our criteria for something networked and flexible.
The plan was to create a functioning prototype, and then to connect virtually with the home based disabled musicians to support them in using and learning the technology (workshop 1). Following their feedback there would be series of adaptations, workshops and feedback until we had a platform which works for the group. (For reasons outlined below this plan changed somewhat).
Stage 3
I would then support the group in exploring modes of performing with each other using live coding free improvisation techniques (workshop 2). Once the group had had some rehearsal time (final rehearsal = workshop 3), I would negotiate a performance for the group. The reason that the performance was not set from the beginning of the project was that I did not want to put anticipation of performance onto the performers. I wanted them to encounter the workshops as something that they could experiment in, make mistakes in, and feel safe in.
The three aspects of the project
1) Interviewing and establishing the needs of home-based disabled musicians.
2a) The development of a live coding platform which is accessible to home based disabled people.
and/or
2b) The development of a system to allow live networked performances.
3) The development of a community of home-based disabled musicians who want to perform together.
Desired outcomes
The project had a number of desired outcomes:
1) To provide access and opportunities for home based disabled musicians to collaborate and perform live online.
2) Reframe disability access from physical access to venues, to contributing from home. Currently housebound people are at the fringes of disability theory and there does not exist an online collaborative musical programme for disabled musicians. I aim to move beyond the approach of bringing disabled musicians into spaces, and begin to think about how networked technology creates an opportunity for disabled and housebound musicians to create a space for themselves.
3) To ensure that work is disabled led and embedded in disabled theory, flipping notions of abled technologists enabling disabled people. It was vital that this project was disabled led. My involvement will help to undermine notions about abled technologists providing opportunities for disabled people, and my theoretical perspective will help to sow seeds of interdependence, cooperation, anarchic structures (bottom up and relevant to those taking part (see chapter 2, Bar-Yam). This ensures that the structure of the project is embedded in disability theory, rather than structurally conservative with disability added on as an afterthought.
4) To influence newly developing technology with disabled theory. This project represented a huge opportunity to influence a cutting edge international project with a practice based in disability theory. This is increasingly important in a field where much of the funding and profile for disabled music work is not disabled led or grounded in disability theory.
5) To reframe home-based disabled people as active musical collaborators
There is very little research around housebound people being active musical creators, with the view being that housebound people are mainly interested in care and social support rather than negotiating an artistic practice.
This will influence my future work in a number of ways
I had a number of reasons for wanting to undertake this project. Firstly, the interview process would increase my network of disabled collaborators, peers, advisors, mentors and friends. Being a disabled composer in an abled world can be incredibly challenging, building a network of other musicians with similar life experiences would be be valuable to my research and mental health.
Secondly the opportunity to Work in Canada and establish a network of international performers would enable me to make contacts in many other countries, and explore performance and residency opportunities in those countries. I would be able to share the learning from this project withother organisations wishing to work with home-based disabled artists, and build a strong understanding of how to develop projects for disabled and home based musicians.
Creatively, I felt that working with technology artists who have more developed coding skills that I had would improve my basic coding skills and give me a whole new platform for making music and sound.
Why Live Coding?
In this project I began by specifically focusing on live coding as a way of exploring disabled networked performance, building on a recent strand of live coding research that considers diversity from various angles (Skuse & Knotts, 2018; Ocelotl, N. del Angel, & Teixido, 2018; Armitage, 2018). By making this work about live coding, I had the opportunity to design things from scratch. Coding is Design. When we code something we make it new from scratch, and we can make it to suit ourselves. This allows us multiple levels of engagement with the Universal Design movement, which can support disabled people in making their own technology, and having access to the skills to adapt it as they see fit. This shift in power from the made for to the maker means that Disabled coders can be at the forefront of countering (potentially unintentional) ableist music making. As described before, when abled tech is made for disabled people, many assumptions and ableist approaches are unconsciously brought into the project. If disabled makers are developing the technology the potential for the project to be based on an ableist premise (i.e. that sign language needs to be translated for hearing people) is less likely to occur. In addition to this, if disabled people are able to make their own technology, they are able to identify their own needs, and address them without being reliant upon an abled person to ‘rescue’ them. They are also equipped with the skills to update and fix their equipment should it be needed. (More on this issue later in the chapter).
There are also a number of key connections between the concerns of live coding research and those of disabled studies. Firstly a focus on open source software responds to a major concern for disabled artists: the costs of software purchase, maintenance and deployment to diverse computing platforms. Secondly, live coding can often be accomplished without a requirement for specific hardware such as MIDI control surfaces, whose buttons, faders and pots can cause difficulty for disabled people with motor control issues or upper limb difference. Thirdly, and conversely, live coding’s use of alternative and diverse programming interfaces connects readily with the use of additional hardware, such as eyegaze and headmouse controllers, that might be required by people with particular needs and preferences. Fourthly, live coding often takes the form of networked performances using a shared media surface. This means that coders send their music as code and the central host computer then creates sound from the code. Moreover, when such networked systems transmit code rather than sound, bandwidth requirements are reduced substantially, making them useful to home-based Disabled artists, cutting down on latency in the system. This can be an issue for musicians as each person’s ‘lag’ (latency) will be slightly different. Making music with a beat can be difficult when each person’s music is delayed by a differeny amount of milliseconds.
Finally, the work of the Live Coding community in breaking down expectations about performance and audience (for example watching someone code is a relatively new progression in terms of gig expectation) can create an opportunity for us to rethink how performance can be made more Disabled, for example how can we present the artist without them becoming some form of curiosity (as discussed in chapter 3) and how can a disabled person contribute from home?
Networks and online presence continue to be a powerful and revolutionary tool for the Disabled community (Pearson & Trevisan, 2015). There are obviously important concerns around surveillance, facial recognition technology, racist algorithms, and oppressive regimes (Umoja Noble, 2018; Eubanks, 2018). However, on a very simple level, Disabled people with limited mobility, or with limited income are able to meet, support each other and undertake activism online (Berghs et. al., 2019). We are still subject to these oppressive technologies of course, alongside trolling, hate speech and negative representations in social and traditional media. But, we are also free from bodies and minds which do not easily meet and communicate in person, or from bodies which would be a distraction or form a spectacle for the audience. (See Chapter 3).
Often the validity of someone’s voice is judged alongside physical judgment such as gender, race, body shape and size, body differences or vocal differences.
Persons with a disability[2] … are often marginalised by society and given limited, if any, decision-making power. (Goethals et al., 2015)
When typing online it is harder for people to make judgments about what we say based on how we look.
The tension between Merleau-Ponty’s phenomenology of having a body being the way that you have a world, and Harraway’s cyborgian existence complicates the question of what it is to be a disabled person. (As in Murray, 2018). Are we less disabled when behind our computers? If the physical barriers are removed, then attitudinal barriers may remain. But working in a networked environment, online, allows us to be more cyborgian, and less of a spectacle.
In this way, networked activity offers a means of collaborating specifically useful to home based disabled people. In this case the question of the impact of networks can come down to ownership, authorship, and agency—whose algorithms are these? Who do they represent (and fail to represent)? How do users have control over changing how something works, understanding how their data is used, and governing its use and aggregation. So again, by shifting made for to made by we have the opportunity to address power imbalances, structural oppressions and bias.
What we did
In order to reflect the principles of Universal Design, and ensuring that the users had as much influence on the process as possible, I interviewed disabled musicians to find out their requirements and then attempted to design systems according to our findings.[3]
The interviewees
The interviewees represented a wide range of disabled musicians, and also included two non-disabled academics who work in the fields of adaptive music technology and live coding (one of these academics has lived experience of being disabled, but they do not currently identify as disabled). The group of disabled musicians included a range of backgrounds and experiences, from acoustic performers who had limited experience of working with music technology to those who have performed as live coders.
The interviewees also represented a range of impairments, racial identities, genders and sexualities. This was explicitly chosen as a strategy as to not foreground a white male perspective. (As discussed in previous chapters, a wide range of perspectives is required to design something which works for a wide range of people). As the pool of ‘disabled musicians who are interested in networked performances’ is currently a particularly small group of people, I was unable to be as diverse as I had hoped.
Image Caption: A Venn diagram showing intersection groups. Three circles are labelleddDisabled people, coders and musicians. The intersection between disabled people and coders, is labelled disabled coders, the intersection between disabled people and musicians is labelled disabled musicians, and the intersection between musicians and coders is labelled live coders. The small intersection between all three circles reads disabled live coders.
However our group was reasonably mixed. Disabled identities included limb difference, mobility issues, hypermobility, stroke recovery, d/Deaf, M.E., Diabetes, Schizophrenia, Autism, and ADHD. 2 Interviewees identified as black British, 2 as British Asian and the rest as White. 9 interviewees were male and 6 female.
Findings
Findings from the interviews show a wide range of preferences, requirements and adaptations. Those requirements broadly fell into four categories, physical adaptations, communication preferences (partially sighted / d/Deaf etc), fatigue requirements, and social interaction. I mention this because physical adaptations and communication preferences are often foregrounded in disabled access projects. Fatigue requirements, and social interaction are less commonly considered.
The paragraphs below show the different responses to the questions which were put to the interviewees.
Hardware
There was a roughly even spread between those who favoured the use of a computer and those who preferred to use a tablet or phone, with some saying that they would often switch between the two. Preferences for using a computer included the larger screen size being easier to view, the keyboard being easier to control than a touch screen, that there is more control over connecting different applications, and that it is easier to plug in adaptive hardware such as Eyegaze or Headmouse. Preferences for tablets and phones included being easier and lighter to transport, that the touchscreen is less impactful on hands and wrists, that the touchscreen allows interaction for those with less motorcontrol, and that they are generally cheaper to purchase than a computer.
Design and Display
The majority of interviewees requested that an electronic music environment’s colour scheme and display be customisable, with users able to choose their own background colour, font type, size and colour. In addition to this, interviewees requested that the different elements of a user interface or display are placed in separate windows which can be moved around the screen, resized, and zoomed in, or out.
This reflects a networked community perspective where each individual is able to define the circumstances in which they work best. By providing customizable design and display we give each person (not just disabled people) the ability to create their own workspace.
One of the interviewees controls his computer with a Headmouse, using his tongue to move the curser and blowing into a tube to click. The Headmouse has no double click or right click function, and in order to right click (or ‘ctrl click’ on a mac in his case) he has to request his assistant to hold down the ctrl button. For this user it is important that there are no double click or right click actions. In order to type he has to select a screen alphabet and click on each letter, this is a slow process. For this user, typing proves problematic and laborious so alternatives to typing should be available (voice to text for example).
Barriers to engaging with new music making software
One of the key barriers to engaging with music technology was cost, a place where the open source live coding community have already made significant inroads. There were also concerns around whether using computer coding to make music is a ‘real’ musical activity, and whether it would be seen as such in the community. Another barrier was the time it would take to learn a new approach to music making. Many disabled people have pain and fatigue conditions, or require care which can be slow, which means that they have less time to function on a daily basis. They may only be able to concentrate or cope with the display screen or controllers for 10-20 minutes a day. This means that it is important that results can be heard after a relatively low amount of time working with the software.
In addition to this requirement, two of the interviewees told me that many disabled music technology applications have a limited progression, which does not allow for continued growth and learning. So although the research shows that the disabled musicians would like to see results fast, they would also like there to be the opportunity to grow with the software and increase complexity as they learn.
Some of the musicians raised the issue of unnecessary technology being made for the disabled community without their consultation. As discussed above with the Sign Language Gloves.
A further barrier was raised around the issue of updating and fixing problems. Much software for disabled musicians is made specifically for disabled people by individual developers and university departments as part of a unique project. However there is limited budget and timeframe for these projects once the software is built. This then leads to issues when the software is no longer compatible with the latest updates, or the disabled person accidentally changes a setting that requires in depth knowledge to fix. This leaves the disabled person having invested time and learning into software which has an in built obsolescence, and leaves the disabled people dependent on the person who built it to find the time and resources to fix the problem. This also leaves the disabled musician unable to take any music work while the issue is resolved. This issue of bespoke software is that it requires bespoke support which is rarely available. Therefore, there is a preference for mainstream software to be made disabled friendly so that it is regularly updated as standard.
Another barrier was the perceived difficulty of learning to code computer music, and a gap in knowledge around what live coding is. In some cases it was considered as an activity where the musicians would have to start from scratch and was only suited to programmers or coders.
Preferred methods of learning new software
Methods showed a diversity of preferences, with the majority wanting to learn by trial and error, with help files to refer to as support. The quality and accessibility of help files was brought up by at least half of the interviewees as an issue for learning new software. Our interviewees told us that help files must be written in clear language, in an accessible font and be consistent throughout the programme.
A small minority preferred to use video tutorials, but with the stipulation that these should be scripted, structured, captioned and have thumbnail previews to enable the user to skip through to the section they require. Video tutorials should show the actions at the same time as the explanation, along with clear captions. The view of the screengrab must be clear and legible. Interestingly, those who preferred video tutorials were also the people who had the most experience of working with music technology and live coding. It is possible that this correlation shows that video tutorials are currently more accessible for those with background knowledge and / or confidence in the field (although more research would be necessary as this is a small sample size).
Only one person said that they would prefer to have someone help them on a one to one basis, with two expressing that this would be their absolute last resort due to social anxiety or communication barriers. Three said that they would find an online workshop situation difficult due to social anxiety, attention span or communication issues.
Accessing forums for support was also considered to be challenging for reasons of social anxiety and a fear of being dismissed or undermined for asking ‘stupid questions’. It was also raised that often the responses received in forums can be either incorrect or overly complex, leading to frustration. Finally, there were comments about how forum environments can often be challenging for those for whom social interaction is difficult, and can lead to arguments or ‘flaming’ due to confusion over the tone of a comment.
Forums can also be difficult to navigate for certain users.
Blind users stated that they often had an arduous and frustrating interaction experience while consuming conversation threads, mainly due to the highly redundant content and the absence of customization options to selectively view portions of the conversations. (Sunkara et al., 2023)
What would a disabled friendly gig look like?
The response to this question showed a range of requirements and preferences amongst the group. As discussed in Chapter 2, access riders should be sent, and the venue or host should take the requests of the disabled person into account when planning the event. Other suggestions included, in a live environment where the performer was present, most welcomed a quiet or silent space where they could relax before, during and after the gig. It was also mentioned that many chill out rooms tend to become appropriated by groups and their focus changes from quiet space to an alternative music or VIP space. One of the musicians said a private space for people to go to if they needed space and quiet would be good for the general audience too.
There were also requests for healthy / diet appropriate food and drinks (for those who have allergies and intolerances) and sugary foods and drinks, or sugar free food and drinks (for those with diabetes). Many venue spaces are mainly stocked with alcohol, caffeinated and sugary drinks which people with a wide range of disabilities need to avoid. Food was another issue, with many disabled people experiencing food intollerances, allergies or digestive issues, food can be difficult to source on the high street outside a venue. Alternatively many disabled people find that they don’t have the energy, or the ability to go looking for food between soundcheck and a gig. The preference was for food prepared specifically according to the access rider to be provided by the venue.
A flexible approach to programming (the running order) was also considered desirable, with musicians having the ability to rearrange their performance order, or slightly adjust times based on how they were feeling. However, one of the musicians said they needed a clear structure and knowledge of what would happen in which section, and how long each section would be.[4]
Other musicians asked for relaxed performances, where the generally accepted protocols of attending a concert were suspended. One of the musicians said that he would prefer to blend into something which had already started and then drop out when he felt he needed to. For him, arriving at a specific time and being ready to perform was a huge anxiety trigger.
Four of the musicians liked the option of being able to pre-record something and send it in advance in case of illness, and 3 of the musicians said they would prefer to perform in the venue, but would like the option of a networked performance if they were unable to make it in person.
In addition to these specific needs, all interviewees agreed on wheelchair accessible venues, captioned performances, signing translation, ear plugs and remote access.
What issues are there around performing live in a networked ensemble?
Many of the performers cited a lack of eye contact and visible communication between players to be a major concern in playing in a networked ensemble. Others were concerned about computer latency, and internet speeds. Concerns around latency were also expressed in terms of hearing back the ensemble playing out of sync with your own playing.
Preference for a networked ensemble or live coding ensemble
Three musicians said that they would prefer an opportunity to perform via network with other disabled musicians using their existing musical set up. Four musicians said that they were currently interested in finding out more about live coding and being part of a live coding networked ensemble.
Implementing Findings
These responses lead to two specific channels of development, firstly, what changes could we make to live coding software, which would support disabled people in becoming part of the community? Secondly, how might we change our working practices to accommodate disabled people in ensembles and performances (both networked and in person)?
Software Design Messages
1. The need for complete flexibility of layout, design and display, allowing people to create a workspace which works for them.
2. The need for the software to deliver musical results quickly, but also allow for ongoing progression and development of skills and complexity.
3. The need for well documented, plain language, accessible help files.
4. The need for captioning and scanning through video tutorials.
5. The need for the software to be accessible on both computer and tablet, with the option of using assistive hardware such as Eyegaze or Headmouse.
6. The need for disabled access to be fundamentally a part of the main software to reduce issues around updates and obsolesence.
7. The need for more disabled people to be involved in design and making of their own technology rather than acting as focus groups for Abled makers.
Changes in Working Practices
1. Learning and development in the disabled musician community around Live Coding, and approaches to making music in this way.
2. The need for performers to be able to dip in and out of obligations depending on their circumstances, without this being seen as a negative by others.
3. The need for live performances to be flexible, relaxed, with appropriate rest spaces, hydration and nutrition available.
4. The need for there to be a mapping document showing what will happen and when.
What Happened on the Project?
Technical Issues
There were several outcomes from these findings which meant that the project needed to take a different direction. Firstly, As Estuary stood, the tutorials were not functioning and there were no help files. This meant that even for a non-disabled person it was challenging to engage with the programme and begin making music.
Secondly, as Estuary has been built layer upon layer by various coders, it is not easy to remake some of the features. For example, creating a display which was customisable would require going through hundreds of pages of code and rebuilding each one. This led to one of the major challenges of the project.
Conceptual and Political Issues
The question of display led us to a major discussion around how much accessibility should and could be built into Estuary. There was considerably hostility concerning the “demands” of disabled users, and how much that would cost in terms of time and financial burden. There was a request that we go for “low hanging fruit” in that, we just choose a few of the things we could change easily, or compromise on some. So for example, rather than having a fully customizable display, we just make a few different presets to choose from, perhaps taking into account the specific needs of our users. There was also a suggestion that we could make an easy version of Estuary which would work for the duration of this project but wouldn’t necessarily be adopted into the main programme or updated over time.
However, these suggestions were entirely at odds with the approach of the project, which is to be disabled led, inclusive, universal, and to listen to the disabled community. The suggest that we tackle a few “long hanging fruit” seems to suggest that we can ‘half do’ disabled access, as long as it is convenient. This leads us to one of the core issues around disabled people and capitalism. Namely that when we build something to be financially viable and hence to be ‘productive’ as a company we can choose a set ‘norm’ to design for in order to streamline costs and to be able to mass produce objects (As described in Foucaults BioPower in Chapter 3).
Once we have established the ‘norm’ for which we design, any deviation from that becomes expensive and time consuming. It then refracts the ‘problem’ back onto the disabled people who are seeking the ‘adjustment’. It is this mode of thinking which creates the notion of ‘low hanging fruit’. The mode of thinking that disabled people are costing us extra by their existence, and that we can only attempt minor alterations to our existing structures and processes.
When we begin to consider disabled people in terms of the networked organisation, we are imagining flexible systems made by and for those involved. This runs counter to the capitalist narrative that we streamline production in order to maximize the number of units produced.
By suggesting that we create a few display presets to suit the specific needs of our users we are also running counter to the idea of this being fully customisable, something our disabled users told us several times. The disabled participants are aware that each user will have different needs, and must have control over their display and design. A rejection of this from Abled people is a failure to listen to the combined knowledge of the disabled community. If we make a few bespoke display presents tailored to the needs of our specific participants, we are still excluding those who are not currently a part of our project. We have not solved the problem, merely postponed it for another cohort to encounter.
Finally the suggestion that this version of Estuary would be solely for this project, not be a major inclusion to the main programme and not necessarily maintained beyond this project was again in direct contradiction to our findings. Our findings told us that disabled access should be at the heart of the main programme and should be easily updated alongside the main programme. Creating a disabled silo which becomes unusable at some point after the project, wastes the time invested by the participants and is contrary to our aim for the project.
At the heart of these project specific issues were two key issues which reoccur within disabled access discussions. Firstly, a fundamental resistance to listening to disabled people and acknowledging their wisdom and experience as valid.
Disabled people, as users of designed technology, are systematically discounted as non experts whose knowledge is not worthy of compensation or recognition (Hartblay, 2020)
Secondly, a tendency to see disabled people as an exception, a problem, for which ‘easy win’ solutions can be made, rather than foreground the design flaws which have created inaccessibility as the problem. The inconvenience of changing the system is seen to outweigh the inconvenience of the disabled person being excluded by the system. In this situation we have to question whose inconvenience is seen as more important, and why that might be.
The other fundamental issue which came up was that the disabled musicians I interviewed were not particularly interested in Live Coding. This was for a number of reasons, firstly that they had worked hard to perfect their musical set up and were happy using it, they didn’t want to have to learn a whole new skill, secondly that live coding required typing which they found difficult or painful, thirdly that they didn’t see the musical value in coding, and fourthly that they found the interface too confusing to work with.
This seemed like the absolute key to changing direction with the project. As the research was to be disabled led, I must listen to my interviewees. They didn’t want live coding particularly, they wanted a streaming platform which would allow them to collaborate from home using their existing expertise in their own performance setup.
Having considered these positions, resistances and preferences it seemed like a new direction was needed, with a new partnership based in disabled led inclusive design.
The Inclusive Design research Centre at OCAD
I then connected with the Universal Design Research Centre at OCAD (Ontario College of Art and Design) to make or find a software system which would allow networked performance from a wide range of disabled musicians on various platforms using various music programmes.
Collaborating with Shelly Knotts (datamusician.net ) and Colin Clark of IDRC we explored the ICESTREAM software used by G.I.A.S.O. (Great International Audio Streaming Orchestra) and OFFAL (Orchestra For Females and Laptops). However the set up can be quite technically complicated and we felt that this might not be accessible for our users.
Icestream was designed as a radio streaming platform and was adapted for use as a mulxistream player by artists Jenny Pickett and Shelly Knotts. Icestream’s downloadable programme is built for a linux system, which means that our players would not be able to download or use it as they all use Mac or Windows.
Only one player – preferably at the venue – needs to be the host, running Icecast to receive the streams. This person however, needs to be running Linux and have considerable technical ability.
In her work with Icestream Shelly Knotts avoided the Linux issue by using a remote server set up by Holger Balweg specifically for the purpose. She then uses command line to manage all the connection streams from the ensemble players. This requires running a separate Terminal window for each player, manually connecting their streams, and monitoring multiple windows during the performance.
As Icestream was designed to be a radio stream, it sometimes struggles with multiple streams and drops the streams. This means that Knotts is constantly monitoring the streams to notice is anyone has dropped from the system. She then needs to reconnect manually whilst performing herself.
In addition to this, each player has to download BUTT software and programme it to send their audio stream to Knotts. Although this is relatively simple, it is certainly not without frustration or error. For example, in all my performances with OFFAL I have never been able to hear the ensemble playback despite adjusting my settings on BUTT. This could be incredibly stressful or confusing to those for whom live streaming and improvisation is a new practice.
Icestream also only sends audio and has considerable latency as a result. The players need to compensate for the fact that what they are playing will not be heard for several seconds, and what they are listening to is not in fact what will be playing when their contribution is added.
Finally, Icestream requires each player to use a routing software such as Jack or Blackhole to route their audio from their system into BUTT rather than the usual options of speakers, headphone outlet or soundcard / interface.
We then looked at Olivia Jack’s LiveLab (https://ojack.github.io/articles/live-lab/index.html). Live Lab is an
Open source, browser-based toolkit for networked performance, that uses a peer-to-peer mesh network to share video, audio, and data streams between individuals and venues. (Jack, 2021)
For example, Livelab uses an online platform available in one browser window. This means that there is considerable reduction in complexity for the player who is ‘hosting’ the concert. Secondly as it is designed for multi streaming it is considerably more stable when attempting to do this. Thirdly, it does not require the players to connect via BUTT but directly through the browser, again removing complexity for the users. Livelab does require users to download and use routing software (Jack, Blackhole etc) but this is not a majorly complex endeavour and only needs to be done once. Finally, as the complexity is reduced, the latency is reduced. Livelab also has the possibility of sending code which is sonified at the ‘host’ computer, again reducing latency significantly.
As Colin and Shelly worked to explore Livelab they felt that there was still some work required to fit the requirements of our users. Our users are not the target audience for live streaming software, and do not have the high spec computers of many of those working in this field.
One key aspect of accessibility is affordability. Within music technology there is a tendency for development to sit at the higher end of technical processing power, using more and more powerful computers and creating more and more complex hardware. However, this tendency creates a barrier to those who are not financially affluent. Specifically this tends to impact upon people of colour, people of the global south, women, single parents and disabled people, as they tend to have less disposable income to purchase these powerful machines.
I issued a Survey Monkey asking about the technical specs of the systems our musicians were using. These were the responses.
| OS | OS Version | Device | Spec | |
| 1 | Mac OS | Mojave 10.14.5 | Desktop | 32ghz Intel Core I5 3.2ghz 16GB RAM |
| 2 | Windows | Windows XP | Laptop | 2.80 gigahertz Intel Core 2 Duo T9600 64 kilobyte primary memory cache 6144 kilobyte secondary memory cache, 3038 Megabytes Usable Installed Memory, |
| 3 | Windows | Windows 10 (and ios on ipad) | Multiple – desktop, laptop, iPad, often used with eye gaze software on Windows | Best one is 2.4 quad i5, 16GB DDR3 RAM, SSD, 4GB DDR5 graphics card |
| 4 | Mac OS | Mojave | Laptop | 1.3GHz Dual-Core Intel Core i5, 8gb |
| 5 | Android | Android 4.4.4 | Tablet | 8 GB total space, 120 GB Sd card, I don’t know where the other information can be found. |
| 6 | Windows | 7 | Desktop | I5 3ghz processor, 16gb ram |
| 7 | Windows | Windows 10 | Laptop | ????? Lenovo ideapad 310 |
| 8 | Mac OS | Mojave | Laptop | 2.3 intel core i9, 16GB |
It is vital that the process of this project needs to meet the vision for a flexible and networked structure. Because of this I not only interviewed people about their preferences for the technology, but in how they prefer to communicate and work together.
This may be that we have different groups with different working practices, or we find some way in which everyone’s needs are met. What it is important for me (as proxy “leader”) to do is to not assume a way of working just because it works for me, or because it has worked before, and indeed, not to assume that I will always be the “leader” of the group.
In order to try to find ways through this, I created an access rider document for each person. This document allows participants to outline any needs they may have around rehearsal or performance etiquette, communication needs or group behaviours. As a group we will then work to find a way to work which supports and respects each of those needs equally. Participants will be encouraged to let me know if their needs are not being met, so that we can strive for a solution.[5]This working practice will reflect a non-hierarchical networked structure, allowing for flexibility and non-judgmental responses to requests[JG1] [JG2] .
In terms of the methodology of the project, it would be disabled led, with the themes and desires taken from the interview group. Using the Nothing About Us Without Us principle, and Treviranus’ Universal Design Principle I would interview the participants about how they would like to see the collaboration designed. From these interviews I then draw up a document which outlines the needs and perspectives of the group. I am also drawing on the Networked Organisational model by decentralizing power, and supporting the ideas of the group in being taken forwards.
What happened next? – A Global Pandemic
We were in the midst of deciding up platforms which we might use to collaborate together. Our idea to create an online disabled improvising ensemble was gaining group, and starting to find ways that we might be able to work. We had also secured a performance at the Music And / As Process conference. Music and/as Process is a Royal Musical Association study group which hosts an annual conference, their aim is to
…bring together practitioners and researchers to discuss music that ‘performs’ process. Furthermore we are interested in the different types of process that are undertaken in and by music and creative work and situate process in music as different from compositional technique; a facet of the performance, experience, and the temporal dimension of music. (Music and/as Process (2024)
At this moment the global pandemic struck. This was a particularly interesting moment for disabled theory as suddenly much of the non-disabled world found themselves experiencing our existence. They were effectively having to live a disabled lifestyle, albeit without significant physical or mental health issues. As abled people were confined to their homes they were discovering realities of disabled lives. Their work options were limited, their socializing time was limited, there were a lot of places they could not go, the could not act on their desires to go somewhere and experience it (for example the beach, or a fun fair, or on holiday). They were also limited in their options for healthcare, with many health care centres suddenly becoming dangerous places to go, abled people had a short insight as to what it is like to be immunocompromised, and to have to be careful of infection everywhere they go. Their mental health began to suffer as they were not able to let off steam or see friends in the same way as before, those who lost their jobs or were put on furlough began to question their role in life, and, now that there were not a ‘productive’ member of society, whether their lives had any value. Society was suddenly concerned about what happens to your mental health when your social life is reduced to online interactions. [6]
Where previously I had called for greater remote access to gigs and festivals, and it had fallen on deaf ears, suddenly it seemed the whole world grasped the importance of being able to access the arts from their homes.
There was a scramble of artists seeking to collaborate online, such as the rendition of Imagine where numerous celebrities sang one line of the John Lennon song each and then pasted it into one video. However, as they had not agreed on a key or a tempo, and did not have access to a hone studio to add mastering effects to the vocals, it was roundly mocked as a creative output (both in terms of idea and execution). A more successful piece of work was “Staged” a British TV show which used the medium of Zoom calls between actors and their director as the environment for a sitcom. The actors were able to record their scenes at home, and then send to the production team to cut them together. One of the reasons that this worked in a way that a lot of the musical piece did not, was that acting has more leeway in terms of hitting the beat. It was however, constructed in post production, so any latency issues could be chopped out of the edit.
We can see from these two examples that some of the issues that we had been concerned with as a group, latency, technical spec, tuning and timing were becoming mainstream issues as a result of the Covid 19 Pandemic.
Interestingly from a perspective of the ‘normality’ bell curve, it seemed that the bell curve of what was now ‘normal’ had shifted. I found myself comfortably in the center of the bell curve, with a long-established practice of being isolated, working from home, missing out on events, unable to travel or take part in sports or festivals, and maintaining friendships remotely. People who had previously been reasonably comfortable in the ‘old normal’ bell curve suddenly found themselves to be uncomfortable, lacking the skills, knowledge or experience to exist in this version of reality. It was as if the abled became temporarily disabled.
From the point of view of the project it was like a tsunami sweeping over us. Where we had a handful of people with limited time and energy trying to work out how we might collaborate online, suddenly the largest tech companies in the world were racing to become the leading platform for online connection. So many approaches and practices opened up, with every musical ensemble ever created (it seemed) making online collaborations (many of which were actually faked by pre-recording and editing together).We knew from our research that there would be considerable lag, and issues of timing, but by recording each performance and layering it on top, ensembles we were able to make it look as though they were singing or playing together live using standard streaming software.
As we tried to explore how we might resolve the issue of latency, several options were proposed. Some users were lucky enough to have superfast systems through their university, meaning that they were almost able to remove the lag in their online collaborations. Other groups tried to use midi data sent as code to a host computer in order to collaborate live (in the same way as live coding, sending midi data is much smaller than sending audio and so removes a lot of lag from the collaboration). Some players used metronomes and then tried to sync via midi clock at the host end and some groups prerecorded sections then pasted them together at the host end.
These live music streaming developments were happening so fast there was no way I could keep up, considering that I have a fluctuating fatigue condition and was also trying to write an opera at the time. As an ensemble we decide to wait and see what options were developed then look at it as a group and decide which ones worked best for us.
The streaming options tended to be on a sliding scale from obscure to hugely commercial. Live online music collaboration has surged in popularity, with platforms catering to different needs. JamKazam and Endlesss prioritize real-time jamming, offering low-latency audio streaming ideal for synchronized performances, but they demand high-speed internet and meticulous audio hardware setups to avoid disruptions. Soundtrap and BandLab provide cloud-based DAWs (Digital Audio Workstations) for asynchronous collaboration, though their real-time capabilities are limited by latency, making live improvisation challenging. Ninjam creatively circumvents latency by looping and time-shifting audio, enabling “pseudo-live” jams, but its unconventional workflow may disorient musicians accustomed to natural timing. Video-call tools like Zoom or Skype are accessible for casual rehearsals, yet their heavy audio compression and lag render them unsuitable for precision. Meanwhile, JackTrip and Audio Movers cater to professionals with high-fidelity audio streaming, though they require advanced technical knowledge and expensive gear. Universal challenges include inconsistent internet stability, the “latency barrier” (even milliseconds disrupt rhythm), and the lack of physical presence, which can stifle spontaneity. While these tools bridge geographical gaps, they often prioritize accessibility over the nuanced, real-time interaction inherent to in-person collaboration.
Unfortunately only the hugely commercial platforms like Zoom and Skype included various accessibility options such as captioning. As we had two deaf musicians in our team, it was vital that the platform we used allowed for captioning, that is, creating live subtitles of the conversations being had on the platform. Despite these musical collaboration platforms which could be ideal for disabled home-based musicians springing up, none of them had thought to include features which made their platforms usable for disabled people. Even as abled people lived through a taste of what it was to be disabled, they failed to take disabled access into account when trying to innovate.
As a result of this, as a group, we used Zoom for our networked performance. This was because one of our players used transcription software called Otter, and Zoom was the only platform which allowed her to have captions on the screen. When we performed at the Music And / As Process conference there was a sense in the room that we had not been sufficiently innovative, or not used one of the bespoke music systems, or perhaps that we were not technically aware of the issues of using Zoom (which high end processors and specialist streaming musical programmes sought to solve) or perhaps we were not sufficiently politically aware of the data protection issues around using Zoom. Once again, we had to explain that we were using Zoom not because we were unaware of the issues with it, but because it was the only software which had thought to include the accessibility options we required.
Image Caption: A screenshot of a zoom call with Shelly Knotts, Amble Skuse, Clarence Adoo, Sonia Allori, Clare Johnson, Steph West and Eluned Charnley. This was the performance of the ensemble at the Music And / As Process event.
At the event we also used Eluned Charnley who is a live captioner. This was in addition to the inbuilt live captioning. Eluned’s role was to describe the music being played, so that the deaf & hearing impaired performers could play in the group. For example, Eluned would describe Steph’s harp music as “flowing water cascading down a forest on a sunny day” and this would give the performers the feel of the music to play. This is a technique developed between Sonia Allori and Eluned Charnley. Eluned Co-led the “Musical Vibrations” project, which investigates how deaf individuals experience live music through tactile feedback (vibrations) and visual cues (e.g., captions, light displays) and she advocates for multi-sensory accessibility. Sonia is a researcher at the Royal Conservatoire of Scotland and Collaborated on research into live captioning adaptations for performances, including integrating speech-to-text and visual rhythm displays. She also explores how lyrics and musical structure can be translated into visual formats for deaf audiences.
If only the technologists who were developing the streaming software had spoken to disabled musicians, or even better, had employed disabled coders to make the software. We could have used the global pandemic to create a platform for disabled musicians to collaborate online. As it was, we continued the pattern of abled people designing things which suit themselves and missing the opportunity to design something which is universally useful[JG3] .
[1] A full copy of the questions is available as Appendix ******
[2] In the USA, disability culture tends to use Person First language, so Person with Disability rather than Disabled Person. This is a cultural difference between the USA and the UK. I prefer the term Disabled Person as it reflects the social model, that Disability is something that is done to people by the way that society is organised, rather than something someone has innately.
In Claiming Disability: Knowledge and Identity, Linton talks about the difference between the terms “people with disabilities” and “disabled people,” Linton says these terms can distinguish between “maintaining disability as a secondary characteristic” and making “disabled … a marker of the identity that the individual and group wish to highlight and call attention to”. (Linton, 1998)
[3] The interview process was granted Ethical Agreement by the University of Plymouth Arts and Humanities Research Ethics Committee, and all data is held in compliance with GDPR, the UK’s Data Protection Act (2018).
[4] I provided one of these performance maps for a piece I wrote called Divergent Sounds. It specifically lets the audience know when certain types of sounds will happen so that they can prepare themselves should they wish to avoid certain sounds. It can be found here https://ambleskuse.net/divergent-sounds/.
[5] This is often a challenge when working with professional disabled musicians as they are used to minimising their needs in order to fit into the existing assumptions about what ‘professional’ might look like.
[6] Society had not been so concerned when it was disabled people confined to their homes, and disabled people experiencing the mental health effects of isolation.
[JG1]Th is is great. I wonder whether you thought about situating this in a design methodology?
There’s a couple of PhDs that you might want to look at on Pearl. Diego Maranan, not you field but a really clear way of situating the methods. And Norbert Herber: Amergent Music: Behaviour and Becoming in Technoetic and Media Arts.
Both might be worth a quick look at structuring and presenting this type of method//knowledge.
[JG2]`Posted this a few years ago, did you have a look?
[JG3]This chapter needs tightening up. See it as an opportunity to discuss expanded methods. Include aims and questions at the beginning, followed by methods, intention and outcomes. Set it out at the beginning so it solidifies the practice, and integrate disability theory too.