A manual solution: Knowing the functionalities of Humdrum, OpenMusic, and Rubato, one can come up with the following process:
- The scores can be obtained in Humdrum’s Kern format from the CCARH repository.
- Humdrum commands are used to extract the relevant parts from the scores.
- A converter is used to transform each result into Rubato’s EHD-Notation. The outputs are stored as files.
- The HarmoRubette is successively fed with each of the files by use of a script. The theory preference settings for the Rubette are made with a different script, stored also as a file. For each input file, the main script is used to output a file with the best harmonic path with respect to the theory preference settings.
- The annotation file (e.g. in Humdrum **harm format) and the Rubette output file are read and compared. The comparison can be made within any of the software packages.
- The differences could be visualized in the Harmonic Path view of the HarmoRubette by scripting the graphical interface, in OpenMusic in common music notation as highlighted chords within a Chord-Sequence editor, or in Humdrum by producing another **harm spine and assembling the annotated and obtained spines.
An automated solution: The whole process can be automated by creating a global script in any of the programming languages, which would forward different tasks to the different software packages. This can be done
- by (remotely) accessing the script interpreter of each one of the software packages (the shell, Rubato’s FScript component, or MCL’s eval-server)
- via some kind of interprocess communication (system calls or remote shell invocation, distributed objects calls or Apple events)
- by feeding the respective interpreter with function definitions and by triggering (evaluating) these or the built-in functions.
Each scripting environment allows to extent the runtime environment of the host application by defining functions or commands. In state preserving situations (OpenMusic and Rubato), such functions can be simply given a label, which is used to reference the function in further function call requests. In a situation, where a new interpreter is started each time a different software package calls (see section 5.2), the function must be installed in the host system, which in the case of UNIX is the file system, where a file can represent an executable command. This is accessible by the following instances of a shell interpreter by use of its path in the file system.