¿Cuáles son las limitaciones del formato de notación ABC?

Esta pregunta surgió en una discusión en Meta , y pensé que podría ser una buena pregunta para hacer en el sitio general.

La notación ABC es un formato basado en texto relativamente simple para escribir partituras musicales y compartirlas en línea. Originalmente se escribió para melodías folklóricas, pero tiene un propósito tan general que se ha utilizado, por ejemplo, para anotar un movimiento de una Sinfonía de Beethoven .

Tengo la sensación de que no tiene tantas funciones como otros formatos de escritura de partituras basados ​​en texto (como lilypond o MusicXML), pero no he usado ninguno de estos sistemas lo suficiente como para tener una buena idea de cuáles son las diferencias. .

Entonces, ¿cuáles son, específicamente, las limitaciones de la notación ABC, en comparación con un sistema con funciones más completas? Tenga en cuenta que busco especialmente las limitaciones inherentes al formato, en lugar de las limitaciones de cualquier herramienta que funcione con el formato. También tengo curiosidad acerca de qué tan importantes o importantes son estas características que faltan, pero probablemente sea una pregunta demasiado subjetiva para este sitio, ya que todos tendrán diferentes objetivos.

Hola. Cambié el título de su pregunta, con la esperanza de captar mejor la intención. Si crees que no entendí tu punto, simplemente devuélvelo. Salud.
Gracias. Creo que entiendo la intención de la edición, pero el nuevo título ("¿Está completo el... formato?") es casi seguro que "no", dado el nivel potencial de complejidad en las partituras. La pregunta no es de completitud, sino de comprender de qué manera no está completa. He tratado de capturar esto en otra edición.
Es importante darse cuenta de que esta pregunta es sobre el formato ABC que se analiza en la partitura real. No se trata del formato ABC muy simple que a veces usamos cuando no tenemos ganas de incluir imágenes en nuestras publicaciones. Había escrito tres párrafos como respuesta antes de darme cuenta de esto... :-)

Respuestas (3)

Mi sensación (después de escribir analizadores para ABC, MusicXML, Cappella, Noteworthy y otros 6 formatos; y salida a Lilypond, etc.) es que las limitaciones de ABC, el formato, no se pueden separar por completo de las limitaciones de los analizadores ABC. Como Kevin y Chris señalaron anteriormente, el formato ABC tiene la capacidad de codificar gran parte de la complejidad de MusicXML y Lilypond y otros formatos, por lo que no está especialmente limitado con respecto a esos formatos (aunque las opciones precisas de formato y diseño de MusicXML y Lilypond, necesarios para el almacenamiento de una partitura que se puede reconstruir, son rudimentarios).

Las limitaciones surgen porque un analizador ABC no puede saber a partir del formato de datos qué tipos de extensiones ABC o funciones poco utilizadas puede encontrar en cualquier momento o cómo puede evolucionar el lenguaje en el futuro. Que yo sepa, no existe una gramática formal para un documento ABC bien formado que le permita a un programador saber dónde terminará la siguiente cadena de elementos (letras, voces, etc.). Contraste con MusicXML, donde el formato XML de <tag>contents</tag> tiene una especie de encapsulación que es fácil de analizar y puede tolerar cambios futuros en la especificación. (Lilypond es más difícil de analizar o generar de esta manera, pero tiene una especificación gramaticalque puede ayudar). La diferencia significa que los lectores de MusicXML (o los pocos lectores de Lilypond) pueden saber de antemano si un archivo está bien formado y analizar o leer selectivamente elementos que pueden o no ser relevantes para la tarea. Con la notación ABC, puede ser extremadamente difícil omitir información que puede ser correcta pero de un estándar diferente (más antiguo o futuro).

Debido a que evolucionó a partir de una (excelente) forma de simplemente editar música, algunos aspectos de la gramática implícita son contradictorios o pueden conducir a resultados muy diferentes según el analizador o intérprete que se utilice. Por ejemplo, la especificación 2.1.1 (dev) dice: "Un símbolo de porcentaje (%) hará que se ignore el resto de cualquier línea de entrada". sin embargo, más adelante "Una directiva de hoja de estilo es una línea que comienza con %%, seguida de una directiva que da instrucciones para escribir o reproducir programas". (como en la directiva %%score anterior). Tales adiciones no estándar permiten que el formato crezca de acuerdo con las necesidades de la comunidad, pero dificultan el análisis de características importantes y dejan un estándar un tanto no estándar. Las constantes o atributos importantes, especialmente en estos signos directivos, se dejan sin definir: uno puede ver que hay un "

Si el OP quiere limitaciones más específicas en lugar de filosóficas, algunas importantes: poco o soporte para grupos irregulares más allá de la información básica (cómo deben mostrarse (número, proporción, sin signo), grupos irregulares anidados, ubicación en metrónomo/marcas de modulación métrica); muchos menos signos de adorno (decoración); soporte para signos de música antigua (completos en Lilypond; algunos en MusicXML) y símbolos de notación contemporáneos (armonías de diamante; acordes de racimo; microtonos, etc.; completos en Lilypond; algunos en MusicXML); control sobre el posicionamiento de las notas decorativas, en particular los grupos de notas decorativas en varias partes (útil para una sinfonía de Beethoven); diferentes armaduras de clave en diferentes partes (muy importante para las sinfonías de Beethoven; necesario incluso después de que los ajustes de transposición estén completos, ya que las trompetas no deben tener armaduras de clave marcadas en ninguna transposición). Metadatos más ricos (arreglista, derechos de autor [para la pieza, aparte de la codificación]), control preciso sobre los esquemas de numeración de compases. Soporte de reproducción de instrumentos enriquecidos (en MusicXML 3.0; a diferencia del número MIDI puro).

Nada de eso quiere decir que ABC sea un formato limitado: es increíble para simplificar las cosas y escribir música a mano en un archivo de texto, pero para algo tan grande como una sinfonía de Beethoven, creo que las limitaciones lo convertirán en un elección desconcertante.

(editado:) Usted preguntó si había una forma no subjetiva de decidir qué tan importantes son estas características; Traté de responder en el contexto de la notación de las sinfonías de Beethoven, ya que usaste ese ejemplo, pero déjame responder en el contexto de cómo la gente podría usar la notación aquí, tal vez un poco menos subjetivo. Para preguntas sobre "¿Qué significa el símbolo oscuro X?" Será mucho más posible hacer ese símbolo en Lilypond o MusicXML (asumiendo que es un signo de trino barroco, un signo de notación contemporánea, etc.); por supuesto, el interrogador probablemente no podría usarlo en su pregunta, ya que tendría que saber el nombre, pero un respondedor podría usarlo en su respuesta. Los acordes de guitarra se discuten a menudo aquí; se pueden escribir en ABC, pero a excepción de esta listano tienen significado semántico (tratados como expresiones de texto); son totalmente compatibles con los otros dos formatos (junto con el bajo cifrado para preguntas de música barroca). Para preguntas de teoría ("¿Qué es un sexto acorde aumentado?", ABC funcionaría bien y sería mucho más fácil de ingresar.

Hay una serie de funciones planificadas para la notación abc: actualizaciones importantes para v2.2 y v2.3, así como una serie de propuestas menores.

abc v2.2 se ocupa principalmente de "resolver las ambigüedades e incompatibilidades en la música de varias voces", en relación con la 'voz de control'. Por lo que puedo ver, tanto Lilypond como MusicXML tienen una funcionalidad de voz múltiple completa. abc parece tener algunas ambigüedades de alcance, detalladas aquí , y ambigüedades de clave .

abc v2.3 analizará el marcado y la incrustación; "es decir, incrustación de abc dentro de otros tipos de documentos e incrustación de otros tipos de marcado dentro de documentos abc". Lilypond se puede incrustar en Latex y permite que Scheme se incruste dentro de sí mismo; estoy seguro de que también hay otros ejemplos. Por lo que deduzco, abc no tiene funcionalidad aquí.

Otros planes futuros menores (¡y más definidos!) incluyen:

Transposición : actualmente es posible transponer un script de lilypond usando \transpose frompitch topitch musicexpry MusicXML tiene una <transpose>etiqueta: la notación abc no parece tener ningún método de transposición todavía.

Una sintaxis para crear popurrís de melodías . Aquí, MusicXML tiene el formato de archivo opus y Lilypond una opción para múltiples \scorebloques.

Toda la información se encuentra en la wiki de notación abc y en el grupo de Yahoo . (retro!)

Existe el formato de archivo opus para MusicXML y la codificación de bloque múltiple \score para Lilypond, pero para simplificar la creación de mezclas de melodías (y compatibilidad con el análisis), nada supera a ABC.

ABC Notation es un maravilloso lenguaje de notación que mucha gente prefiere a Lilypond . Muchas de las limitaciones de la Notación ABC no están en la notación sino en la implementación de herramientas. Antes de la Notación ABC 2.1 , la principal limitación estaba en la escritura de música de múltiples voces , pero esto se ha abordado en la Notación ABC 2.1 y se finalizará en la Notación ABC 2.2.

Ejemplo (de ABCnotation.com):

    X: 1  
    T: Lago Zocharti  
    C: Luis Lewandowski (1821-1894)  
    M:C
    P: 1/4 = 76
    %%puntuación (T1 T2) (B1 B2)
    V: T1 clave = agudos-8 nombre = "Tenore I" snm = "TI"
    V: clave T2 = nombre de agudos-8 = "Tenore II" snm = "T.II"
    V: B1 medio = clave de re = bajo nombre = "Bajo I" snm = "BI" transposición = -24
    V: B2 medio = clave de re = nombre de bajo = "Bajo II" snm = "B.II" transponer = -24
    K:Gm
    % Fin del encabezado, inicio del cuerpo de la melodía:
    % 1
    [V:T1] (B2c2 d2g2) | f6e2 | (d2c2 d2)e2 | d4 c2z2 |
    [V:T2] (G2A2 B2e2) | d6c2 | (B2A2 B2)c2 | B4 A2z2 |
    [V:B1] z8 | z2f2 g2a2 | b2z2 z2 e2 | f4 f2z2 |
    [V:B2] x8 | x8 | x8 | x8 |
    % 5
    [V:T1] (B2c2 d2g2) | f8 | d3c (d2fe) | H d6 ||
    [V:T2] z8 | z8 | B3A (B2c2) | H A6 ||
    [V:B1] (d2f2 b2e'2) | d'8 | g3g g4 | H^f6 ||
    [V:B2] x8 | z2B2 c2d2 | e3e (d2c2) | H d6 ||

Producción:

Producción

¿Conoces algunas de las limitaciones actuales? Si no hay limitaciones significativas, también es buena información.
Múltiples voces es la única limitación que conozco y que se resuelve provisionalmente en 2.1 y debería resolverse de forma permanente en 2.2.
A juzgar por este ejemplo, para un ejemplo más avanzado, está a la par con lilypond en legibilidad. Para ejemplos más simples, ABC es mucho más legible.
Se agregaron etiquetas <pre></pre>, que mantienen alejado el jTab. Es bastante molesto, con suerte se implementará una solución ahora que lo estamos mostrando en el radar.