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 syntactisch 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/haar compositie), en niet op de notatieaspecten, aangezien deze automatisch worden afgehandeld door het tool.Software architectuur
De centrale ontwerpbeslissing was om bladmuziek conceptueel weer te geven als een tijdgeordende stroom van "muzikale entiteiten". De datastructuur die ik gekozen had bestond uit akkoorden, rusten, maatstrepen, maatsoorten, toonsoortwisselingen en andere muzikale "entiteiten" (in temporele volgorde met elkaar verbonden). De akkoord-entiteiten wezen dan naar een reeks van noten, waardoor “het waslijn-model” werd gevormd. De grafische weergave van deze muziek was dan van tweede orde. Door deze opzet werd het mogelijk om een analyse van de opbouw van het muziek te bepalen (waaronder de toonsoort) alvorens de visuele lay-out te kiezen.Het systeem is bewust opgebouwd uit duidelijk gescheiden subsystemen:
- Reader: de lezer is het gedeelte waarmee het bronbestand wordt ingelezen. Dit kan een MIDI-bestand of een bestand in het eigen MFx-formaat (oorspronkelijk MF1, later (toen er ook akkoordsymbolen werden ondersteund) het MF2 bestand en daarna (toen er ook liedtekst werd ondersteund) het MF3-formaat. De reader plaatst het muziekstuk uit het bronbestand in de interne MUSIC datastructuur
- Editor: de bewerker is het belangrijkste gedeelte van het MUSIC programma, het stelt de gebruiker in staat de muzieknotatie te zien en te bewerken. De kracht van MUSIC zit hem in het kunnen bewerken van een muziekstuk op bladmuziek= notatie niveau.
- Writer: de schrijver kan de inhoud van de datastructuur wegschrijven naar een MIDI of MFx-bestand
- Player: de speler kan het muziekstuk als audio afspelen, aanvankelijk alleen als piepjes via de interne PC-speaker, in latere versies ook naar een SoundBlaster geluidskaart
- Printer: de afdrukeenheid maakt het mogelijk bladmuziek te printen, dit kon zowel een Epson als een HP printer zijn, maar ook een PostScript file (voorloper van het PDF-formaat) of een HTML-bestand vol XBM bitmap files. De MUSIC bladmuziek is in feite een screenshot van wat de Editor kon tonen.
Software architectuur van de Muziekverwerker
Intelligentie in notatie
De vertaling van laag-niveau reeksen toets-aanslag en -loslaat informatie naar muzikale notatie kent twee uitdagende aspecten:- Horizontaal: de notatie van lange noten is eenvoudig, maar bij reeksen van achtsten, zestienden en nog kortere noten dienen de vlaggen aan de stokken geclusterde te worden, en wel op een wijze die past bij de onderhavige maatsoort. Daarom wordt er in het systeem een expliciet onderscheid gemaakt tussen "logische muzikale duur" en "visuele groepering voor notatie". Noten krijgen "pseudo-waarden" die alleen gebruikt worden voor de notatie beslissingen van het groeperen van korte noten. Ook de accentuering werd hierbij berekend op basis van maatsoort en onderverdeling (zware en lichte maatdelen).
- Verticaal: de notatie van de toonhoogte is lastig bij “zwarte toetsen” omdat daar meerdere en harmonische spellingen mogelijk zijn (b.v. Fis (F#) verses Ges (Gb)). De keuze tussen een kruis (#) en een mol (b) wordt bepaald door de toonsoort van het stuk (of het betreffende gedeelte daarvan) en soms ook door de melodische context. Daarom voert MUSIC zowel een harmonische analyse uit (het bepalen van de toonsoort) als een melodische analyse (stemvoering, vooral belangrijk bij chromatische passages).
Menu om nooteigenschappen te wijzigen in Muziekverwerker
Rule-checker
Een belangrijk uitgangspunt van het MUSIC-programma is dat het de gebruiker in staat stelt om een (nieuw) muziekstuk te noteren en daarbij door het programma geholpen te worden om dat op een muzikaal syntactisch juiste manier te doen. Haast iedere maat moet het juiste aantal tellen hebben dat past bij de maatsoort van dat moment en de enharmonische notatie (F# of Gb, A# of Bb) moet kloppen bij de onderhavige toonsoort. Ook de notatie van meervoudige rusten moet op een bepaalde manier gebeuren, overeenkomstig de maatsoort en het maatritme (dus 3/4 en 6/8 verschillen hierin). Dit zijn een drietal voorbeelden van muzikale notatie regels waarin het MUSIC programma helpt. Soms gaat die hulp automatisch, soms door de rule-checker, een functie die door de gebruiker aangeroepen kan worden om het muziekstuk helemaal door te lopen en te controleren. Een groene melding dat alle maten kloppen is dan fijn :-)Implementatiecontext
Dit alles heb ik “met de hand” ontwikkeld op een MS-DOS computer met beperkte geheugencapaciteit, zonder moderne refactoringtools of grafische frameworks. De object oriented taalextensies van Borland's Turbo Pascal heb ik uitgebreid benut, inclusief overerving en abstracte methoden, om zo een strakke structuur qua systeemontwerp te kunnen doorvoeren (incl. information hiding) en het systeem uitbreidbaar te houden. Terugkijkend lijkt de architectuur op wat later zou worden omschreven als een gelaagd en domeingestuurd ontwerp – maar voor mij was het destijds de beste manier om de weergave van de muzieknotatie correct te kiezen, helemaal 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 gestructureerdheid 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
