Miért éppen 31250?

Címkék: midi

2014.03.05. 15:12

Az előző bejegyzésben az elpusztíthatatlan MIDI volt a téma. A cikkben megemlítettem, hogy a rendszer adatátviteli sebessége már a kezdetekben sem számított gyorsnak. djuice egy hozzászólásban rákérdezett, hogy miért is tartom lassúnak, mert ő nem érzékelte ezt soha. A kérdés megválaszolása túlmutat egy kommenten, meg másokat is érdekelhet, ezért inkább leírom röviden.

Motorola_MC6850.jpgElőször is a címben feltett kérdést válaszolom meg. A 31250-es baud rate roppant prózai okra vezethető vissza. Ez a szám úgy jön ki, hogy 1000000 / 32 =31250. A digitális technikában valamelyest jártas emberek számára ez azt jelenti, hogy a szokásos 1 MHz-es (2, 4, 8 MHz-es) kvarcokból könnyedén le lehet osztani a rendszer működtetéséhez szükséges alap órajel frekvenciát. Vagy megfordítva,  azt is mondhatjuk, hogy egyszerűen lehetett gyártani vagy találni olyan chipet (Motorola 6850 UART), ami a MIDI kiszolgálásához nem igényelt egzotikus kvarcot, hanem a bármely fiókban fellelhető 2 vagy 4 MHz-es kvarccal működött. Ne feledjük el, hogy a rendszer kitalálásakor 1981-et írtunk, akkoriban a chip és kvarcözönt ma a világra ontó kínai állampolgárok jelentős része még nem is élt, az elektronikai alkatrészek nagyságrendekkel drágábbak voltak. Igyekeztek tehát a gyártók nem egyedi megfejtéseket kitalálni, hanem a szokásos, akkor standardnak számító digitális elektronikai alkatrészekre alapozni. Egy ilyen fapados megoldás látható a korábbi, házilag barkácsolt C64 interfészt bemutató bejegyzésben is. 
A soros kommunikáció sebességét ettől persze még elvben tetszőlegesre választhatták volna, a fenti gondolatmenet szerint lehetett volna 62500 vagy akár 125000 baud is. A MIDI megalkotói elég óvatosan döntöttek. A lassú átvitel természetesen nagyobb üzembiztonságot ad, kevésbé lesz érzékeny a rendszer a külső zavarokra és a kábelhosszra, a midi kábel minőségére, meg hasonló gyakorlati szempontok merülhettek még fel.

Nézzük meg, hogy a gyakorlatban mire elég ez a baud rate! A 31250-es sebesség a soros protokoll szerint durván 3 kbyte átvitelére elég másodpercenként. Tudva azt, hogy egy MIDI parancs átlagosan 3 byte, ez ugye azt jelenti, hogy nagyjából 1000 parancsot tudunk átvinni egy másodperc alatt. Ez nagyon durva közelítés, mert nem számol a Running Status üzemmóddal, és még sok minden bekavarhat. Amíg arról van szó, hogy egy billentyűzeten játszva egy másik hangszer átküldve a jelet szólaltatjuk meg az utóbbit, addig nincs is baj. Nagyon virtuóz játék esetében se lesz kihallható az a késés, amit esetleg 2-3 ms sorbaállás jelent. A gyakorlatban ha leütünk mondjuk 4 hangot egyszerre a zongorán, akkor a billentyűzet érzékelő elektronikája sem fogja tökéletesen egyszerre érzékelni őket, a MIDI pedig, mint soros jelfolyam eleve idő szerint besorolva képes csak továbbítani az információt. A négy "egyszerre" leütött hang tehát 3-4 ms alatt fog átérni a fogadó rendszerre. A gyakorlatban ez még nem jelent problémát. Az igazi gondok akkor kezdődnek, amikor szekvencerrel dolgozunk, és 10, 12 vagy akár 16 csatornán párhuzamosan toljuk az információt. Note On, Note Off, Controller, stb bőségesen áramlik az OUT porton kifelé, és ilyenkor már füllel hallható akadozások fordulhatnak elő, szerencsétlen esetben pedig olyan adatkavarodások, amik miatt például megbolondul a fogadó készülék. Akik korábban professzionális SMF dal gyártásból éltek, jól tudják, mennyire kell ügyelni a hangszerelésnél arra, hogy elkerüljük az egyidejűséget. A szekvencer programokban az esemény szintű szerkesztés során lehet finoman széthúzkodni az esetleg zavaróan egy helyre került MIDI eseményeket. Ügyelni kell persze arra, hogy ne képződjön ebből ritmikai probléma, meg persze funkcionálisan se kavarodjanak meg a MIDI események, tehát például a szám elején a Bank Select és Program Change üzenetek jó helyen legyenek. 15 évvel ezelőtt ezek még lényeges problémák voltak. Ma a hangszerelések többsége egy számítógépes DAW szerkesztő programban, szoftver szintetizátorokkal zajlik, és bár a gépen belül is látszólag MIDI kommunikációt használunk, ott természetesen nincs kirakva a 31250-es lassító tábla, hanem inkább az audio latency jelenti a küzdés tárgyát.
Szintihegyek_k.jpgA másik ügy, ami miatt már a kezdetektől lassúnak tartottuk a MIDI sebességét, a SysEx átvitel. A dumpok átjátszása rettentő lassú, hiszen a fentiek alapján kiszámolható, hogy egy kisebb fájl átvitele is elég sokáig tart, némelyik operációs rendszer frissítés pedig akár egy órát is igénybe vett. Voltak hangszerek, amelyek sampling mintákat is képesek voltak MIDI-n adni vagy venni. Természetesen csak nyúlfarknyi mintákról lehetett szó, és akkor is csak stúdió környezetben Élő fellépés során inkább floppyzott a nép, bár az is dögletesen lassú volt. A SMF vagy egyéb midis dalokba beépített menet közbeni SysEx üzenetekkel is sok baj volt, mert ugye a SysEx prioritást élvez a többi MIDI üzenettel szemben.
A lassú MIDI elleni morgolódások tulajdonképpen azért csitultak, mert a korábbiakhoz képest egyre kevesebben használnak már nagy, sok készülékre kiterjedő MIDI rendszereket, mint például a képen is látható. A stúdiókban ugyan mintha reneszánszát élné a vasak bevetése, de ehhez az "újrahasznosításhoz" például nem gyárt már senki olyan fajta MIDI routereket, melyek számítógép nélkül is életképesek lennének. Színpadon is csak néhány nagyobb koncertező zenekar esetében találunk igazán komoly midis cucc felhalmozást, tejednek a workstation hangszerek. Ezért lehet az, hogy az utóbbi időben halkult a lassú midit ostorozó vélemények, és lehet, hogy ebben az állapotában még elég sokáig elvegetál a zenei kapcsolatok öreg rendszere.

A bejegyzés trackback címe:

https://bitzenede.blog.hu/api/trackback/id/tr875844424

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

djuice 2014.03.15. 10:40:24

Nagyon köszi a nép nevében! :)
Hát igen, anno még egy szem hangszerrel nehezen lehetett volna ezt itthon tapasztalni. Kettőnél több meg sosem volt egyszerre. :) Meg kell hagyni azért a Hans Zimmer féle midi setupokhoz már titkárnő is kell, mert pl szekvenszer nélkül adott szintiről még egy rack hangmodul megfelelő bank/preset dolgait sem lehet mindig irányítani.

Azért a multi track felhasználást nézve, az már elég korán megjelent az automata kíséretes hangszerekben is és mondjuk 91-ben egy PSR37 esetében sem voltak olyan említett hallható akadások, mint később egy jóval több szólammal dolgozó E86 vagy i3 esetében sem. Vagy ott a belső midi processz nem teljesen összevethető a midi outon kifelé történő kommunikációval?

Még valami: az írt 3000 kB/s adatátvitel durván 3 MB/s lefordítva. Ez a net kommunikációban sem túl lassú még és az 56k-s modemekhez képest anno, amik jóval a midi után születtek... szóval nekem számszaki megvilágításban sem egy vészes lassúságot mutat!
Azért ha a

MidiTom · http://bitzenede.blog.hu 2014.03.15. 13:30:11

@djuice:
észrevettél egy hibát, amin én is, meg a cikket eddig elolvasó emberek is lazán átsiklottak. Eredetileg 3000 kbyteot írtam, ami természetesen marhaság, a 31250 baudból jó esetben 3 kbyte adatátvitel lesz. Ezt gyorsan ki is javítottam, köszi!
A hangszereken belül a hangkeltést régebben is csak ritkán oldották meg MIDI sebességű soros átvitellel. Vagy egy sima 8 bites adatbuszon ment a belső kommunikáció, vagy egy nagy sebességű soros buszon. Mostanában már egyértelműen ez a jellemző. Azoknál a kísérőautomata hangszereknél, amelyek képesek kiadni egy jó gazdag arrangment sávjait, korábban is voltak már MIDI eseménytorlódásra utaló problémák. Mondok egy egyszerű példát. Sokan próbáltak lelopni (fogalmazzunk finomabban: lehámozni) egy-egy igen jól sikerült stílust valamelyik automata hangszerről úgy, hogy szekvencerrel rögzítették a lejátszott Dúr, moll, stb. harmóniákat, variációkat, aztán ezt átfejtették saját hangszerükre. Ilyenkor szoktak belecsúszni abba, hogy ha ezt ezt egy menetben tették meg (multitrack recording), akkor meglehetősen széteső ritmikát kaptak bonyolultabb hangszerelések esetében. Amit aztán vagy lehetett kézzel-lábbal utókvantálni, vagy nem. Az emberek sokszor azt hitték, hogy a számítógépükkel vagy a hardver szekvencerrel van a baj, de többnyire nem az volt a probléma forrása. Azt szoktam javasolni, hogy több meneteben végezzék el a rögzítést, egyszerre csak 4-6 sávot, és akkor általában szépen összejött a mutatvány, bár ugye többet kellett vele vacakolni. A gyártók arra sok gondot fordítottak, hogy magában a hangszerben pontos és precíz legyen a ritmika, hiszen egy profi felhasználó számára ez létfontosságú. Az azonban nem nagyon érdekelte őket, hogy egy cikornyásabb, sok MIDI eseményt (pl. kontrollereket is) tartalmazó arrangement szépen sorban kiférjen a MIDI OUT-on is. Nem feltételezek ebben szándékosságot, de az is lehet, hogy örültek neki, ha a stílusfejtés emiatt nem lett túl egyszerű :)

djuice 2014.03.19. 00:44:08

Zseniális! :)
A bugnál tartva én olyanról tudok hogy E86 esetében egy adott stílussal játszva, sustein pedált használva nyomtak variációs fillt egyidejűleg, akkor minden leállt és elindult a gyári demó! :D
Akkor jól gondoltam, csak sok lett vna az a 3000 kB/s. Tévedni emberi dolog...
süti beállítások módosítása