A üzenetek kódolásán túljutva ismerkedjünk meg a MIDI alkalmazásának néhány gyakorlati kérdésével. Elsőként lássunk egy igen fontos technikát, a státusztartást, amit a MIDI-specifikációban és a szakirodalomban Running Status néven hívnak. Ennek alapgondolata a takarékosság; ha lehet, minél kevesebb bájttal kelljen az adónak a vonalat terhelnie.
Egy rövid példa fog segíteni: üssünk le egy három hangból álló akkordot a billentyűzeten. A hangszer MIDI-kimenetén ennek megfelelően három darab Note On üzenetnek kellene megjelennie, a megfelelő csatornakóddal ellátva, a megfelelő billentyű- és dinamikaértékekkel, valahogy így:
90 b1 d1 90 b2 d2 90 b3 d3
9 bájt ideig foglaljuk le ezzel a megoldással a MIDI-vonalat, amiből 3 bájt tökéletesen egyforma! Ezen segít a státusztartással küldött adás - a vevőnek kötelessége megjegyeznie az utoljára érkezett státuszt, az ezután következő, neki megfelelő számú adatbájtot pedig fogjuk fel önálló MIDI-üzenetként, még akkor is, ha ez az adatcsomag nem volt újabb, önálló státuszbájttal bevezetve! Az előző akkord tehát, ezen a módon küldve, így fog kinézni:
90 b1 d1 b2 d2 b3 d3
A sort lehet folytatni is, hiszen ha semmi egyéb MIDI-eseményt nem közlünk közben, a kkor a következő billentyű lenyomásához is csak a két adatbájtot kell elküldeni. Ez időben akár jóval később is történhet, az egyetlen kritérium az, hogy az adó ne küldjön közben más csatornaüzenetet.
Az eljárás természetesen nemcsak a Note On üzenettel működik, hanem valamennyi csatornaüzenettel megtörténhet. Igazi haszna főleg a hajlításnál és a kontrollereknél mutatkozik, hiszen ezen eszközök használata kis idő alatt is nagyon sok MIDI-üzenetet generál, ezek hosszát a státusztartással a kétharmadára lehet csökkenteni. A státusztartás használata adás közben opcionális, minden csatornaüzenetre érvényes, de csak rájuk; egy beérkező egyszerű, vagy valós idejű rendszerüzenet a specifikáció szerint figyelmen kívül hagyható ebből a szempontból, tehát helyes a következő példa:
90 b1 d1 F8 b2 d2 b3 d3
Itt a hármashangzat első és második hangja közé egy Timing Clock státuszú egybájtos üzenet került, amely a valós idejű rendszerüzenetek közé tartozik, így a csatornaüzenetek státusztartását nem befolyásolja. Ki tudja, miért, akadnak azonban olyan hangszerek (pl. a Yamaha DX-ek), melyeknél a státusztartás megtörik az Active Sensing nevű valós idejű rendszerüzenet hatására. Ez természetesen teljességgel legális, csak nem annyira takarékos megoldás.
Az igazán takarékosak (pl. Casio VZ-sorozat) viszont a Note Off üzenetet is behúzzák a Note On státusztartása alá, hiszen a Note Off egyik formája a 0 dinamikaértékkel ellátott Note On. Egy billentyű leütése és felengedése itt a következő bájtsorozatot generálja:
9n b1 d1 b1 00
Az első három bájt a billentyű lenyomásakor, az utána következő kettő pedig a billentyű felengedésekor generálódik. Noha a státusztartást adásnál nem kötelező használni, a vételi oldalon implementálása minden esetben kötelező, hiszen a vevő bemenetére bármikor kapcsolhatnak ilyen technikát alkalmazó adót, melynek az üzeneteit meg kell értenie. Természetesen nem okozhat fennakadást az sem, ha az adó státusztartást nem alkalmaz.
A MIDI-hálózatok kialakításánál számos gyakorlati megfontolást kell figyelembe venni, az eszközök fizikai megvalósítása miatt. Az egyik legalapvetőbb probléma a kábelezés kérdése. A MIDI-specifikáció a MIDI-kábelek maximális hosszát 15 méterre javasolja korlátozni. Ennek oka a közönséges kábelek ellenállása miatt fellépő jelveszteség, mely rosszabb esetben ilyen nagyságrendű kábelhosszaknál kezdhet nehézségeket okozni. Jobb minőségű kábelekkel jóval messzebb elvezethető a MIDI-jel, egyébként ismétlőt (Thru Boxot) kell alkalmazni.
Eddig rendben is van, azonban a dolgokat nem kimondottan technikai nézőpontból vizsgáló felhasználók körében a kábelhossz kérdése valamilyen úton-módon összekeveredett a később még sűrűn emlegetendő MIDI-késleltetés témakörével, mondván: a túl hosszú kábeleken a MIDI-üzenetek a szokottnál később érnek rendeltetési helyükre, ami a rendszert használhatatlanná teszi. Erről természetesen szó sincs, hiszen a MIDI-üzenetek elektromos jelek alakjában utaznak, az elektronok haladási sebessége pedig összemérhető a fénysebességgel, vagyis a százezer km/másodperc nagyságrendbe esik, tehát akár a földgolyó túloldalára is elküldhető, zeneileg érzékelhető késlekedés nélkül.
A MIDI-késleltetés egyébként igen gyakran emlegetett fogalom, és egészen eltérő dolgoknál is elő szokott kerülni. Emlegetik a gitár-MIDI átalakítóknál, itt a húr rezgésének MIDI-üzenetekké való átalakítási sebességét értik alatta, előkerül az egyszerű, egy adó-egy vevő kapcsolatnál, mint reakciósebesség, a hosszú MIDI-láncoknál, mint terjedési késleltetés, és sok más esetben, melyeknek egy közös vonásuk van: az elektronikus eszközök véges feldolgozási sebessége miatt a folyamatok valamekkora idő alatt mennek végbe. A MIDI-késleltetés kapcsán gyakran előfordul a valóságos jelenségek téves értelmezése és a felhasználók emiatt gyakran téves következtetéseket vonnak le.
Az egyik legnépszerűbb ilyen tévhit a MIDI-s eszközök láncba fűzésével kapcsolatos. A lánc kialakítását már láttuk, minden, a láncban szereplő hangszer az őt megelőző eszköz THRU csatlakozójáról kapja bemenetére az üzeneteket (kivéve a legelső vevőt, természetesen). A THRU csatlakozók késleltetése az, amit az elterjedt hiedelem kárhoztat, mondván, akkora nagy késleltetést okoz, hogy négy-öt hangszer sorbakapcsolásának már semmi értelme, a láncban hátul lévőkhöz akkora késleltetéssel jutnak az üzenetek. A valóságban viszont a probléma inkább az, hogy a hangszerek túlnyomó többségében a Hard THRU megoldást alkalmazzák; itt a bemenő jel az IN csatlakozóról egy optoizolátor közvetítésével közvetlenül a THRU csatlakozóra kerül. Az egyetlen késleltetési tényező ez az elektronikai alkatrész, melynek kapcsolási ideje 3 mikroszekundum, vagyis a másodperc egymilliomod részével van egy súlycsoportban. Kapcsoljunk össze akár tíz eszközt, még mindig csak a százezredmásodperces nagyságrendbe kerülünk, ami még mindig kb. százszor kisebb az érzékelhető legkisebb időtartamnál, arról nem is beszélve, hogy egy három bájtos MIDI-üzenet közlése egyébként önmagában hozzávetőlegesen egy ezredmásodpercig tart. Ráadásul, egy hang megszólalásának késleltetésébe keményen beleszól az is, hogy milyen gyors a vevő processzora; ezek sebességkülönbségei ezredmásodperces eltéréseket eredményezhetnek. Ha a lánc végén egy gyorsabb egységet helyezünk el, az esetleg hamarabb is reagálhat a láncon végigfutó üzenetekre, mint a lánc elején álló, lassabb hangszer.
A tévhit elterjedésének egyik oka a 'Soft THRU' megoldás használata bizonyos eszközöknél, ami valóban jelentős késleltetést állít a jelterjedés útjába. Ebben az esetben ugyanis a MIDI-bájt először a központi mikroprocesszorba kerül, feldolgozásra, onnan jut a THRU-ra, így, a processzornál töltött időt nem számítva, legalább egy bájtnyi (ami a MIDI-átvitelben 10 bit) időt késik minden egyes üzenet. Ha pedig a processzornál töltött is beszámítjuk, néhány Soft THRU összefűzésével hamar eljuthatunk akár 20 ezredmásodperces késleltetéshez is, ami füllel már észlelhető. Szerencsére a Soft THRU megoldás olyan ritka, hogy szinte lehetetlen rendszerünket olyan hangszerekből összeállítani, melyek közül mondjuk akár kettő-három alkalmazná ezt az eljárást.
A hosszú MIDI-láncok valódi problémája az alkalmazott optoizolátorok kismértékű jeltorzítása. A logikai 1 és 0 értékekhez rendelt feszültségszintek közül a magasabb feszültségérték tartási ideje elkezd csökkenni az alacsonyabbhoz képest, ami sokszor egymás után ismételve jelentékeny lehet. Ekkor a láncban hátul állóknál bittévesztések fognak fellépni, ami hangok kimaradásában, vagy ellenkezőleg, nem várt hangok, zajok jelentkezésében, és más hasonlóan borzasztó eseményekben nyilvánulhat meg. Ha ezt tapasztaljuk, a rendszert azonnal át kell szervezni, hiszen ebben a formában nem sok mindenre lehet használni. Megoldás lehet bizonyos esetekben az eszközök sorrendjének megváltoztatása, hiszen az optoizolátorok sem egyformák; láttunk már olyan, hét elemből álló láncot, amely egy adott sorrendben teljesen használhatatlanul, egy másik sorrendben pedig tökéletesen működött.
A biztos megoldás a csillaghálózat kiépítése, melyhez egy olyan MIDI-elosztót kell beszerezni, melynek egy MIDI-bemenete és több kimenete van, funkciója pedig roppant egyszerű: a bemenetre érkező jelet valamennyi kimenetére elküldi. ezáltal minden eszköz "első kézből" hozzájuthat az üzenetekhez.
Gyakran érik vádak a MIDI 31250 bit/másodperces átviteli sebességét is, mondván, a követelményekhez képest túl lassú. Valóban, a számítógépes lokális hálózatok 10 vagy 100 megabit/másodpercéhez képest nem túl sok, azonban vizsgáljunk meg egy egyszerű szituációt. Figyeljük meg, milyen késleltetések lépnek fel, ha egy hangszeren leütünk egy billentyűt, és az a MIDI-kapcsolat segítségével egy másik hangszert szólaltat meg! A billentyű leütésének ténye eljut a vezérlő hangszer processzorához, a billentyű kódjával és a leütés sebességével együtt. Ez az első késleltetés, a következő pedig akkor lép fel, amikor a processzor eljuttatja a saját, MIDI-t kezelő kimeneti egységének ezeket az adatokat. A MIDI-kábelen átfolyik a három bájtos kód, majd a vevő bemeneti egysége fogadja, eljuttatja a processzorhoz, amely lefoglal az új hang számára egy hanggenerátort, feltölti az adatokkal, és utasítja a hang elindítására. Ez a teljes folyamat a hangszerekben általánosan használt egyszerű 8 bites processzorokkal akár a 10 ezredmásodpercet is elérheti, ebből a MIDI adatátvitele csak egy ezredmásodpercet vett igénybe. A gond tehát inkább a processzorok kis teljesítménye, nem a MIDI lassúsága. Szerencsére manapság már a 16 bites processzorok egyszerűbb sorozatai is az olcsóbb kategóriába kerültek, így találhatunk példát ezek használatára is, a jövőben pedig szélesebb elterjedésük várható.
El is terjedtek azóta; nemcsak 16 bites, hanem annál sokkal erősebb mikroprocesszorok ketyegnek már a mai hangszerekben, így az előző bekezdésben ismertetett késleltetési tényező ma már sokkal inkább elhanyagolható.
A sebességprobléma nem abban a formában vetődik fel, hogy egy üzenet lassan kerül-e át a vevőhöz, hanem úgy, hogy a vonalat bonyolultabb alkalmazások esetén esetleg telítésbe lehet vinni. Egy dalszerkesztőt használva, ha valaki mind a 16 csatornát egyszerre használja a vonalon, és sűrű eseménysorozatokat küld, például minden csatornán egyszerre végez hajlításokat, mozgat folyamatos kontrollereket, akkor előbb-utóbb találkozik a MIDI-torlódással; bizonyos eseményekhez rendelt üzenetek nem férnek fel a megfelelő időben a MIDI-vonalra, csak később, vagy egyáltalán nem. A legtöbbször gyógyírt jelent e problémára a dalszerkesztő Controller Thin funkciója, amely a folyamatos kontrollereket a kívánt mértékben megritkítja, így kikísérletezhető az a sűrűség, amely már nem okoz torlódást, zeneileg pedig még elfogadható. Ha ez nem járható út, akkor független, párhuzamos MIDI-kimeneteket és kábelezést kell használni a rendszerben.
A már említett MIDI Time Code is felveti a torlódás lehetőségét. Az a berendezés, amely ilyen üzeneteket küld, 6%-ban lefoglalja a MIDI-vonalat, mivel ez egy olyan állandó időkód közvetítését jelenti, amelynek üzenetei másodpercenként többször is tartalmazzák a teljes óra-perc-másodperc-képkocka értékeket - ezt elsősorban mozgóképes anyagokhoz való szinkronizálásra használják. A 6%-os foglaltsági érték egyszerűbb alkalmazásoknál még nem kritikus, az időkód azonban nem kimondottan egyszerű alkalmazásokban használatos, így azok a dalszerkesztők, amelyek ezt a szinkronizációs formát is ismerik, nemritkán egy külön MIDI-vonalat lefoglalnak erre a célra, amelyre zenei üzeneteket nem engednek küldeni.
Gyakran félreértés tárgya a Timing Clock üzenet és alkalmazása is. Ez az üzenet volt ugye a dalszerkesztők egymáshoz szinkronizálásának az eszköze, tulajdonképpen egy órajel. A zenei negyedhang 1/24 része telik el két ilyen üzenet közvetítése között, ebben a dimenzióban szokásos a dalszerkesztők időbeli felbontását megadni; a zenei negyedhangot hány részre képesek még feldarabolni. Az angol elnevezés (Pulses Per Quarternote) alapján ppq-nak rövidítik, a MIDI-óra tehát 24 ppq-val pereg. Igenám, de a dalszerkesztők közt nem ritka a 384 ppq felbontású sem, pazarlás lenne ez? A válasz természetesen nem, a megoldás pedig az, hogy ha egy dalszerkesztő lejátszási sebességét a Timing Clock-hoz igazítják, akkor valójában ugyanúgy a saját belső, nagy felbontású órajeléról működtetik, mint egyébként, ennek időalapját azonban mindig a Timing Clock beérkezési idejéhez igazítják. Lehet, hogy így szabálytalanná válhat az óra a negyedhang 1/24 részéig - a tempóban beállt változást a vevő ennyi idő elteltével tudja észlelni - ez azonban füllel még érzékelhetetlen a hallgató számára.
Utolsó kommentek