Část 5 ze série článků popisujících protokol MIDI.

Jednou ze tří částí protokolu MIDI je specifikace formátu datového úložiště (nezapomeňte, že další dvě jsou formát zprávy a specifikace hardwarového rozhraní). Formát zpráv byl probrán v prvních třech článcích série, nyní je čas na formát úložiště. Byl navržen organizací MMA na konci roku 1987 a byl pojmenován Standard MIDI Files (SMF).

Účelem souborů MIDI je umožnit výměnu událostí (tj. zpráv MIDI s časovým razítkem) mezi různými zařízeními a programy. Před příchodem standardních MIDI souborů nebylo možné uspořádání připravené v jednom sekvenceru načíst do jiného kvůli nekompatibilitě formátů. Tím nechci říct, že s příchodem SMF na tento formát přešli všichni výrobci sekvencerů. Důvodů je více a dnes si o nich také povíme.

Vzhledem k tomu, že ukládání informací přímo souvisí se zařízením sekvenátorů, zastavíme se u této záležitosti podrobněji, ale pouze v rozsahu nezbytném pro pochopení SMF. A nepochybně sekvencerům budeme věnovat jeden z příštích článků cyklu.

Vývoj
Je volána MIDI zpráva s časovým razítkem událost... K indikaci času lze použít různé jednotky - ticks, interní impulsy, čas ve formátu SMPTE atd. Je důležité pochopit základní rozdíl mezi událostí a zprávou. Zpráva „žije“ zlomek milisekundy reálného času – od okamžiku, kdy je vygenerována zdrojem, do okamžiku, kdy je odeslána příjemci k provedení. Může být zachycen v procesu přenosu přes MIDI kabel ve formě sady impulsů. Událost je několik bajtů informace zaznamenané v paměti zařízení, na základě které bude v budoucnu, v určený čas, vygenerována zpráva.

Sekvencer může například uložit událost „pick a note“ s časovou značkou 100 ms od začátku přehrávání. Tuto událost můžete upravit ve dvou rozměrech: za prvé, změnit parametry samotné MIDI zprávy (v tomto případě výšku nebo dynamiku noty) a za druhé, posouvat notu po stopě, to znamená změnit dobu provedení. zprávy.

Události se objevují v paměti sekvenceru během nahrávání MIDI zpráv. Když stisknete tlačítko Record, sekvencer zapne hardwarový pulzní generátor (ticky) a začne „poslouchat“ určený MIDI vstup. Když například stisknete klávesu, vstup obdrží zprávu „vyberte poznámku“. Sekvencer vypadá - aha, zpráva dorazila při 20. tiknutí a zapíše ji do paměti štítkem 20. Po pár sekundách klávesu pustili - přišla zpráva "odstraň poznámku", vnitřní generátor vesele zamával 64 v tu chvíli tiká do sekvenceru. Sekvencer uloží zprávu s označením 64. Nyní máme co do činění se dvěma událostmi - Note On a Note Off. Během přehrávání se pulzní generátor znovu zapne. Když se objeví 20. tik, je do MIDI výstupu sekvenceru odeslána zpráva Note On, 64. tik je Note Off. Nahráli jsme a poté přehrávali akce interpreta!

Je zřejmé, že totéž lze provést offline, tedy bez nutnosti živého hraní. Kliknutím myši na správné místo na stopě (a předem zvolenou dobu trvání noty) zabudujeme do paměti sekvenceru přesně předchozí obrázek.

Typy paměti
Nyní je čas použít dva skličující počítačové termíny: primární a sekundární paměť. Primární (neboli interní) paměť je paměť sekvenceru, kde se zaznamenávají zprávy a ukládají události během celé relace. Obsah této paměti se vymaže po vypnutí napájení. Tato interpretace je vhodnější pro hardwarové sekvencery. V softwarových sekvencerech je primární pamětí jednoduše RAM počítače. K dlouhodobému uložení obsahu primární paměti slouží sekundární paměť, jinak řečeno datové nosiče. Může to být disketa, pevný disk, čipová karta a podobně.

Velikost primární paměti v hardwarových sekvencerech a pracovních stanicích (nezapomeňte, že pracovní stanice je tónový generátor a sekvencer v jedné krabici) se obvykle vyjadřuje počtem uložených not (například 200 tisíc). Někdy je hlasitost vyjádřena v událostech, v tomto případě je třeba být ve střehu – jedna nota vyžaduje k uložení dvě události (stisknutí a uvolnění klávesy) a otočení kolečka pitch nebo aftertouch může vygenerovat až 100 nebo více událostí. Stává se, že velikost paměti sekvenceru je vyjádřena v nativních počítačových jednotkách – kilobajtech. To však také není příliš pohodlné - jedna událost může zabírat různý počet bajtů (od pěti do několika desítek).

V moderních softwarových sekvencerech málokoho zajímá množství primární paměti – i na stroji se 128 MB RAM můžete na jakákoliv omezení při práci s MIDI daty zapomenout. Navíc existují sekvencery, které dokážou přehrát aranžmá přímo z disku, aniž by je načítaly do primární paměti (a mimochodem i nahrávaly), což obecně smazává rozdíl mezi těmito dvěma typy pamětí.

V sekundární paměti se data obvykle zapisují do souboru. Většina sekvencerů má svůj vlastní proprietární formát tohoto souboru, což ztěžuje výměnu uspořádání vytvořených v různých zařízeních nebo programech. Již dříve bylo uvedeno, že to byl hlavní důvod pro vytvoření SMF.

Měření času
Ve skutečnosti nejsou uvnitř sekvenceru žádná „tikátka“. Existuje hardwarový časovač, který generuje pulzy s přísně konstantní frekvencí (například každou mikrosekundu). Nutit hudebníky měřit čas v mikrosekundách by byl monstrózní výsměch, stejně jako v jiných jednotkách reálného času (sekundy, minuty). Hudebníci jsou zvyklí přemýšlet v taktech a taktech a vyjadřovat čas v relativních jednotkách (doba trvání not), v závislosti na aktuálním tempu.

"Žádný problém," odpověděli výrobci, "nechte je změřit, jak je to pro ně pohodlnější." Jen minimální měrnou jednotkou nebude nějaká 32. doba trvání, ale konvenčně odebraný tik (jednotka je ještě menší, takže např. jedna třicetisekunda může obsahovat 48 ticků). Vzhledem k tomu, že od klasické éry se tempo měřilo počtem čtvrtin za minutu (BPM, tepy za minutu), rozhodli se jako hlavní trvání vzít čtvrtinu a uvést počet tiků za čtvrtletí - PPQN (Pulse Per Čtvrtletní poznámka). Čím větší je PPQN, tím lepší je rozlišení sekvenceru a tím přesnější v čase dokáže zachytit zprávy během nahrávání a vyvést je na MIDI výstup během přehrávání. Většina sekvencerů umožňuje libovolně nastavit PPQN - například od 32 do 1536 tiků za čtvrtletí (moderní sekvencery - až 15360 PPQN).

Tick ​​je jednotka závislá na rychlosti: čím rychlejší je rychlost, tím kratší je interval mezi tiky v jednotkách v reálném čase. Tento interval lze zjistit vzorcem na obr. 1.

Například při 120 BPM a 96 PPQN budou tiky následovat každých 5,208 milisekund. Při stejném rozlišení a 180 BPM se interval mezi tikáním zkrátí na 3,472 ms. Jak tiká počet sekvenceru, pokud jeho vnitřní časovač pulzuje každou mikrosekundu? Je to velmi jednoduché: na základě aktuálního tempa a rozlišení ve čtvrtině, přesně podle zadaného vzorce. Protože jedna milisekunda obsahuje 1000 mikrosekund, v posledním příkladu sekvencer vygeneruje další tik, když obdrží 3472 pulzů z časovače.

Pozice události na časové ose se nastavuje v sekvenceru, obvykle ve formátu „takty: doby: ticks“, například 22: 3: 152. Tedy: dvacátý druhý takt, třetí takt, 152. takt od začátku třetího taktu. Tento princip časování (anglický termín - Timebase) se nazývá hudební, protože je pro hudebníky známý a pohodlný. Vezměte prosím na vědomí, že pro práci v tomto formátu potřebujete znát aktuální takt. To znamená, kolik taktů obsahuje takt a čemu se každý takt rovná.

Takže u 4/4 taktu se takt rovná čtvrtině a takt obsahuje čtyři doby. Při rozlišení 384 PPQN to bude 384 tiků v jednom taktu a 1536 tiků v každém tiku (384 x 4). Při 6/8 a stejném rozlišení bude jeden takt 192 taktů (osmný je poloviční než čtvrtina) a takt bude mít šest taktů nebo 1152 taktů (192 x 6). 22: 3: 152 tedy v prvním případě znamená 35096 tiků od začátku skladby (22 x 1536 + 3 x 384 + 152) a ve druhém - 26072 tiků (22 x 1152 + 3 x 192 + 152) .

Chcete-li tedy určit polohu události v jednotkách reálného času na základě formátu „takty: doby: ticks“, potřebujete znát tři parametry: aktuální tempo, takt a rozlišení v ticích za čtvrtletí (PPQN).

Existuje další možnost časování, kdy je poloha události na stopě vyjádřena v absolutních jednotkách nezávislých na tempu, nejčastěji ve formátu času SMPTE - "hodiny: minuty: sekundy: snímky". Tento princip časování se nazývá „time-code-based“ (založený na časovém kódu, absolutní). Potřeba vyvstává, když sekvencer spolupracuje s magnetofonem nebo filmovým/video zařízením. Editační operace s filmem, videem a zvukovým materiálem, upřesnění pozic začátku a konce nahrávky je pohodlnější provádět, protože jsou vázány na absolutní měřítko a ne na takty a doby.

V tomto případě závisí souřadnice události na časovém pravítku na aktuálním tempu. Takže při tempu 120 BPM může mít první takt druhého taktu SMPTE čas 00: 00: 02: 00 a při tempu 60 BPM - 00: 00: 04: 00. Když je událost umístěna v rámci snímku (mezi sekundami), její souřadnice se budou lišit také v jiném formátu snímku (počet snímků za sekundu). Více o SMPTE a MIDI Time Code si můžete přečíst v předchozím článku ze série.

Variabilní délkové množství
Dost lyrických odboček, nyní je naším úkolem porozumět formátu ukládání dat. A první výzvou, které vývojáři SMF čelili, bylo, jak dodržet načasování události.

Zde jsou dvě možnosti: uložit pro každou událost čas od začátku skladby nebo od poslední události před ní (na stejném kanálu). První možnost však není racionální, protože nejčastěji je interval mezi událostmi malý, sousední události mají časy provedení blízko sebe. Takže v pasáži o třech tónech může mít první čas řekněme 22: 3: 152, druhý - 22: 3: 244, třetí - 22: 3: 288. Chcete-li uložit tato čísla (přeložená do ticků od začátku skladby), musíte pro každé vyhradit alespoň čtyři bajty. Pokud půjdete po druhé cestě, můžete místo tří velkých čísel uložit jedno velké počáteční (22: 3: 152) a po něm - dvě malá, rozdíl v tikátech mezi prvním a druhým a druhým a třetí noty (v tomto případě 92 a 44), stačí jim jeden bajt. Problém však stále zůstává: v závislosti na události musíte alokovat jiný počet bajtů, abyste ušetřili čas.

Pokud by v současné době vyvíjel SMF (a dokonce i Microsoft, který se obecně málo stará o velikost svých souborů a potřebnou paměť), nad tímto problémem by se zavíralo oko. Přidělili jsme pevné pole pro úsporu času, řekněme 8 bajtů na událost, a neutrpěli jsme. V roce 1988 však byla primární (RAM) paměť velmi drahá, každý bajt se počítal a sekundární (disková média) měla velmi skromnou velikost. Vývojáři SMF proto chtěli získat co nejkompaktnější formát.

Bylo rozhodnuto zachovat delta čas, tedy rozdíl v tikáních mezi touto událostí a předchozí (nebo začátkem skladby). Pokud například k první události – úderu noty do první oktávy – došlo v čase 40 ticků od začátku písně, pak její delta čas bude 40. Jestliže po čtyřech tiklech zazní tón F, pak jeho delta čas bude 4. Pokud nastanou dvě události současně, pak jedné z nich je přiřazen delta čas rovný nule. Pokud událost nastane přesně na začátku skladby, má také delta čas nula. K další události však může dojít za hodinu a půl (to znamená za několik milionů tiků). Jak být v tomto případě? Koneckonců, paměť je třeba šetřit a je nežádoucí přidělovat pevné pole několika bajtů pro delta čas.

Takzvaný variabilní délky... Poskytují pohodlný způsob zápisu celých čísel, od nejmenších po největší, aniž by bylo nutné číslu přidělovat pevný počet bajtů. Bity původního čísla jsou zabaleny do jednoho nebo více bajtů: každý bajt má sedm bitů (vpravo bity 0 až 6). Nejvýznamnějším bitem v bajtu je služba; všechny bajty v řadě, kromě posledního, musí obsahovat jedničku, poslední - nulu. Několik příkladů balení je znázorněno na obr. 4.

Například musíte zabalit číslo 64 (hex 0x40) do formátu s proměnnou délkou. V binární podobě je toto číslo zapsáno jako 0100 0000. Existuje pouze sedm platných bitů, takže toto číslo je zabaleno do jednoho bajtu beze změny - 0100 0000 (je to také poslední bajt řady), nejvýznamnější bit je 0.

Nyní je číslo 128 (0x80). V binární podobě se zapisuje jako 1000 0000. Významných bitů je osm, takže se vše nevejde do jednoho bajtu, je potřeba ho rozdělit na dva. První bajt musí mít jedničku v nejvýznamnějším bitu, druhý (jako koncový bajt řady) - nulu. Do druhého bajtu vložíme sedm nejméně významných bitů původního čísla, vyjde nám 0 000 0000. Zbývající jeden bit (jeden) dáme na pravou stranu prvního bajtu – dostaneme 1 000 0001. Výsledkem je, číslo 0x80 se zapisuje jako dva bajty: 0x81 0x00. Rozbalení je velmi jednoduché. Předem nevíme, kolik bajtů je v řadě. Přečteme první bajt - 1000 0001. Nejvýznamnější servisní bit (1) udává, že toto není poslední bajt řady, bajtů je více. Zahodíme servisní jednotku a ponecháme sedm bitů - 000 0001. Přečtěte si druhý bajt - 0000 0000. Nejvýznamnější servisní bit (0) udává, že se jedná o poslední bajt série (to znamená, že v řadě jsou pouze dva bajty série). Vyhazujeme servisní bit. Zbývá také sedm bitů - 000 0000. Přičteme k nim vlevo sedm bitů přidělených z prvního bajtu, dostaneme 000 0001 000 0000. Vyřazením prvních šesti nul dostaneme požadované číslo 1000 0000 (0x80).

Metoda proměnných délek tedy umožňuje alokovat různé počty bajtů pro různá čísla: pro čísla v rozsahu od 0 do 127 - jeden bajt, od 128 do 16383 - dva bajty a tak dále. Maximální počet zastoupený tímto způsobem není v zásadě omezen. V SMF je však délka shluku omezena na čtyři bajty (tři s nastaveným nejvýznamnějším bitem a jeden končící nulou). V důsledku toho může být maximální delta čas 0x0FFFFFFF (nebo 268 435 455 tiků), což je při rychlosti 500 BPM a rozlišení 96 PPQN asi čtyři dny. Víc než dost!

Ve formě hodnot proměnné délky udává SMF nejen delta čas, ale i délku některých událostí.

Interchange File Format (IFF)
Struktura standardního MIDI souboru je téměř zcela odvozena od IFF (Interchange File Format), vyvinutého v roce 1985 společností Electronic Arts. Jedná se o formát pro ukládání a výměnu dat, který již téměř dvacet let usnadňuje život uživatelům i vývojářům softwaru. Electronic Arts neposkytlo pouze dokumentaci s otevřeným zdrojovým kódem, ale také zdrojový kód C pro čtení a zápis souborů IFF.

Formát IFF je zpětně kompatibilní a rozšiřitelný. První znamená, že nová verze programu dokáže bez problémů číst soubory vytvořené předchozí verzí. Za druhé, nemusíte vymýšlet nový formát pro ukládání dalších informací, stačí zadat do IFF vlastní rozšíření. Struktura formátu umožňuje programům od různých výrobců vyměňovat si data, která mezi sebou nemají odpovídající obchodní dohody. To vše potěší uživatele - po uložení dat ve formátu IFF již nejsou připoutáni k uzavřenému formátu svého systému a mohou data používat v jakémkoli softwarovém a hardwarovém prostředí kompatibilním s IFF.

Soubor IFF je sbírka dat organizovaná takovým způsobem, že je mohou číst různé nesouvisející programy. Na druhou stranu může program do IFF ukládat specifické informace, které mají význam pouze pro něj samotného. Struktura IFF to usnadňuje. Jiné programy, které nevědí, jak s takovými informacemi zacházet, je mohou ignorovat, aniž by ohrozily čtení hlavního obsahu.

Existuje několik typů souborů IFF. Například soubory ILBM a GIFF obsahují grafické informace, soubory SMUS obsahují hudební notaci a soubory AIFF a WAVE obsahují digitální zvuk.

Soubor IFF se skládá z podobných prvků, které se nazývají chunks. Blok je datová struktura skládající se z abecedního identifikátoru (čtyři znaky ASCII), velikosti bloku (čtyři bajty) a samotných dat (obrázek 5). Je vhodné si představit blok jako shell, ve kterém jsou data „zabalena“. Samotná data mohou obsahovat cokoli: grafiku, text, animaci, zvuk, sadu 3D objektů a tak dále.

Bloky v souboru IFF lze vnořovat, obr. 6. Soubor IFF ve skutečnosti není nic jiného než blok nejvyšší úrovně obsahující jeden nebo více dalších bloků uvnitř. Tento princip ukládání dat umožňuje „zabalit“ několik heterogenních dat do souboru, včetně několika souborů IFF, který již připomíná systém souborů uvnitř souboru. Pravda, organizace vnořených dat má jednu nevýhodu – soubor se obtížně interpretuje, izoluje z něj bloky.

Většina souborů IFF obsahuje blok nejvyšší úrovně s identifikátorem „FORM“. Jeho součástí jsou další bloky (obr. 7). Jedinými daty v bloku FORM jsou čtyři bajty popisující typ souboru (např. "ILBM", InterLeaved Bit Map). Bezprostředně za nimi jsou vnořené bloky jako „BMHD“ (záhlaví obrázku), „CMAP“ (paleta) a „BODY“ (samotné pixely). Názvy bloků a formát dat jsou vynalezeny vývojářem konkrétního typu souboru. Jiné programy, pokud narazí na blok s neznámým názvem, jej mohou bezpečně přeskočit, vedené polem obsahujícím délku bloku.

Všechna číselná data v souborech IFF jsou uložena v pořadí big-endian, to znamená, že jako první je uložen nejvýznamnější bajt čísla (MSB) a poté bajt s nejnižší hodnotou. Více o tom najdete na postranním panelu. Bloky v souboru musí vždy začínat sudým bajtem. Pokud předchozí blok obsahuje lichý počet bajtů, je doplněn prázdným bajtem, aby byl sudý.

SMF struktura
Standardní soubory MIDI, jako soubory IFF, se skládají z bloků. Celkem existují dva typy bloků: Header Chunk a Track Chunk. V souboru SMF může být pouze jeden blok záhlaví a jeden nebo více bloků stop. Blok má typickou strukturu IFF: první čtyři bajty jsou identifikátor, další čtyři bajty jsou délka bloku v bajtech, s výjimkou typu / délky osmi bajtů. Identifikátor bloku záhlaví jsou čtyři znaky "MThd" a identifikátor bloku stopy jsou čtyři znaky "MTrk". Tato struktura umožní v budoucnu definovat nové typy bloků a neznámý blok lze snadno ignorovat na základě jeho délky. Specifikace SMF varuje: "Programy by měly být připraveny ignorovat bloky neznámých typů, když na ně narazí."

Blok záhlaví obsahuje obecné informace o souboru, blok stopy obsahuje proud MIDI zpráv s časovými razítky. MIDI soubor navíc ukládá další informace nezbytné pro sekvencery: tempo, takt, tóninu, nastavení metronomu a podobně. Tyto informace nejsou přenášeny přes MIDI rozhraní a události, které je tvoří, se nazývají meta-události.

MIDI soubor vždy začíná blokem záhlaví následovaným jedním nebo více bloky stopy (obrázek 9). To znamená, že jakýkoli standardní MIDI soubor začíná čtyřmi písmeny „M“, „T“, „h“, „d“. To znamená, že soubor MIDI nevyhovuje specifikaci IFF (která vyžaduje, aby každý soubor vyhovující IFF začínal blokem nejvyšší úrovně jednoho ze tří typů – „FORM“, „CAT“ nebo „LIST“). Existují další rozdíly: SMF nemohou obsahovat vnořené bloky a délka bloku nemusí být sudá. Převod SMF na soubor vyhovující IFF je však jednoduchý. Bloky liché délky stačí vycpat nulovým bytem (pokud existuje) a veškerý obsah vložit do bloku FORM. Podobná operace se používá ve formátu RMID navrženém společností Microsoft (viz postranní panel).