vcera som podstatnu cast dna zabil tym ze som hladal chybu preco mi pri prijimani midi dat vypadavaju rychlo posebe poslane udalosti, myslel som ze sa mi stracaju alebo ze ich dostatocne rychlo nenacitavam zo serial zbernice, po dlhsom debugovani som uvidel ze mi namiesto tych stratenych eventov prichadzaju nejake "nerozpoznane" alebo "invalid" data a keby som sa v tom vrtal este dlhsie tak by som zistil ze problem nie je u mna, ale v tom zariadeni co tie data posielalo, pretoze mne sa nestracalo nic, ale uz to zariadenie tie nekompletne data tak posielalo.

Nakoniec som sa po dlhom gugleni (ani som nevedel co mam guglit) dozvedel ze vsetko je v poriadku, to len ja som neosetril sucast midi protokolu - tzv "running status". Totiz midi specifikacia umoznuje, aby zariadenie ked rychlo posebe posiela data s rovnakym statusom (napriklad povedzme ze 3x posebe posle note-on na rovnakom kanali a nic ine medzi tym) tak pri tych dalsich dvoch smie vynechat status byte, cize ako napriklad v tomto priklade, namiesto posle iba (cize v tych druhych dvoch eventoch vynechal 0x90)

jedno z moznych rieseni je take ze ak v momente ked ocakavas status byte (cize vacsi ako 127) pride namiesto neho datovy byte (cize mensi ako 128), tak ho spracujes s takym statusom ako mal status predchadzajuci event (cize vzdy ked spracovavas event tak si musis pre buducnost zapametat aky to bol status)

inak specifikacia este hovori ze "realtime" statusy (jednobajtove eventy vacsie ako 247) toto vraj nemaju ovplyvnovat, cize pomedzi tie "nekompletne" "bezstatusove" eventy kludne mozu ist aj realtime statusy.

super .. toto dava zmysel .. vdaka za info .. i ked toto je info pre programatora .. muzikant sa s tym nestretne ..

charonme, este si zabudol, ze preto sa pouziva NoteOn Velocity=0 namiesto korektneho NoteOff.
uz by fakt mohli ten MIDI standard prerobit na koax a trochu zmodifikovat. Vela by to nechcelo.
Vyhli by sme sa takymto zbytocnym technickym veciam, ktore su v dnesnej dobre uz uplne smiesne...

A ty co robis?, ze sa v tom tak musis vrtat

A co si vy, Kefalin, predstavujete pod tym "prerobit MIDI standard na koax" ?

ina ano samozrejme toto je optimalizacia koli rychlosti, midi rozhrania nie su extra rychle, pracuju s relativne malymi prenosovymi rychlostami, takze vyhodenim zbytocneho posielania 1 udaja sa da daco usetrit.. ma to svoju logiku..

koax - to je suosi kabel, pane majore... (cize stieneny)

To bol priklad. Hoci trebars aj na TP kabel. Proste na nejaky vyrazne rychlejsi a spolahlivy nosic.
A v standarde zadefinovat rychlesie optocleny alebo ich inu nahradu.
31,5 kBaud je na dnesnu dobu STRASNY pravek. Ved tolko sa posielalo modemom po hnusnych CSSR telefonnych linkach asi v roku 1985.
Pritom uz takch 128 alebo 256 by mohlo celkom slusne stacit.

no sak cez USB mas vacsinou minimalne 8 kanalov .. to uz je lepsie potom ..

USB vacsinou potrebuje nejaky host a neda sa zretazit. To je pri 2 alebo 3 masinach uplne zbytocna otrava s dalsim hardware. A o problemoch s uzemnenim a hucanim ani netusim...

no tak potom tu mame MADI .. to riesi uplne vsetko .. i ked tam som si neni isty , kolko je midi portov .. mozno len jeden ..

MDudas píše:preto sa pouziva NoteOn Velocity=0

vyborny postreh, toto som si ani neuvedomil, ale tato aplikacia je od toho nezavisla

inak tento running status ma dopad aj na sposob akym treba mergovat dva a viac midi vstupov do jedneho, pretoze ked na jednom idu zaradom rovnake eventy s running statusom a do toho medzi ne pride daco ine z druheho tak na mergi treba tym nasledujucim znova nastavit ten status

MDudas píše:A ty co robis?, ze sa v tom tak musis vrtat

nemusim, ja sa s tym len tak hram ako hobby, napriklad toto alebo toto alebo sa este chystam pomocou toho isteho principu na midi procesor ktory by napr. vedel arpegiovat alebo sekvencovat alebo hocico ine

inak ale az zas takym strasnym vrtanim by som to nenazyval vsak to su uplne zaklady midi, bez toho s midickom nespravis vobec nic (no... mozno okrem sysexov a casovania, tie sa mozno daju aj bez vedomosti o running statuse )