Desarrollo de una tiflo-aplicación para traducir partituras musicales a braille

DESARROLLO DE UNA TIFLO-APLICACI´ ON PARA TRADUCIR PARTITURAS MUSICALES A BRAILLE DEVELOPMENT OF A TIFLO-APPLICATION FOR TRANSLATING MUSIC SCORES TO BRAILLE ´ OSCAR D´ IAZ RIBAGORDA CLAUDIA GUERRERO GARC´ IA-HERAS LUCAS DE TORRE BARRIO DOBLE GRADO EN INGENIER´ IA INFORM´ ATICA Y MATEM´ ATICAS. FACULTAD DE INFORM´ ATICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo Fin de Grado en Inform´atica Junio 2020 Directores: Mar´ıa Guijarro Mata-Garc´ıa Borja Manero Iglesias 2 Agradecimientos Queremos empezar por agradecer a nuestros tutores Mar´ıa y Borja por ofrecernos la posibilidad de realizar un proyecto con implicaciones reales como este y de colaborar con una instituci´on como la ONCE. Gracias adem´as, por orientarnos durante el desarrollo de este trabajo y por instarnos a escribir nuestro primer art´ıculo para el congreso ICCE 2020, lo que ha resultado ser una experiencia enriquecedora. Tambi´en queremos agradecer a la ONCE por su propuesta y su colaboraci´on con el proyecto. En especial, a Pablo Carre˜no Gea por su gran ayuda en el desarrollo de la aplicaci´on LiveDots. Otra parte muy importante han sido los voluntarios que nos han prestado su tiempo probando la aplicaci´on y rellen´andonos las encuestas, muchas gracias. Por ´ultimo, agradecemos a nuestras familias por habernos apoyado y aguantado durante todos los meses en los que hemos estado trabajando en este proyecto, en especial durante los meses de confinamiento trabajando desde casa. Y por su apoyo y compa˜n´ıa durante toda la carrera que cerramos con este proyecto, gracias, Manolo. 3 4 Resumen La m´usica es una de las mayores formas de expresi´on que tenemos los seres humanos. Actualmente, la forma m´as com´un para representarla es el uso de partituras en tinta. Esta representaci´on es completamente visual, por lo que una persona invidente no puede hacer uso de ella. Por ello, existe la notaci´on llamada braille musical, que permite a las personas ciegas leer una partitura usando las manos a trav´es de un papel perforado o de una l´ınea braille. Sin embargo, el uso y modificaci´on de este tipo de partituras es m´as complicado que el de las partituras en tinta, algo que se pone de manifiesto en ´ambitos como las clases de m´usica o las orquestas. Con los instrumentos que hay hoy en d´ıa, modificar en tiempo real una partitura con notaci´on braille es m´as complicado que hacerlo en una partitura en tinta. Esto se debe a que existen programas que modifican partituras en tinta f´acilmente, mientras que los que modifican partituras en braille son m´as escasos y menos completos. Existen programas, como MuseScore (Schweer, s.f.), que permiten modificar partituras y otros, como FreeDots (Repain y col., s.f.), que las traducen a notaci´on braille. Aunque este sistema es ´util, es evidentemente lento en el contexto de una clase. Sin embargo, en otros campos encontramos soluciones de editores interactivos en tiempo real, como es el caso de EDICO (Carenas y col., 2018), editor de matem´aticas, f´ısica y qu´ımica desarrollado por la ONCE (“ONCE”, s.f.). Del ´exito de EDICO naci´o la idea de LiveDots, un editor musical interactivo en tiempo real. LiveDots es una aplicaci´on accesible que utiliza al mismo tiempo la representaci´on mediante partitura en tinta y mediante notaci´on braille. Permite la modificaci´on de la partitura en tinta, algo que cambia en tiempo real la notaci´on braille. Adem´as, es posible el uso de un revisor de pantalla para que vaya leyendo los elementos musicales de la partitura en notaci´on braille. As´ı, la idea de LiveDots es facilitar la docencia musical accesible. Por eso, realizamos un experimento a gente vidente para comprobar si LiveDots facilitar´ıa la inclusi´on de alumnos invidentes en clases de m´usica. Los participantes utilizaron la aplicaci´on dos veces, la primera con los ojos tapados y la segunda sin tapar. De esta manera, probaron la parte desarrollada para gente invidente, que ser´ıan los estudiantes, y la parte desarrollada para gente vidente, que ser´ıan los profesores. Durante el desarrollo de la aplicaci´on, comprobamos las diferencias entre dise˜nar una 5 6 aplicaci´on accesible y una no accesible, buscando en la primera que el uso sea posible sin necesidad de visualizar la pantalla. A partir de los resultados del experimento, comprobamos que LiveDots es una aplicaci´on accesible que podr´ıa facilitar la inclusi´on de estudiantes invidentes en clases de m´usica. Palabras clave: accesibilidad, tiflotecnolog´ıa, educaci´on inclusiva, m´usica, interactividad en tiempo real, WPF, m´usica braille, JAWS, revisor de pantalla, aplicaci´on de escritorio. Abstract Music is one of the major forms of expression that the humankind has. In this day and age, the most common way of representing it is through sheet music. This representation is completely visual, therefore a blind person cannot make any use of it. For that reason, there exists the notation called musical braille, which allows blind people to read a music score using their hands on an embossed paper or a Braille line. However, the use and modification of this type of scores are more complicated than that of the sheet music, something that is brought to light in situations like music classes or orchestras. A modification on a score with Braille notation is more complicated than a modification in a score in sheet music since the first one cannot be done in real-time. There exists programs, like MuseScore (Schweer, s.f.), that allow to modificate sheet music scores and others, like FreeDots (Repain y col., s.f.), that translate them to Braille notation. Although this system is useful, it is obviously slow in the context of a class. However, in other fields we find solutions of real-time interactive Braille editors, like the case of EDICO (Carenas y col., 2018), a mathematics, physics and chemistry editor developed by the ONCE (“ONCE”, s.f.). From the success of EDICO was born the idea of LiveDots, an interactive musical Braille editor in real-time. LiveDots is an accessible application that uses at the same time the representation in sheet music and in Braille notation. It allows modification of the sheet music, which changes in real-time the braille notation. Moreover, it is possible to use a screen reader to read the musical elements of the score in braille notation. That way, the idea of LiveDots is to make accessible musical education easier. For that reason, we made an experiment to non-blinded people to check if LiveDots would help with the inclusion of blind students in music classes. The participants used the application twice, the first time blindfolded and the second time without the blindfold. This way, they tested both the part developed for the blind people, which would be the students, and the part developed for the non-blinded people, which would be the teachers. Throughout the development of the application, we verified the differences between designing an application that is accessible and one that is not, making sure that the use of the first did not require screen visualisation. Following the results of the experiment, we confirmed that LiveDots is an accessible application that could help with the inclusion of blind students in music classrooms. 7 8 Keywords: Accessibility, tiflotechnology, inclusive education, music, real time interactivity, Braille music, WPF, screen reader, JAWS, desktop application. ´ Indice general 1. Introducci´on 15 1.1. Motivaci´on ..................................... 17 1.2. Objetivos ...................................... 18 1.2.1. Objetivos Iniciales ............................. 18 1.2.2. Modificaci´on de los Objetivos ....................... 19 1.3. Estructura de este documento ........................... 20 2. Estado del Arte 29 2.1. Uso de computadores por personas invidentes .................. 29 2.2. Docencia con aplicaciones accesibles ....................... 31 2.3. M´usicograf´ıa Braille ................................ 33 2.4. Editores musicales enfocados a personas invidentes ............... 36 2.4.1. Braille Music Editor ............................ 37 2.4.2. FreeDots .................................. 38 2.4.3. Dancing Dots ................................ 39 2.5. Otras aplicaciones musicales y de edici´on de partituras ............. 40 2.5.1. Audacity .................................. 41 2.5.2. MuseScore .................................. 42 2.5.3. Sibelius ................................... 43 2.5.4. Finale .................................... 43 9 16 CAP´ ITULO 1. INTRODUCCI ´ ON videntes e invidentes son ense˜nados usando diferentes metodolog´ıas que conducen a una dicotom´ıa entre el braille musical y la escritura musical convencional. La falta de familiaridad con la escritura musical convencional hace m´as dif´ıcil que los estudiantes ciegos se incorporen m´as tarde en entornos con m´usicos videntes, por ejemplo un conservatorio o una orquesta (Goldstein, 2000). Hay por tanto una necesidad de integrar a estudiantes videntes e invidentes en el mismo aula y ense˜nar a cada uno de ellos los conocimientos esenciales para desarrollar sus habilidades musicales (Quaglia, 2015; Buhagiar y Tanti, 2011). Es decir, queremos que los estudiantes ciegos puedan seguir una clase de m´usica con estudiantes mayormente videntes mientras aprenden la notaci´on braille musical y se familiarizan con la concepci´on musical de la m´usica en tinta tradicional. Algunas de las estrategias m´as utilizadas por los estudiantes ciegos o con discapacidad visual para facilitar la participaci´on en el aula son: partituras en tinta ampliadas, que una tercera persona (compa˜neros de clase, padres o profesores) les lea la partitura y el uso de braille musical siempre que sea posible (Frederick, 2009; Smaligo, 1998). Todas estas herramientas necesitan la ayuda de una persona que transcriba la partitura oralmente o de un profesor que conozca el braille musical y se lo ense˜ne al alumno, lo cual no siempre es posible. Esto hace que el estudiante dependa de las personas que lo rodean. Con el desarrollo de la tecnolog´ıa tenemos en nuestras manos la posibilidad de crear herramientas que nos ayuden a integrar la concepci´on musical de videntes e invidentes, facilitando as´ı aspectos como la integraci´on de alumnos invidentes y videntes en clases de m´usica o la colaboraci´on de m´usicos videntes e invidentes en una orquesta. Ya hay programas dise˜nados para que personas con discapacidad visual puedan visualizar y editar m´usica en notaci´on braille (Homenda, 2008), estudios sobre c´omo ense˜nar braille musical a ni˜nos mediante aplicaciones de ordenador (Borges y Tom´e, 2014) y programas que traducen partituras de m´usica en tinta a braille y viceversa. El avance de la tecnolog´ıa en los ´ultimos a˜nos nos ha dado la oportunidad de facilitar la integraci´on de los estudiantes ciegos. Existen proyectos como Braitico (ONCE, s.f.), un m´etodo de alfabetizaci´on en Braille inclusivo desarrollado por la ONCE (Organizaci´on Nacional de Ciegos de Espa˜na) destinado a que los ni˜nos aprendan braille. En el campo de la m´usica, ya hay programas inform´aticos para que las personas con discapacidad visual puedan visualizar y editar m´usica usando notaci´on braille (Homenda, 2008) como el BME, Braille Music Editor (Giuseppe Paccini, s.f.), estudios sobre c´omo ense˜nar braille musical a ni˜nos utilizando aplicaciones inform´aticas (Nicotra y Quatraro, 2008; Borges y Tom´e, 2014), estudios y aplicaciones enfocados a ense˜nar m´usica a los estudios de ciegos utilizando m´usica hablada en lugar de braille (Capozzi y col., 2012), aplicaciones de traducci´on de partituras de m´usica en tinta a braille musical y viceversa como FreeDots (Repain y col., s.f.) e incluso existe un est´andar para compartir partituras en notaci´on musical braille en la web llamado BMML, Braille Music Markup Language (Encelle y col., 2009). El problema de integrar a los estudiantes ciegos en el aula est´a presente en casi todos los campos de la educaci´on. Hay muchos enfoques diferentes para buscar una soluci´on, como Aim-Math, un sistema de aprendizaje de matem´aticas interactivo para estudiantes ciegos y con discapacidad visual que utiliza un sintetizador de texto a voz para leer en voz alta expresiones matem´aticas (Naruedomkul, 2013). Sin embargo, este enfoque no promueve la 1.1. MOTIVACI ´ ON 17 integraci´on en una ´unica clase de estudiantes videntes e invidentes. Otro enfoque es EDICO (Editor Cient´ıfico de la ONCE) (Carenas y col., 2018), un proyecto promovido por la ONCE y desarrollado en cooperaci´on con la Universidad Complutense de Madrid. Es un editor de matem´aticas, f´ısica y qu´ımica accesible. Traduce en tiempo real lenguaje cient´ıfico en tinta a notaci´on cient´ıfica en braille y viceversa. Esto permite a los estudiantes ciegos seguir una clase de ciencias interactuando en tiempo real con un profesor que no sabe Braille. Tras el ´exito de EDICO, la ONCE quiso desarrollar soluciones similares para integrar a los estudiantes ciegos en otras asignaturas, como la m´usica. As´ı naci´o la idea de LiveDots: un editor musical que traduce partituras en tinta a braille musical en tiempo real. 1.1. Motivaci´on Hoy en d´ıa, cualquier persona puede conseguir partituras para poder acceder a ellas m´as tarde. Esto resulta muy ´util para el aprendizaje musical, entre otras cosas. Por ejemplo, un profesor puede utilizar una herramienta de edici´on de partituras (como MuseScore oSibelius, entre otras) para crear unas partituras que permitan a sus alumnos practicar alg´un tipo de ejercicio concreto. Otra opci´on es, durante el desarrollo de una clase, proyectar una partitura para estudiarla. Desgraciadamente, estos sistemas suelen estar menos desarrollados para gente con discapacidad visual. En el caso del ejemplo anterior, s´ı existen programas (como FreeDots) que permiten traducir una partitura a braille y usar la l´ınea braille para su lectura y otros que permiten escribir una partitura en braille y traducirlas para su visualizaci´on (por ejemplo, Braille Music Editor, que permite escribir una partitura en braille y exportarla en un formato que otra aplicaci´on, como MuseScore, permite visualizar como una partitura en tinta). Una situaci´on t´ıpica durante el desarrollo de una clase consiste en que el profesor proponga un ejercicio (supongamos de crear una partitura) para posteriormente corregirlo. Sin embargo, un profesor de m´usica vidente no tiene porqu´e saber braille. El alumno entonces puede usar un programa para escribir su partitura y traducirla. Despu´es, el profesor podr´a leerla, corregirla y escribirla en un programa para traducci´on de partituras a braille y, as´ı, finalmente, el alumno tendr´a su partitura corregida. Aunque este m´etodo funciona, es claro que no es pr´acticamente nada interactivo, porque ni el profesor ni el alumno tienen acceso a las creaciones del otro hasta que son finalizadas. Se podr´ıa decir que, en este caso, la relaci´on profesor-alumno tiene un componente epistolar, ya que, hasta que cada uno no acaba su “carta”, el otro no puede leerla y escribir la suya. Con este ejemplo se pone de manifiesto que resulta realmente complicado que alumnos con discapacidad visual se sientan incluidos en una clase de m´usica, ya que hay muchas actividades en las que no pueden participar. Es por eso que resulta necesario un sistema que permita aumentar su participaci´on y, con ello, su inclusi´on en la clase. Otra situaci´on se da en el ´ambito profesional de la m´usica. Por ejemplo, es mucho m´as 18 CAP´ ITULO 1. INTRODUCCI ´ ON complicado integrar a un m´usico con discapacidad visual en una orquesta ya que los cambios o adaptaciones que realice el director de orquesta en una partitura en tinta deber´an ser traducidos a braille para que este m´usico pueda leerlos. Esto tambi´en ocurre con las propuestas del propio m´usico, que tambi´en deber´a traducir al completo para que sean legibles en tinta. Esto da lugar tambi´en a una comunicaci´on poco interactiva, ya que ninguno de los dos podr´a ver los cambios en tiempo real, sino que tendr´an que esperar a la traducci´on completa de la otra persona para poder leer los cambios en la partitura. As´ı, se ve que, aunque hay sistemas que permiten compartir las partituras entre personas videntes e invidentes, la interacci´on es lenta, lo que provoca una menor inclusi´on de gente con esta discapacidad. Adem´as, esto pasa en diferentes niveles dentro de la m´usica, tanto a gente que est´a aprendiendo a tocar un instrumente como a m´usicos profesionales. Por tanto, es importante desarrollar alg´un tipo de sistema que permita “agilizar” la comunicaci´on de los cambios en las partituras entre gente vidente e invidente para favorecer la interacci´on entre ellos. Si se consiguiera, habr´ıa m´as gente que podr´ıa disfrutar de la m´usica y, sobre todo, habr´ıa m´as gente que podr´ıa sentirse incluida en el ´ambito del aprendizaje y desarrollo musical. 1.2. Objetivos Acabamos de ilustrar la necesidad de tener una forma interactiva de compartir partituras entre videntes e invidentes. Queremos integrar los elementos que necesitan ambos para entender la m´usica en una aplicaci´on que les permita interactuar en tiempo real con la partitura. As´ı nace la idea de LiveDots. La aplicaci´on mostrar´ıa al mismo tiempo la partitura en tinta por pantalla y la partitura en braille mediante una l´ınea braille. Un vidente podr´ıa ver un pentagrama en tinta y modificarlo, reflej´andose, en tiempo real, estas modificaciones en la partitura braille. Del mismo modo, una persona con discapacidad visual podr´ıa leer en la l´ınea braille la misma partitura e introducir modificaciones en la misma, bien mediante la propia l´ınea o bien mediante pulsaciones de teclado, que se reflejar´ıan en tiempo real en el pentagrama en tinta. 1.2.1. Objetivos Iniciales Desarrollar una aplicaci´on como la que acabamos de describir es un proyecto muy extenso. Por ello nuestro objetivo principal es hacer una primera prueba de concepto de una aplicaci´on de traducci´on de partituras en tinta a braille en tiempo real, dejando la modificaci´on de partituras para una posible futura ampliaci´on. Decidimos centrarnos en algunas funcionalidades y desarrollar c´odigo modular y legible para que el proyecto pudiese continuarse en el futuro y aprovechar as´ı el trabajo hecho. Inicialmente, los objetivos de nuestro trabajo eran los siguientes: Estudiar y analizar el estado actual del campo de las aplicaciones de notaci´on musical 1.2. OBJETIVOS 19 en braille. •Estudiar qu´e hay hecho. •Estudiar qu´e falta por hacer. •Ver qu´e podemos aportar. Hacer una primera prueba de concepto de aplicaci´on de traducci´on de partituras con las siguientes especificaciones •Traducci´on en tiempo real de partitura en tinta a braille •Traducci´on en tiempo real de braille a tinta. •Compatibilidad con MusicXML •Salida por pantalla en braille y partitura en tinta •Salida por l´ınea braille •Accesible mediante un revisor de pantalla Probar la aplicaci´on en una l´ınea braille Probar la aplicaci´on con usuarios con discapacidad visual y realizar una evaluaci´on de la misma Redactar un art´ıculo sobre el desarrollo de la aplicaci´on LiveDots as´ı como sobre sus posibles aplicaciones y las implicaciones que puede tener en otros campos (ver anexo A) para el congreso ICCE 2020 (28th International Conference on Computers in Education) organizado por APSCE (Asia-Pacific Society for Computers in Education). Este es un congreso de tipo Core B. La intenci´on de art´ıculo es divulgar las implicaciones de nuestro trabajo en el mundo acad´emico para intentar que llegue a tener un impacto real sobre el panorama educativo actual. 1.2.2. Modificaci´on de los Objetivos El 15 de marzo de 2020 se decret´o en Espa˜na el estado de alarma debido a la pandemia mundial causada por el COVID-19. Una de las medidas fue el confinamiento de la poblaci´on. Debido a esta situaci´on social que ha surgido durante el desarrollo de nuestro proyecto ha habido objetivos que no hemos podido llevar a cabo por falta de medios. La principal consecuencia de esta situaci´on ha sido no poder colaborar con la ONCE como ten´ıamos planeado. Esto nos ha hecho modificar o eliminar los siguientes objetivos: Traducci´on en tiempo real de braille a tinta. Mientras que la traducci´on de tinta a braille es un´ıvoca y est´a recogida en un manual internacional (Krolick, 1996), la traducci´on inversa, de braille a tinta, no es un´ıvoca. Por tanto para poder hacer una implementaci´on de esta traducci´on se necesita la colaboraci´on directa mano a mano con un experto en la materia, ya que hay que evaluar caso por caso como realizar dicha traducci´on. Al no poder contar con dicho experto hemos suprimido esta funcionalidad de nuestro proyecto, dej´andolo como una posible ampliaci´on en un trabajo futuro. 20 CAP´ ITULO 1. INTRODUCCI ´ ON Probar la aplicaci´on en una l´ınea braille. Para poder cumplir este objetivo era indispensable disponer de una l´ınea braille. ´ Ibamos o bien a hacer estas pruebas directamente en la sede de la ONCE, o bien, pedirles una l´ınea braille prestada para poder probarlo. Ninguna de estas opciones se pudieron llevar a cabo por la situaci´on de confinamiento. Sin embargo, est´a implementada esta funcionalidad a falta de probarla. Probar la aplicaci´on con usuarios con discapacidad visual y realizar una evaluaci´on de la misma. De nuevo por el mismo motivo, no hemos podido colaborar presencialmente con usuarios con discapacidad visual. Hemos transformado el esfuerzo que ´ıbamos a dedicar a estos objetivos en a˜nadir funcionalidad al programa y realizar un experimento distinto: Modificaci´on en tiempo real de partitura en tinta. Hemos a˜nadido esta funcionalidad a nuestro programa. Se permite arrastrar las notas en el pentagrama en tinta cambi´andolas de tono y se puede ver en tiempo real esta modificaci´on en braille. Reproducci´on de partitura. Hemos a˜nadido la posibilidad de reproducir una partitura. Probar la aplicaci´on con usuarios videntes y realizar una evaluaci´on de la misma. Hemos realizado un estudio que incluye una parte blindfolded (sin usar la vista) con usuarios videntes para comprobar la usabilidad de la aplicaci´on desarrollada desde el punto de vista de ambos usuarios finales (vidente e invidente) y para comprobar si una aplicaci´on con modificaci´on en tiempo real como la que hemos desarrollado puede ser ´util para integrar al alumno ciego en el aula de m´usica. 1.3. Estructura de este documento Este documento se divide en 7 cap´ıtulos, cada uno dedicado a una tem´atica. Este secci´on est´a encuadrada en el primer cap´ıtulo introductorio en el que se han definido la motivaci´on y los objetivos del proyecto. El cap´ıtulo 2 recoge todo el estudio inicial del estado del arte que nos pone en antecedentes de la tem´atica del proyecto. Est´a dividido en distintas secciones, las tres primeras explican el uso que hacen las personas invidentes de un computador, el uso de aplicaciones accesibles en la docencia y la musicograf´ıa braille, mientras que las dos ´ultimas hacen un estudio de distintas aplicaciones musicales y de edici´on de partituras creadas para ciegos entorno a la accesibilidad y de aplicaciones musicales dirigidas mayormente a p´ublico vidente, respectivamente. En el cap´ıtulo 3 explicamos todo lo relacionado con la implementaci´on de la aplicaci´on LiveDots que ha sido la parte que m´as tiempo ha llevado de este proyecto. Las dos primeras secciones cuentan en lineas generales la gesti´on del proyecto y las tecnolog´ıas usadas. La tercera secci´on cuenta pormenorizadamente c´omo se ha llevado a cabo el desarrollo de la aplicaci´on y da detalles sobre partes relevantes de la implementaci´on. Tambi´en habla de todas las caracter´ısticas relacionadas con accesibilidad. 1.3. ESTRUCTURA DE ESTE DOCUMENTO 21 El cap´ıtulo 4 recopila el experimento que hemos llevado a cabo para probar la aplicaci´on desarrollada. Las diferentes secciones describen el objetivo del experimento, los participantes, el dise˜no experimental, los instrumentos usados para realizar el experimento, los resultados obtenidos y la discusi´on sobre estos resultados. El cap´ıtulo 5 recoge la narraci´on de cada autor de este trabajo sobre su aportaci´on del proyecto y su visi´on del mismo. En el cap´ıtulo 6 damos una visi´on general del trabajo futuro que inspira este proyecto. Por ´ultimo, el cap´ıtulo 7 explica detalladamente las conclusiones obtenidas despu´es de realizar este trabajo. 22 CAP´ ITULO 1. INTRODUCCI ´ ON Introduction Since de beginning of time, music has accompanied humankind having a very important roll through its history. It is a ubiquitous element in every culture, a universal cultural manifestation that has the power of communicating no matter the barriers in time, space or language (Wallin y col., 2001). It is, therefore, a very powerful element. Musical notation is the generic name that is given to any writing system used for representing graphically any music piece (de Cand´e, 2002). The first testimonies of written scores using musical notation in the occidental culture are dated in between forth century and beginning of the III century B.C. Burkholder y col., 2008. In fact we know that musical theory goes back even further in time, the Pythagorean tuning which is the construction system for the music scale that gives birth to the circle of fifths is attributed to the philosopher Pythagoras in the sixth century B.C. and it is still used nowadays (Benward y Saker, 2009). The ability to portray music in a paper allows us to share it and communicate it through time and space. The most extended method of musical representation amongst the blind people is musical braille, which is an adaptation of the reading and writing braille system. The braille system consists of different combinations of embossed dots (Kent, 2012). The musical braille is a transcription technique which allows to represent any conventional music score with a precise notation (de Cand´e, 2002). The knowledge of musical braille gives the blind musician not only a tool to comprehend and express music but also a very different conception of music to that of a sighted person that is used to the graphical representation in a music staff (Abramo y Pierce, 2013; Johnson, 2015). Music is an element of union, however in music education there is still a gap between sighted people and people with visual disabilities. In many cases, blind students do not receive the necessary training to understand musical braille notation and many sighted teachers do not know how to facilitate student learning, as denounced by David Goldstein, director of the National Resource Center for Blind Musicians in the United States. . An alternative for blind students to improve their musical knowledge is to attend a school for the blind. In this scenario, sighted and blind students are taught using different methodologies that lead to a dichotomy between musical braille and conventional musical writing. Lack of familiarity with conventional musical writing makes it more difficult for blind students to later enter settings with sighted musicians, such as a conservatory or orchestra (Goldstein, 2000). 23 24 CAP´ ITULO 1. INTRODUCCI ´ ON There is therefore a need to integrate sighted and blind students in the same classroom and teach each of them the essential knowledge to develop their musical skills (Quaglia, 2015; Buhagiar y Tanti, 2011). That is, we want blind students to be able to follow a music class with mostly sighted students as they learn musical braille notation and become familiar with the traditional musical conception of printed music. Some of the strategies most commonly used by blind or visually impaired students to facilitate participation in the classroom are: enlarged printed sheet music, that another person reads the sheet for them (classmates, parents or teachers) and the use of musical braille whenever possible (Frederick, 2009; Smaligo, 1998). All these tools need the help of a person to transcribe the score orally or a teacher who knows the musical braille and teaches it to the student, which is not always possible. This makes the student depend on the people around him. With the development of technology we have in our hands the possibility of creating tools that help us integrate the musical conception of blind and sighted people, thus facilitating aspects such as the integration of blind and sighted students in music classes or the collaboration of sighted and blind musicians in an orchestra. There are already programs designed for visually impaired people to view and edit music in braille notation (Homenda, 2008), studies on how to teach musical braille to children using computer applications (Borges y Tom´e, 2014), and programs that translate scores from printed music to braille and vice versa. The progress of technology in recent years has given us the opportunity to facilitate the integration of blind students. There are projects such as Braitico (ONCE, s.f.), an inclusive Braille literacy method developed by the ONCE (National Organization of the Blind of Spain) aimed at children learning braille. In the field of music, there are already computer programs for the visually impaired to view and edit music using braille notation (Homenda, 2008) such as the BME, Braille Music Editor (Giuseppe Paccini, s.f.), studies on how to teach musical braille to children using computer applications (Nicotra y Quatraro, 2008; Borges y Tom´e, 2014), studies and applications focused on teaching music to blind studies using spoken music instead of braille (Capozzi y col., 2012), applications for translating printed music scores into musical braille and vice versa such as FreeDots (Repain y col., s.f.) and there is even a standard for sharing scores in braille music notation on the web called BMML, Braille Music Markup Language (Encelle y col., 2009). The problem of integrating blind students into the classroom is present in almost all fields of education. There are many different approaches to finding a solution, such as AimMath, an interactive math learning system for blind and visually impaired students that uses a text-to-speech synthesizer to read aloud mathematical expressions (Naruedomkul, 2013). However, this approach does not promote integration into a single class of sighted and blind students. Another approach is EDICO (ONCE Scientific Editor) (Carenas y col., 2018), a project promoted by ONCE and developed in cooperation with the Complutense University of Madrid. It is an accessible math, physics and chemistry editor. It translates in real time printed scientific language to braille scientific notation and vice versa. This allows blind students to follow a science class by interacting in real time with a teacher who does not know Braille. Following EDICO’s success, the ONCE wanted to develop similar solutions to integrate 1.3. ESTRUCTURA DE ESTE DOCUMENTO 25 blind students into other subjects, such as music. This is how the idea of LiveDots was born: a music editor that translates printed sheet music into musical braille in real time. Motivation Nowadays, anyone can get access to sheet music and be able to access them later. This is very useful for musical learning, among other things. For example, a teacher can use a score editing tool (such as MuseScore or Sibelius, among others) to create scores that allow their students to practice some type of specific exercise. Another option is, during a class, to project a score to study it. Unfortunately, these systems are usually less developed for visually impaired people. In the case of the previous example, there are programs (such as FreeDots) that allow you to translate a score into Braille and use the braille display for reading, and others that allow you to write a score in Braille and translate them for display (for example , Braille Music Editor, which allows you to write a score in Braille and export it in a format that another application, such as MuseScore, allows you to view as a printed score). A typical situation during the development of a class is for the teacher to propose an exercise (let’s suppose creating a score) to then correct it. However, a sighted music teacher does not necessarily know braille. The student can then use a program to write their score and translate it. Afterwards, the teacher will be able to read it, correct it and write it in a program for translating scores into Braille and, thus, finally, the student will have their score corrected. Although this method works, it is clearly not interactive, because neither the teacher nor the student have access to each other’s creations until they are finished. We could say that, in this case, the teacher-student relationship has an epistolary component, since, until each one finishes their “letter”, the other cannot read and write theirs. This example shows that it is really difficult for students with visual disabilities to feel included in a music class, since there are many activities in which they cannot participate. That is why there is the need of a system that increases their participation and, with it, their inclusion in the class. Another situation occurs in the professional field of music. For example, it is much more complicated to integrate a visually impaired musician in an orchestra since the changes or adaptations made by the conductor in a printed score will have to be translated into braille for this musician to read them. This also occurs with the musician’s own proposals, which must also be translated in full so that they are legible in a printed sheet. This also results in a poor interactive communication, since neither of them will be able to see the changes in real time, but they will have to wait for the complete translation from the other person to be able to read the changes in the score. This way, it can be seen that, although there are systems that allow the scores to be shared between sighted and blind people, the interaction is slow, which causes less inclusion 32 CAP´ ITULO 2. ESTADO DEL ARTE informarnos de la ´ultima iniciativa de “ObjectiveEd”, s.f. en colaboraci´on con Microsoft para desarrollar una inteligencia artificial accesible que pretende sustituir al profesor ense˜nando Braille a un estudiante (Eyewire News, s.f.). Este proyecto pretende solucionar la necesidad de un profesor especializado para cada alumno, d´andole a cada estudiante las herramientas adecuadas para recibir un aprendizaje espec´ıfico al mismo tiempo que aut´onomo. Este proyecto est´a a´un en desarrollo pero, mientras tanto, hay otras opciones a la hora de ense˜nar el lenguaje Braille. En Espa˜na, la ONCE hace una labor similar a la de la Perkins School, dedic´andose a buscar formas de incluir a los alumnos invidentes en las aulas y de facilitar su aprendizaje con herramientas accesibles. En la “Web de Educaci´on de la ONCE”, s.f. se recopila y se informa sobre las diferentes aplicaciones accesibles orientadas a la educaci´on. Entre ellas est´a uno de los ´ultimos proyectos de la ONCE llamado Braitico (ONCE, s.f.). Este consiste en un m´etodo de ense˜nanza para que los m´as peque˜nos aprendan la lectura y escritura en braille. Con este m´etodo se utilizan herramientas tecnol´ogicas a trav´es del ordenador para su mayor eficacia. El ofrecer una soluci´on digital a la ense˜nanza mejora la facilidad y comodidad a la hora de distribuir el contenido. Adem´as permite corregir, mejorar y actualizar el programa ofreciendo la mejor versi´on posible. Aparte de tener aplicaciones que ense˜nen el sistema Braille, para lograr una ense˜nanza verdaderamente inclusiva, es interesante el desarrollo y uso de aplicaciones que fomenten la integraci´on de los alumnos con ceguera o discapacidad visual dentro de las aulas. Esto consiste en proporcionar las herramientas necesarias para que un profesor sin conocimiento del sistema Braille pueda ofrecer a una persona invidente todo el contenido necesario para el aprendizaje. Tambi´en, en el sentido contrario, es necesario que la persona invidente pueda comunicar informaci´on a la persona vidente. Podemos poner el ejemplo de un profesor preparando un examen para una clase en la que hay un alumno invidente. Este profesor no conoce el lenguaje braille y, por tanto, no puede proporcionar una copia del examen a su alumno invidente. Buscando soluciones a este problema, encontramos software de traducci´on a Braille o editores de texto en Braille para permitir la comunicaci´on de informaci´on escrita en ambos sentidos. Existen programas e incluso sitios web que realizan la traducci´on de textos a braille de forma inmediata como “Braille Translator”, s.f. y “Traductor braille : Traduce de Braille a Texto”, s.f. En el ´area de aplicaciones de escritorio que permiten la edici´on y traducci´on de texto Braille (“Braille Translation Software - Index Braille”, s.f.), podemos encontrar diversos programas que se utilizan por todo el mundo como Ebrai, Euler o NatBraille (figura 2.2). Este ´ultimo, por ejemplo, es una aplicaci´on de software libre que fue financiada por el Ministerio de Educaci´on Franc´es. Como parece l´ogico un editor capaz de traducir a Braille es una herramienta muy ´util para la integraci´on de un alumno invidente en el aula pero no es suficiente, por ejemplo, para traducir s´ımbolos matem´aticos y ecuaciones a braille. Es en este ´ambito donde encontramos aplicaciones m´as especificas como Edico o Lambda. Edico (“CTI. Editor Cient´ıfico ONCE”, s.f.) es un proyecto realizado en colaboraci´on entre la UCM y la ONCE que consiste en un editor matem´atico accesible. Es un programa muy potente que permite escribir y traducir entre lenguaje cient´ıfico y Braille en los campos de matem´aticas, f´ısica y qu´ımica. Esta funcionalidad permite que un alumno ciego pueda realizar los ejercicios o recibir las lecciones de manera sencilla. No solo permite traducir entre un lenguaje y otro c´omodamente, sino que adem´as lo hace en tiempo real, generando 2.3. M ´ USICOGRAF´ IA BRAILLE 33 Figura 2.2: Captura de pantalla del editor de Braille NatBraille (“NatBraille : un transcripteur Braille libre”, s.f.). una interacci´on entre el profesor y el alumno esencial para el aprendizaje. Tambi´en existen calculadoras accesibles (“Accessible calculators - ATWiki”, s.f.) que permiten su uso por una persona invidente como la Talking Texas Instruments Scientific Calculator, desarrollada por Living Aids o, incluso, alguna aplicaci´on de calculadora accesible como “Talking Calculator on the AppStore”, s.f. que ofrece una opci´on mucho m´as econ´omica aunque menos potente y c´omoda. Esto solo son algunas de las herramientas que hay para ofrecer un aprendizaje accesible para aquellos que lo necesitan. Como conclusi´on que aunque hay disponibles diversas aplicaciones muy ´utiles, normalmente no son sencillas de encontrar y en la mayor parte de los casos, requieren una licencia de pago. Por tanto, algunas de estas herramientas no son totalmente accesibles puesto que ofrecen una soluci´on pero a una coste alto y en consecuencia no es una soluci´on para todo el mundo. Esto se est´a intentando cambiar con la iniciativa de organizaciones como Perkins o la ONCE pero a´un as´ı queda un largo camino por recorrer hasta una educaci´on completamente accesible. 2.3. M´usicograf´ıa Braille Cuando pensamos en una partitura musical, normalmente, pensamos en un papel con varios pentagramas y sobre estos, diferentes s´ımbolos musicales y anotaciones que describen la composici´on musical. Sin embargo, este no es un formato que pueda interpretar una persona invidente. Para ello, existen diferentes sistemas de representaci´on musical que hacen uso de elementos que puedan ser interpretados de forma t´actil. 34 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.3: Representaci´on de las letras en Moon Type. Los s´ımbolos que se han dise˜nado alrededor del mundo para permitir la lectura por medio del tacto son muy diferentes (“Una Breve Historia de los Sistemas de Escritura T´actil para Lectores con Ceguera e Discapacidades Visuales”, s.f.). Desde imprimir las letras del alfabeto en relieve (utilizado en el sistema Boston Line Type, figura 2.4) hasta la codificaci´on por medio de puntos del sistema Braille. Pasando, tambi´en, por formatos como el Moon Type (figura 2.3) que utiliza s´ımbolos con cierta similitud a las letras, lo que facilita el aprendizaje a las personas que han perdido la vista tras una edad avanzada y est´an familiarizadas con la forma de las letras. Dicho esto, con el objetivo de universalizar y estandarizar un c´odigo para todo el mundo, el sistema Braille ha resultado la elecci´on m´as popular y la que hoy en d´ıa se utiliza en la mayor parte del planeta. Louis Braille, mientras estudiaba en el Instituto Real para J´ovenes Ciegos en Francia, dise˜n´o un sistema basado en puntos para que las personas ciegas pudieran leer y escribir de forma r´apida y eficiente. Adem´as, era un gran aficionado a la m´usica y se asegur´o de que su sistema fuera lo suficientemente flexible para permitir la representaci´on de partituras para cualquier instrumento. Este sistema utiliza cajetines de seis puntos para representar todos los elementos necesarios (Figura 2.5). Sin embargo, el sistema propuesto por Louis Braille 2.3. M ´ USICOGRAF´ IA BRAILLE 35 Figura 2.4: Boston Type. Figura 2.5: Cajet´ın Braille. no es el ´unico que utiliza la representaci´on de puntos. Uno de los problemas que pudiera tener el sistema Braille es el reducido tama˜no de las celdas. La representaci´on sobre seis puntos conlleva la ambig¨uedad de los s´ımbolos y la utilizaci´on de una gran cantidad de cajetines para algunas figuras musicales. Con la intenci´on de dise˜nar un sistema que mejorase la capacidad de representar m´usica, Gabriel Abreu ampli´o y modific´o a su conveniencia el sistema Braille para acabar creando su propio sistema con ocho puntos (Burgos-Bordonau, s.f.). Este es conocido como sistema Abreu (figura 2.6) y permite mayor n´umero de combinaciones por cada cajet´ın y, por tanto, una estructura menos compleja. Adem´as de este hubo otro formato importante desarrollado en Espa˜na contempor´aneamente con los de Louis Braille y Gabriel Abreu (Campos-Arcaraz, 2017). Este es el sitema Llorens (figura 2.6) que consiste en representar los s´ımbolos musicales a partir de l´ıneas que cambian su significado seg´un la posici´on y orientaci´on. A pesar de que, tanto el sitema Abreu como el sistema Llorens, se utilizaron en Espa˜na durante bastante tiempo, el sistema Braille acab´o imponi´endose debido a su popularidad y universalizaci´on. Figura 2.6: Comparaci´on de la representaci´on de las siete notas musicales con duraci´on semibreve (redonda) en los sistemas Braille, Abreu y Llorens. El sistema Braille se extendi´o mundialmente, pero a´un as´ı hab´ıa regiones del planeta con sus propias formas para representar m´usica. Adem´as, el sistema Braille se modificaba y adaptaba seg´un la zona donde se utilizara y esto llevaba a una inconsistencia en la forma de 36 CAP´ ITULO 2. ESTADO DEL ARTE representar partituras en Braille entre los diferentes pa´ıses. Tomando de base el sistema de seis puntos elaborado por Louis Braille, Bettye Krolick recopil´o y escribi´o el Nuevo Manual Internacional de Musicograf´ıa Braille (Krolick, 1996). Este manual recoge las reglas de la representaci´on musical en braille para la estandarizaci´on y universalizaci´on de las partituras en este formato. Un manual internacional permite, entre otras cosas, la elaboraci´on de sistemas inform´aticos que hagan uso de este sistema de musicograf´ıa para que se puedan utilizar por todo el mundo, y permite que todas las personas trabajen sobre el mismo formato para una mayor eficiencia del desarrollo. En esta l´ınea, se han realizado numerosos estudios para computarizar las partituras en Braille y tambi´en se han desarrollado diversos programas que interpretan, escriben o manipulan estas partituras. Cabe destacar estudios como A Transcription System from MusicXML Format to Braille Music Notation (Gotoh y col., 2008) donde proporcionan una forma de convertir una partitura en formato MusicXML a una partitura en Braille. Uno de los puntos m´as interesantes de este estudio es que interpretan la partitura Braille en un formato de ´arbol y de esta forma se puede lograr una correspondencia con la estructura de ´arbol de las partituras en formato MusicXML. 2.4. Editores musicales enfocados a personas invidentes Una aplicaci´on musical necesita poder almacenar la informaci´on de una partitura (por ejemplo, de una nota necesitamos su duraci´on y su tono). Para ello, es necesario un formato de notaci´on musical que permita este almacenamiento y edici´on de partituras. La mayor´ıa de aplicaciones musicales utilizan MIDI o MusicXML (o ambos) como formatos de notaci´on musical. Estos formatos se diferencian de los formatos de audio (como mp3, por ejemplo) en que no est´an destinados a la reproducci´on del archivo musical (no en primera instancia, al menos), sino a su almacenamiento y modificaci´on (esto ´ultimo no es posible con un archivo de tipo mp3), es decir, est´an destinados a la edici´on musical. MIDI fue creado en 1983 mientras que MusicXML se public´o en 2004. El primero es altamente compatible con una gran cantidad de software musical y est´a dise˜nado para facilitar la conexi´on de instrumentos digitales y ordenadores que se comuniquen entre s´ı (“El protocolo y el formato MIDI”, s.f.). Sin embargo, no ofrece mucha informaci´on en el dise˜no de partituras (no se˜nala agrupamientos de notas ni mec´anicas de din´amica como el staccato o el picado, entre otras cosas). Por otro lado, MusicXML, a pesar de tener menos compatibilidades, permite una representaci´on musical mucho m´as exacta (“Musicolog´ıa digital - Fundaci´on Juan March”, s.f.), por lo que, a´un siendo mucho m´as moderno, es un est´andar y los programas de edici´on musical m´as utilizados (como Sibelius o Finale) soportan tambi´en este formato. Las aplicaciones musicales accesibles suelen hacer uso de MusicXML como formato notacional, ya que esto permite utilizar las partituras provenientes de otras aplicaciones. Existen distintos servicios musicales relacionados con la accesibilidad, como son BME, FreeDots o DancingDots . 2.4. EDITORES MUSICALES ENFOCADOS A PERSONAS INVIDENTES 37 2.4.1. Braille Music Editor Una aplicaci´on muy interesante de cara al desarrollo de nuestro proyecto es Braille Music Editor (BME) (Giuseppe Paccini, s.f.). Como su propio nombre indica, es un editor musical en braille. Esta aplicaci´on permite importar y exportar archivos tanto en MIDI como en MusicXML (“Braille Music Editor (BME)”, s.f.). BME es un software de pago (con una versi´on de prueba de 30 d´ıas) de origen italiano que permite la edici´on de partituras con m´ultiples pistas para, posteriormente, reproducirlas con distintos instrumentos o exportarlas como archivos MIDI o MusicXML. Actualmente se encuentra en su segunda versi´on (BME2), que es la que permite esta entrada y salida de archivos con formato MusicXML. Figura 2.7: Braille Music Editor Este programa consta de una ventana en la que el texto est´a escrito en braille (figura 2.7). Se puede cargar un archivo de notaci´on musical, el cual aparecer´a en la ventana traducido a braille. A partir de ah´ı (o sin ning´un archivo cargado previamente), el usuario puede editar el fichero escribiendo caracteres en braille. Una vez editada la partitura, BME permite la reproducci´on de toda la partitura o de parte de la misma y tiene la posibilidad de cambiar alguna configuraci´on (por ejemplo, se puede a˜nadir un metr´onomo o se puede cambiar el instrumento con el que se reproduce la partitura eligiendo entre un abanico de m´as de 100 elementos, entre los que se encuentran todos los sonidos de instrumentos MIDI est´andar). Adem´as, se puede exportar la partitura en otros formatos o guardarlo en el propio formato del programa (braille music markup language, .bmml), el cual es una extensi´on del formato MusicXML que soporta partituras en braille. Para que la aplicaci´on sea accesible, Braille Music Editor cuenta con distintas propiedades: Una s´ıntesis de voz propia para leer la partitura en braille, aunque tambi´en puede hacer uso del revisor de pantalla JAWS mediante el uso de unos scripts que permiten que este revisor pueda identificar las notas y sus caracter´ısticas de forma precisa. La s´ıntesis de voz dispone de distintos niveles de profundidad (elegibles por el usuario). Se tiene la opci´on de que diga la combinaci´on de puntos braille del car´acter actual (aquel en el que se encuentra situado el cursor) o, por el contrario, que lo que diga sea el elemento musical correspondiente al car´acter actual. Sin embargo, mientras se escribe, 38 CAP´ ITULO 2. ESTADO DEL ARTE siempre utilizar´a la opci´on de decir los puntos braille del car´acter escrito ya que, sin contexto, un car´acter braille puede significar distintas cosas dentro de la notaci´on musical (incluso, hay elementos musicales que necesitan de m´as de un ´unico car´acter para ser representados, por lo que, hasta que el elemento no est´a completamente escrito, es imposible saber qu´e elemento musical est´an representando los caracteres). Sin embargo, cuando una partitura est´a escrita al completo en braille, su representaci´on s´ı es un´ıvoca, lo que permite al sintetizador de voz utilizar los elementos musicales en lugar de la combinaci´on de puntos braille en su mon´ologo. Se puede utilizar la navegaci´on con el teclado, de manera que podemos recorrer los men´us de la aplicaci´on con distintas teclas. Esta propiedad de accesibilidad es de especial importancia en el caso de las personas invidentes, ya que, al no poder alcanzar las distintas opciones mediante el uso del rat´on, esta posibilidad permite el uso de todas las caracter´ısticas de la aplicaci´on mediante el uso del teclado (ayudado por el revisor de pantalla, el cual va diciendo el lugar en el que est´a localizado actualmente el foco de la aplicaci´on). Permite la salida del texto por una l´ınea braille, lo que da la posibilidad a los usuarios de que, adem´as de escuchar mediante el revisor de pantalla el texto escrito en braille, puedan utilizar su l´ınea braille para la lectura del mismo. La entrada del texto es en braille de 6 puntos, lo que permite escribir las notas, acordes o partituras de la misma forma que ser´an le´ıdas posteriormente. Para ello, se utilizan las teclas f, d, s, j, k, yl, que se corresponden con los puntos 1, 2, 3, 4, 5 y 6 de un cajet´ın braille, respectivamente. De esta manera, si se quiere escribir el car´acter cuyos puntos correspondientes son el 1, el 4 y el 6, se deber´a pulsar simult´aneamente las teclas f, j yl. En caso de disponer de impresora braille, BME da la opci´on de imprimir el fichero actual. Adem´as, para ello, permite configurar algunos par´ametros. Braille Music Editor nos resulta realmente interesante de cara a la accesibilidad porque nuestra aplicaci´on necesitar´a tener algunas de sus propiedades: ser´a necesario un script para JAWS que permita que este revisor de pantalla lea elementos musicales en lugar de los caracteres con los que los representamos, la navegaci´on por la aplicaci´on debe ser posible a trav´es de teclado y el texto braille debe ser legible con el uso de una l´ınea braille. Tanto la escritura en braille como la posibilidad de imprimir el texto braille son dos caracter´ısticas muy interesantes de cara a nuestra aplicaci´on; sin embargo, est´an fuera del alcance de este trabajo. 2.4.2. FreeDots Freedots es una aplicaci´on que, dado un archivo con formato MusicXML, devuelve un archivo con la traducci´on a braille de la partitura en MusicXML (figura 2.8). Adem´as, permite la reproducci´on de la partitura actual. A diferencia de Braille Music Editor, se trata de un proyecto de software libre que podemos descargar desde el github de Mario Lang (Repain y col., s.f.). Adem´as, la aplicaci´on permite visualizar la partitura en braille y tienen 2.4. EDITORES MUSICALES ENFOCADOS A PERSONAS INVIDENTES 39 la intenci´on de que se pueda editar desde el mismo texto braille, aunque, desgraciadamente, llevan m´as de 3 a˜nos sin actualizar la aplicaci´on. A partir de esta aplicaci´on, Nicolas Froment cre´o un sitio web (“MusicXML to Braille converter”, s.f.) en el que convertir un MusicXML a braille sin necesidad de descargarse una aplicaci´on en el ordenador. Figura 2.8: Freedots Freedots es una muy buena aproximaci´on a la idea de nuestra aplicaci´on, ya que importa las partituras en MusicXML y las traduce a braille, aunque no permite la edici´on de la partitura en tiempo real. 2.4.3. Dancing Dots Dancing Dots (“Braille Music Software for Blind: Magnified Music for Low Vision by Dancing Dots”, s.f.) es una plataforma que ofrece aplicaciones para estudiantes con discapacidad visual y para sus profesores. Tienen distintos programas orientados a hacer la m´usica m´as accesible. Uno de los programas que ofrecen es el Lime Lighter (figura 2.9, una aplicaci´on para que personas con visibilidad reducida puedan leer partituras. Lime Lighter muestra las partituras con un gran tama˜no y permite que la partitura contraste del fondo de diversas maneras, algo que puede facilitar su lectura (por ejemplo, se puede mostrar cada una de las siete notas en distinto color). Tambi´en permite el uso de un sistema OCR para escanear partituras y el uso de la aplicaci´on mediante un pedal inal´ambrico, lo que permite tener las manos libres al recorrer la partitura (aunque se puede configurar la opci´on de que la partitura se recorra autom´aticamente a la velocidad que se indique). Dispone de versi´on de prueba y una licencia cuesta unos 80 d´olares al mes. Adem´as, tienen la aplicaci´on Lime Aloud, que trabaja haciendo uso del revisor de pan- 40 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.9: The Lime Lighter talla JAWS. Su funci´on es permitir la creaci´on musical a personas con discapacidad visual haciendo uso del editor Lime. Otro programa del que disponen es GOODFEEL, que permite escanear y editar una partitura para hacer su traducci´on a braille. Una persona invidente tendr´a acceso a la partitura mediante su verbalizaci´on (o mediante su reproducci´on). Este software permite el uso de archivos MusicXML como entrada para la traducci´on. Tambi´en da la opci´on de usar distintos revisores de pantalla, como JAWS o NVDA. Dispone de una versi´on de prueba de 15 d´ıas o de la opci´on de hacerse con una licencia del programa. Adem´as, disponen de cursos donde aprender musicograf´ıa braille y de otros productos y servicios. Por tanto, Dancing Dots es una plataforma orientada a la accesibilidad con diversas aplicaciones que favorecen el aprendizaje musical a personas con discapacidad visual. 2.5. Otras aplicaciones musicales y de edici´on de partituras A la hora de afrontar el desarrollo de una aplicaci´on tan grande como puede llegar a ser la que tenemos entre manos, el primer paso es plantearnos qu´e software hay ya hecho que podamos usar para implementar ciertas partes de la aplicaci´on. Nuestro objetivo es que el producto final sea ´util y fiable, para ello no es necesario, ni recomendable, hacer cada parte de nuestra aplicaci´on desde cero. Estudiaremos en primer lugar aplicaciones ya existentes con un prop´osito similar al de nuestra aplicaci´on. Despu´es hablaremos de distintos c´odigos relacionados con las partituras musicales y la notaci´on braille. 2.5. OTRAS APLICACIONES MUSICALES Y DE EDICI ´ ON DE PARTITURAS 41 2.5.1. Audacity Audacity es un editor de audio de c´odigo libre y gratuito (Dannenberg y Mazzoni, s.f.). Permite grabar, reproducir, importar y exportar datos en varios formatos como WAV, AIFF y MP3. Trabaja con un sistema de pistas, como se puede ver en la figura 2.10. A pesar de ser una aplicaci´on accesible, tiene ciertas carencias. Procedamos a estudiar su accesibilidad. Figura 2.10: Reproducci´on de una pista de audio con Audacity Tiene un alto n´umero de atajos de teclado, que son personalizables. Sin embargo hay partes de la aplicaci´on que no son completamente accesibles usando el teclado (Audacity Team, s.f.), lo cual priva de funcionalidad a usuarios con discapacidad visual, que usan este elemento como medio de interacci´on con la aplicaci´on. Las partes de Audacity que no son completamente accesibles incluyen: Recortes: Un recorte es un fragmento de audio que puede ser manipulado de manera independiente. Una pista puede contener uno o m´as recortes organizados de manera paralela, secuencial o cualquier combinaci´on de los mismos. En Audacity no hay forma de moverse a trav´es de estos fragmentos usando el teclado. Por ejemplo, no hay un atajo de teclado para moverse al principio del siguiente fragmento. Pista de tiempo: Es una pista que sirve para controlar la velocidad de reproducci´on de las pistas de audio. Solo puede manejarse mediante el rat´on. 48 CAP´ ITULO 3. METODOLOG´ IA DE TRABAJO 3.1.2. Control de versiones Para el control de versiones hemos usado Git, que es un sistema distribuido. Esto nos permit´ıa realizar de forma paralela distintos avances de una iteraci´on (en distintas ramas) para, una vez conseguido finalizar cada avance, incluirlo en la rama principal del proyecto. Adem´as, al tener cada integrante una r´eplica local, nos permit´ıa realizar de diversas formas un mismo objetivo de forma coet´anea para, posteriormente, seleccionar aquel que consider´asemos m´as favorable. 3.1.3. Planificaci´on temporal En la figura 3.1, podemos ver el diagrama de Gantt del proyecto. Se utiliza un c´odigo de colores, el cual se basa en tareas y subtareas y en la modificaci´on de objetivos explicada en la secci´on 1.2.2. El color azul se corresponde con las tareas que hab´ıan sido planificadas antes de comenzar a desarrollar el proyecto y que se han completado. En amarillo aparecen las subtareas de estas tareas realizadas. En color rojo aparecen las tareas que se planificaron pero no fueron realizadas (como se explica en la modificaci´on de objetivos, secci´on 1.2.2). Por ´ultimo, el color verde se utiliza para aquellas tareas que no fueron planificadas inicialmente pero s´ı se desarrollaron finalmente en el proyecto. 3.2. Tecnolog´ıas usadas Para elaborar nuestro proyecto hemos utilizado diversas herramientas de software. Tras una primera discusi´on con nuestros tutores decidimos que desarrollar´ıamos el proyecto en el lenguaje C# dado que facilita la implementaci´on de aplicaciones accesibles y es compatible con las herramientas que se utilizan hoy en d´ıa en accesibilidad. 3.2.1. Wpf en Visual Studio Durante la carrera nos hemos familiarizado mucho con el entorno de desarrollo Visual Studio as´ı que tomamos este como punto de partida para nuestro proyecto. A la hora de comenzar el proyecto, decidimos que este fuera un proyecto de Wpf (Windows Presentation Foundation). Los proyectos Wpf proporcionan una plantilla de proyecto muy ´util para desarrollar aplicaciones de escritorio. Separa la parte visual del programa de la parte funcional como se hace tambi´en en WinForms o en otros tipos de proyectos parecidos. El lenguaje que se utiliza Wpf para la parte visual es XAML (Extensible Aplication Markup Language) y en la parte funcional (code-behind) se utiliza C#. Adem´as los proyectos Wpf son proyectos que se desarrollan sobre .NET que es un marco de desarrollo software creado por Microsoft para facilitar la compatibilidad de los programas con los distintos sistemas y para permitir 3.2. TECNOLOG´ IAS USADAS 49 Figura 3.1: Planificaci´on temporal. 50 CAP´ ITULO 3. METODOLOG´ IA DE TRABAJO una mayor compartici´on de herramientas software entre los desarrolladores de las distintas plataformas que utilizen .NET. 3.2.2. C# C# fue dise˜nado como un lenguaje de programaci´on orientada a objetos (como Java y muchas otras) basado en C. Dentro de este tipo de lenguajes, una utilidad muy importante es el polimorfismo de clases. Gracias a este podemos crear una estructura jer´arquica con interfaces y diferentes clases en nuestro proyecto. Adem´as hemos realizado un desarrollo modular del programa para permitir un c´omodo punto de partida para trabajo futuro. Otra raz´on importante para modularizar nuestro programa es que crear partes diferenciadas nos permite seguir una buena metodolog´ıa de proyecto poniendo como objetivos la finalizaci´on de m´odulos completos. Por ´ultimo, tener diferentes m´odulos facilita corregir, modificar y mejorar las diferentes diferentes partes de nuestro programa. El desarrollo del lenguaje C# est´a ligado a la creaci´on de .NET y por esta raz´on podemos hacer uso de su facilidad a la hora de utilizar herramientas de software desarrolladas por terceros. As´ı como en otros lenguajes ser´ıa necesario instalar librer´ıas externas (DLL’s) en tu proyecto, trabajando sobre .NET podemos hacer uso de paquetes NuGet para lograr el mismo objetivo. Los paquetes NuGet son, en resumen, paquetes de c´odigo compilado que se publican en nuget.org para el consumo de cualquier usuario que utilice .NET. Visual Studio en Windows cuenta con un administrador de paquetes NuGet que facilita enormemente la b´usqueda, descarga e instalaci´on de dichos paquetes en el proyecto. 3.2.3. XAML y sus Componentes XAML (Extensive Aplicaton Markup Language) es un lenguaje declarativo basado en XML que utiliza una jerarqu´ıa por nodos para definir los diferentes objetos o componentes que se presentar´an en la pantalla de un proyecto en Wpf. El nodo ra´ız es la ventana en la que se presenta el programa y dentro de ella se van incluyendo los diferentes componentes (o controles) que pueden ser botones, textos, layouts, etc. Al igual que en C#, existen paquetes NuGet para XAML para hacer uso de controles dise˜nados por otros usuarios. 3.2.4. Uni´on entre las dos partes (Binding) Una vez conocemos las dos partes de un proyecto en Wpf, falta por determinar c´omo enlazarlas para que la ventana muestre elementos de nuestro c´odigo y viceversa, que nuestro c´odigo pueda obtener informaci´on de la ventana. Para ello hay diferentes formas de comunicaci´on que var´ıan seg´un el uso que se quiera hacer. Las dos m´as importantes, que utilizamos en nuestro proyecto son el paso de eventos y el binding (enlazado). El paso de eventos consiste en lanzar una se˜nal (evento) cuando se realiza una acci´on pre-definida, esta se˜nal ser´a capturada por un controlador que est´a esperando y el controlador ejecuta la funci´on deseada para dicho suceso. En resumen, los eventos nos permite realizar acciones en respuesta a 3.2. TECNOLOG´ IAS USADAS 51 sucesos en la ventana. En nuestro caso, por ejemplo, nos permite controlar lo que sucede cuando se selecciona alguna opci´on del men´u. En cuanto al binding (o enlazado) podemos decir que nos permite la comunicaci´on de informaci´on entre la parte visual y el c´odigo. Es posible obtener el valor en la ventana de una variable declarada en el c´odigo e, incluso, es posible hacerlo en el otro sentido sin hacer uso de ninguna herramienta adicional. El problema surge en que la consulta de esa informaci´on se hace de forma est´atica. Esto provoca que cada vez que la informaci´on cambie, es necesario realizar una nueva consulta y esto puede complicar el programa. Como soluci´on, se ha desarrollado la utilidad del binding. El binding se hace sobre variables que tienen lo que se denomina como propiedades de dependencia que indican cuando el estado de una variable cambia. Una variable enlazada (binded) a otra con propiedades de dependencia, se actualizara autom´aticamente tras el cambio de estado de esta segunda. El binding se puede realizar en los dos sentidos, por separado o, incluso, a la vez. En nuestro proyecto esta funcionalidad es ´util, por ejemplo, a la hora de modificar el tama˜no de los elementos. 52 CAP´ ITULO 3. METODOLOG´ IA DE TRABAJO Cap´ıtulo 4 Desarrollo de la aplicaci´on LiveDots 4.1. Dise˜no inicial Despu´es del an´alisis realizado sobre aplicaciones de edici´on de partituras y de traducci´on a braille pasamos a pensar en un primer dise˜no para nuestra prueba de concepto. Hemos identificado los componentes que m´as se repiten en otras aplicaciones similares y hemos escogido los que nos parec´ıan ´utiles para darle funcionalidad completa a nuestra aplicaci´on. Panel visualizaci´on partitura en tinta El objetivo principal de nuestra aplicaci´on es facilitar la interacci´on entre vidente e invidente, por tanto es necesario incluir funcionalidades y componentes que les permitan a ambos comprender la partitura e interactuar con la aplicaci´on. En todos los dise˜nos de editores o visualizadores de partituras para videntes que hemos analizado, la representaci´on gr´afica de la partitura es el componente principal ocupando la mayor parte de la pantalla. Para representar la partitura de forma gr´afica se usa un pentagrama, que es una notaci´on musical internacional. En nuestro dise˜no, decidimos incluir este panel. Sin embargo, en lugar de ocupar la totalidad del espacio de trabajo, decidimos que el tama˜no fuese aproximadamente de la mitad de la pantalla para poder incorporar los siguientes elementos. Salida por l´ınea braille Este es un componente no gr´afico de la aplicaci´on. El c´odigo braille correspondiente a la partitura que se est´a visualizando en pantalla, se muestra simult´aneamente a trav´es de una l´ınea braille. Esto permite a personas invidentes o con discapacidad visual alta ser 53 54 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS capaces de leer la partitura de la forma que les resulta m´as natural. Aunque tambi´en se pueda escuchar la lectura de la partitura mediante el revisor de pantalla, este audio puede resultar engorroso y poco intuitivo a la hora de comprender la m´usica. Panel visualizaci´on braille Otra caracter´ıstica importante que hemos encontrado en aplicaciones musicales adaptadas a personas con discapacidad visual es la visualizaci´on del braille por pantalla expresada en forma de cajetines braille. Tenemos un ejemplo de esto en Braille Music Editor (Giuseppe Paccini, s.f.). Hemos incluido este componente porque facilita la interacci´on entre vidente e invidente. Por ejemplo, un profesor vidente que sabe braille puede ver en tiempo real lo mismo que el alumno est´a leyendo mediante la l´ınea braille. Tambi´en puede ser ´util para personas con discapacidad visual que tengan dificultades a la hora de leer un pentagrama en tinta. Los cajetines braille tienen una estructura muy simple y se pueden reconocer mejor que ciertos s´ımbolos musicales en tinta. Espacialmente este componente debe ser suficientemente grande para permitir una lectura fluida y c´omoda, ser´a nuestro segundo componente principal. Men´u Por ´ultimo decidimos incorporar un men´u que recogiese las funcionalidades principales de la aplicaci´on, como abrir un archivo MusicXML. Se puede recorrer mediante el rat´on o mediante el teclado para que, usando un revisor de pantalla adecuado, sea totalmente accesible. Disposici´on Figura 4.1: Primer dise˜no de LiveDots Una vez escogidos los componentes principales de la parte gr´afica (men´u, partitura en tinta y partitura en braille) pasamos a su ordenaci´on espacial. Situamos el men´u en una barra en la parte superior de la ventana, por convenio. Dividimos el resto de la pantalla 4.2. VISUALIZACI ´ ON DE LA PARTITURA EN TINTA 55 de forma vertical en dos espacios donde ir´an las representaciones de la partitura en tinta a la izquierda y en braille a la derecha (figura 4.1). El espacio designado a la partitura en tinta es ligeramente mayor, ya que un pentagrama ocupa m´as espacio que una secuencia de cajetines braille. 4.2. Visualizaci´on de la partitura en tinta Una vez elegido y programado el dise˜no general de nuestra aplicaci´on, el objetivo era, dado un archivo en formato MusicXML, obtener la partitura en tinta correspondiente. Una posibilidad habr´ıa sido desarrollar la implementaci´on por nosotros mismos. Esto habr´ıa requerido la implementaci´on gr´afica de un pentagrama, de las distintas claves, de las distintas notas y sus duraciones y de las alteraciones, entre otras muchas cosas. Considerando que no era el objeto de este trabajo, decidimos buscar c´odigo que ya implementara esta funcionalidad. Encontramos la biblioteca Manufaktura (secci´on 2.5.5), que es de c´odigo abierto. Esta biblioteca permite importar archivos en formato MusicXML y mostrar la partitura en tinta correspondiente. De esta manera, decidimos introducir esta biblioteca a nuestro proyecto. As´ı, en el panel izquierdo de nuestra aplicaci´on, introducimos un control de tipo ManufakturaControls:NoteViewer, el cual permite visualizar la partitura. Este control tiene distintos atributos (como los m´argenes o la posici´on horizontal y vertical), siendo el m´as importante XMLSource, que es un atributo de tipo string que contiene el texto MusicXML del que pretendemos obtener la partitura en tinta. Con unas primeras pruebas (pasando el texto MusicXML directamente al atributo XMLSource) vimos que la partitura se mostraba perfectamente. Despu´es, quer´ıamos que el control de tipo ManufakturaControls:NoteViewer mostrara una partitura en tinta de un MusicXML que pudi´eramos seleccionar desde la aplicaci´on. Para ello, creamos un bot´on de abrir en el men´u, el cual, al ser pulsado, permite seleccionar un archivo de formato MusicXML que tengamos en nuestro ordenador. Una vez seleccionado el archivo, la variable sourceXml toma el valor del texto del archivo MusicXML seleccionado. Despu´es, hacemos un binding (cuyo funcionamiento hemos visto en la secci´on 3.2.4) entre esta variable y el atributo XMLSource. As´ı, tenemos que, cada vez que se abra un archivo MusicXML en la aplicaci´on, la variable sourceXml se actualiza con el texto de dicho archivo y el atributo XMLSource, al estar binded a esta variable, toma tambi´en su valor, y por tanto se actualiza la partitura en tinta que se muestra por pantalla a la correspondiente al archivo abierto. En la figura 4.2 se observa el resultado de la visualizaci´on de la partitura en tinta. Adem´as, este control de la biblioteca Manufaktura ( ManufakturaControls:NoteViewer), permite la edici´on de la partitura. Para ello, dispone de un atributo llamado InnerScore, el cual almacena el archivo MusicXML. Cuando se modifica una nota en la partitura en tinta (mediante el uso del rat´on, haciendo que esta se desplace en verticalmente), se modifica ese atributo, de manera que la partitura en tinta queda modificada. Adem´as, a partir del atributo InnerScore, podemos obtener el texto MusicXML en formato string asociado a la partitura en tinta modificada. En principio, no ´ıbamos a hacer uso de esta funcionalidad 56 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS Figura 4.2: Vista de la partitura pero, como explicamos en la secci´on 4.8, al final s´ı lo hicimos. 4.2.1. Visualizaci´on del texto MusicXML Por otro lado, para empezar a usar la aplicaci´on, hicimos que el texto MusicXML del archivo abierto se mostrara a la derecha de la partitura, en el panel que posteriormente corresponder´ıa al texto braille asociado a la partitura. Para ello, creamos un TextBox (el cual configuramos como no editable) cuyo valor tambi´en asociamos mediante un binding a la variable sourceXml. De esta manera, al abrir un archivo MusicXML, se mostraba, en el panel derecho de la aplicaci´on, el texto MusicXML de dicho archivo. Esto ocurr´ıa al mismo tiempo que se mostraba la partitura en tinta, por lo que ten´ıamos ambas representaciones a la vez, tal y como se observa en la figura 4.3. 4.3. Traducci´on de MusicXML a Braille Una vez conseguido que se muestre la partitura en tinta en el panel de la izquierda y el texto MusicXML correspondiente en el panel de la derecha, el objetivo era lograr que, en lugar del texto MusicXML, en el panel derecho se mostrara el texto en braille correspondiente a la partitura en tinta. Para ello, deb´ıamos pasar del texto MusicXML asociado a la partitura al texto braille y necesit´abamos poder representar el texto MusicXML y el texto braille de manera que pudi´eramos hacer la traducci´on de uno a otro. En la figura 4.4, podemos ver un esquema de esta traducci´on. Lo primero fue estudiar la representaci´on de una partitura en MusicXML y en braille. En MusicXML, al tratarse de un formato basado en XML, tenemos una estructura en forma 4.3. TRADUCCI ´ ON DE MUSICXML A BRAILLE 57 Figura 4.3: Vista de la partitura y el texto MusicXML asociado de ´arbol. El caso del braille es m´as complejo, ya que no se distingue una estructura clara con facilidad. Sin embargo, tras un tiempo de investigaci´on, encontramos A Transcription System from MusicXML Format to Braille Music Notation Gotoh y col., 2008, un paper japon´es en el que hab´ıan realizado un estudio te´orico para realizar esa traducci´on de MusicXML a braille, en el que se explicaba la estructura (tambi´en en forma de ´arbol) de la partitura en braille. As´ı, nuestra idea fue crear ambos ´arboles, de manera que podr´ıamos pasar del texto MusicXML a ´arbol MusicXML, de este ´arbol al ´arbol braille y, por ´ultimo, del ´arbol braille al texto braille. Adem´as, estas representaciones permiten tambi´en ser utilizadas para el recorrido inverso, de manera que se podr´ıan utilizar para programar el paso de texto braille a texto MusicXML (y, con esto, a la partitura). 4.3.1. ´ Arbol MusicXML Para el dise˜no del ´arbol, nuestra idea inicial era crear una clase para cada tipo de elemento de un texto MusicXML. As´ı, tendr´ıamos una clase MusicxmlScore, la cual representar´ıa la partitura al completo. Para ello, contendr´ıa una lista de MusicxmlPart. Cada MusicxmlPart estar´ıa compuesto por una lista de MusicxmlMeasure, que son los compases de esa parte. Cada uno de los compases tendr´ıa por un lado un MusicxmlAtribute y por el otro las distintas MusicxmlElement. El MusicxmlAtribute contendr´ıa las divisiones, el tono, el tempo y la clave. Un MusicxmlElement puede ser un MusicxmlNote o un backward oforward. Por ´ultimo, cada MusicxmlNote contendr´ıa informaci´on sobe su tipo, su duraci´on, su alteraci´on, su tono, su voz, su mano (izquierda o derecha, para el piano, por ejemplo) y si es o no un silencio. En la figura 4.5, podemos ver un esquema b´asico de la estructura en forma de ´arbol que pretend´ıamos obtener a partir del texto MusicXML. Sin embargo, encontramos que en el github de Vincent Daron hab´ıa una biblioteca con 64 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS 4.5.1.1. Elecci´on del Revisor El primer paso fue elegir el revisor de pantalla para el que ´ıbamos a dise˜nar la aplicaci´on. En nuestro caso, la decisi´on estaba entre JAWS y NVDA. La principal ventaja de NVDA es que no requiere licencia de pago para su uso. Esto nos facilitar´ıa el testeo en nuestros ordenadores personales. Sin embargo, el uso de JAWS est´a m´as extendido y, adem´as, mejor documentado. Tras valorar la decisi´on, nos decantamos por orientar el programa hacia JAWS. Esta elecci´on tiene como inconveniente que para probar el correcto funcionamiento de la aplicaci´on tendr´ıamos que hacer uso de una versi´on de prueba de JAWS que te permite un uso de 40 minutos cada vez que reinicias el ordenador. A pesar de esto, nos pareci´o que el resultado final ser´ıa mejor al elegir JAWS. 4.5.1.2. Configuraci´on de JAWS El programa de JAWS hace uso de Scripts para implementar sus funcionalidades. Los Scripts son documentos que contienen funciones en el lenguaje JavaScript. En este caso, JAWS utiliza una versi´on adaptada con la extensi´on de fichero .jss y utiliza su propio compilador para este tipo de ficheros. Una vez el revisor de pantalla se est´a ejecutando, se van llamando a diferentes Scripts que JAWS tiene configurados que ejecutar´an las funcionalidades necesarias. JAWS, en realidad, no utiliza los ficheros de Script directamente si no que hace uso de una versi´on en binario de estos (con la extensi´on .jsb) que es generada por su compilador. El revisor de pantalla tiene implementados .jss (y sus asociados .jsb) para las aplicaciones y funcionalidades habituales en un ordenador. Estas son funcionalidades generales que funcionan para cualquier aplicaci´on, el problema aparece cuando se desea que JAWS funcione de forma diferente a la que tiene programada. A la hora de que JAWS lea los men´us de nuestra aplicaci´on todo lo que est´a ya programado nos result´o muy ´util ya que, por defecto, JAWS lee lo que es necesario leer de un men´u. Sin embargo, para leer la partitura tuvimos que dise˜nar una forma tanto de recorrerla como de leerla que tuviera sentido para el usuario. Para hacer estos cambios sobre el uso habitual de JAWS fue necesario implementar un Script asociado a nuestro programa que indica a JAWS las acciones a tomar. JAWS est´a dise˜nado para que cuando una aplicaci´on reciba el foco en la pantalla, se ejecute el Script con el mismo nombre que la aplicaci´on. Por tanto, nosotros nos tuvimos que asegurarnos que el Script tuviera el mismo nombre que el de nuestra aplicaci´on. Adem´as, es necesario que el Script LiveDots.jss (junto con su asociado LiveDots.jsb) se copie junto con el resto de Scripts de JAWS. Para lograr esto, creamos una funci´on de configuraci´on (JawsSettings.CheckJawsInstalled) en nuestro programa que se encarga de mover el .jss implementado y el .jsb compilado asociado a la carpeta donde el programa JAWS almacena habitualmente todos sus Scripts. 4.5. ACCESIBILIDAD 65 4.5.1.3. Comunicaci´on con la App Preparando un esquema para conseguir que el revisor leyera los elementos de la partitura, nos encontramos con dos puntos importantes. El primer punto que tuvimos en cuenta fue el recorrido de la partitura (explicado en la secci´on 4.5.1.6). Esto no tiene una soluci´on obvia ya que cada elemento musical se representa con, posiblemente, m´as de un cajet´ın braille. La soluci´on que dise˜namos fue un recorrido de la partitura braille saltando por el n´umero de cajetines que ocupa cada elemento en vez de leer todos los cajetines uno a uno. De esta forma, al pulsar la flecha para avanzar, en vez de leer el siguiente cajet´ın que puede pertenecer al mismo elemento musical, se salta todos los cajetines del elemento y lee el siguiente elemento. Por defecto JAWS lee los cajetines como el car´acter que se utiliza para representarlo. Entonces, el otro punto importante a tratar fue, c´omo conseguir que JAWS dijera el nombre de los elementos musicales en vez de lo que dice por defecto (explicado en la secci´on 4.5.1.5). Para dar soluci´on a este problema, necesit´abamos comunicar el Script de JAWS con nuestra aplicaci´on para que esta le proporcionara el nombre de los diferentes elementos. Adem´as, para resolver el recorrido mencionado antes, pensamos en un primer momento que tambi´en podr´ıamos indicarle a JAWS desde la aplicaci´on el n´umero de cajetines a saltar cada vez que se avanzaba el cursor. Por tanto, tuvimos que estudiar c´omo realizar esta comunicaci´on entre el Script de JAWS y nuestra aplicaci´on. La forma intuitiva de resolverlo fue creando una instancia de un objeto de nuestra aplicaci´on en el Script. Este objeto tiene funciones que, al llamarlas, se encargan de proporcionar la informaci´on necesaria. Sin embargo, dado que los Scripts y nuestra aplicaci´on utilizan lenguajes de programaci´on diferentes, esta comunicaci´on no se pod´ıa hacer de forma directa. Para instanciar un objeto de nuestra aplicaci´on desde una aplicaci´on externa, fue necesario hacer uso de un objeto COM (Component Object Model, ver figura 4.9). Este objeto, se registra en el ordenador para que el Script conozca su existencia y pueda hacer uso de ´el. De esta forma, desde el Script, ´unicamente hay que instanciar el objeto COM y llamar a sus funciones. Para registrar el objeto COM en el ordenador, implementamos una funci´on que se llama dentro de la funci´on de configuraci´on antes mencionada (JawsSettings.CheckJawsInstalled) para que se haga autom´aticamente. Adem´as, decidimos que en vez de controlar las llamadas a nuestra aplicaci´on directamente desde el objeto COM, har´ıamos una clase (BrailleMusicViewer) que se encargara de saber qu´e es lo que el revisor de pantalla tiene que decir seg´un la posici´on en la que est´a el cursor. 4.5.1.4. Implementaci´on del Script Para lograr que nuestro Script tenga la funcionalidad que deseamos, el manual de JAWS indica que una de las formas consiste en sobrescribir las funciones que est´an definidas por defecto en JAWS. La documentaci´on de JAWS proporciona el nombre y una breve descripci´on de todas las funciones definidas por defecto. Para sobrescribir una de estas funciones, hay que crear una nueva definici´on de la funci´on, con el mismo nombre, en el Script asociado a nuestra aplicaci´on (LiveDots.jss). As´ı, siempre que JAWS vaya a llamar a una funci´on, mientras nuestra aplicaci´on tenga el foco, llamar´a a la nueva definici´on. En el caso de que la funci´on no est´e sobrescrita en el Script, se llama a la definici´on por defecto de la funci´on. 66 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS Figura 4.9: Esquema del proceso de comunicaci´on entre el Script de JAWS y el programa LiveDots a trav´es de un objeto COM Dada esta informaci´on, buscamos la funci´on m´as adecuada a sobrescribir y result´o ser la funci´on SayCharacter. Esta funci´on se se llama cada vez que se quiere leer un car´acter. En nuestro caso, cada cajet´ın est´a representado por un car´acter. Entonces, sobrescribimos la funci´on SayCharacter para que, en vez de leer el car´acter, leyera el nombre del elemento musical al que pertenece este car´acter (explicado en la secci´on 4.5.1.5). En la misma funci´on, despu´es de leer el nombre del elemento, se avanza el cursor hasta el final del elemento. La informaci´on del nombre del elemento y el n´umero de caracteres que tiene que avanzar viene proporcionada por nuestra aplicaci´on. Hay que tener cuidado al sobrescribir las funciones de JAWS ya que, al hacerlo, se altera el funcionamiento habitual dentro de la aplicaci´on en ejecuci´on. Por tanto, est´a nueva funcionalidad solo la realizamos cuando el panel de visualizaci´on braille est´a seleccionado. Para obtener esta informaci´on tambi´en se hace una consulta a nuestra aplicaci´on. Controlar el movimiento del cursor desde el Script de JAWS result´o ser una mala idea. Esto fue porque, en el mismo instante que se llamaba a la funci´on SayCharacter, se realizaba el movimiento del cursor con alguna otra funcionalidad (probablemente del propio sistema de Windows). Esto generaba muchas dificultades para obtener correctamente la posici´on actualizada del cursor y que avanzase la cantidad de cajetines deseada. Por tanto, decidimos buscar otra soluci´on para el recorrido de los elementos y, ´unicamente, mantener la funci´on SayCharacter sobrescrita para la lectura correcta del elemento. La nueva forma para recorrer los elementos se explica en la secci´on 4.5.1.6. 4.5.1.5. Lectura de Elementos La clase BrailleMusicViewer se encarga de saber el nombre del elemento que tiene que decir seg´un la posici´on actual y cu´anto hay que mover el cursor dependiendo del elemento que se est´e saltando. Para poder tener toda esta informaci´on, guardamos tres listas y un entero con la posici´on actual (ver figura 4.10 con un ejemplo). La primera lista (Viewer) contiene lo que el revisor tiene que decir al leer el elemento. Dado que cada elemento ocupa, posiblemente, varios cajetines, guardamos el nombre del elemento una vez por cada cajet´ın 4.5. ACCESIBILIDAD 67 que ocupa. De esta forma, podemos averiguar f´acilmente qu´e elemento de la lista Viewer es necesario leer seg´un la posici´on del cursor. La segunda lista (Forward) contiene el n´umero de cajetines que ocupa el elemento en esa posici´on hasta el siguiente elemento. Esto nos interesa porque no siempre ser´a necesario saltar el elemento entero y con una simple consulta a la lista podemos averiguar cu´anto hay que moverse adelante. La tercera y ´ultima lista (Backward) contiene informaci´on parecida a Forward pero, esta vez, cu´anto tiene que saltar hacia detr´as para llegar al final del elemento anterior. Hay que tener en cuenta que si consideramos los extremos donde podr´ıa situarse el cursor, el n´umero de posiciones puede ser una m´as que el n´umero de cajetines. Para que esto no cause problemas, a˜nadimos un cero al final de la lista Forward y otro al comienzo de la lista Backward, as´ı indicamos que no se salte al llegar a los extremos. Figura 4.10: Ejemplo con el contendido de las distintas listas de BrailleMusicViewer (no se incluye la traducci´on de la armadura por simplificar). Una vez organizamos el contenido de cada lista, tuvimos que implementar varias funciones para generar las listas correctamente seg´un la partitura que estuviera abierta. Las dos funciones principales son AddElement yParseText. AddElement se encarga de introducir los elementos dentro del BrailleMusicViewer. Es necesario pasarle el nombre del elemento y el tama˜no del mismo. Introduce a Viewer el nombre del elemento el n´umero de veces correspondiente al tama˜no. Adem´as, calcula los valores que hay que a˜nadir a Forward yBackward para que el n´umero a saltar en esas listas sea correcto. ParseText es una funci´on que tienen que implementar todos los elementos musicales en braille para indicar su nombre y el n´umero de cajetines que ocupa para despu´es llamar a la funci´on AddElement con esos valores. Esta funci´on necesita como atributo el BrailleMusicViewer donde se quiere a˜nadir el nuevo elemento. Para el funcionamiento correcto, tuvimos que implementar todas las funciones ParseText para cada elemento donde, dependiendo de los valores del objeto actual, este tendr´ıa un nombre diferente o un tama˜no diferente. Esta funci´on sigue una idea muy parecida a la anteriormente mencionada ParseBraille pero, en vez de preocuparse de su representaci´on en braille, se interesa por c´omo se va a leer cada elemento. As´ı, al realizar una llamada a ParseText con el elemento ra´ız (BrailleScore) como atributo, se recorre el ´arbol con todos los elementos de braille introduciendo la informaci´on necesaria para que se lean correctamente. 68 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS 4.5.1.6. Recorrido de Elementos Como ha sido mencionado antes, decidimos cambiar el recorrido de los elementos para que se hiciera desde nuestra aplicaci´on en vez que desde JAWS. Esto, nos dimos cuenta, tiene sentido en el contexto de que es posible controlar el cursor directamente desde el TextBox (panel de visualizaci´on braille) de nuestra aplicaci´on. Y, adem´as, es interesante minimizar los cambios sobre la funcionalidad habitual de JAWS sobrescribiendo lo menos posible sus funciones. La soluci´on consisti´o en implementar una funci´on que controlara el evento que se lanza cuando en el TextBox se mueve el cursor. En esta funci´on, tenemos que comprobar si el movimiento se ha realizado hacia delante o hacia detr´as. Esto lo hacemos comparando la posici´on actual del cursor con la posici´on que tenemos nosotros guardada en el BrailleMusicViewer. Una vez sabemos si hay que mover hacia delante o hacia detr´as, movemos el cursor adecuadamente haciendo uso de las listas Forward yBackward que hab´ıamos dise˜nado con este objetivo precisamente. Por ´ultimo, actualizamos la posici´on actual en BrailleMusicViewer. Esta soluci´on, nos permite incluso actualizar la posici´on actual en el caso de que se seleccione con el rat´on, resolviendo as´ı un posible problema a˜nadido. 4.5.1.7. Salto de L´ınea y Reorganizaci´on Una vez el revisor de pantalla le´ıa correctamente los elementos musicales, nos ten´ıamos que preocupar por el resto de funcionalidades necesarias para que nuestra aplicaci´on fuera accesible. Entre ellas, estaba dentro de nuestro plan, implementar la salida por l´ınea braille. Para obtener una salida por l´ınea braille tendr´ıamos que realizar una divisi´on de las l´ıneas por el tama˜no de la l´ınea braille. Esto adem´as permitir´ıa ver m´as c´omodamente la partitura braille en la pantalla. Sin embargo, significar´ıa varios cambios en nuestra aplicaci´on. El primero en la forma en la que escribimos el braille por la pantalla y el segundo en la forma en la que el revisor lee los elementos. Empezando por la forma en la que se muestra el braille, decidimos que la longitud de l´ınea braille que tomar´ıamos de referencia ser´ıa 40 (la longitud m´as habitual de l´ıneas braille). Adem´as, pensamos que nuestra partitura podr´ıa saltar de l´ınea, ´unicamente, entre elementos para que no partiera elementos por la mitad, lo que creemos que es m´as c´omodo para su lectura. Con esto en mente, decidimos que la soluci´on resultaba en crear una clase (BrailleText) que controlara el n´umero de cajetines introducidos en la l´ınea y metiendo un salto de l´ınea en caso de que se llegara al tama˜no m´aximo de l´ınea. Esta clase pasar´ıa a contener el texto que se representa en braille. Este cambio llev´o a una modificaci´on sobre la clase (ParseBraille) para que en vez de devolver la forma de escribir los elementos en braille directamente, utilizara una funci´on (AddText) de BrailleText que introdujera un salto de l´ınea si era necesario dependiendo del tama˜no y la posici´on del elemento. Pasando a la forma con la que el revisor lee los diferentes elementos, era necesario que tambi´en se indicara cu´ando se ha llegado al final de l´ınea ya que esto requerir´ıa avanzar una vez m´as el cursor para pasar a la siguiente l´ınea. Para resolver esto, hicimos algo parecido que en el caso del texto. Introdujimos el BrailleMusicViewer dentro de la clase BrailleText para que esta tambi´en pudiera hacer uso del tama˜no de l´ınea. De esta forma, igualmente, 4.5. ACCESIBILIDAD 69 hab´ıa que cambiar las funciones ParseText para que utilizaran una funci´on AddViewer que introdujera un elemento de final de l´ınea en caso de haber llegado al tama˜no m´aximo. Sin embargo, a parte de este cambio, se pod´ıan seguir utilizando el resto de funcionalidades del BrailleMusicViewer. Al realizar este peque˜no cambio, decidimos hacer un cambio m´as grande que solucionaba algunos problemas que surg´ıan cuando la l´ınea no ten´ıa el tama˜no de l´ınea m´aximo. Esto ocurre cuando un elemento es m´as grande que el espacio restante de la l´ınea. El cambio que hicimos fue sobre el recorrido del ´arbol. En vez de hacer el recorrido una vez para obtener el texto que se muestra con ParseBraille y otra para obtener lo que se dice con ParseText, se har´ıa una ´unica vez llamando a ambas funciones en cada elemento. Adem´as las funciones ParseBraille yParseText solo las implementar´ıan los elementos musicales que necesitan representaci´on (las hojas del ´arbol braille). De esta forma, ahorramos en el coste por el recorrido para cada partitura y solucionamos los peque˜nos problemas que est´abamos teniendo. Ahora, cuando se realiza un salto de l´ınea porque el elemento no cabe en la l´ınea en la funci´on ParseBraille, directamente se introduce tambi´en en el BrailleMusicViewer la informaci´on para que lea el final de l´ınea. Despu´es, al llamar a ParseText, puesto que el salto de l´ınea ya se ha introducido, no hay que preocuparse por el tama˜no de l´ınea. Por ´ultimo para poder realizar este recorrido del ´arbol que llama a las funciones ParseBraille yParseText en las hojas, creamos la funci´on Parse que tienen que implementar todos los elementos braille. La funci´on Parse en las hojas, simplemente, llama a las dos funciones otras dos funciones en orden y en los elementos que no son hojas se encarga de realizar el recorrido del ´arbol correctamente. 4.5.1.8. Detalles de Lectura Una vez solucionada la lectura de todos los elementos por medio del revisor de pantalla arreglamos un par de detalles. El primero es que, al cambiar el foco de la aplicaci´on al TextBox donde mostramos la partitura en braille, no se le´ıa el elemento donde se hubiera seleccionado (habitualmente el primero). Esto es porque en esa acci´on no se ejecuta la funci´on SayCharacter de JAWS y, por tanto, no pasa por nuestra funci´on sobrescrita. Para arreglar esto, buscamos la funci´on que se llamaba en este caso para sobrescribirla y encontramos que al menos una de las funciones que se llamaban era FocusChangedEventEx. De nuevo tuvimos que tener cuidado para no sobrescribir demasiado la funcionalidad habitual de JAWS pero, sin muchas m´as complicaciones, arreglamos este detalle. El segundo consist´ıa en un detalle m´as espec´ıfico y, es que, cuando se cambiaba el foco dentro de la aplicaci´on al TextBox, JAWS dec´ıa, por lo que nos pareci´o entender, “type index” tras leer correctamente el elemento. Esto lo dec´ıa incluso habiendo sobrescrito la funci´on que se llamaba al cambiar el foco de la aplicaci´on. Dado que no encontramos ninguna otra funci´on que fuese la causante de este mensaje encontramos otra manera de solucionarlo. Utilizamos la instrucci´on SpeechOff de JAWS para bloquear la lectura del revisor de pantalla. Esto puede ser peligroso y no recomendable ya que puedes evitar la lectura de otros mensajes importantes, sin embargo, la lectura se vuelve a activar (SpeechOn) en el momento en el que se realiza cualquier otra acci´on. Dado que, en nuestro caso, despu´es de cambiar el foco al TextBox y de leer el elemento ah´ı presente, no hay que comunicar ning´un otro mensaje antes de realizar otra acci´on, podemos hacer uso de esta soluci´on sin estropear 70 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS el resto de funcionalidades. Con estos dos detalles y tras varias pruebas de uso, dimos por acabada la parte relacionada con el revisor de pantalla y continuamos con otros aspectos importantes de la accesibilidad. 4.5.2. Recorrido por Teclado y Atajos Recordemos que otro de los aspectos m´as importantes de la accesibilidad es el de permitir hacer uso completo de la aplicaci´on a trav´es del teclado. La forma en la que est´an implementados los controles de Wpf ya permite un recorrido a trav´es de ellos por medio del tabulador. No solo esto, si no que tiene funcionalidades para facilitar el movimiento a trav´es de los men´us por medio del teclado. Gracias a esto, nosotros ´unicamente tuvimos que asegurarnos de que los elementos se recorr´ıan de una forma c´omoda. Para asegurarnos de esto, tuvimos que tener cuidado con qu´e elementos eran seleccionables y cu´ales no. Por ejemplo, no nos interesaba permitir la selecci´on del panel de visualizaci´on de partitura en tinta puesto que no es modificable por teclado y ´unicamente entorpecer´ıa el recorrido de la aplicaci´on por medio del teclado. Adem´as del recorrido de la aplicaci´on por medio del teclado pensamos en dise˜nar algunos atajos de teclado para permitir un acceso f´acil a las funcionalidades m´as importantes de la aplicaci´on. Para hacer esto, fue necesario crear objetos en nuestro proyecto que implementaran la interfaz ICommand. A estos elementos les indicamos la combinaci´on de teclas necesaria para activarlos y las acciones que deben ejecutar al activarse. Tambi´en fue necesario a˜nadir estos elementos a la lista de comandos que se pueden introducir en nuestra ventana principal. De esta forma, mientras la ventana principal de la aplicaci´on tenga el foco, al realizar la combinaci´on de teclas adecuada se ejecutar´a la acci´on deseada. 4.5.3. Tama˜no de los Elementos Otro aspecto importante que quer´ıamos que permitiera nuestra aplicaci´on era modificar el tama˜no de los diferentes elementos. Con esta funcionalidad, permitir´ıamos que las personas con visibilidad reducida pudieran adaptar el tama˜no de los diferentes elementos de la aplicaci´on a su gusto. La forma en la que implementamos esto fue a trav´es de Binding. El Binding, como se ha explicado en el apartado de tecnolog´ıas usadas (secci´on 3.2.4), es una herramienta muy potente. En este caso, lo hemos utilizado para que el tama˜no asociado a los elementos, en vez de ser un n´umero constante, sea una variable que var´ıa din´amicamente. En la aplicaci´on hay tres partes principales, el men´u, la partitura en tinta y la partitura en braille. Para modificar el tama˜no de los men´us, la propiedad que cambiamos es el tama˜no de fuente de la letra. En la partitura en braille lo mismo, dado que est´a en formato de texto modificamos el tama˜no de la fuente. En la partitura en tinta modificamos la propidedad de ZoomFactor que viene proporcionada por el control de Manufaktura para cambiar el tama˜no de la partitura. Para cada una de estas partes guardamos una variable (FontSize, BrailleSize yScoreZoomFactor, respectivamente) a la que se realiza un Binding desde la 4.6. MODIFICACI ´ ON DE LOS OBJETIVOS INICIALES 71 ventana. Adem´as implementamos funciones que var´ıan el valor de estas variables y creamos opciones dentro del men´u para variar cada uno de estos tama˜nos. Por ´ultimo, a˜nadimos un atajo de teclado que incrementa todos los elementos a la vez y otro que decrementa de la misma forma. 4.5.4. Resto de Elementos de Accesibilidad Para completar la accesibilidad de nuestra aplicaci´on nos faltaban algunos detalles. Uno de ellos era el contraste de colores de nuestra aplicaci´on. Aunque nuestra aplicaci´on no utiliza muchos colores y los elementos se representan en un b´asico negro sobre blanco, tenemos que tener en cuenta que personas con diferentes discapacidades visuales pueden necesitar otras gamas de colores para distinguir los elementos correctamente. Sin embargo, al ser una aplicaci´on Wpf y teniendo cuidado de no modificar la configuraci´on por defecto, nuestra aplicaci´on hereda correctamente el contraste de colores establecido por el sistema Windows. Esto quiere decir que si en el panel de control, el usuario decide invertir los colores, nuestra aplicaci´on tambi´en se ver´a con los colores invertidos. Un ´ultimo detalle, pero muy importante, es la elaboraci´on de una gu´ıa de uso. Esto es ´util para cualquier usuario pero, especialmente, para los usuarios invidentes. En esta gu´ıa indicamos los diferentes elementos que hay en la aplicaci´on y las acciones que se pueden realizar dentro de esta. De esta forma, un usuario nuevo, puede tener una referencia para no tener que explorar la aplicaci´on antes de poder hacer uso de ella. La gu´ıa se adjunta en un archivo de texto (.txt) con la aplicaci´on pero, adem´as, la hemos metido dentro de la aplicaci´on. En el men´u se puede seleccionar la opci´on de abrir la gu´ıa de uso que abrir´a una nueva ventana con la gu´ıa de uso. Es importante mencionar que JAWS leer´a correctamente esta gu´ıa, ya que, el uso habitual de JAWS soporta la lectura de texto y en nuestro Script hemos tenido cuidado de no sobrescribir esta funcionalidad. Otra cosa relevante de la ventana de la gu´ıa es el hecho de que los atajos de teclado que hemos implementado no funcionar´an ya que, estos est´an asociados a la ventana principal de la aplicaci´on y no a la de la gu´ıa. Para arreglar esto, hicimos algunas modificaciones sobre los comandos para que se incluyera el atajo que cambia de tama˜no el texto en la ventana de la gu´ıa de uso. 4.6. Modificaci´on de los objetivos iniciales En esta etapa del desarrollo tenemos una aplicaci´on que lee una partitura en formato MusicXML y la muestra por pantalla tanto en tinta como en braille siendo compatible con salida por l´ınea braille. Todo esto con c´odigo libre y modular para facilitar la ampliaci´on y reutilizaci´on del trabajo hecho en este proyecto. Llegados a este punto del proyecto, nuestra idea inicial era desarrollar la traducci´on inversa de braille a tinta. Esto nos permitir´ıa, con el c´odigo que ya ten´ıamos desarrollado, cargar partituras en formato braille y mostrarlas tanto por pantalla (en tinta y en braille) como por l´ınea braille. Adem´as de sentar las bases para poder ampliar el programa en el futuro a˜nadiendo la opci´on de modificar el braille y que los cambios se mostrasen en tiempo real. Sin embargo, tras un estudio te´orico sobre la traducci´on de braille a tinta, nos encontramos 72 CAP´ ITULO 4. DESARROLLO DE LA APLICACI ´ ON LIVEDOTS Figura 4.11: Correspondencia de notas musicales en braille con el problema de que esta traducci´on no es un´ıvoca: hay distintas combinaciones de cajetines braille que pueden tener distintos significados seg´un el contexto en el que est´en escritos. Por ejemplo, la figura musical (signo que representa gr´aficamente la duraci´on musical de un sonido) no queda identificada un´ıvocamente por un cajet´ın braille (figura 4.11) sino que necesita un an´alisis del contexto. Por tanto para poder hacer esta traducci´on necesit´abamos hacer un estudio pormenorizado del c´odigo braille musical y su traducci´on dependiente del contexto. Para desempe˜nar esta tarea cont´abamos inicialmente con la colaboraci´on de la ONCE, sin embargo, debido a la situaci´on de confinamiento en que nos hall´abamos en este punto del proyecto (y con la previsi´on de que esta situaci´on no cambiar´ıa en un futuro cercano) parec´ıa poco probable que pudi´esemos colaborar con ellos mano a mano, algo que resultaba fundamental para poder llevar a cabo este objetivo. Una vez nos dimos cuenta de que a causa del confinamiento no ´ıbamos a tener el asesoramiento necesario para poder realizar esta traducci´on correctamente decidimos cambiar los objetivos iniciales del proyecto. En lugar de hacer la traducci´on inversa, de braille a MusicXML, decidimos incluir otras funcionalidades a nuestra aplicaci´on: reproducci´on de la melod´ıa y modificaci´on en tiempo real de la partitura en tinta. 4.7. Reproducci´on de la melod´ıa Dada la reelaboraci´on de los objetivos iniciales, una de las funcionalidades que decidimos incluir en el proyecto como nuevo objetivo fue la reproducci´on de la partitura. En primer lugar investigamos sobre c´omo pasar la partitura de MusicXML a MIDI ya que, al ser ambos formatos muy populares, parec´ıa factible encontrar una librer´ıa que hiciese esta traducci´on. Sin embargo no fue as´ı. Tuvimos muchas dificultades para encontrar una librer´ıa de c´odigo abierto con este fin y no pod´ıamos invertir personas en desarrollar este m´odulo desde cero ya que hubiese supuesto eliminar otras tareas (ver figura 3.1). Por tanto, pasamos a buscar una soluci´on a partir del c´odigo desarrollado hasta el momento para la aplicaci´on, buscando alg´un punto a lo largo de la traducci´on de MusicXML a braille a partir del cu´al fuese m´as sencillo pasar la partitura a MIDI (u otro formato musical). As´ı, encontramos la soluci´on de usar la librer´ıa Manufaktura.Controls (Salamon, s.f.) que hab´ıamos empleado ya para representar una partitura en tinta a partir de un archivo MusicXML. Esta librer´ıa tiene m´etodos para generar un archivo MIDI a partir de clases 4.7. REPRODUCCI ´ ON DE LA MELOD´ IA 73 internas que representan la partitura y que se crean a partir de un archivo MusicXML. En primer lugar, pasamos de un string (SourceXml) que contiene el archivo MusicXML en su totalidad a un objeto Manufaktura.Controls.Model.Score que representa una partitura mediante el m´etodo Manufaktura.Controls.Linq.ToScore. A partir de dicha representaci´on de la partitura usamos el constructor Manufaktura.Controls.Desktop.Audio.MidiTaskScorePlayer para crear un objeto de tipo MidiTaskScorePlayer, que es un reproductor para una partitura en particular. La clase MidiTaskScorePlayer hereda de la clase abstracta ChannelSelectingTaskScorePlayer que a su vez hereda de la clase abstracta TaskScorePlayer que a su vez hereda de la clase abstracta ScorePlayer, como vemos en la figura 4.12. Un ScorePlayer proporciona los m´etodos Play, Stop yPause para controlar el reproductor y tiene un atributo State que nos indica qu´e est´a haciendo el reproductor en cada momento, sus posibles valores son Idle (inactivo), Paused (pausado) y Playing (reproduciendo). Con estos controles tendr´ıamos las herramientas suficientes para hacer un reproductor con opci´on de parar y pausar una melod´ıa. Sin embargo, cuando probamos un reproductor creado como acabamos de describir, descubrimos ciertas deficiencias en la librer´ıa de Manufaktura.Controls ya que la reproducci´on no funcionaba correctamente: se solapaban melod´ıas, hab´ıa notas que no sonaban, hab´ıa que detener una partitura manualmente para poder volver a reproducirla sin tener que reiniciar el programa, etc. Tuvimos entonces que meternos en el c´odigo de esta librer´ıa y estudiar clase por clase qu´e estaba fallando, ya que la librer´ıa viene sin documentaci´on. Finalmente descubrimos que todos los problemas del reproductor se deb´ıan a dos factores: 1. Cuando se acaba de reproducir una partitura, el estado permanec´ıa en Playing, cuando deber´ıa pasar a ser Idle. Esto imped´ıa distinguir cuando pod´ıamos reproducir de nuevo la partitura y cuando no; no pod´ıamos gestionar cuando permit´ıamos pulsar el bot´on de reproducir para evitar solapamientos en el audio. 2. Al reproducir una partitura se usa un iterador para recorrer las estructuras internas que forman el archivo de audio. Al pausar y volver a reproducir una partitura, se mueve el iterador antes de volver a reproducir de forma que en ocasiones se pierden notas en el audio. Figura 4.12: Diagrama de algunas clases de Manufaktura.Controls Gracias a que el c´odigo de Manufaktura.Controls tiene licencia MIT, hemos podido modificar sus clases para corregir estos bugs. Las funciones PlayInternal, Play, Pause y 80 CAP´ ITULO 5. EXPERIMENTACI ´ ON Al terminar la primera parte blindfolded, los participantes descubrieron sus ojos y probaron LiveDots desde el punto de vista de un usuario vidente. Las tareas visuales eran: abrir una partitura, modificarla, guardar los cambios e identificar esos cambios en la partitura en braille usando el lector de pantalla. La primera parte del experimento comprob´o si los usuarios ciegos pueden usar la aplicaci´on LiveDots sin ayuda externa (RQ2) y la segunda parte si las personas videntes sin conocimiento sobre braille musical pueden utilizar la aplicaci´on (RQ3). Adem´as, probar la aplicaci´on desde el punto de vista de ambos usuarios finales permite a los participantes evaluar si LiveDots es ´util para incluir a un estudiante ciego en una clase de m´usica (RQ1). Por ´ultimo, hicieron un cuestionario con cuatro partes, cada una relacionada con una de las preguntas de la investigaci´on. La duraci´on de la prueba fue de unos 30 minutos, incluyendo el uso de la aplicaci´on y cuestionario. 5.6. Material e instrumentos Para realizar el experimento se facilit´o a los participantes la aplicaci´on LiveDots que usaron junto al revisor de pantalla JAWS. 5.6.1. Cuestionario El cuestionario ten´ıa dos preguntas iniciales de s´ı/no. La primera era si consideraban que usar aplicaciones inform´aticas para conseguir partituras en braille facilita la tarea en comparaci´on a la forma tradicional de imprimirlas en papel perforado, y la segunda era si el participante conoc´ıa previamente alguna aplicaci´on de traducci´on o lectura de partituras en braille. Nuestra hip´otesis era que las respuestas ser´ıan s´ı y no, respectivamente. Esto resaltar´ıa la necesidad de una aplicaci´on como LiveDots para hacer esta traducci´on y lectura, justificando as´ı de forma afirmativa la primera pregunta de investigaci´on (RQ1). Despu´es de estas dos preguntas, el cuestionario constaba de cuatro partes diferentes. Las tres primeras valoradas en escala Likert-5, siendo 1 la peor puntuaci´on para la aplicaci´on y 5 la mejor. La tabla 5.1 describe estas tres partes. Por ´ultimo, hab´ıa una pregunta abierta para sugerir mejoras de la aplicaci´on LiveDots. Cuadro 5.1: Resumen del cuestionario Variable medida Instrumento Tipo C´omo se calcula N´umero de preguntas Rango Utilidad de LiveDots Test blindfolded y visual Escala Likert-5 Media de los valores de las preguntas 5 1-5 Usabilidad de LiveDots para usuario invidente Test blindfolded Escala Likert-5 Media de los valores de las preguntas 5 1-5 Usabilidad de LiveDots para usuario vidente Test visual Escala Likert-5 Media de los valores de las preguntas 5 1-5 5.7. RESULTADOS 81 5.7. Resultados Tras realizar el experimento, obtuvimos 7 respuestas al cuestionario. La baja tasa de respuesta se debe, una vez m´as, a la inesperada situaci´on de pandemia mundial que no nos permiti´o realizar el experimento en las instalaciones de la ONCE ni reunir a m´as personas para que probasen la aplicaci´on. Dicho esto, logramos obtener y analizar los resultados de la mejor manera posible. Para las 5 preguntas de escala Likert-5 calculamos la media de las respuestas obtenidas en cada pregunta y los resultados son los que se muestran en la figura 5.3. Figura 5.3: Resultados de las preguntas Likert-5 En la tabla se distinguen en por colores tres secciones diferentes. Cada secci´on est´a pensada para ayudar a responder una de las preguntas de investigaci´on. La primera secci´on (correspondiente a RQ1) contiene las preguntas relacionadas con la utilidad de la aplicaci´on (U1-U3) y con la probabilidad de que los participantes usen o recomienden la aplicaci´on (P1-P2). La segunda secci´on (correspondiente a RQ2) pregunta con qu´e facilidad los participantes hicieron las distintas tareas blindfolded (con los ojos vendados) (B1-B5). La tercera secci´on (correspondientes a RQ3) se corresponde con la parte visual de la prueba (sin los ojos vendados) y pregunta c´omo de f´acil encontraron los participantes las diferentes tareas (S1-S4) y si se requer´ıa conocimiento previo sobre braille musical (K1). Para cada grupo de preguntas relacionadas, calculamos la media aritm´etica de las respuestas medias y la representamos en un gr´afico de caja (figura 5.4). Por ´ultimo, para las preguntas de s´ı/no 82 CAP´ ITULO 5. EXPERIMENTACI ´ ON obtuvimos que el 100 % de los participantes piensa que el uso de aplicaciones inform´aticas hace m´as sencilla la obtenci´on de una partitura braille en comparaci´on con los m´etodos tradicionales. Y el 85,7 % de los participantes no conocen ninguna aplicaci´on inform´atica para la traducci´on y/o lectura de partituras en Braille. Figura 5.4: Diagrama de cajas de las distintas secciones estudiadas 5.8. Discusi´on de los resultados A lo largo de esta secci´on, trataremos de responder a las preguntas de investigaci´on expuestas en la secci´on 5.3 usando los resultados expuestos en el apartado anterior. En primer lugar, observamos la necesidad de una aplicaci´on como LiveDots en el hecho de que aunque todos los participantes (100 %) piensan que el uso de aplicaciones inform´aticas facilita la tarea de obtener partituras en braille, casi ninguno (14 %) conoce una aplicaci´on para ello. En cuanto a probar la utilidad de la aplicaci´on LiveDots (RQ1) es necesario probar primero su usabilidad (RQ2, RQ3 ), por tanto, responderemos a las preguntas de investigaci´on en ese orden. RQ2. ¿Puede una persona ciega usar la aplicaci´on LiveDots sin ninguna ayuda externa? S´ı. Los resultados de la prueba blindfolded muestran que la aplicaci´on puede ser utilizada f´acilmente usando ´unicamente el teclado con JAWS como lector de pantalla (4.36/5 en la usabilidad para invidentes B1-B5). RQ3. ¿Puede una persona vidente con conocimientos musicales que no sabe braille musical usar la aplicaci´on LiveDots? S´ı. Los resultados de la prueba visual muestran que los participantes sin ning´un conocimiento de braille musical podr´ıan utilizar la aplicaci´on sin ning´un problema (4.33/5 en usabilidad para videntes S1-S4). De hecho, la mayor´ıa de los participantes (85 %) piensa que se necesitan poco o ning´un conocimiento sobre braille musical para utilizar la aplicaci´on. 5.8. DISCUSI ´ ON DE LOS RESULTADOS 83 RQ1. ¿Puede la aplicaci´on LiveDots ayudar a incluir a un alumno ciego en una clase de m´usica? S´ı. Despu´es de realizar la prueba blindfolded y la visual, los participantes piensan que la aplicaci´on y sus funcionalidades pueden ser ´utiles para integrar a un estudiante ciego en una clase de m´usica (4,38/5 en utilidad U1-U3) y es probable que usen o recomienden la aplicaci´on (4,08/5 en P1-P2). Adem´as, RQ2 yRQ3 muestran que la aplicaci´on tambi´en es utilizable, lo cual es un requisito necesario para que sea ´util. 84 CAP´ ITULO 5. EXPERIMENTACI ´ ON Cap´ıtulo 6 Aportaci´on individual 6.1. ´ Oscar D´ıaz Ribagorda El proyecto comenz´o con la propuesta de la ONCE para realizar un programa que ayudara con la inclusi´on de alumnos invidentes en aulas de m´usica. Empezamos con una reuni´on con algunos encargados de la ONCE que nos indicaron el objetivo e inter´es de una aplicaci´on de estas caracter´ısticas. Tras esto nos pusimos a investigar todos los diferentes recursos que nos pudieran ayudar a encontrar una soluci´on. Yo me encargu´e de estudiar c´omo se adaptan los ordenadores a trav´es de la l´ınea braille y el revisor de pantalla para servir como herramienta a las personas invidentes. Esta investigaci´on, junto con la ayuda de nuestros tutores y las sugerencias de la ONCE nos ayud´o a escoger a JAWS como revisor de pantalla y el lenguaje de programaci´on C# como lenguaje de desarrollo. Adem´as de esto, investigu´e que soluciones se han dado a problemas parecidos (sin estar necesariamente relacionados con la m´usica) centr´andome en qu´e programas inform´aticos se utilizan en la educaci´on de alumnos ciegos. Varios de los dise˜nos e ideas de concepto nos sirvieron para inspirar nuestra soluci´on. Una de las aplicaciones que m´as nos ha inspirado en el dise˜no es el editor de braille cient´ıfico EDICO. Por ´ultimo, me inform´e de c´omo se representa la m´usica en braille y busqu´e diferentes recursos, como el manual internacional de musicograf´ıa braille (Krolick, 1996), para que mis compa˜neros y yo pudi´eramos utilizar durante el desarrollo de la aplicaci´on. Durante toda esta b´usqueda de recursos fuimos recolectando cualquier fuente que nos pudiera ser de ayuda m´as adelante y hubo una publicaci´on que encontr´e (A Transcription System from MusicXML Format to Braille Music Notation, Gotoh y col., 2008) que result´o ser una gran contribuci´on al desarrollo del programa. Tras el estudio del estado del arte, nos propusimos empezar a programar cuanto antes e ir logrando versiones cada vez m´as funcionales de la aplicaci´on. De esta forma, evit´abamos el riesgo de organizar un proyecto que tuviera un tama˜no fuera de nuestras posibilidades. Las primeras funcionalidades del programa las fuimos a˜nadiendo de forma colectiva pues, en esta etapa, est´abamos entrando en contacto con el lenguaje de programaci´on C# (en particular con los proyectos Wpf) que ninguno hab´ıamos utilizado con anterioridad. En cuanto nos 85 86 CAP´ ITULO 6. APORTACI ´ ON INDIVIDUAL empezamos a familiarizar con el entorno y pusimos toda la informaci´on y propuestas sobre la mesa, logramos entre los tres tener un primer dise˜no conceptual de la aplicaci´on sobre el cual poder distribuir el trabajo. La primera gran funcionalidad que logramos implementar fue la representaci´on de partituras en tinta a partir de ficheros en formato MusicXml. Para esto hicimos uso de una librer´ıa de c´odigo libre (Manufaktura) que encontramos durante nuestro estudio del estado del arte (Salamon, s.f.). Durante esta etapa ya ten´ıamos pensado que el braille se iba a mostrar a la vez en la pantalla pero dado que no hab´ıamos implementado a´un la traducci´on, decidimos mostrar el documento MusicXml donde deber´ıa ir el braille. En la segunda etapa nos centramos en la traducci´on de MusicXml a braille. En este momento ya ten´ıamos suficientemente organizado el proyecto como para poder distribuir las diferentes tareas aunque continu´aramos ayud´andonos y poniendo en com´un todos los avances. En mi caso, fue en este momento cuando se me ocurri´o que podr´ıamos utilizar las ideas que se propon´ıan en la publicaci´on de Gotoh y col., 2008 para implementar la traducci´on de MusicXml a braille en C#. Para ello, propuse implementar un ´arbol diferente para cada una de las partes y programar una funci´on que convirtiera de un ´arbol al otro. Mi compa˜nero Lucas de Torre y yo nos encargamos de implementar esta funci´on de traducci´on entre los ´arboles. Esto fue importante hacerlo entre dos personas porque hac´ıa falta que hubiera coherencia entre los atributos de los diferentes objetos de los ´arboles y la forma en la que convert´ıamos los objetos de un ´arbol a otro. Con esta din´amica logramos que el programa convirtiera correctamente de un archivo MusicXml a un ´arbol de elementos braille. A partir de aqu´ı, era necesario que cada elemento braille supiera c´omo se escrib´ıa para poder mostrarlo por pantalla y se dar´ıa por finalizada la traducci´on de partitura en tinta a braille. Con la traducci´on a braille lograda solo nos quedaba una gran funcionalidad por cumplir, esto consist´ıa en la accesibilidad de la aplicaci´on. Dentro de la accesibilidad de la aplicaci´on quer´ıamos incluir la lectura de los elementos musicales en braille por el revisor de pantalla. Esta parte result´o ser la m´as complicada de todas ya que tuvimos que entender bien el funcionamiento de JAWS y c´omo conectar nuestra aplicaci´on con este revisor de pantalla para que leyera los elementos musicales que representaba el braille mostrado. Yo me encargu´e de entender bien el funcionamiento y la documentaci´on de JAWS. En este proceso, realic´e pruebas para ver que funciones de JAWS podr´ıamos sobrescribir para lograr el comportamiento que quer´ıamos con el revisor de pantalla. Encontr´e que la funci´on SayCharacter ser´ıa la m´as adecuada y me encargu´e de programar el Script para que JAWS funcionara como quer´ıamos con nuestra aplicaci´on. Con esto y con las partes de las que se encargaron mis compa˜neros logramos llegar a una soluci´on que diferencia a nuestra aplicaci´on de la mayor´ıa del resto de aplicaciones accesibles. Adem´as del revisor de pantalla, acabamos entre todos la implementaci´on del resto de funcionalidades que hacen que nuestra aplicaci´on se accesible. Una vez tuvimos una aplicaci´on con las funcionalidades que quer´ıamos, nos centramos en a˜nadir y comprobar diferentes partes de la aplicaci´on que resultar´ıan en una soluci´on m´as completa. En mi caso, utilic´e las diferentes herramientas que nos proporcionaba el lenguaje (Binding) y la librer´ıa de Manufaktura (edici´on) para permitir la modificaci´on en tiempo real de la altura de las notas. Esta funcionalidad se puede ampliar si se ampl´ıa las posibilidades de edici´on de la partitura en tinta puesto que nuestra aplicaci´on ya utiliza una traducci´on a braille de la partitura en tiempo real. 6.2. CLAUDIA GUERRERO GARC´ IA-HERAS 87 Art´ıculo LiveDots: Realtime Interactive Braille Music Translator to Integrate Blind Students into Music Classes El desarrollo de este proyecto y la investigaci´on realizada para su concepci´on y dise˜no nos pareci´o, a nuestros tutores y a nosotros, de gran importancia para el avance en el uso de tecnolog´ıas para la inclusi´on de personas ciegas. Con esta idea, decidimos realizar un experimento formal para comprobar nuestras sospechas. En este experimento, prepar´e junto con mis compa˜neros el cuestionario que ´ıbamos a utilizar y prepar´e la aplicaci´on para su f´acil distribuci´on. Adem´as, me encargu´e de realizar la prueba con tres participantes. Con la informaci´on recopilada del experimento decidimos escribir un art´ıculo para el congreso ICCE 2020 en el campo del uso de ordenadores en la educaci´on. A la hora de escribir este art´ıculo, yo me encargu´e de explicar el desarrollo de la aplicaci´on LiveDots (Apartado 3 del Anexo A). Para ello, realic´e un esquema conceptual de la aplicaci´on para organizar correctamente todas las partes importantes. Despu´es expliqu´e de forma concisa cada parte de la aplicaci´on LiveDots centr´andome en los aspectos innovadores de cada una. Tanto la escritura del art´ıculo como el desarrollo del resto del proyecto han sido una gran experiencia que me ha servido no solo para aprender mucho sino para querer aprender m´as. 6.2. Claudia Guerrero Garc´ıa-Heras El primer paso del proyecto fue hacer un estudio del estado del arte para familiarizarse con el campo del braille musical, de las aplicaciones accesible y de las aplicaciones musicales. Como primera aportaci´on me encargu´e de la investigaci´on acerca de las aplicaciones de edici´on de partituras. Al analizar estas aplicaciones me di cuenta de que casi ninguna era completamente accesible ya que pierden funcionalidades al usar un revisor de pantalla. Este problema se debe en la mayor´ıa de los casos a que el desarrollo de la aplicaci´on se hace pensando ´unicamente en los usuarios videntes y se a˜nade la accesibilidad como una caracter´ıstica a posteriori. Al hacer esto es posible que nos encontremos con situaciones que son muy complicadas de transcribir con un revisor. El origen por tanto del problema es un sesgo a la hora de desarrollar software. Por tanto, mi estudio aport´o que para poder hacer una aplicaci´on totalmente accesible necesit´abamos pensar en desarrollar software tanto para videntes como para invidentes desde el comienzo del desarrollo de la aplicaci´on. Tras implementar un primer boceto de la aplicaci´on de forma colaborativa, llegamos al problema de c´omo representar pentagramas y braille en una aplicaci´on WPF. Yo me encargu´e de resolver c´omo representar cajetines braille por pantalla en un formato legible y c´omo saber qu´e cajetin braille estamos representando sin necesidad de saber braille. Para ello realic´e en primer lugar un diccionario que nos permitiese usar la fuente TrueType de cajetines braille edico es br6.tt que nos proporcion´o la ONCE. Era necesario este paso intermedio porque esta fuente estaba pensada para EDICO, que es un editor cient´ıfico y las correspondencias entre caracteres ASCII y s´ımbolos de la fuente estaba orientada a 88 CAP´ ITULO 6. APORTACI ´ ON INDIVIDUAL representar s´ımbolos cient´ıficos. El diccionario desarrollado establec´ıa una correspondencia entre cadenas de n´umeros que indican los puntos resaltados en un cajet´ın braille y el caracter ASCII correspondiente a dicho cajet´ın en la fuente. De esta manera di una soluci´on general al problema. El siguiente paso fue la traducci´on de una partitura de MusicXML a braille. En esta etapa me encargu´e de la traducci´on de ´arbol MusicXML a braille. Para conseguir una secuencia de caracteres braille que represente el ´arbol a˜nad´ı atributos de representaci´on a cada una de las clases del ´arbol braille que asignan a cada elemento los cajetines braille correspondientes. Posteriormente un recorrido del ´arbol en el orden correcto proporciona la secuencia de braille deseada. Para realizar esta tarea era necesario saber qu´e s´ımbolos braille asignar a cada s´ımbolo, ´esta fue la parte que m´as tiempo llev´o. Para realizar esta correspondencia us´e el est´andar del manual internacional de musicograf´ıa braille (Krolick, 1996). Fue en general un proceso de aprendizaje y familiarizaci´on con el braille muy necesario ya que no sab´ıa nada al respecto antes de comenzar el proyecto. Para la correcta representaci´on del braille en linea braille es importante hacer los saltos de l´ınea en braille de manera adecuada, lo cual tiene la complicaci´on de que en braille hay elementos que se representan de distinta forma en funci´on de si caben en la l´ınea actual o no. Implement´e tambi´en un sistema de contadores para solucionar esta cuesti´on. En la siguiente etapa trabajamos en configurar el lector de pantalla JAWS para que funcionase correctamente con la aplicaci´on y conseguir que leyese las figuras musicales correspondientes al pasar el cursor por los cajetines braille. Mi aportaci´on en esta etapa fue desarrollar e implementar una soluci´on que nos permitiese que al recorrer los elementos braille con el cursor se leyesen los s´ımbolos musicales correspondientes con el revisor de pantalla. Esta tarea tiene la complicaci´on de que mientras que muchos de los elementos que se representan en tinta con un ´unico s´ımbolo se corresponden con varios cajetines braille y el n´umero de cajetines con los que se representa no solo depende de la figura en s´ı, sino tambi´en del contexto en el que se encuentre. Implement´e por tanto un sistema de tres listas para llevar toda la informaci´on necesaria como se explica en la secci´on 4.5.1.5. Como ´ultima etapa de desarrollo de la aplicaci´on, buscamos una forma de reproducir la partitura como funcionalidad a˜nadida. Buscamos una librer´ıa para pasar a MIDI desde MusicXML, pero al final encontr´e una forma m´as sencilla usando directamente la librer´ıa Manufaktura.Controls que hab´ıamos usado para representar la partitura en tinta. Cre´e una primera versi´on de reproductor con opci´on de reproducir y parar pero me di cuenta de que las clases por esta librer´ıa no funcionaban como era esperable. Una parte importante de mi aportaci´on fue arreglar los bugs de las librer´ıas. La librer´ıa ven´ıa sin documentaci´on por tanto tuve que analizar directamente el c´odigo para ver que estaba pasando, encontr´e un par de bugs (ver secci´on 4.7) y los solucion´e cambiando el c´odigo de algunas clases para nuestro proyecto, lo que pude hacer gracias a que la librer´ıa tiene licencia MIT. Art´ıculo LiveDots: Realtime Interactive Braille Music Translator to Integrate Blind Students into Music Classes Este proyecto es una prueba de concepto sobre c´omo generalizar la idea de interactividad mediante modificaciones en tiempo real de EDICO a otros campos. Una parte esencial del 6.3. LUCAS DE TORRE BARRIO 89 proyecto es probar la aplicaci´on y difundir el proyecto para que pueda tener repercusi´on en m´as ´areas del conocimiento. Para ello dise˜namos un experimento en el que distintos usuarios probasen y valorasen la aplicaci´on. Yo me encargu´e de supervisar la prueba de pruebas de tres participantes. Por ´ultimo, tras ver la exposici´on de los resultados hecha por mis compa˜neros me encargu´e de discutir los resultados obtenidos en el experimento y de ver c´omo respond´ıan a las preguntas de investigaci´on. Para divulgar este proyecto, escribimos un art´ıculo para el congreso ICCE 2020 (International Conference on Computers in Education) que es un congreso Core B organizadopor APSCE (Asia-Pacific Society for Computers in Education). El art´ıculo est´a centrado en el desarrollo del experimento y la discusi´on de los resultados obtenidos. Est´a enfocado a demostrar que, efectivamente, la aplicaci´on LiveDots senta un precedente de que se puede generalizar la idea de interactividad en tiempo real propuesta por el proyecto EDICO a los campos art´ısticos. Mi principal aportaci´on fue concentrar la informaci´on sobre la escena de la ense˜nanza musical a personas invidentes para poner en contexto el proyecto y demostrar su necesidad y utilidad. 6.3. Lucas de Torre Barrio En el estudio del estado del arte, realizado con la intenci´on de adquirir conocimientos sobre los avances realizados en el uso de la inform´atica para facilitar la accesibilidad (tanto en el campo de la m´usica como en otros campos, como el de las matem´aticas), me enfoqu´e en el estudio de formatos de notaci´on musical y en las aplicaciones musicales relacionadas con la accesibilidad. La intenci´on era ver qu´e formato usan mayormente las aplicaciones musicales accesibles y qu´e posibilidades proporcionan estas aplicaciones. Los formatos musicales m´as extendidos son MIDI y MusicXML, siendo este ´ultimo el m´as utilizado en aplicaciones accesibles. El programa BME permite la edici´on de partituras braille para despu´es exportar el archivo en formato MusicXML (algo que no hemos implementado en nuestra aplicaci´on, porque habr´ıa sido inabarcable). FreeDots es una aplicaci´on que traduce un archivo en formato MusicXML a uno en notaci´on de braille musical, parecido al programa GOODFEEL, y Lime Lighter est´a dise˜nado para personas con visibilidad reducida. As´ı, la idea que tuvimos para nuestra aplicaci´on era utilizar el formato MusicXMLpara importar y exportar partituras e implementar las caracter´ısticas de estas aplicaciones (no hemos implementado la de BME por no ser objeto de este trabajo, pero la aplicaci´on ha sido dise˜nada con la idea de facilitar futuras ampliaciones), con la funcionalidad a˜nadida de la interactividad en tiempo real. Despu´es, programamos el primer dise˜no de la aplicaci´on. Esto lo hicimos en grupo (como gran parte del proyecto) porque era nuestro primer contacto desarrollando con WPF. Una vez finalizado un primer dise˜no, implementamos la representaci´on de la partitura en tinta y del texto MusicXML correspondiente a dicha partitura. La siguiente parte fue conseguir representar la estructura de una partitura en formato MusicXML y traducirla a notaci´on de braille musical. Mi parte aqu´ı se centr´o en la imple- 96 CAP´ ITULO 8. CONCLUSIONES or her music knowledge. In addition, the results also proved that a blind person can use the application without external assistance. All of this concludes that LiveDots can be used in music classes, with no other tools than the application itself, since both the teacher and the blind student can use the application without any external assistance. Furthermore, this part of the project led us to the following conclusion which we consider fundamental: it is not only important that software whose main target audience is sighted is extended to be accessible, but also the other way around. That is, it is also important that applications whose target audience is blind people are designed to be easily used by sighted people (who are not used to the same type of keyboard management and who use visual tools, such as the mouse). If we hadn’t taken this into account, testing the application would have been really complicated, as the way sighted people use the computer is very different from that of blind people. As an overall conclusion of the experiment, LiveDots is a real-time interactive application related to the field of music which has been empirically proved useful and usable. Therefore, this project has shown that the EDICO project idea of real-time interactivity (translation between ink and Braille with real-time modifications) can be generalized to other fields in order to achieve interactivity between sighted and blind people and thus achieve a better integration of the blind student in the classroom. This generalisation from a scientific field to an artistic field such as music opens the door to a whole series of applications that will bring this philosophy to other areas of knowledge. In order to disseminate the idea of LiveDots, we have written an article called LiveDots: Real time Interactive Braille Music Translator to Integrate Blind Students into Music Classes. The article, which is structured in a similar way to this final dissertation thesis, is more focused on the experimental part. It explains in detail the development of the application, the objective of the experiment, the experimental design, the results and the discussion of the test carried out. The paper has been sent to the ICCE 2020 conference (28th International Conference on Computers in Education) which is a Core B conference organized by APSCE (Asia-Pacific Society for Computers in Education). Bibliograf´ıa ¿Qu´e es la ONCE? Historia de la Organizaci´on, empleo y acci´on. (s.f.). Recuperado el 25 de abril de 2020, desde https://www.once.es/conocenos Abramo, J. M. & Pierce, A. E. (2013). An ethnographic case study of music learning at a school for the blind. Bulletin of the Council for Research in Music Education, (195), 9-24. https://doi.org/10.5406/bulcouresmusedu.195.0009 Accessibility in the Store - UWP applications — Microsoft Docs. (s.f.). Recuperado el 15 de junio de 2020, desde https://docs.microsoft.com/en-us/windows/uwp/design/ accessibility/accessibility-in-the-store Accessible calculators - ATWiki. (s.f.). Recuperado el 25 de abril de 2020, desde http : //atwiki.assistivetech.net/index.php/Accessible%7B%5C %7Dcalculators Audacity Team. (s.f.). Opciones de Accesibilidad - Audacity Manual. https://ttmanual. audacityteam.org/man/Accessibility/es Avid Technology. (s.f.). Sibelius: composition and notation software. Recuperado el 6 de abril de 2020, desde https://www.sibelius.com/helpcenter/article.php?id=444% 7B%5C&%7Dsearchid=5143573 Benward, B. & Saker, M. N. (2009). Music in theory and practice (8.aed., Vol. 1). McGrawHill. Bitteur, H. (s.f.). GitHub - Audiveris/audiveris: Latest generation of Audiveris OMR engine. https://github.com/Audiveris/audiveris Borges, J. A. & Tom´e, D. (2014). Teaching Music to Blind Children: New Strategies for Teaching through Interactive Use of Musibraille Software MicroFenix View project Mapavox View project. Procedia - Procedia Computer Science,27, 19-27. https: //doi.org/10.1016/j.procs.2014.02.004 Braille Music Editor (BME). (s.f.). Recuperado el 6 de mayo de 2020, desde https://www. compartolid.es/braille-music-editor-bme/ Braille Music Software for Blind: Magnified Music for Low Vision by Dancing Dots. (s.f.). Recuperado el 6 de mayo de 2020, desde https://www.dancingdots.com/main/ index.htm Braille Translation Software - Index Braille. (s.f.). Recuperado el 25 de abril de 2020, desde https://www.indexbraille.com/en-us/support/braille-editors Braille Translator. (s.f.). Recuperado el 15 de junio de 2020, desde https://www.brailletranslator. org/ Buhagiar, M. A. & Tanti, M. B. (2011). WORKING TOWARD THE INCLUSION OF BLIND STUDENTS IN MALTA: THE CASE OF MATHEMATICS CLASSROOMS (MALTA’DAK˙ I G ¨ ORME ENGELL˙ I¨ O˘ GRENCILERIN KATILIMINI SA ˘ GLAMAYA 97 98 BIBLIOGRAF´ IA Y¨ ONELIK C¸ALIS¸MA: MATEMATIK DERSLERI ¨ ORNE ˘ G˙ I) (inf. t´ec. N.o1). http: //eku.comu.edu.tr/index/7/1/mabuhagiar%7B%5C %7Dmbtanti.pdf Burgos-Bordonau, E. (s.f.). Las musicograf´ıas de Abreu y Llorens: dos sistemas alternativos a la recepci´on del Braille en Espa˜na. Burkholder, J. P., Grout, D. J. & Palisca, C. V. (2008). Historia de la M´usica Occidental. Campos-Arcaraz, T. (2017). A Proposal for a Music Writing for the Visually Impaired. Springer, Cham. https://doi.org/10.1007/978-3-319-47337-6 6 Capozzi, A., De Prisco, R., Nasti, M. & Zaccagnino, R. (2012). Musica parlata : AAA methodology to teach music to blind people, En ASSETS’12 - Proceedings of the 14th International ACM SIGACCESS Conference on Computers and Accessibility, New York, New York, USA, ACM Press. https://doi.org/10.1145/2384916.2384975 Carenas, J. M., Cabra, A. B., Mata-Garc´ıa, M. G., Gea, P. C. & Hern´andez, D. H. (2018). Pr´acticas Edico ¿ Qu´e es Edico ?, 100-108. CESyA. Centro Espa˜nol del Subtitulado y la Audiodescripci´on. (s.f.). Pautas de accesibilidad — CESyA — Centro Espa˜nol del Subtitulado y la Audiodescripci´on. Recuperado el 25 de abril de 2020, desde https://www.cesya.es/comunicacion/pautas Comunidad de desarrolladores de MuseScore. (s.f.). MuseScore Accessibility. https://musescore. org/en/handbook/3/accessibility CTI. Centro de Tiflotecnolog´ıa e Innovaci´on de la ONCE. (s.f.). Recuperado el 15 de junio de 2020, desde http://cidat.once.es/ CTI. Editor Cient´ıfico ONCE. (s.f.). Recuperado el 15 de junio de 2020, desde http://cidat. once.es/home.cfm?id=2351%7B%5C&%7Dnivel=2 DanLisMusic. (s.f.). Finale and Sibelius User Reviews - Composer’s Toolbox. Recuperado el 21 de abril de 2020, desde https://composerstoolbox.com/2018/08/14/finalesibelius-user-reviews/ Dannenberg, R. & Mazzoni, D. (s.f.). Audacity, editor de audio libre. Recuperado el 10 de junio de 2020, desde https://audacity.es/ Daron, V. (s.f.). GitHub - vdaron/MusicXml.Net: Quick C# parser for MusicXML. https: //github.com/vdaron/MusicXml.Net de Cand´e, R. (2002). Nuevo diccionario de la musica. Grasindo. El protocolo y el formato MIDI. (s.f.). Recuperado el 6 de mayo de 2020, desde http : //www.disca.upv.es/adomenec/IASPA/tema5/Midi.html Encelle, B., Jessel, N., Mothe, J., Ralalason, B. & Asensio, J. (2009). BMML: Braille Music Markup Language (inf. t´ec.). Eyewire News. (s.f.). ObjectiveEd Joins Microsoft’s AI for Accessibility Program to Develop Braille AI Tutor Platform – Eyewire News. Recuperado el 25 de abril de 2020, desde https://eyewire.news/articles/objectiveed-joins-microsofts-ai-for-accessibilityprogram-to-develop-braille-ai-tutor-platform/ Frederick, b. W. (2009). Quality of Experience in Mainstreaming and Full Inclusion of Blind and Visually Impaired High School Instrumental Music Students (inf. t´ec.). Freedom Scientific. (s.f.). JAWS®– Freedom Scientific. Recuperado el 3 de junio de 2020, desde https://www.freedomscientific.com/products/software/jaws/ Giuseppe Paccini, A. (s.f.). Bme2 Veia progetti... Recuperado el 5 de mayo de 2020, desde https://www.veia.it/en/bme2%7B%5C %7Dproduct Goldstein, D. (2000). Music pedagogy for the blind. International Journal of Music Education,os-35(1), 35-39. https://doi.org/10.1177/025576140003500112 Google TalkBack. (s.f.). Recuperado el 15 de junio de 2020, desde https://en.wikipedia.org/ wiki/Google%7B%5C %7DTalkBack BIBLIOGRAF´ IA 99 Gotoh, T., Minamikawa-Tachino, R. & Tamura, N. (2008). A web-based Braille translation for digital music scores, En Proceedings of the 10th international ACM SIGACCESS conference on Computers and accessibility, ACM. GW Micro. (s.f.). WindowsEyes-GW Micro. Recuperado el 15 de junio de 2020, desde http: //www.gwmicro.com/ Homenda, W. (2008). Breaking accessibility barriers: Computational intelligence in music processing for blind people. Studies in Computational Intelligence,107, 207-232. https://doi.org/10.1007/978-3-540-77662-8 9 Johnson, S. (2015). Understanding Is Seeing. https://doi.org /10.1093/OXFORDHB/ 9780199331444.013.7 Kent, D. (2012). What is Braille? Enslow Elementary. Krolick, B. (1996). New international manual of Braille music notation. Braille Press Zurich. Louis Braille - Wikipedia. (s.f.). Recuperado el 15 de junio de 2020, desde https://en. wikipedia.org/wiki/Louis%7B%5C %7DBraille MakeMusic. (s.f.). Finale — Music Notation Software That Lets You Create Your Way. https://www.finalemusic.com/ Moon type - Wikipedia. (s.f.). Recuperado el 25 de abril de 2020, desde https://en.wikipedia. org/wiki/Moon%7B%5C %7Dtype Musicolog´ıa digital - Fundaci´on Juan March. (s.f.). Recuperado el 28 de abril de 2020, desde https://www.march.es/bibliotecas/tme/musicologia/musicxml MusicXML to Braille converter. (s.f.). Recuperado el 6 de mayo de 2020, desde https : //musicxml2braille.appspot.com/ Naruedomkul, K. (2013). Aim-Math: An audio-based interactive media for learning mathematics. NatBraille : un transcripteur Braille libre. (s.f.). Recuperado el 25 de abril de 2020, desde http://natbraille.free.fr/ Nicotra, G. & Quatraro, A. (2008). CONTRAPUNCTUS Project: A new computer solution for braille music fruition, Springer, Berlin, Heidelberg. https://doi.org/10.1007/9783-540-70540-6 45 NV Access. (s.f.). NVDA-NV Access. Recuperado el 15 de junio de 2020, desde https : //www.nvaccess.org/about-nvda/ ObjectiveEd. (s.f.). Recuperado el 25 de abril de 2020, desde https://www.objectiveed.com/ ONCE. (s.f.). BRAITICO - Web de Educaci´on de la ONCE. Recuperado el 30 de mayo de 2020, desde https://educacion.once.es/braitico ONCE. (s.f.). Recuperado el 15 de junio de 2020, desde https://www.once.es/ Organizaci´on Nacional de Ciegos Espa˜noles - Wikipedia, la enciclopedia libre. (s.f.). Recuperado el 25 de abril de 2020, desde https://es.wikipedia.org/wiki/Organizaci% 7B%5C’%7Bo%7D%7Dn%7B%5C %7DNacional%7B%5C %7Dde%7B%5C % 7DCiegos%7B%5C %7DEspa%7B%5C∼%7Bn%7D%7Doles Perkins School for the Blind. (s.f.). Recuperado el 25 de abril de 2020, desde https://www. perkins.org/ Quaglia, B. W. (2015). Planning for Student Variability: Universal Design for Learning in the Music Theory Classroom and Curriculum. Music Theory Online,21(1). Repain, A., Marzin, A., Sacc, C., Royer, J., Lang, M., Kainz, M. S., Froment, N. & Loubatier, X. (s.f.). GitHub - mlang/freedots: MusicXML to Braille Music transcription. Recuperado el 1 de junio de 2020, desde https://github.com/mlang/freedots Rugman, D. (s.f.). Sibelius Access. http://www.musicaccess.co.uk/sibelius-access/ 100 BIBLIOGRAF´ IA Salamon, J. (s.f.). Manufaktura Controls - music engraving libraries for .NET. http:/ / musicengravingcontrols.com/en-US/Home/ Schweer, W. (s.f.). MuseScore: software gratuito de composici´on y notaci´on musical. https: //musescore.org/es Smaligo, M. A. (1998). Resources for Helping Blind Music Students. Music Educators Journal,85(2), 23-45. https://doi.org/10.2307/3399168 Talking Calculator on the AppStore. (s.f.). Recuperado el 25 de abril de 2020, desde https: //apps.apple.com/us/app/talking-calculator/id424464284 Traductor braille : Traduce de Braille a Texto. (s.f.). Recuperado el 15 de junio de 2020, desde http://traductorbraille.com/ Una Breve Historia de los Sistemas de Escritura T´actil para Lectores con Ceguera e Discapacidades Visuales. (s.f.). Recuperado el 25 de abril de 2020, desde http://www. tsbvi.edu/seehear/spring06/history-span.htm VoiceOver. (s.f.). Recuperado el 15 de junio de 2020, desde https://en.wikipedia.org/wiki/ VoiceOver W3C Music Notation Community Group. (s.f.). GitHub - tisimst/smufl: Standard Music Font Layout. https://github.com/tisimst/smufl Wallin, N., Merker, B. & Brown, S. (2001). The origins of music. Web de Educaci´on de la ONCE. (s.f.). Recuperado el 15 de junio de 2020, desde https: //educacion.once.es/ WebAIM. (s.f.). WebAIM: Screen Reader User Survey #7 Results. Recuperado el 15 de junio de 2020, desde https://webaim.org/projects/screenreadersurvey7/ ZoomText. (s.f.). Recuperado el 15 de junio de 2020, desde https://www.zoomtext.com/ Ap´endice A Art´ıculo LiveDots 101 LiveDots: Real time Interactive Braille Music Translator to Integrate Blind Students into Music Classes Claudia GUERRERO-GARCÍA-HERASa*, Óscar DÍAZ-RIBAGORDAa, Lucas DE-TORRE-BARRIOa, Borja MANEROa* & María GUIJARRO-MATA-GARCÍAa* aComplutense University of Madrid, Spain *[email protected], [email protected], [email protected] Abstract: Music is a universal cultural expression; however blind students may have difficulties to follow a sighted music class due to the lack of a common written music language between teacher and student. This problem is also present in other academic fields, like science. An approach to solve it is EDICO, a real time interactive Scientific Editor. We want to take the solution of real time interactivity to the music field. This paper presents the development process of a real time interactive solution called LiveDots and an experiment to test it in which we develop a real time interactive solution called LiveDots and test it with blindfolded users to check if it could help integration of a blind student in a music classroom. Results show that LiveDots was usable by both sighted and blindfolded users and that real time interactivity may be useful to integrate blind students in music class. These results open up a new horizon of solutions based on real time interactivity to ease blind and sighted students’ integration in the same class. Keywords: Accessibility, blind people, tiflotechnology, inclusive education, education, music, real time interactivity, Braille, Braille music, screen reader, Braille line, computer application. 1. Introduction Braille is the most extended method of tactile reading and writing amongst the blind. It is based on different combinations of embossed dots (Kent, 2012). The extension of Braille to the music field is known as Braille music. It is a transcription technique that allows to represent any conventional music score with accurate notation (de Candé, 2002). Musical Braille not only gives blind students a tool to understand and express music but also shapes how we think and talk about music and, by extension, how we analyse it (Abramo & Pierce, 2013; Johnson, 2015). However, blind students do not often receive the education needed to understand musical Braille notation and most schoolteachers do not know Braille neither how to facilitate the student's learning. The alternative for blind students in order to improve their musical skills is to attend a school for the blind. In this scenario, blind and non-blind students are taught using different teaching strategies leading to a dichotomy between music Braille and conventional music writing. The lack of familiarity with conventional music writing makes it more difficult for blind students to later join in an environment with sighted musicians, for example in music college or in an orchestra (Goldstein, 2000). There is a need to integrate blind and non-blind students in the same classroom and teach every one of them the essential knowledge to develop their musical skills (Quaglia, 2015; Buhagiar & Tanti, 2011). In other words, we want blind students to be able to follow a music class with mostly sighted students while learning Braille music notation and understanding the conception of print music. Some of the conventional strategies and tools used by blind or visually impaired students to facilitate participation in class are: enlarged print notation, fellow class members, parents or teachers reading the scores for them and use of Braille music notation whenever it is possible (Frederick & Moss, 2009; Smaligo, 1998). All these tools need either the help of a person who transcribes the score orally or a teacher who knows musical Braille and teaches it to the student which may not always be possible. This makes the student dependent on people around him. The advance of technology in recent years has given the chance to ease the integration of blind students. There are projects like Braitico (ONCE, n.d.), an inclusive Braille literacy method developed by the ONCE (National Organization of the Blind in Spain) intended for children to learn Braille. In the field of music, there are computer programs designed to enable visually impaired people to view and edit music in Braille notation students (Homenda, 2008) like Braille Music Editor (Veia Progetti, n.d.), studies about how to teach Braille music to children using computer applications (Nicotra and Quatraro, 2008; Borges y Tomé, 2014), approaches to teach music to blind studies using talking music instead of Braille (Capozzi, Prisco, Nasti & Zaccagnino, 2012), score translation programs from print music into Braille music and vice versa like FreeDots (Repain et al, n.d.) and there is even a standard to share Braille music notation in the web called Braille Music Markup Language (Encelle, Jessel, Mothe, Ralalason & Asensio 2009). These applications allow the teacher to create a print score with an editing score program, like MuseScore (Schweer, n.d.), and to translate it into Braille using a translation program so the student can read it. However, interactivity is missing: if the teacher wants to modify an element of the score, first, the changes should be done in the editing score program, then exported and translated into Braille with the translation program and finally the student could see the changes. This is a slow process that does not integrate a blind student into the usual development of a music class. The problem of integrating blind students in the classroom is present in almost every field in education. There are many different approaches for a solution, like Aim-Math, an interactive-enhanced mathematics learning system for blind and visually impaired students using text-to-speech to read aloud math expressions (Naruedomkul, 2013). However, this approach is not friendly for a class of blind and non-blind students. Another approach is EDICO (Scientific Editor ONCE) (Carenas, Cabra, Mata-García, Gea & Hernández, 2018), a project promoted by the ONCE and developed in cooperation with the University Complutense of Madrid. It is an accessible mathematics, physics and chemistry editor. It translates scientific language in real time from printed writing into Braille and vice versa. This allows blind students to follow a science lesson interacting in real time with a teacher who doesn’t know Braille. After the success of EDICO, the ONCE wanted to develop similar solutions to integrate blind students in other subjects, like music. This is how the idea of LiveDots was born: a music editor that translates music scores from print music to Braille music in real time. LiveDots is an innovative desktop application which allows users to read a score in Braille and in print at the same time and to modify the print score and see the changes in the Braille score in real time. This would give blind students an interactive music learning environment. In this paper we are going to study the effectiveness of using real time interactive applications like LiveDots in order to integrate a blind student in a sighted class. This paper is structured as follows: In section 2 we talk about the main objectives of the study and we propose three research questions we want to answer to. Section 3 illustrates the design of the application and gives an overview about its development. Section 4 introduces an experiment we are performing to check usefulness and usability. In section 5 we show the results from the experiment and in section 6 we discuss these results. Finally, in section 7 we describe the conclusions drawn from this project and illustrate the long way to go with the presented and future related projects. 2. Objectives The main objective of this study was to check if the application LiveDots is useful to include a blind student in a music class. We believed that being able to translate scores into Braille in real time would increase the interaction between teacher and blind students improving blind students' participation. To verify this theory, we formulate the following research questions: RQ1. Can the application LiveDots help with the inclusion of a blind student in a music class? In addition, to test the utility of the application LiveDots, it is important to verify its usability. Therefore, another goal of this test was to verify usability for both target users: music teachers and blind music students. On the one hand, it is required that a blind person can use the application LiveDots without any assistance for the application to be useful. Thus, the keyboard shortcuts and the screen reader must be practical and easy to use. To check this, we posed the following research questions: RQ2. Can a blind person use the application LiveDots without any assistance? On the other hand, a teacher should be able to use LiveDots even without knowledge on musical Braille. The actions loading a score and doing score changes have to be uncomplicated. Therefore, the last research question was: RQ3. Can a sighted person with musical background who doesn´t know musical Braille use the application LiveDots? 3. Tool Design 3.1. Application requirements and characteristics Building on the previous requirements (a teacher should be able to use the application without any knowledge about musical Braille and blind students should be able to use the application without any assistance), we decided to implement the following features in LiveDots (Figure 1). The application uses scores in MusicXML format since it is the most used musical representation format. When it is selected, the score is showed both in print and in Braille. The print score for sighted users is displayed by a stave and musical elements and the Braille score is shown in Figure 1. LiveDots Application Concept Design Musical Braille notation to be read with a refreshable Braille display. On one side, a sighted user can edit the print score. These changes are shown in real time in the musical Braille score, so a blind student could read the new score in the refreshable Braille display at the same time it is modified. On the other side, a blind user can use keyboard shortcuts to use the application LiveDots and read the Braille score by a Braille line or using the screen reader: when placing the focus in the musical Braille score displayed on the screen, the screen reader will say the musical elements as you go through them. These features: screen reading of Braille musical elements and real time modification are an innovation of the application LiveDots. Other applications allow you to edit the score (for example, Musescore), but not in real time, or can be used with a screen reader (for example, Braille Music Editor), but they do not say each musical element in the Braille music score when you select them. Lastly, the application LiveDots can be used by reduced visibility people and color-blinded people. The application allows to regulate the zoom (both in the scores and in the menu) and it is compatible with the Windows Colorblind Mode. 3.2 Interface Design In the design of the application we took into consideration two main factors: an easy way to move through the application window for the visually impaired user and an intuitive and useful interface for the non-visually impaired. The application´s main window is divided into three main sections (Figure 2): 1. Menu: This menu contains the main actions that can be taken while running the applications. It´s important to include a user’s guide for a first-time user. We have also found that having keyboard shortcuts of the functions of the program is very useful for visually impaired users. 2. Print Score: In this area the print score will be displayed. This area will only be used by the non-visually impaired user so it´s important that it is not accessible by keyboard. Here the teacher would be able to see the score and make modifications of pitch if needed. 3. Braille Score: This is the area for the visually impaired user, in our case, the student. It’s accessible by keyboard and it will read the elements displayed. Although it is not necessary to display the Braille score for the visually impaired user, we found that by displaying it, the application is a lot more intuitive for the non-visually impaired user and helps with the communication between the student and the teacher. Figure 2. LiveDots Application Main Window. These three sections are stacked vertically since this way the display of the printed score is optimized. The print score and the Braille score are divided by a movable separator in order to allow the desired configuration. It is also possible to change the size of the elements of any of these three sections or change all at the same time using the shortcuts CTRL+ “+” and CTRL+ “-”. 3.3 Translation MusicXML to Braille After doing some research on the matter we found that there is a standard open format for digitalised sheet music. This is a Xml file with the MusicXml format. However, the Braille music is constructed