A MIDI protokollt részletező cikksorozat 5. része.

A MIDI protokoll három részéből az egyik az adattárolási formátum specifikációja (ne feledje, a másik kettő az üzenetformátum és a hardver interfész specifikációja). Az üzenetformátumról a sorozat első három cikkében volt szó, most jött el a tárolási formátum ideje. Az MMA szervezet javasolta 1987 végén, és a Standard MIDI Files (SMF) nevet kapta.

A MIDI-fájlok célja, hogy lehetővé tegyék az események (azaz időbélyegzett MIDI-üzenetek) cseréjét a különböző eszközök és programok között. A szabványos MIDI fájlok megjelenése előtt az egyik szekvenszerben elkészített elrendezést nem lehetett betölteni a másikba a formátum-összeférhetetlenség miatt. Ez nem azt jelenti, hogy az SMF megjelenésével minden szekvenszergyártó erre a formátumra váltott. Ennek több oka is van, ma ezekről is lesz szó.

Mivel az információ tárolása közvetlenül kapcsolódik a szekvenszerek eszközéhez, részletesebben foglalkozunk ezzel a kérdéssel, de csak az SMF megértéséhez szükséges mértékben. És kétségtelenül a ciklus következő cikkeinek egyikét a szekvenszereknek fogjuk szentelni.

Események
Időbélyegzett MIDI üzenet kerül meghívásra esemény... Különböző mértékegységek használhatók az idő jelzésére - ketyegés, belső impulzusok, idő SMPTE formátumban stb. Fontos megérteni az esemény és az üzenet közötti alapvető különbséget. Az üzenet a valós idő egy ezredmásodpercének töredékéig "él" - attól a pillanattól kezdve, hogy a forrás generálja, egészen addig a pillanatig, amikor elküldik a vevőnek végrehajtásra. A MIDI-kábelen keresztüli átvitel során impulzuskészlet formájában fogható meg. Az esemény a készülék memóriájában rögzített néhány bájtnyi információ, amely alapján a jövőben, a megadott időpontban üzenet generálódik.

Például a szekvenszer eltárolhat egy "pick a note" eseményt a lejátszás kezdetétől számított 100 ms időbélyeggel. Ezt az eseményt két dimenzióban szerkesztheti: egyrészt magának a MIDI-üzenetnek a paramétereit (jelen esetben a hang hangmagasságát vagy dinamikáját), másrészt a hangot a sáv mentén mozgathatja, azaz módosíthatja a végrehajtási időt. az üzenetről.

Az események a szekvenszer memóriájában jelennek meg MIDI üzenetek rögzítése közben. Amikor megnyomja a Record gombot, a szekvenszer bekapcsolja a hardveres impulzusgenerátort (kettyeg), és elkezdi "hallgatni" a megadott MIDI bemenetet. Például, amikor megnyom egy billentyűt, a bemenet megkapja a "válasszon jegyzetet" üzenetet. A szekvenszer nézi - aha, az üzenet a 20. pipára érkezett, és 20-as címkével írja be a memóriába. Pár másodperc múlva elengedték a kulcsot - jött a "remove the note" üzenet, a belső generátor boldogan intett 64-et. ketyeg a szekvenszerre abban a pillanatban. A szekvenszer elment egy üzenetet a 64-es címkével. Most két eseménnyel van dolgunk - Note On és Note Off. Lejátszás közben az impulzusgenerátor újra bekapcsol. Amikor a 20. tick megjelenik, egy Note On üzenetet küld a szekvenszer MIDI kimenetére, a 64. tick egy Note Off. Felvettük, majd visszajátszottuk az előadó akcióit!

Nyilvánvalóan ugyanez megtehető offline, vagyis élő előadás nélkül. A sávon a megfelelő helyre kattintva az egeret (és előre kiválasztva a hang időtartamát), pontosan az előző képet építjük be a szekvenszer memóriájába.

Memória típusok
Itt az ideje, hogy alkalmazzunk két ijesztő számítógépes fogalmat: az elsődleges és a másodlagos memóriát. Az elsődleges (vagy belső) memória a szekvenszer-memória, ahol az üzeneteket rögzítik és az eseményeket a teljes munkamenet során tárolják. A memória tartalma törlődik, ha a készüléket kikapcsolja. Ez az értelmezés inkább hardveres szekvenszerekhez való. A szoftveres szekvenszereknél az elsődleges memória egyszerűen a számítógép RAM-ja. Az elsődleges memória tartalmának hosszú távú tárolására másodlagos memóriát, vagy más szóval adathordozókat használnak. Ez lehet hajlékonylemez, merevlemez, intelligens kártya és hasonlók.

A hardveres szekvenszerekben és munkaállomásokban (ne feledjük, egy munkaállomás hanggenerátor és szekvenszer egy dobozban) az elsődleges memória mennyiségét általában a tárolt hangjegyek számában fejezik ki (például 200 ezer). Néha a hangerőt eseményekben fejezik ki, ebben az esetben résen kell lenni – egy hangjegy tárolása két eseményt igényel (egy billentyű lenyomása és felengedése), a hangmagasság elforgatása vagy az utóérintés pedig akár 100 vagy több eseményt is generálhat. Előfordul, hogy a szekvenszer memória méretét natív számítógépes egységekben - kilobájtokban - fejezik ki. De ez sem túl kényelmes - egy esemény különböző számú bájtot foglalhat el (öttől több tízig).

A modern szoftveres szekvenszerekben kevesen törődnek az elsődleges memória mennyiségével - még egy 128 MB RAM-mal rendelkező gépen is elfelejtheti a korlátozásokat a MIDI adatokkal való munka során. Ezen kívül vannak olyan szekvencerek, amelyek képesek lejátszani egy elrendezést közvetlenül a lemezről anélkül, hogy az elsődleges memóriába töltenék (és mellesleg rögzítenék is), ami általában törli a különbséget a két memóriatípus között.

A másodlagos memóriában az adatok általában fájlba íródnak. A legtöbb szekvenszernek saját formátuma van ennek a fájlnak, ami megnehezíti a különböző eszközökön vagy programokban létrehozott elrendezések cseréjét. Korábban elhangzott, hogy ez volt a fő oka az SMF létrehozásának.

Időmérés
Valójában nincsenek "kullancsok" a szekvenszer belsejében. Van egy hardveres időzítő, amely szigorúan állandó frekvenciájú impulzusokat generál (például minden mikroszekundumban). A zenészeket arra kényszeríteni, hogy mikroszekundumban mérjék az időt, szörnyű gúny lenne, akárcsak a valós idő más egységeiben (másodpercben, percben). A zenészek hozzászoktak, hogy ütemekben és ütemekben gondolkodjanak, és az időt relatív egységekben (hanghosszúságban) fejezzék ki, az aktuális tempótól függően.

"Semmi baj" - válaszolták a gyártók -, mérjék meg, ahogy nekik kényelmesebb. Csak a minimális mértékegység nem valami 32. időtartam lesz, hanem egy hagyományosan vett kullancs (az egység még kisebb, így például egy harminc másodpercben 48 kullancs is szerepelhet). Mivel a klasszikus korszak óta a tempót a percenkénti negyedek számával mérik (BPM, ütések percenként), ezért úgy döntöttek, hogy a negyedet veszik fő időtartamnak, és jelzik a negyedenkénti kullancsok számát - PPQN (Pulse Per). negyedjegyzet). Minél nagyobb a PPQN, annál jobb a szekvenszer felbontása, és annál pontosabb időben képes rögzíteni az üzeneteket a felvétel során, és lejátszás közben a MIDI kimenetre továbbítani. A legtöbb szekvenszer lehetővé teszi a PPQN tetszőleges beállítását - például negyedévente 32-1536 tick (modern szekvenszerek - 15360 PPQN-ig).

A kullancs egy árfolyamfüggő mértékegység: minél gyorsabb az árfolyam, annál rövidebb idő telik el a tickek között valós idejű egységekben. Ezt az intervallumot az ábra képletével találhatjuk meg. egy.

Például 120 BPM és 96 PPQN esetén a ketyegés 5,208 ezredmásodpercenként követi. Ugyanezen felbontás és 180 BPM mellett a ketyegések közötti intervallum 3,472 ms-ra csökken. Hogyan számol egy szekvenszer, ha a belső időzítője minden mikroszekundumban pulzál? Nagyon egyszerű: az aktuális tempó és felbontás alapján negyedben, pontosan a megadott képlet szerint. Mivel egy ezredmásodperc 1000 mikroszekundumot tartalmaz, az utolsó példában a szekvenszer újabb ticket generál, amikor 3472 impulzust kap az időzítőtől.

Egy esemény helyzete az idővonalon a szekvenszerben van beállítva, általában "sávok: ütemek: ketyeg" formátumban, például 22:3:152. Vagyis: a huszonkettedik ütem, a harmadik ütem, a 152. pipa a harmadik ütem elejétől. Ezt az időzítési elvet (az angol kifejezés - Timebase) zeneinek nevezik, mert ismerős és kényelmes a zenészek számára. Kérjük, vegye figyelembe, hogy ismernie kell az aktuális órajelet, ha ebben a formátumban szeretne dolgozni. Vagyis hány ütemet tartalmaz a mérték, és mennyivel egyenlők az egyes ütemek.

Tehát 4/4-es időjelnél az ütem egyenlő a negyeddel, és egy ütem négy ütemet tartalmaz. 384 PPQN felbontásnál 384 tick lesz egy ütemben, és 1536 tick lesz minden tickben (384 x 4). 6/8-nál és azonos felbontásnál egy ütem 192 tics lesz (egy nyolcad fele olyan hosszú, mint egy negyed), egy ütem pedig hat ütemből vagy 1152 ticsből áll (192 x 6). Így a 22:3:152 az első esetben 35096 pipát jelent a dal elejétől (22 x 1536 + 3 x 384 + 152), a másodikban pedig - 26072 pipát (22 x 1152 + 3 x 192 + 152) .

Tehát ahhoz, hogy egy esemény valós idejű egységekben való helyzetét a "sávok: ütemek: ketyeg" formátum alapján meghatározhassa, három paramétert kell ismernie: az aktuális tempót, az időjelet és a felbontást negyedenkénti osztásban (PPQN).

Van egy másik lehetőség az időzítésre, amikor egy esemény pozícióját a pályán a tempótól független abszolút egységekben fejezik ki, leggyakrabban SMPTE időformátumban - "óra: perc: másodperc: képkocka". Ezt az időzítési elvet "időkód-alapúnak" (timecode-based, abszolút) nevezik. Erre akkor van szükség, ha a szekvenszer magnóval vagy filmes/videó berendezéssel együtt dolgozik. A film-, videó- ​​és hanganyaggal végzett szerkesztési műveletek, a felvétel eleje és vége pozíciójának megadása kényelmesebb, mivel abszolút skálához kötődik, nem ütemekhez és ütemekhez.

Ebben az esetben az esemény koordinátája az idővonalzón az aktuális tempótól függ. Tehát 120 BPM-es tempónál a második ütem első ütemének SMPTE ideje 00: 00: 02: 00, 60 BPM - 00: 00: 04: 00 tempónál lehet. Ha egy esemény egy képkockán belül van elhelyezve (másodperc között), annak koordinátája is különbözik egy másik képkocka formátumtól (kockák száma másodpercenként). Az SMPTE-ről és a MIDI Time Code-ról bővebben a sorozat előző cikkében olvashat.

Változó hosszúságú mennyiségek
Elég a lírai kitérőből, most az adattárolási formátum megértése a feladatunk. Az első kihívás, amellyel az SMF fejlesztői szembesültek, az volt, hogyan tartsák be az esemény időpontját.

Itt két lehetőség van: minden eseményhez eltárolni az időt a dal elejétől, vagy az azt megelőző utolsó eseménytől (ugyanazon a csatornán). Az első lehetőség azonban nem racionális, mert legtöbbször kicsi az események közötti intervallum, a szomszédos események végrehajtási ideje közel van egymáshoz. Tehát egy három hangból álló szakaszban az elsőnek mondjuk 22:3:152, a másodiknak - 22:3:244, a harmadiknak - 22:3:288 lehet az idő. Ezen számok tárolásához (a dal elejétől pipára fordítva) mindegyikhez legalább négy bájtot kell lefoglalnia. Ha a második úton halad, akkor három nagy szám helyett elmenthet egy nagy kezdőpontot (22: 3: 152), és utána - két kicsi, az első és a második, valamint a második közötti különbséget. és harmadik hangok (jelen esetben 92 és 44), elég nekik egy bájt. A probléma azonban továbbra is fennáll: az eseménytől függően eltérő számú bájtot kell lefoglalnia, hogy időt takarítson meg.

Ha az SMF-et jelenleg fejlesztenék (és még a Microsoft is, amely általában keveset törődik a fájljai méretével és a szükséges memóriával), akkor ez a probléma szemet hunyna. Kiosztottunk egy fix mezőt az időmegtakarítás érdekében, mondjuk eseményenként 8 bájtot, és nem szenvedtünk kárt. 1988-ban azonban az elsődleges (RAM) memória nagyon drága volt, minden bájtot megszámoltak, a másodlagos (lemezes adathordozó) pedig nagyon szerény méretű volt. Ezért az SMF fejlesztői a lehető legkompaktabb formátumot akarták elérni.

Úgy döntöttek, hogy megtartják delta idő, vagyis az esemény és az előző (vagy a dal eleje) közötti ketyegés különbség. Például, ha az első esemény - a hang elütése az első oktávra - a dal elejétől számított 40 ketyegés idején történt, akkor a delta ideje 40 lesz. Ha négy pipálás után az F hang szólal meg, akkor a deltaideje 4 lesz. Ha két esemény történik egyszerre, akkor az egyikhez nullával egyenlő deltaidőt rendelünk. Ha az esemény pontosan a dal elején következik be, akkor annak deltaideje is nulla. A következő esemény azonban másfél óra múlva következhet be (vagyis több millió kullancsban). Hogyan lehet ebben az esetben? Végül is a memóriát meg kell menteni, és nem kívánatos több bájtos fix mezőt lefoglalni a deltaidőhöz.

Az úgynevezett változó hosszúságú... Kényelmes módot biztosítanak egész számok írására a legkisebbtől a legnagyobbig anélkül, hogy fix számú bájtot kellene lefoglalni a számhoz. Az eredeti szám bitjei egy vagy több bájtba vannak csomagolva: minden bájt hét bites (jobb oldalon 0-6 bit). A bájt legjelentősebb bitje a szolgáltatás; a sorozat összes bájtjának, az utolsó kivételével, egyet, az utolsónak nullát kell tartalmaznia. ábrán több csomagolási példa látható. 4.

Például a 64-es számot (hex 0x40) változó hosszúságú formátumba kell csomagolnia. Bináris formában ezt a számot 0100 0000-nek írjuk. Csak hét szignifikáns bit van, így ez a szám változatlanul egy bájtba van csomagolva - 0100 0000 (ez egyben a sorozat utolsó bájtja is), a legjelentősebb bit 0.

Most a szám 128 (0x80). Bináris formában 1000 0000-nek írják. Nyolc szignifikáns bit van, tehát nem fog minden beleférni egy bájtba, ketté kell osztani. Az első bájtnak egynek kell lennie a legjelentősebb bitben, a másodiknak (mint a sorozat záró bájtja) nullának kell lennie. Az eredeti szám hét legkisebb jelentőségű bitjét a második bájtba helyezzük, így kiderül, hogy 0 000 0000. A maradék egy bitet (egyet) az első bájt jobb oldalára tesszük - 1000 0001-et kapunk. a 0x80 szám két bájtban van írva: 0x81 0x00. A kicsomagolás nagyon egyszerű. Nem tudjuk előre, hogy hány bájt van a sorozatban. Az első bájtot olvassuk be - 1000 0001. A legjelentősebb szervizbit (1) azt jelzi, hogy nem ez a sorozat utolsó bájtja, több bájt van. Eldobjuk a szolgáltatási egységet, így hét bit marad - 000 0001. Olvassa be a második bájtot - 0000 0000. A legjelentősebb szervizbit (0) azt jelzi, hogy ez a sorozat utolsó bájtja (vagyis csak két bájt van a sorozatban). sorozat). A szervizbitet eldobjuk. Hét bit is maradt - 000 0000. Hozzájuk adunk a bal oldalon hét bitet az első bájtból, így 000 0001 000 0000-et kapunk. Az első hat nullát eldobva megkapjuk a szükséges 1000 0000 (0x80) számot.

Tehát a változó hosszúságú módszer lehetővé teszi különböző számú bájt kiosztását a különböző számokhoz: 0 és 127 közötti számokhoz - egy bájt, 128 és 16383 között - két bájt és így tovább. Az így képviselt maximális szám elvileg nem korlátozott. Az SMF-ben azonban a burst hossza négy bájtra korlátozódik (három bájt a legjelentősebb bitkészlettel, egy pedig nullával végződik). Ennek eredményeként a maximális deltaidő 0x0FFFFFFF (vagy 268 435 455 tick) lehet, ami 500 BPM sebességgel és 96 PPQN felbontással körülbelül négy nap. Több mint elég!

Változó hosszúságú értékek formájában az SMF nemcsak a deltaidőt jelzi, hanem egyes események hosszát is.

Interchange File Format (IFF)
A szabványos MIDI fájl szerkezete szinte teljes egészében az Electronic Arts által 1985-ben kifejlesztett IFF-ből (Interchange File Format) származik. Ez egy olyan adattárolási és -csereformátum, amely közel húsz éve megkönnyíti mind a felhasználók, mind a szoftverfejlesztők életét. Az Electronic Arts nemcsak nyílt forráskódú dokumentációt biztosított, hanem a C forráskódot is az IFF-fájlok olvasásához és írásához.

Az IFF formátum visszafelé kompatibilis és bővíthető. Az előbbi azt jelenti, hogy a program új verziója gond nélkül képes olvasni az előző verzió által létrehozott fájlokat. Másodszor, nem kell új formátumot kitalálni további információk tárolására, elég, ha beírja a saját kiterjesztését az IFF-be. A formátum felépítése lehetővé teszi, hogy a különböző gyártók programjai adatokat cseréljenek egymással, amelyek nem rendelkeznek megfelelő üzleti megállapodással. Mindez örömet okoz a felhasználóknak – az adatok IFF formátumban történő mentése után már nincsenek rendszerük zárt formátumához láncolva, és bármilyen IFF-kompatibilis szoftver- és hardverkörnyezetben használhatják az adatokat.

Az IFF-fájl olyan adatgyűjtemény, amely oly módon van elrendezve, hogy azt különböző, nem kapcsolódó programok elolvassák. Másrészt a program olyan konkrét információkat tud tárolni az IFF-ben, amelyek csak a maga számára jelentenek. Az IFF szerkezet ezt megkönnyíti. Más programok, amelyek nem tudják, hogyan kell kezelni az ilyen információkat, figyelmen kívül hagyhatják azokat anélkül, hogy veszélyeztetnék a fő tartalom olvasását.

Többféle IFF fájl létezik. Például az ILBM és GIFF fájlok grafikus információkat, az SMUS fájlok zenei jelöléseket, az AIFF és WAVE fájlok pedig digitális hangot tartalmaznak.

Az IFF-fájl hasonló elemekből, úgynevezett darabokból áll. A blokk egy adatstruktúra, amely egy alfabetikus azonosítóból (négy ASCII karakter), a blokk méretéből (négy bájt) és magából az adatból áll (5. ábra). Kényelmes úgy tekinteni a blokkra, mint egy héjra, amelybe az adatok "csomagolva" vannak. Maguk az adatok bármit tartalmazhatnak: grafikát, szöveget, animációt, hangot, 3D objektumok halmazát stb.

Az IFF fájl blokkjai egymásba ágyazhatók, ábra. 6. Valójában az IFF fájl nem más, mint egy legfelső szintű blokk, amely egy vagy több további blokkot tartalmaz. Ez az adattárolási elv lehetővé teszi több heterogén adat "csomagolását" egy fájlba, beleértve több IFF fájlt is, amelyek már egy fájlon belüli fájlrendszerre hasonlítanak. Igaz, a beágyazott adatszervezésnek van egy hátránya - a fájl nehezen értelmezhető, blokkokat izolálhat tőle.

A legtöbb IFF-fájl tartalmaz egy legfelső szintű blokkot "FORM" azonosítóval. Más blokkokat is tartalmaz (7. ábra). A FORM blokkban az egyetlen adat négy bájt, amely leírja a fájl típusát (pl. "ILBM", InterLeaved Bit Map). Közvetlenül ezek mögött vannak olyan beágyazott blokkok, mint a "BMHD" (képfejléc), a "CMAP" (paletta) és a "BODY" (maguk a képpontok). A blokkok nevét és az adatformátumot az adott fájltípus fejlesztője találja ki. Más programok, ha ismeretlen nevű blokkra bukkannak, a blokkhosszt tartalmazó mezőtől vezérelve nyugodtan kihagyhatják azt.

Az IFF fájlok minden numerikus adata nagy sorrendben tárolódik, vagyis először a szám legjelentősebb bájtja (MSB), majd a legkisebb jelentőségű bájt kerül tárolásra. Erről bővebben az oldalsávban olvashat. A fájlon belüli blokkoknak mindig páros bájttal kell kezdődniük. Ha az előző blokk páratlan számú bájtot tartalmaz, akkor egy null bájttal töltjük ki, hogy páros legyen.

SMF szerkezet
A szabványos MIDI-fájlok, például az IFF-fájlok, darabokból állnak. Összesen kétféle darab van: fejlécdarab és nyomelemdarab. Egy SMF-fájlban csak egy fejlécblokk és egy vagy több sávblokk lehet. A blokk tipikus IFF felépítésű: az első négy bájt az azonosító, a következő négy bájt a blokk hossza bájtban, a nyolc bájt típus/hossz nélkül. A fejlécblokk azonosítója négy "MThd" karakterből, a sávblokk azonosítója pedig négy "MTrk" karakterből áll. Ez a struktúra lehetővé teszi új blokktípusok meghatározását a jövőben, és egy ismeretlen blokk könnyen figyelmen kívül hagyható a hossza alapján. Az SMF specifikációja figyelmeztet: "A programoknak fel kell készülniük arra, hogy figyelmen kívül hagyják az ismeretlen típusú blokkokat, amikor találkoznak velük."

A fejléc blokk általános információkat tartalmaz a fájlról, a sávblokk a MIDI üzenetek folyamát tartalmazza időbélyegekkel. Ezenkívül a MIDI fájl a szekvenszerekhez szükséges további információkat tárol: tempó, időjelzés, billentyű, metronóm beállítások és hasonlók. Ezeket az információkat nem a MIDI interfészen keresztül továbbítják, az ezt alkotó eseményeket metaeseményeknek nevezzük.

A MIDI fájl mindig egy fejléc blokkkal kezdődik, amelyet egy vagy több sávblokk követ (9. ábra). Ez azt jelenti, hogy bármely szabványos MIDI fájl négy „M”, „T”, „h”, „d” betűvel kezdődik. Ez azt jelenti, hogy a MIDI-fájl nem felel meg az IFF-specifikációnak (amely megköveteli, hogy minden IFF-kompatibilis fájl a három típus egyikének legfelső szintű blokkjával kezdődjön – „FORM”, „CAT” vagy „LIST”). Vannak más különbségek is: az SMF-ek nem tartalmazhatnak beágyazott blokkokat, és a blokk hosszának sem kell párosnak lennie. Az SMF-ek IFF-kompatibilis fájllá konvertálása azonban egyszerű. A páratlan hosszúságú blokkokat elég egy nulla bájttal kitölteni (ha van ilyen), és az összes tartalmat a FORM blokkba tenni. Hasonló műveletet használnak a Microsoft által javasolt RMID formátumban (lásd az oldalsávot).