I am writing the following article. The format is a two-pages length for a poster presentation. I write the abstract, introduction and architecture overview. Next, I am going to write the chapter: Front End Compilers. Please provide your expectation about this chapter, what you consider I must write as content, the structure and anything useful to know before to start. Here the already written chapters.
~
Title: Rethinking Front-End Compiler in Computer Music for Score-Based Audio Computation: a Composer's Perspective
Abstract: This paper presents the challenges and innovations encountered in developing the Audio Processing Kit Front End. The Audio Processing Kit is a modern C++ framework designed for offline audio composition in electroacoustic and computer music. Currently, the framework is based on a dual-score system for purely offline computation and batch processing. It is divided into a Back End, responsible for constructing the DSP graph and managing audio processes, and a Front End, which facilitates the reading of two scores in textual format. Additionally, there is a third layer that acts as a linker between the two scores, handling their grammatical and semantic analysis. This paper will explain the current state of the art of the Front End.

Introduction: In choosing to develop a custom Score-Based Music System, rather than utilizing existing solutions such as Pure Data or Csound, the author aimed to address specific project requirements that these platforms could not fulfill. While a comprehensive discussion of these decisions is beyond this article’s scope, they have been pivotal to the framework’s evolution.

In 2023, while pursuing an advanced diploma in Electronic Composition at the Accademia Nazionale di Santa Cecilia in Rome, the author undertook the creation of ‘Campi Instabili,’ a composition for the S.T.One, an innovative outer-radiating spherical loudspeaker array with tetrahedral geometry. To facilitate this composition, the author developed a custom Score-Based Music System in C++, referred to as the initial version. Following the successful premiere of ‘Campi Instabili’ later that year, a thorough analysis of the system revealed several areas for improvement. The primary issues identified were the hardcoding of parameters and graph connections within the Back End, which constrained flexibility and scalability.

Consequently, the decision was made to develop a new, enhanced version of the system, with a strong focus on creating a comprehensive Front End solution. By extracting these hardcoded elements and integrating them into a dynamic score-based system, the aim was to improve usability and accessibility, allowing for greater versatility in audio composition. This effort not only enhances the framework’s adaptability but also empowers composers to engage with the system in a more intuitive and less error-prone manner.

Architecture Overview: The initial component of the architecture is AudioLogic. It takes as input two text files (.txt): the first is conventionally named Instrument, and the second is called Parametric. The Instrument file includes declarations of audio processors and their connections. The Parametric file lists the parameters for these audio processors. Essentially, these two files represent the scores intended for playback. AudioLogic is primarily responsible for analyzing these scores.

At this stage, a Back End component known as the Topological Sorter ensures the Instrument file does not contain loops, maintaining a direct flow of processes. On the Front End, tools are used to interpret and analyze text within the scores. Lexers are tools that break down text into tokens, while parsers take these tokens and arrange them into syntactic structures. These processes are detailed in Chapter 3. If the scores pass all the checks during the scanning and parsing phase at constructor time (build time), the AudioSystem class is initialized as a container for the audio processors. This class is analogous to a patch in patch-based environments like Pure Data, AudioSystem manages time-related parameters—such as the duration of the gestures described in the scores—and the sampling frequency. AudioSystem is thus key in managing Back End processes, audio processors, and buffer management.

In the early stages of processing, before the semantic analysis, the system conducts thorough checks to ensure data integrity and adherence to expected formats. This phase, which includes syntactic and structural validation, can raise exceptions if errors are detected. By conducting these checks early, the system enhances reliability, ensuring that errors are caught and addressed before advancing to complex processes. The configure() method passes parameters from the Instrument’s audio processors and the AudioSystem to the Vocabulary class. Next, the semantic analyzer connects the two scores by employing the Vocabulary and the ExpressionEvaluator, which assesses the expressions to ensure meaningful content in the Parametric file. An expression might involve a complex initialization requiring multiple evaluations or a time-variable function. If this final check is successful, AudioLogic is ready to execute the run() method, which subsequently calls AudioSystem.run() to process the DSP graph.

This architecture not only facilitates efficient processing and management of audio scores but also exemplifies our commitment to enhancing flexibility and resilience in audio composition.