Spheren
Muziek van
Paul Merkus
de Muziekverwerker

Introductie en context

In de jaren 1988...1995 heb ik voor de hobby veel tijd besteed aan het zelf programmeren van een "muziekverwerker". Het waren de jaren waarin de Personal Computer zijn intrede deed en ik ook via een "PC-privé" regeling vanuit mijn werkgever werd gestimulleerd om daarmee kennis te maken. Het was de tijd waarin de "tekstverwerker" in opmars was als de killer application van de MS-DOS PC. Dit was ook het tijvak tussen mijn eerste en tweede periode voor wat betreft het componeren van mijn Spheren oeuvre.

de Muziekverwerker

Als tegenhanger van de "tekstverwerker" ontstond aldus de "muziekverwerker", en heb ik een compleet systeem voor muzieknotatie op een 16-bit MS-DOS PC ontworpen en geimplementeerd, geschreven in Turbo Pascal met behulp van Borland's Graphics Interface (BGI). Ik wilde een muzieknotatie systeem maken dat notie had van hoe westerse tonale muziek in elkaar zit door dat intern te modelleren, vanuit de muziektheoretische basisprincipes. Al met al had het MUSIC systeem vele features die ook beschreven zijn in de MUSIC Help File.

Bach's Badinerie in de MUSIC Muziekverwerker

Concept

Het concept achter deze muziekverwerker is dat het een symbolische editor is van MIDI bestanden (destijds in opmars), en dat dit tool de gebruiker in staat stelt om MIDI bestanden in muzieknotatie te bewerken. Gezien het feit dat er meerdere verschillende representaties mogelijk zijn in het muziekschrift, kiest het tool de beste weergave op basis van muziektheoretische analyses. Het tool bepaalt de muzikaal correcte weergave van een noot, de gebruiker heeft hier geen invloed op. Dit leidt ertoe dat de gebruiker zich kan concentreren op de muzikale aspecten van een stuk (wellicht zijn compositie), en niet op de notatieaspecten, aangezien deze automatisch worden afgehandeld.

Software architectuur

De centrale ontwerpbeslissing was om bladmuziek weer te geven als een tijdgeordende stroom van "muzikale entiteiten", en niet als weer te geven noten in maten en notenbalken als plaatjes. Eerst de datastructuur van akkoorden, rusten, maatstrepen, maatsoorten, toonsoortwisselingen en andere muzikale "entiteiten" (in temporele volgorde met elkaar verbonden), daarna de grafische weergave daarvan. Hierdoor was het mogelijk om de muzikale betekenis (maatsoort, duur, accentuering) onafhankelijk van de visuele lay-out te bepalen.
Deze aanpak bleek robuust: het inschatten van de toonsoort, het nummeren van de maat, het detecteren van een eventuele opmaat en andere beslissingen over de weergave konden allemaal worden afgeleid van dezelfde onderliggende datastructuur.

Het systeem was bewust opgebouwd uit duidelijk gescheiden lagen:

  • Kernmodel: Fundamentele muzikale concepten – toonhoogte, duur, maatsoort, tonaliteit, accenten en maatstructuur – werden geďmplementeerd in een herbruikbare, niet-grafische kern
  • Muzikale verwerking: Intelligentie met betrekking tot de grafische weergave, zoals accentuering, keuze van de muzieksleutel, afhandeling van de opmaat en het nummeren van de maat, werd geďmplementeerd als transformaties die op het muzikale model werken, onafhankelijk van eventuele weergaveaspecten
  • Presentatie en lay-out: De lay-out van de muziek werd gepland in termen van pagina's, systemen en rechthoekige gebieden, geabstraheerd van elk specifiek uitvoerapparaat (scherm of printer).
  • Abstracte invoer en uitvoer: Het parsen, afdrukken en opslaan werden gedefinieerd via abstracte basisobjecten, waardoor meerdere bestandsformaten en uitvoerdoelen dezelfde kernlogica konden delen. Deze scheiding maakte het mogelijk om te redeneren over muzikale correctheid zonder constant rekening te hoeven houden met de weergave.

Intelligentie in notatie

Een belangrijk aspect van het systeem was het expliciete onderscheid tussen "logische muzikale duur" en "visuele groepering voor notatie". Noten konden "pseudo-waarden" krijgen die uitsluitend werden gebruikt voor notatiebeslissingen zoals het groeperen van notenbalken, zonder hun muzikale duur te veranderen. Accentuering werd algoritmisch berekend op basis van maatsoort en onderverdeling, in plaats van heuristisch te worden afgeleid tijdens de lay-out. In feite werden notatieregels behandeld als een formele laag bovenop de muzikale structuur, niet als tekentrucs.

Menu om nooteigenschappen te wijzigen in Muziekverwerker

Implementatiecontext

Dit alles werd ontwikkeld op een MS-DOS computer, zonder moderne taalfunctionaliteiten, refactoringtools of grafische frameworks. De object oriented taalextensies van Borland's Turbo Pascal zijn uitgebreid benut, inclusief overerving en abstracte methoden, om het systeem ondanks de beperkingen van de omgeving uitbreidbaar te houden. Terugkijkend lijkt de architectuur op wat later zou worden omschreven als gelaagd of domeingestuurd ontwerp – hoewel het destijds simpelweg de meest directe manier was die ik kon vinden om muzieknotatie correct te laten werken op basis van interpretatie van de invoer.

Waarom het project eindigde

Midden jaren negentig was de kernarchitectuur van het systeem stabiel en uitbreidbaar, maar een aantal essentiële weergavefuncties waren nog niet geďmplementeerd, waaronder dynamische markeringen, legato-bogen, triolen en andere complexere constructies. Deze functies werden niet geblokkeerd door architectonische beperkingen; ze vertegenwoordigden de volgende laag van complexiteit, maar er was (veel) meer tijd voor nodig die features ook allemaal te implementeren. Rond dezelfde tijd veranderde het PC-platformlandschap ingrijpend met de komst van Windows 95, waardoor een op DOS gebaseerd grafisch systeem steeds minder praktisch werd om voort te zetten. Kort daarna begon ik Encore te gebruiken, een commercieel muzieknotatieprogramma dat vrijwel alle resterende features al had geďmplementeerd die ik nog op mijn ontwikkelingslijst had staan. Op dat moment verdween mijn motivatie om mijn eigen systeem verder te ontwikkelen. Ik had nu een compleet muzieknotatieprogramma tot mijn beschikking en ging me weer richten op het componeren; dit was het begin van de tweede periode. Dit project eindigde daarom zeker niet omdat het mislukte, maar omdat het een punt bereikte waarop verder werk voor mij alleen als enige ontwikkelaar (in mijn vrije tijd) niet langer zinvol was. Ik heb er veel van geleerd, zowel over muziektheorie, als ook over programmeren en software architectuur.

Consistentie check foutloos doorlopen voor Badineri

Terugblik

Als we deze code tientallen jaren later opnieuw bekijken, valt niet de taal of het platform op, maar de duurzaamheid van de onderliggende ideeën. Hoewel de implementatie duidelijk een product van zijn tijd is, blijft het conceptuele model solide (en dat geeft me jaren later nog steeds veel voldoening)

NotebookLM Studio materiaal

Met behulp van NotebookLM heb ik meer verdiepend materiaal kunnen genereren over de MuziekVerwerker (allemaal in het Engels, net als de MUSIC Help File).

  • Een podcast over hoe muzieksoftware toonhoogte en ritme definieert ("How Music Software Defines Pitch and Rhythm") is hier te beluisteren (36 min).
  • Een presentatie over het ontwerp van het muzieknotatiesysteem ("The Digital Scriptorium and Orchestra") is hier te downloaden (14 slides).
  • Een video overview over de architectuur van de MuziekVerwerker ("the music tool") hier te zien en te horen (< 8 min).
  • Een analytische studie van de architectuur en logica van de MuziekVerwerker ("Analysis of MusicTool Architectural Framework and Logic") is hier te downloaden (3 pagina's).
  • Een grafisch overzicht van het MUSIC programma als symbolische MIDI editor ("MUSIC: the Intelligent Symbolic MIDI Editor") is hier te zien.
  • Een grafisch overzicht van de interne afhankelijkheden tussen de vele Pascal units ("A Pascal Unit Dependency Map") is hier te zien.
  • Klik op de infographic over de anatomie van het muzieknotatiesysteem in de full resolution versie