Abschlussbericht Modul 2 | Beethovens Werkstatt

Abschlussbericht Modul 2: Beethoven als Bearbeiter eigener Werke

Bedeutung und Aufgabe des Moduls im Gesamtprojekt

Nachdem in Modul 1 die Bildung von Varianten, ihre Erscheinungsformen sowie ihre zeitlichen und inhaltlichen Beziehungen an ausgewählten, verschiedenen Gattungen zugehörenden Ausschnitten von Werkstattmanuskripten Beethovens untersucht worden waren, widmete sich das 2. Modul dem Vergleich von Eigenbearbeitungen, die philologisch als Makrovarianten ein und desselben Werks untersucht werden können. Ziel war die Erschließung der Bearbeitungsprozesse durch eine synoptische Darstellung der Doppelfassungen, in der die Transformationsprozesse durch verschiedene Darstellungsmodi aus unterschiedlicher Perspektive betrachtet und verglichen werden können, um Beethovens Anpassungsmaßnahmen an die Zielgattung der Bearbeitung transparent zu machen und zugleich zu verdeutlichen, worin für den Komponisten die strukturelle Gemeinsamkeit zweier Fassungen (der „Satzkern“ eines Werks) besteht. Das Spektrum der Bearbeitungen Beethovens reicht dabei von der handwerklichen Routinearbeit, etwa bei Klavierauszügen, bis hin zu Bearbeitungen eigenen Rechts, die den Anspruch einer vollgültigen Werkfassung erheben (und daher meist eine eigene Opus-Nummer erhielten). Im Modul sollte möglichst diese Bandbreite an Fällen abgedeckt werden (vgl. Allgemeine Voraussetzungen und Festlegung der berücksichtigten Werke).

Technisch erforderte dies die Entwicklung eines prototypischen Werkzeugs, das automatisierbare Textvergleiche der Werk-Paare (Originalfassung und Bearbeitung) erlaubt. Dies setzte damit erstmals komplette MEI-Codierungen der ausgewählten Werke voraus. Auf dieser Basis sollte im Rahmen systematisierter Kriterien ermittelbar sein, auf welche Art und Weise Fassungen sowohl durch Invarianz (strukturgleiche Textelemente) als auch durch Varianz (strukturverwandte Textelemente) sowie in besonderen Fällen durch Differenz (Textelemente ohne korrespondierende Parameter in der jeweils anderen Fassung) aufeinander bezogen sind. Für Nutzer*innen sollte so ein Tool entstehen, das in der jeweils gewählten Perspektive beim Erkennen von Bezügen unterstützen kann und zugleich garantiert, dass die von bestimmten Fragestellungen geleiteten Anfragen mühelos wiederholbare Ergebnisse produzieren. Die damit notwendige feinmaschige Verknüpfung aller Details stellte zugleich höchste Anforderungen an die Qualität der zugrundeliegenden Codierungen.

Zu den angestrebten Nebenergebnissen des Moduls gehörte die Entwicklung einer Suche, die es erlaubt, beliebige, von Benutzer*innen markierte Ausschnitte eines Stimmverlaufs automatisiert in einen Suchstring umzusetzen, mit dessen Hilfe identische oder verwandte Strukturen in anderen Stimmen oder Satzteilen ermittelt werden können. Außerdem sollten erstmals Audio-Elemente einbezogen werden. Dies wurde durch die Zusammenarbeit mit dem Projekt Inside Beethoven in einer sehr spezifischen, auf den klanglichen Vergleich eingespielter Versionen fokussierten Weise umgesetzt, da eine Unterstützung analytischer Arbeiten durch rein MIDI-basierte Verklanglichung weniger hier als im Kontext von Modul 4 förderlich schien.

Technische Voraussetzungen für einen optimalen Workflow

Vor dem Hintergrund der erheblich größeren Datenmengen in Modul 2 war die technische Infrastruktur des Projekts so anzupassen, dass lokale Änderungen der an zentraler Stelle versionierten Daten automatisch zu einer Aktualisierung des online verfügbaren Prototyps führten, so dass die Mitarbeiter*innen an beiden Standorten unmittelbar und ohne weitere technische Eingriffe über die Anzeige-Ergebnisse einerseits ihre Inhalte korrigieren, andererseits aber auch konkrete Optimierungsmaßnahmen für diese Anzeige festlegen konnten. Dieses iterative Vorgehen (im Rahmen von Continuous Integration/Continuous Delivery-Prozessen) trug ebenso zu einer wesentlich effizienteren Arbeitsweise bei, wie eine stärkere Modularisierung verbunden mit der Dokumentation von Quelltexten sicherstellte, dass auch Kristin Herold und Agnes Seipelt (sowie in der Endphase Ran Mo) als neue Mitarbeiterinnen produktiv zur Softwareentwicklung beitragen und die Aufgabenverteilungsprozesse flexibler gehandhabt werden konnten.

Allgemeine Voraussetzungen und Festlegung der berücksichtigten Werke

Im Vorfeld der Auswahl der zu untersuchenden Beispiele, die eine sehr differierende Problemlage repräsentieren sollten, experimentierten die Mitarbeiter*innen der Bonner Arbeitsstelle zunächst mit analogen Darstellungsversuchen von Ähnlichkeitsbeziehungen zwischen Fassungen, mit dem Ziel, solche Beziehungen zu systematisieren. Diese analog mit Stift und Papier entworfenen Darstellungsmodi bildeten die Grundlage für die in der entwickelten Software digital umgesetzten und anwendbaren Perspektiven. Im Kontext der Bestimmung der invarianten Anteile zweier Fassungen wurde die Definition des schon in Modul 1 wichtigen Begriffs der Invarianz modifiziert. Auch Fragen des Verhältnisses zwischen Bearbeitungsmaßnahmen und Variantenbildung wurden diskutiert, so dass 2017 die Fragestellungen im Modul 2 in einem Text auf der Website des Projekts präzisiert werden konnten, wobei die textgenetische Bedeutung von Bearbeitungen, Eigenbearbeitungen und Bearbeitungsprozessen im Mittelpunkt stand.
In dieser Vorbereitungsphase wurden verschiedene Wege zur Analyse von Beethovens Eigenbearbeitungen aus textgenetischer Sicht ausprobiert und die Werke sowohl aus der Perspektive des Produktes als auch aus der Perspektive des Prozesses untersucht. Der grundsätzliche Fassungsvergleich lieferte dabei sowohl Informationen über eine mögliche Systematisierung von Ähnlichkeitsbeziehungen (zur Klassifizierung der Art der Variante) als auch über die dahinterliegende Textoperation (Tilgung, Einfügung, Ersetzung, Umstellung). Dabei galt Beethovens Brief vom 13. Juli 1802 an Breitkopf und Härtel (BGA 97) als Schlüsseltext, denn hier beschreibt der Komponist die für ihn notwendigen kompositorischen Maßnahmen, um eine Bearbeitung durchführen zu können. Beide Untersuchungsansätze sind schließlich in den Perspektiven der VideApp-Arr jeweils als „Einzelnotenvergleich“ und „Bearbeitungsmaßnahmen“ umgesetzt worden.

Für die detailliertere Untersuchung ausgewählt wurden schließlich die Klaviersonate op. 14/1 mit ihrer Bearbeitung als Streichquartett (inhaltlich gemeinsam an der Bonner Arbeitsstelle erarbeitet), die Klavierauszüge zum Opferlied op. 121b (S. Cox) und Bundeslied op. 122 (R. Sänger), die vierhändige Klavierbearbeitung der Großen Fuge op. 133/134 (E. Novara) und das Violinkonzert op. 61 mit der Bearbeitung als Klavierkonzert (F. Rovelli) – dieses letzte Beispiel konnte nur zum Teil berücksichtigt werden, da Federica Rovelli Ende September 2018 eine Stelle am Musikwissenschaftlichen Institut in Cremona antrat. Die Detmolder Mitarbeiter*innen übernahmen neben der technischen Seite die inhaltliche Erarbeitung des Septetts op. 20 und seiner Triofassung op. 38, deren technische Umsetzung dann auch Ausgangspunkt der im Jubiläumsjahr BTHVN2020 vom Zentrum für Musik- und Filminformatik der Hochschule für Musik Detmold und der Technischen Hochschule Ostwestfalen (ZeMFI) entwickelten und von der Beethoven-Jubiläumsgesellschaft geförderten Klanginstallation „Inside Beethoven“ wurde. Im Kontext dieser inhaltlichen Erarbeitungen der Beispiele entstanden jeweils Mockups für die anschließend technisch zu realisierenden Darstellungsoptionen. Zusätzlich erarbeitet wurde in Bonn und Detmold ein Vergleich des Septetts op. 20 mit der bei Hoffmeister erschienenen Fremdbearbeitung als Streichquintett. Diese Edition wurde ebenfalls in die Website integriert, da sie als routinierte Handwerksarbeit die kreativen Eigenbearbeitungen Beethovens exemplarisch kontrastiert und zugleich zeigt, dass die im Projekt entwickelte Darstellungsmethode auch auf fremde Bearbeitungen anwendbar ist.

Neben der Aufarbeitung der verschiedenen Beispiele aus philologischer Sicht und der Erarbeitung möglicher Darstellungsformen bestand ein erheblicher Anteil der Vorarbeiten aus der Erstellung kompletter Codierungen der genannten Werke und ihrer Fassungen, wobei der Weg einerseits über die Noteneingabe mit unterschiedlicher Notationssoftware (MuseScore, Finale, Sibelius) und anschließender Konvertierung über MusicXML in ein Basis-MEI-Format lief, andererseits über OMR und die entsprechende Konversion (wobei sich dieser zweite Weg wenig bewährte). In allen Fällen waren umfangreiche und intensive Korrekturlesungen nach dem Rendering der erstellten MEI-Dateien durch Verovio notwendig, wobei in der Endphase des Moduls auch das entwickelte Vergleichstool mit seinen unterschiedlichen Perspektiven zum rascheren Erkennen von Fehlern bzw. Problemen der Codierung beitrug.

Während des gesamten Moduls blieb die Diskussion und Definition von Begrifflichkeiten und Darstellungsformen (im Projekt Perspektiven genannt), die im Kontext der fortschreitenden Arbeiten die Verständigung erleichtern bzw. Sachverhalte für Außenstehende präzise beschreiben sollen, eine kontinuierliche Aufgabe, die zu entsprechenden Erweiterungen des Glossars führte. Darüber hinaus war zu dokumentieren, welche Art von Vergleichen mit den entwickelten Tools möglich werden und welche Ergebnisse sich in den untersuchten Werken im Hinblick auf Beethovens eigene Bearbeitungsweise formulieren lassen. Diese Texte wurden werkweise per Link an die entwickelte VideApp-Arr[angements] angebunden.

Workflows und die entwickelte VideApp-Arr

Um die komplexen Verwandtschaftsbeziehungen zweier Fassungen möglichst genau untersuchen und anzeigen zu können, wurden sechs Perspektiven entwickelt, die die vergleichende Betrachtung der jeweiligen Werk-Paare aus verschiedenen Blickwinkeln ermöglichen. Diese Entwicklung vollzog sich als ein von analogen Entwürfen ausgehender Prozess, dem erste digitale Umsetzungen folgten, die dann in mehrstufigen Feedbackrunden verfeinert oder gelegentlich auch stark modifiziert wurden. Dabei wurde deutlich, dass die Art der Codierung starken Einfluss auf die Möglichkeiten der Darstellung hat und sich nicht alle Wünsche digital umsetzen lassen, da Aufwand und Ertrag in einem verantwortbaren Verhältnis stehen müssen. Die sechs realisierten Perspektiven haben den Vorteil, dass sie über die hier untersuchten Fälle hinaus auch in anderen Kontexten und natürlich auch auf das Oeuvre anderer Komponist*innen übertragbar sind und Erkenntnisvorgänge beschleunigen.

Als Basis für alle weiteren Perspektiven dient die synoptische Gegenüberstellung der jeweiligen Fassungen in einer simplen simultanen Darstellung der übereinander angeordneten Notentexte („Fassungssynopse“), so dass diese in der Vertikalen leicht verglichen werden können. Die Perspektiven „Bearbeitungsmaßnahmen“ und „Einzelnotenvergleich“ beruhen auf der Notentextanzeige der Fassungssynopse, erweitern diese aber um automatisch errechnete Vergleichsergebnisse, die durch farbliche Hervorhebungen im Basisnotentext angezeigt werden. Die vierte Perspektive zeigt eine abstrahierte, sich überlagernde Darstellung der Notentexte beider Fassungen als schematisch-lineare „Stimmenkontur“: Noten werden hier als Punkte in einem Tonhöhen-Raster angezeigt und Noten der einzelnen Stimmen mit Linien verbunden. Dadurch ergeben sich die charakteristischen Stimmenkonturen, die den Vergleich auf horizontaler, melodischer bzw. stimmenbezogener Ebene erleichtern. Die fünfte Perspektive bietet einen „Harmonievergleich„, der zunächst prototypisch auf der Basis einer sehr komplexen Auswertung simultaner Klangereignisse (unter Berücksichtigung von Vorhalten und Durchgangstönen) realisiert wurde. Die sechste und letzte Perspektive dient dem Vergleich der „Ereignisdichte“. Sie ist ein analytisches Hilfsmittel, das auf einfachste Weise (durch Markierung der „onsets“, d. h. der auf einem Zeitstrahl gebündelten, in den einzelnen Stimmen jeweils eintretenden akustischen Ereignisse) sichtbar macht, an welchen Stellen der rhythmische Puls eines Abschnittes verändert wird oder unverändert beibehalten wird.

Für diese sechs Perspektiven wurde eine ausführlich getestete und sukzessive modifizierte und optimierte Nutzeroberfläche als Webanwendung mit dem Javascript Framework Vue.js erstellt (J. Kepper), die den Namen „VideApp-Arr“ erhielt. Sie fasst zugleich die Beispielfälle unter einer Oberfläche zusammen und wurde mit einer ganzen Reihe von Navigationshilfen und Auswahloptionen versehen. So können in den synchronen Darstellungen einzelne Stimmen ausgeblendet, Fassungen in unterschiedlicher Tonart in die Tonart des jeweils anderen Stückes (oder eine vorzeichenlose) transponiert, einzelne Takte gezielt angesteuert und Partiturausschnitte vergrößert oder verkleinert werden. Für die Navigation wurde außerdem ein neues Tool auf der Basis der Sunburst-Diagramme erprobt, das nicht nur einen Überblick über einen kompletten Satz, sondern auch die Integration einzelner Perspektiven in eine schematische Darstellung erlaubt (z. B. durch farbige Markierung von Differenzen oder Varianzen im Satzverlauf).

Beim Entwickeln und Testen der VideApp-Arr-Software zeigte sich die Notwendigkeit einer über das Kontrollieren des Rendering durch Verovio weit hinausgehenden intensiven Korrekturlesung, da der Rechner beim Erzeugen der Perspektiven nicht die gerenderten Noten, sondern deren codierte Werte vergleicht. So sind z. B. bei wiederholten Akzidentien im Takt diese wie heute üblich in der Darstellung durch Verovio zu unterdrücken, in der Codierung müssen die klingenden Töne aber durch ein @accid.ges hinterlegt sein, damit nicht falsche, unveränderte Tonhöhen als Berechnungsgrundlage dienen. Hier war häufig im Detail zu präzisieren, zum anderen erfolgte im Verlauf des Moduls auch die Umstellung auf den aktuellen Stand des MEI-Schemas 4.0. Damit alle Mitarbeiter*innen im Hinblick auf die gewünschte Ergebnisanzeige einheitlich codierten bzw. korrigierten, wurden Codierungsrichtlinien erarbeitet, die in einer ODD-Datei das Schema für die Codierungen dieses Moduls festhielten.

Schließlich wurde im Rahmen der Realisierung der oben erwähnten Klanginstallation „Inside Beethoven! Das begehbare Ensemble“, die im Jubiläumsjahr an sechs Orten (Detmold, Paderborn, Bonn, Wien, Leipzig und Frankfurt) gezeigt werden sollte, gemeinsam mit dem ZeMFI, dem Beethoven-Haus Bonn und der Hochschule für Musik Detmold auch eine Begleitpublikation zu diesem Projekt in Form eines Medienbuchs erarbeitet, das neben Neueinspielungen des behandelten Septetts op. 20 und der Triofassung op. 38 auch Texte mehrerer Mitarbeiter*innen des Projekts enthielt.

Die VideApp-Arr ist als Software zwar gezielt für die im Modul 2 ausgewählten Eigenbearbeitungen Beethovens entwickelt, sie eignet sich aber grundsätzlich für den Vergleich von Fassungen – damit kann sie z. B. auch innerhalb von Korrekturvorgängen bei der Erstellung von (MEI-basierten) Editionen eingesetzt werden. Dass dabei die verschiedenen Perspektiven auf unterschiedliche Fehlertypen hinweisen können, hat sich (teils überraschend) bei der Arbeit in Modul 2 gezeigt und somit als eine wertvolle Korrekturhilfe erwiesen.

Arbeitstreffen, Vorstellungen und Öffentlichkeitsarbeit des Projekts

Im Laufe des Moduls fanden mehrere Klausurtagungen des Projekts statt, die in den internen Redmine-Ablagen dokumentiert wurden und der Justierung der jeweiligen Arbeitsprozesse dienten. In der Corona-Krise musste die für eine Klausurtagung geplante Besprechung der Abschlussarbeiten an Modul 2 virtuell durchgeführt werden – in diesem Kontext konnten die Kommunikationsformen auch für die wöchentlichen gemeinsamen Besprechungen der beiden Arbeitsstellen deutlich verbessert werden. Die umfangreiche Präsentationstätigkeit, mit der die Mitarbeiter*innen die Projektarbeit auf wissenschaftlichen Tagungen, bei Workshops und in Lehrveranstaltungen vorstellten, ist der Liste der Vorträge und Präsentationen, der Rubrik „Veranstaltungen & Neuigkeiten“ sowie der Aufstellung der publizierten Aufsätze zu entnehmen.

Eine besondere Nähe hat das Projekt zur MEI-Community und trägt durch seine speziellen Anforderungen, aber auch durch die aktive Einbindung von Mitarbeiter*innen in die Steuerungsgremien von MEI zur Weiterentwicklung dieses für die Arbeiten essentiellen Codierungsstandards bei. Bei den jährlichen Music-Encoding-Konferenzen (MEC) berichteten die Werkstättler regelmäßig über die laufenden Entwicklungen im Projekt und beteiligten sich auch mit Kursen zu TEI, MEI und digitalen Methoden an der Paderborner Edirom-Summer-School.

In der Beethoven-Forschung wird das Projekt zunehmend beachtet, wie die Teilnahme an der 8. New Beethoven Research Conference (Boston 2019) und die Veranstaltung eines eigenen Roundtables zum Thema „Skizzen als Werkstattdokumente“ bei dem Kongress „Beethoven-Perspektiven“ im Februar 2020 in Bonn belegt (eine Veröffentlichung ist in Vorbereitung). Zudem beteiligt sich das Projekt regelmäßig an den Jahrestagungen der Gesellschaft für Musikforschung mit Vorträgen und Postern, zuletzt 2019 mit einem von Andreas Münzmay und Joachim Veit organisierten Symposion unter dem Titel „Brückenschläge – Informatik und Musikwissenschaft im Dialog“. Darüber hinaus hat sich Beethovens Werkstatt wiederholt beim Studienkolleg des Bonner Beethoven-Hauses engagiert.

Ferner bemüht sich das Projekt um einen regen Austausch mit anderen universitären Einrichtungen, z. B. durch die Kooperation mit der Universität Pavia (Musikwissenschaftliches Institut von Cremona), die jetzt offizieller Erasmus+-Partner der Universität Paderborn ist. Innerhalb des Erasmus-Austauschprogramms arbeitete bereits im Mai/Juni 2017 Francesco Fontanelli, zu dieser Zeit Doktorand aus Cremona, in der Bonner Arbeitsstelle, um sich mit terminologischen und methodologischen Problemen der genetischen Textkritik auseinanderzusetzen. Zudem nahm die Doktorandin Franziska Militzer an einem der Arbeitstreffen teil, um mit der Werkstatt über ihre Dissertation zu den Skizzen von Regers Klarinettenquintett op. 146 zu diskutieren.

Im Kontext der Arbeiten am 2. Modul wurden außerdem etliche neue Begriffe für das Glossar des Projekts verfasst (u. a. Bearbeitung, Klavierauszug, primäre und sekundäre Notation, Genetische Textkritik, Satzkern, Ähnlichkeit, Differenz, Ersetzung, Einfügung, Substitution, Tilgung, Umstellung, Kontextzwang, syntaktische Position, Varianz, Ereignisdichte, Fassung, Lesart) und einige Begriffe unter der Perspektive der Bearbeitung aktualisiert. Im Hinblick auf die Integration der VideApp-Arr und der übrigen Entwicklungen in den Gesamtzusammenhang des Projekts wurde die Struktur der Website überarbeitet, um durch eine stärkere Orientierung an der Modulgliederung die Übersichtlichkeit zu erhöhen. Diese Version wird zusammen mit dem vorliegenden Bericht freigeschaltet.

Lessons learned in Modul 2

Die Arbeit in Modul 2 hat insbesondere dazu beigetragen, die Anforderungen an die Codierungen zu präzisieren – es liegen nun Erfahrungswerte vor, die künftig helfen, den teils erheblichen Zeitaufwand bei der kontinuierlichen Nachbesserung der Codierungen zu minimieren. Im Einzelnen ist hierzu festzuhalten:

Die Erwartung, durch den Rückgriff auf freie, teils auch im Netz verfügbare Vorlagen eine bedeutende Zeitersparnis zu erzielen, hat sich als trügerisch erwiesen. Im Rahmen des ambitionierten Forschungsprojekts sind hochwertige Codierungen erforderlich, die sinnvoller von Anfang an selbst erstellt werden, denn das Überführen freier Vorlagen in Daten der erwünschten Qualität ist außerordentlich zeitintensiv und verlangt wiederholte Nachbesserungen.
Von Anfang an sollte feststehen, welche Vorlage für die Codierung ausgewählt wird und welche Konsequenzen dies hat. In Modul 2 wurden teils Originalausgaben als Grundlage gewählt, die zahlreiche Fehler aufwiesen und an diesen Stellen die Ergebnisse des Vergleichs verfälschten. Zwar konnte das entwickelte Tool auch dafür verwendet werden, solche Fehler aufzuspüren, um das Analyseergebnis aber davon unabhängig zu machen, müssten solche Fehler korrigiert werden. Da es in Modul 2 aber nicht um praxisbezogene oder gar historisch-kritische Editionen, sondern um den Vergleich von Vorlagen ging, wäre eine solche Vorgehensweise nicht konsequent bzw. müsste durch entsprechende Annotationen aufgefangen werden. Es ist also jeweils zu bedenken, was die Codierung leisten soll.
Als essentiell erwies sich erneut die Notwendigkeit der Dokumentation: In den Metadaten sollte festgehalten sein, wie die Codierungen erstellt wurden (über Konvertierung aus welchen Programmen, mit welchen Eingriffen, inwieweit „von Hand“ erstellt), welches die Codierungsvorlage war (bei Originalausgaben oder Handschriften mit Angabe der Signatur der Quelle) sowie welche Änderungen an den Daten vorgenommen wurden. Auch bestimmte editorische Grundsätze (etwa bei Klaviermusik die Notation von Dynamik zwischen den Systemen von rechter und linker Hand mit Gültigkeit für beide) sind festzuhalten – handelt es sich um umfangreichere Richtlinien, können diese auch als separate Datei angelegt und darauf verlinkt werden.

Besondere Herausforderungen stellten in Modul 2 der Harmonievergleich und die Suche dar:

Der Harmonievergleich zielt darauf ab, gleichzeitig erklingende Töne zu erfassen, ihren Zusammenklang zu analysieren und die Analyseergebnisse miteinander zu vergleichen. Dazu sollte eine möglichst neutrale Bezeichnung simultaner Klangereignisse mit Akkordsymbolen (also ohne Interpretation in einem Stufen- oder Funktionsmodell) verwendet werden. Technisch basiert die harmonische Analyse auf Skripten, die aus den MEI-Daten die Abstände zwischen gleichzeitig erklingenden Tönen berechnen. Dabei wird, wie im Einzelnotenvergleich, ein sehr strenger und auf die jeweilige Zählzeit beschränkter Blick eingenommen, der jedoch ohne Berücksichtigung von Vorhalten und Durchgangstönen zu musikalisch inadäquaten Interpretationen führen kann. Erst durch die Formulierung von Regeln für Vorhalte können diese erkannt und kann somit der Zusammenklang in seinem Kontext bestimmt werden.
Ein weiteres Problem stellen geringstimmige Zusammenklänge dar: Während vollständige Dreiklänge oder Septakkorde problemlos von den Skripten erkannt werden, kommt es bei „fehlenden Tönen“ teilweise zu kontextuell „falschen“ oder fragwürdigen Ergebnissen. Da die Skripte nur die vorhandenen Töne erfassen, wird z. B. ein vor dem Klangereignis vorhandener oder nachträglich hinzutretender Grundton von der Maschine nicht (wie von einem analysierenden Menschen) „hinzugedacht“, so dass es zu abweichenden Bestimmungen kommt. Auch können Vorhalte nur erkannt werden, wenn der richtige Grundton vorhanden ist.
Eine automatisierte Analyse benötigt also Regeln, nach denen die Daten abgefragt werden. Basale harmonische Regeln konnten entsprechend in den Skripten formalisiert werden. Erweiterte oder je nach musikalischem Kontext variierende harmonische Besonderheiten in den Werken können jedoch mit allgemein gültigen Regeln der Skripte nicht erfasst werden: Würde man eine Regel für eine Stelle X anpassen, würde sie an Stelle Y eventuell nicht mehr greifen. Für eine tiefergehende harmonische Analyse müsste also ein umfassendes Regelwerk formalisiert werden – was den Rahmen des Moduls gesprengt hätte, während der hier beabsichtigte Vergleich zweier Fassungen unter harmonischen Gesichtspunkten mit der realisierten Perspektive möglich ist: Die erklingenden Noten werden, wie beim Einzelnotenvergleich, aufbereitet und miteinander in Beziehung gesetzt. Dadurch werden rasch Veränderungen im Detail – z. B. Dreiklangserweiterungen, die sich in der Vergleichsfassung nicht finden – sichtbar.
Die Umsetzung einer sinnvollen und leicht handhabbaren Form der musikalischen Suche erwies sich ebenfalls als komplexe Aufgabe, da im Modul bereits etablierte Verfahren nicht ausreichend auf Unterschiede der Fassungen eingehen, d.h. die zu implementierende Suche muss auch musikalisch ähnliche, aber nicht deckungsgleiche Notate identifizieren. Hierfür gibt es weder von musikwissenschaftlicher Seite hinreichend formalisierte bzw. formalisierbare Theorien, noch von musikinformatischer Seite wirklich überzeugende Konzepte, die den inhaltlichen Anforderungen des Projekts gerecht werden. Im Projekt konnte bereits eine erste Suche, die bestehende Suchverfahren innovativ kombiniert und damit gerade die gewünschte Unschärfe erlaubt, entwickelt werden. Da allerdings auch im dritten Modul des Projekts vergleichbare Suchmöglichkeiten relevant sind, werden diese Ansätze anhand der Arbeiten des dritten Moduls weiter verfeinert; gleichzeitig wird im (internationalen) Austausch mit anderen Projekten die langfristige Tragfähigkeit der Methode evaluiert. Zu gegebener Zeit soll dieser Prozess in einer gesonderten Publikation dokumentiert werden. Bis dahin sollen auch weitere Eingabemöglichkeiten zur Formulierung von Suchanfragen bereitgestellt werden: Aktuell können einzelne Stellen im Notentext markiert werden, zu denen dann entsprechende Parallelstellen gesucht werden. Diese Lösung ist einerseits sehr intuitiv nutzbar, andererseits vermeidet sie den ggf. beträchtlichen (und für die Erreichung der Projektziele nicht notwendigen) Entwicklungsaufwand einer Benutzeroberfläche, welche die Eingabe komplexerer Suchanfragen erlaubt.

Weitere bedeutende Verbesserungen betrafen die Kommunikation innerhalb des Projekts. Hier hat sich neben dem schon seit Modul 1 benutzten open-source-Tool Redmine die Einführung weiterer technischer Hilfsmittel bewährt:

Während Redmine für die allgemeinen Verwaltungsaufgaben und die gemeinsame Arbeit an Texten (etwa am Glossar oder einem Text wie dem vorliegenden) verwendet wird, dient das online-Verwaltungs-Tool Trello der vereinfachten Zuweisung und nachvollziehbaren Abarbeitung konkreter Aufgaben. Durch die Möglichkeit, auf Dringliches durch entsprechende Positionierung oder Terminierung aufmerksam zu machen, sowie durch eine thematische Strukturierung behalten alle am Projekt Beteiligten einen guten Überblick über den Stand der Arbeiten in einem bestimmten Bereich.
Für die rasche Kommunikation über Spezialfragen wird seit Modul 2 Slack genutzt, das auch einen direkten Austausch von Bildern oder Grafiken und damit z. B. die konkrete Diskussion über fragwürdige Stellen in Manuskripten oder Drucken erlaubt. Da die Kommunikation per Chat hier sowohl zwischen zwei Beteiligten als auch in kleineren Gruppen erfolgen kann, ist Slack auch zu einem flexibel und viel genutzten Instrument der täglichen Arbeit geworden (und ersetzt die häufig umständlichere e-Mail-Kommunikation).
Allerdings sind sich die Mitarbeiter*innen bewusst, dass im Gegensatz zu Redmine diese beiden Tools kommerzielle Produkte mit entsprechenden Risiken sind (bei Slack gehen zudem ältere Einträge in der kostenlosen Version verloren). Sobald im Wissenschaftsbereich ähnlich leistungsfähige Werkzeuge etabliert werden, sollte daher ein Umstieg auf europäischen Datenschutzrichtlinien entsprechende Produkte (vorzugsweise aus dem open-source-Bereich) erfolgen.

Als wichtig für den Erfolg des Projekts erwies sich wiederholt die Außendarstellung bzw. die Art der Vermittlung der Ergebnisse. Das Feedback von Kolleg*innen und Nutzer*innen bzw. auch von neuen Mitarbeiter*innen im Projekt, die durch ihren noch unverstellten Blick wertvolle Anregungen gaben, wurde zu eingehenden Diskussionen und Modifikationen nicht nur der Struktur der Website (vgl. oben), sondern auch der Darstellung der VideApp-Arrangements genutzt. Gleichzeitig zeigten sich auch hier wieder Grenzen der technischen Umsetzung, die nicht ohne großen Aufwand überwunden werden können. Das gilt auch für die verschiedenen Perspektiven, die in der VideApp-Arrangements realisiert wurden – es muss stets klar vermittelt werden, was der Rechner hier (nur) zu leisten im Stande ist und wie die Ergebnisanzeigen zu interpretieren sind bzw. welche Analysen zwar wünschenswert aber mit den vorhandenen Kapazitäten gegenwärtig noch nicht in befriedigender Form umsetzbar sind.

Zu den erfreulichen Ergebnissen gehörte, dass durch die innerhalb der neuen Infrastruktur umgesetzten Continuous Delivery/Continuous Integration-Prozesse die Mitarbeiter*innen beider Arbeitsstellen inzwischen sehr viel intensiver auch im Bereich der verwendeten Technologien und Standards zusammenarbeiten und damit die Verbindung textgenetischer und digitaler Ansätze auch im Team enger gelebt werden kann.