Het vijfde deel van een reeks artikelen waarin het MIDI-protocol wordt beschreven.

Een van de drie componenten van het MIDI-protocol is de specificatie van het gegevensopslagformaat (laat me u eraan herinneren dat de andere twee componenten het berichtformaat en de hardware-interfacespecificatie zijn). Het berichtformaat werd besproken in de eerste drie artikelen van de serie, nu is het tijd voor het opslagformaat. Het werd eind 1987 voorgesteld door de MMA-organisatie en heette Standard MIDI Files (SMF).

Het doel van MIDI-bestanden is om de uitwisseling van gebeurtenissen (dat wil zeggen MIDI-berichten met een tijdstempel) tussen verschillende apparaten en programma's mogelijk te maken. Vóór de komst van standaard MIDI-bestanden kon een arrangement dat in de ene sequencer was voorbereid, niet in een andere worden geladen vanwege incompatibele formaten. Er kan niet worden gezegd dat met de komst van SMF alle sequencerfabrikanten op dit formaat zijn overgestapt. Daar zijn verschillende redenen voor, en we zullen er vandaag ook over praten.

Omdat informatieopslag rechtstreeks verband houdt met het ontwerp van sequencers, zullen we hier dieper op ingaan, maar alleen in de mate die nodig is om SMF te begrijpen. En een van de volgende artikelen in de serie zullen we ongetwijfeld aan sequencers wijden.

Evenementen
Er wordt een MIDI-bericht met een tijdstempel aangeroepen evenement. Er kunnen verschillende eenheden worden gebruikt om de tijd aan te geven: tikken, interne impulsen, tijd in SMPTE-formaat, enz. Het is belangrijk om het fundamentele verschil tussen een gebeurtenis en een bericht te begrijpen. Het bericht ‘leeft’ een fractie van een milliseconde in realtime - vanaf het moment dat het door de bron wordt gegenereerd tot het moment dat het bij de ontvanger arriveert voor uitvoering. Het kan tijdens de verzending via een MIDI-kabel worden opgevangen in de vorm van een reeks impulsen. Een gebeurtenis is een aantal bytes aan informatie die in het geheugen van het apparaat worden vastgelegd, op basis waarvan in de toekomst op een afgesproken tijdstip een bericht wordt gegenereerd.

Een sequencergeheugen kan bijvoorbeeld een note-on-gebeurtenis opslaan met een tijdstempel van 100 ms vanaf het begin van het afspelen. Je kunt deze gebeurtenis in twee dimensies bewerken: ten eerste verander je de parameters van het MIDI-bericht zelf (in dit geval de toonhoogte of dynamiek van de noot), en ten tweede verplaats je de noot langs het spoor, dat wil zeggen, verander je de uitvoeringstijd. van het bericht.

Events verschijnen in het sequencergeheugen terwijl MIDI-berichten worden opgenomen. Wanneer u op de Record-knop drukt, schakelt de sequencer de hardware-pulsgenerator in (tikt) en begint te "luisteren" naar de gespecificeerde MIDI-invoer. Wanneer u bijvoorbeeld een toets indrukt, is het invoerbericht ‘speel een noot’. De sequencer ziet eruit - ja, het bericht arriveerde bij de 20e tik en schrijft het in het geheugen met een markering van 20. Na een paar seconden lieten ze de toets los - het bericht "verwijder notitie" arriveerde, de interne generator op dat moment zwaaide vreugdevol 64 tikken naar de sequencer. De sequencer slaat het bericht op met label 64. Nu hebben we te maken met twee gebeurtenissen: Note On en Note Off. Tijdens het afspelen wordt de pulsgenerator weer ingeschakeld. Wanneer de 20e tik nadert, wordt er een Note On-bericht naar de MIDI-uitgang van de sequencer gestuurd, en een Note Off-bericht naar de 64e tik. We hebben de acties van de artiest opgenomen en vervolgens afgespeeld!

Uiteraard kan hetzelfde “offline” worden gedaan, dat wil zeggen zonder dat er live optredens nodig zijn. Door met de muis op de gewenste plek op de track te klikken (en vooraf de nootduur te selecteren), bouwen we precies het vorige beeld op in het geheugen van de sequencer.

Geheugentypen
Dit is het moment om twee enge computertermen te gebruiken: primair en secundair geheugen. Het primaire (of interne) geheugen is het sequencergeheugen waarin berichten worden opgenomen en gebeurtenissen gedurende de hele run worden opgeslagen. De inhoud van dit geheugen wordt gereset als de stroom wordt uitgeschakeld. Deze interpretatie is meer geschikt voor hardwaresequencers. Bij softwaresequencers is het primaire geheugen eenvoudigweg het RAM-geheugen van de computer. Om de inhoud van het primaire geheugen voor langere tijd op te slaan, wordt secundair geheugen of anders opslagmedia gebruikt. Dit kan een diskette, harde schijf, smartcard, enz. zijn.

De hoeveelheid primair geheugen in hardwaresequencers en werkstations (laat me u eraan herinneren dat een werkstation een toongenerator en een sequencer in één doos is) wordt meestal uitgedrukt in het aantal opgeslagen noten (bijvoorbeeld 200 duizend). Soms wordt het volume uitgedrukt in events, in welk geval je voorzichtig moet zijn: voor één noot zijn twee events nodig (het indrukken en loslaten van een toets), en het draaien aan het pitchwiel of de aftertouch kan tot wel 100 of meer events genereren. Het komt voor dat de geheugencapaciteit van een sequencer wordt uitgedrukt in native computereenheden: kilobytes. Maar dit is ook niet erg handig: één gebeurtenis kan een ander aantal bytes in beslag nemen (van vijf tot enkele tientallen).

In moderne softwaresequencers geven maar weinig mensen om de hoeveelheid primair geheugen - zelfs op een machine met 128 MB RAM kun je eventuele beperkingen vergeten bij het werken met MIDI-data. Daarnaast zijn er sequencers die een arrangement rechtstreeks vanaf schijf kunnen afspelen, zonder het in het primaire geheugen te laden (en het overigens ook op te nemen), waardoor het onderscheid tussen de twee soorten geheugen doorgaans wordt opgeheven.

In het secundaire geheugen worden gegevens doorgaans naar een bestand geschreven. De meeste sequencers hebben hun eigen gesloten formaat voor dit bestand, wat het moeilijk maakt om arrangementen uit te wisselen die in verschillende apparaten of programma's zijn gemaakt. Eerder werd gezegd dat dit de belangrijkste reden was voor de oprichting van SMF.

Tijd meten
In feite zijn er geen "vinkjes" in de sequencer. Er is een hardwaretimer die pulsen genereert met een strikt constante frequentie (bijvoorbeeld elke microseconde). Het dwingen van muzikanten om de tijd in microseconden te meten zou een monsterlijke aanfluiting zijn, net als bij andere eenheden van realtime (seconden, minuten). Muzikanten zijn gewend te denken in maten en tellen, en de tijd uit te drukken in relatieve eenheden (nootduur), afhankelijk van het huidige tempo.

“Geen probleem”, antwoordden de producenten, “laat ze meten zoals zij dat nodig achten.” Alleen zal de minimale meeteenheid niet een 32e duur zijn, maar een voorwaardelijk genomen tick (de eenheid is nog kleiner, zodat bijvoorbeeld één dertigste 48 ticks kan bevatten). Omdat het tempo in het klassieke tijdperk werd gemeten aan de hand van het aantal kwartalen per minuut (BPM, slagen per minuut), hebben we besloten een kwart als hoofdduur te nemen en het aantal tikken per kwart aan te geven - PPQN (Pulse Per Quarter Note) . Hoe groter de PPQN, hoe beter de resolutie van de sequencer en hoe nauwkeuriger in de tijd deze berichten tijdens de opname kan vastleggen en deze tijdens het afspelen naar de MIDI-uitgang kan uitvoeren. Met de meeste sequencers kunt u PPQN willekeurig instellen, bijvoorbeeld van 32 tot 1536 ticks per kwartaal (moderne sequencers - tot 15360 PPQN).

Een tik is een tempo-afhankelijke eenheid: hoe sneller het tempo, hoe korter het interval tussen tikken in realtime-eenheden. Dit interval kan worden gevonden met behulp van de formule in Fig. 1.

Met een tempo van 120 BPM en een resolutie van 96 PPQN zullen er bijvoorbeeld elke 5,208 milliseconden tikken optreden. Bij dezelfde resolutie en hetzelfde tempo van 180 BPM wordt het interval tussen de tikken teruggebracht tot 3,472 ms. Hoe telt een sequencer de tikken als de interne timer elke microseconde pulseert? Ja, het is heel eenvoudig: op basis van het huidige tempo en de kwartresolutie, precies volgens de opgegeven formule. Omdat één milliseconde 1000 microseconden bevat, genereert de sequencer in het laatste voorbeeld de volgende tik wanneer hij 3472 pulsen van de timer ontvangt.

De positie van een gebeurtenis op de tijdliniaal wordt gespecificeerd in de sequencer, meestal in het formaat "maten: tellen: tikken", bijvoorbeeld 22:3:152. Dat wil zeggen: tweeëntwintigste maat, derde tel, 152e tik vanaf het begin van de derde tel. Dit principe van tijdtelling (de Engelse term is Timebase) wordt muzikaal genoemd, omdat het bekend en handig is voor muzikanten. Houd er rekening mee dat u, om in dit formaat te kunnen werken, de huidige maatsoort moet kennen. Dat wil zeggen, hoeveel tellen bevat een maat en waar is elke tel gelijk aan?

In een 4/4 maatsoort is de tel dus gelijk aan een kwart, en bevat de maat vier tellen. Met een resolutie van 384 PPQN zijn er 384 tikken in één tel en 1536 tikken in elke maat (384 x 4). Met een 6/8 maatsoort en dezelfde resolutie zijn er 192 tikken in één tel (een achtste noot is half zo lang als een kwartnoot), en zijn er zes tellen in een maat, of 1152 tikken (192 x 6 ). Dus het opnemen van 22:3:152 betekent in het eerste geval 35096 tikken vanaf het begin van het nummer (22 x 1536 + 3 x 384 + 152), en in het tweede geval - 26072 tikken (22 x 1152 + 3 x 192 + 152). ).

Om dus de positie van een gebeurtenis in real-time eenheden te bepalen op basis van het formaat beats: beats: ticks, moet je drie parameters kennen: het huidige tempo, de maatsoort en de resolutie in ticks per quarter (PPQN).

Er is nog een andere mogelijkheid om de tijd te tellen, wanneer de positie van een gebeurtenis op een track wordt uitgedrukt in absolute eenheden die niet afhankelijk zijn van het tempo, meestal in het SMPTE-tijdformaat - "uren: minuten: seconden: frames". Dit timingprincipe wordt “tijdcodegebaseerd” (tijdcodegebaseerd, absoluut) genoemd. De behoefte daaraan ontstaat wanneer de sequencer samenwerkt met een bandrecorder of film-/videoapparatuur. Het is handiger om bewerkingshandelingen uit te voeren met film-, video- en audiomateriaal, waarbij de posities van het begin en einde van de opname worden aangegeven, verwijzend naar een absolute schaal, in plaats van naar maten en tellen.

In dit geval hangt de coördinaat van de gebeurtenis op de tijdliniaal af van het huidige tempo. Dus bij een tempo van 120 BPM kan de eerste tel van de tweede maat een SMPTE-tijd hebben van 00:00:02:00, en bij een tempo van 60 BPM - 00:00:04:00. Wanneer de gebeurtenis binnen het frame wordt gepositioneerd (tussen seconden), zal de coördinaat ervan ook verschillen bij verschillende frameformaten (aantal frames per seconde). Meer over SMPTE en MIDI Time Code kun je lezen in het vorige artikel in de serie.

Variabele lengtehoeveelheden
Genoeg lyrische uitweidingen, nu is het onze taak om het gegevensopslagformaat te begrijpen. En de eerste moeilijkheid waarmee SMF-ontwikkelaars te maken kregen, was hoe ze de tijd van een evenement moesten opslaan.

Er zijn hier twee opties: sla de tijd op voor elke gebeurtenis vanaf het begin van het nummer, of vanaf de laatste gebeurtenis ervoor (op hetzelfde kanaal). De eerste optie is echter niet rationeel, omdat het interval tussen gebeurtenissen meestal klein is en aangrenzende gebeurtenissen uitvoeringstijden hebben die dicht bij elkaar liggen. Dus in een passage van drie noten kan de eerste een tijd hebben van bijvoorbeeld 22:3:152, de tweede - 22:3:244, de derde - 22:3:288. Om deze nummers (vertaald in ticks vanaf het begin van het nummer) op te slaan, moet je voor elk minimaal vier bytes reserveren. Als je het tweede pad volgt, kun je in plaats van drie grote getallen één groot startgetal (22:3:152) opslaan, gevolgd door twee kleine, het verschil in ticks tussen het eerste en het tweede, en de tweede en derde noten (in dit geval 92 en 44), is één byte voldoende voor hen. Maar het probleem blijft bestaan: afhankelijk van de gebeurtenis moet een ander aantal bytes worden toegewezen om tijd te besparen.

Als SMF op dit moment zou worden ontwikkeld (en zelfs door Microsoft, dat zich doorgaans weinig bekommert om de grootte van de bestanden en het benodigde geheugen), zouden ze dit probleem door de vingers zien. We hebben een vast veld toegewezen om tijd te besparen, bijvoorbeeld 8 bytes per gebeurtenis, en hebben daar niet onder geleden. In 1988 was het primaire (RAM) geheugen echter erg duur; elke byte werd geteld, en het secundaire (schijfmedia) had een zeer bescheiden volume. Daarom wilden de SMF-ontwikkelaars een zo compact mogelijk formaat bereiken.

Er werd besloten om te behouden delta-tijd, dat wil zeggen het verschil in tikken tussen deze gebeurtenis en de vorige (of het begin van het nummer). Als de eerste gebeurtenis - het spelen van de noot C van het eerste octaaf - bijvoorbeeld plaatsvond op het moment dat 40 tikken vanaf het begin van het nummer plaatsvond, dan zal de deltatijd gelijk zijn aan 40. Als de noot F vier tikken later wordt gespeeld, dan zal de deltatijd gelijk zijn aan 4. Als twee gebeurtenissen tegelijkertijd plaatsvinden, krijgt één ervan een deltatijd toegewezen die gelijk is aan nul. Als een gebeurtenis precies aan het begin van het nummer plaatsvindt, heeft deze ook een deltatijd van nul. De volgende gebeurtenis kan echter over anderhalf uur plaatsvinden (dat wil zeggen na enkele miljoenen tikken). Wat te doen in dit geval? Er moet immers geheugen worden bespaard, en het is onwenselijk om voor deltatijd een vast veld van meerdere bytes in omvang toe te wijzen.

De zogenaamde hoeveelheden met variabele lengte. Ze bieden een handige manier om gehele getallen van de kleinste naar de grootste te schrijven, zonder dat u een vast aantal bytes aan het getal hoeft toe te wijzen. De bits van het oorspronkelijke getal zijn verpakt in een of meer bytes: elke byte bevat zeven bits (rechts, bits 0 tot en met 6). Het belangrijkste bit in een byte is een servicebit; alle bytes in de reeks, behalve de laatste, moeten een één bevatten, de laatste moet een nul bevatten. Verschillende verpakkingsvoorbeelden worden getoond in Fig. 4.

U moet bijvoorbeeld het getal 64 (hexadecimaal 0x40) in een formaat met variabele lengte verpakken. In binaire vorm wordt dit getal geschreven als 0100 0000. Er zijn slechts zeven significante bits, dus dit getal is zonder wijzigingen in één byte verpakt - 0100 0000 (het is ook de laatste byte van de reeks), de meest significante bit is 0 .

Nu is het nummer 128 (0x80). In binaire vorm wordt het geschreven als 1000.0000. Er zijn acht significante bits, dus niet alles past in één byte, je moet het in tweeën splitsen. De eerste byte moet een één hebben in het meest significante bit, de tweede (als laatste byte van de reeks) moet een nul hebben. In de tweede byte plaatsen we de zeven minst significante bits van het oorspronkelijke getal, we krijgen 0 000 0000. We plaatsen de resterende bit (één) aan de rechterkant van de eerste byte - we krijgen 1000 0001. Als gevolg hiervan wordt de nummer 0x80 wordt geschreven als twee bytes: 0x81 0x00. Uitpakken is heel eenvoudig. We weten van tevoren niet hoeveel bytes de reeks bevat. We lezen de eerste byte - 1000 0001. De meest significante servicebit (1) geeft aan dat dit niet de laatste byte van de serie is, er zijn meer bytes. We gooien de service-eenheid weg en laten zeven bits over - 000 0001. Lees de tweede byte - 0000 0000. De meest significante servicebit (0) geeft aan dat dit de laatste byte van de reeks is (dat wil zeggen dat er slechts twee bytes in de reeks zijn). serie). De servicebit wordt weggegooid. Er zijn ook nog zeven bits over - 000 0000. We voegen aan de linkerkant de zeven bits toe die uit de eerste byte zijn gehaald, we krijgen 000 0001 000 0000. Als we de eerste zes nullen weggooien, krijgen we het gewenste getal 1000 0000 (0x80).

Met de variabele lengtemethode kunt u dus verschillende aantallen bytes toewijzen aan verschillende getallen: voor getallen in het bereik van 0 tot 127 - één byte, van 128 tot 16383 - twee bytes, enzovoort. Het aldus weergegeven maximum aantal is in principe onbeperkt. In SMF is de runlengte echter beperkt tot vier bytes (drie met de meest significante bitset en één eindigend met een nul). Als gevolg hiervan kan de maximale deltatijd 0x0FFFFFFF (of 268.435.455 ticks) zijn, wat bij een tempo van 500 BPM en een resolutie van 96 PPQN ongeveer vier dagen is. Meer dan genoeg!

In de SMF-vorm met variabele lengte wordt niet alleen de deltatijd gespecificeerd, maar ook de lengte van sommige events.

Bestandsformaat uitwisselen (IFF)
De structuur van een standaard MIDI-bestand is vrijwel volledig ontleend aan het IFF-formaat (Interchange File Format), ontwikkeld in 1985 door Electronic Arts. Dit is een formaat voor gegevensopslag en -uitwisseling dat het leven van zowel gebruikers als softwareontwikkelaars al bijna twintig jaar gemakkelijker maakt. Electronic Arts leverde niet alleen open documentatie, maar ook C-broncode voor het lezen en schrijven van IFF-bestanden.

Het IFF-formaat is achterwaarts compatibel en uitbreidbaar. De eerste betekent dat de nieuwe versie van het programma gemakkelijk bestanden kan lezen die door de vorige versie zijn gemaakt. Ten tweede hoeft u geen nieuw formaat te bedenken om aanvullende informatie op te slaan; u hoeft alleen maar uw eigen extensie in IFF in te voeren. Dankzij de structuur van het formaat kunnen programma's van verschillende fabrikanten, die geen overeenkomstige zakelijke overeenkomsten hebben, gegevens uitwisselen. Dit alles maakt gebruikers blij: omdat ze gegevens in het IFF-formaat hebben opgeslagen, zijn ze niet langer gebonden aan het gesloten formaat van hun systeem en kunnen ze de gegevens gebruiken in elke IFF-compatibele hardware- en softwareomgeving.

Een IFF-bestand is een verzameling gegevens die zo zijn georganiseerd dat verschillende, niet-gerelateerde programma's deze kunnen lezen. Aan de andere kant kan een programma specifieke informatie in de IFF opslaan die alleen voor zichzelf betekenis heeft. De IFF-structuur maakt dit eenvoudig te doen. Andere programma's die niet weten hoe ze met dergelijke informatie moeten omgaan, kunnen deze negeren zonder de lezing van de hoofdinhoud te beïnvloeden.

Er zijn verschillende soorten IFF-bestanden. ILBM- en GIFF-bestanden bevatten bijvoorbeeld grafische informatie, SMUS-bestanden bevatten muzieknotatie en AIFF- en WAVE-bestanden bevatten digitaal geluid.

Een IFF-bestand bestaat uit vergelijkbare elementen die blokken worden genoemd. Een blok is een datastructuur die bestaat uit een letteridentificatie (vier ASCII-tekens), een blokgrootte (vier bytes) en de gegevens zelf (figuur 5). Het is handig om een ​​blok te beschouwen als een schil waarin gegevens zijn ‘verpakt’. De gegevens zelf kunnen van alles bevatten: afbeeldingen, tekst, animatie, geluid, een reeks 3D-objecten, enzovoort.

Blokken in een IFF-bestand kunnen worden genest, Fig. 6. In feite is een IFF-bestand niets meer dan een blok op het hoogste niveau dat een of meer andere blokken bevat. Met dit principe van gegevensopslag kunt u verschillende heterogene gegevens in een bestand 'verpakken', inclusief verschillende IFF-bestanden, wat doet denken aan een bestandssysteem in een bestand. Toegegeven, met een geneste gegevensorganisatie is er één nadeel: het bestand wordt moeilijk te interpreteren en er blokken uit te isoleren.

De meeste IFF-bestanden bevatten een blok op het hoogste niveau met de identificatie "FORM". Het bevat andere blokken (Fig. 7). De enige gegevens in het FORM-blok bestaan ​​uit vier bytes die het bestandstype beschrijven (bijvoorbeeld "ILBM", InterLeaved Bit Map). Direct daarachter bevinden zich geneste blokken, bijvoorbeeld "BMHD" (afbeeldingskop), "CMAP" (palet) en "BODY" (de pixels zelf). De namen van de blokken en het dataformaat worden gemaakt door de ontwikkelaar van een specifiek bestandstype. Als andere programma's een blok tegenkomen met een onbekende naam, kunnen ze dit veilig overslaan, waarbij ze zich laten leiden door het veld met de lengte van het blok.

Alle numerieke gegevens in IFF-bestanden worden opgeslagen in big-endian-volgorde, dat wil zeggen dat de meest significante byte van het getal (MSB) eerst wordt opgeslagen en daarna de minst significante byte. Dit wordt in meer detail besproken in de zijbalk. Blokken binnen een bestand moeten altijd beginnen met een even byte. Als het vorige blok een oneven aantal bytes bevat, wordt het opgevuld met een nulbyte om het even te maken.

SMF-structuur
Standaard MIDI-bestanden bestaan, net als IFF-bestanden, uit blokken (Chunks). Er zijn twee soorten blokken: Header Chunk en Track Chunk. Een SMF-bestand kan slechts één headerblok en één of meer trackblokken bevatten. Het blok heeft een typische IFF-structuur: de eerste vier bytes zijn de identificatie, de volgende vier bytes zijn de lengte van het blok in bytes, exclusief acht type/lengtebytes. De headerblokidentificatie bestaat uit vier tekens "MThd", de trackblokidentificatie bestaat uit vier tekens "MTrk". Dankzij deze structuur kunnen in de toekomst nieuwe bloktypen worden gedefinieerd en kan een onbekend blok gemakkelijk worden genegeerd op basis van zijn lengte. De SMF-specificatie waarschuwt: "Programma's moeten voorbereid zijn om, wanneer ze blokken tegenkomen van typen die ze niet kennen, deze te negeren."

Het headerblok bevat algemene informatie over het bestand, het trackblok bevat een stroom MIDI-berichten met tijdstempels. Bovendien slaat het MIDI-bestand aanvullende informatie op die sequencers nodig hebben: tempo, maatsoort, toonsoort, metronoominstellingen en dergelijke. Deze informatie wordt niet via de MIDI-interface verzonden en de gebeurtenissen waaruit deze informatie bestaat, worden meta-gebeurtenissen genoemd.

Een MIDI-bestand begint altijd met een headerblok, gevolgd door een of meer trackblokken (Afbeelding 9). Dat wil zeggen dat elk standaard MIDI-bestand begint met vier letters "M", "T", "h", "d". Dit betekent dat het MIDI-bestand niet voldoet aan de IFF-specificatie (die vereist dat elk IFF-compatibel bestand begint met een blok op het hoogste niveau van een van de drie typen - "FORM", "CAT" of "LIST"). Er zijn nog meer verschillen: SMF kan geen geneste blokken bevatten, en de bloklengte hoeft niet even te zijn. Het converteren van een SMF naar een IFF-compatibel bestand is echter eenvoudig. Het is voldoende om blokken van oneven lengte (indien aanwezig) op te vullen met een nulbyte en alle inhoud in een FORM-blok te plaatsen. Een soortgelijke bewerking wordt gebruikt in het door Microsoft voorgestelde RMID-formaat (zie kader).