1.1 Nos, a jelenlegi set up-omban van két szinti amit multitimbrálisként használok (FA-06, MC-808) és van 3 amit monotimbrálisként (Blofeld, D-05, RADIAS [na jó ezt van hogy 2-3 timbrálisként]). A "főkarmester" az MC-808; a remek kis pattern szekvenszerét felhasználva vezérelném vele a többi szintit mint "hangmodult".
A klasszikus MIDI THRU Box technika azért nem volt megfelelő számomra, mert az FA-06-on ki kellett mute-olnom azokat a csatornákat amiken a monotimbrálisként használt vasak ülnek. Ez így azonban minimum 3, esetenként 4-5 csatorna kiesését is jelentette az FA-06-on. Persze ezeket a track-eket felhasználhattam volna layer-ekhez (volt amikor ez is előfordult) azonban az élő előadáshoz ennyivel kevesebb timbre-ével, hangszínnel rendelkeztem volna...
Most azonban az MC-808-ról hiába megy ki a szekvencia a monotombrális Blofeld, D-05, stb. vasak felé - az FA-06-hoz már nem jutnak el ezek az üzenetek így az FA-06 megmaradhatott 16 multitimbrális eszköznek!
1.2 "Ok, de miért nem vettél egyet?"
Az a helyzet hogy próbáltam.... kerestem olyat ami képes számítógép közbeiktatása nélkül is működni (ja, nem említettem hogy DAWLESS workflow-ról beszélünk!) és/vagy megfelelően konfigurálható az igényeim szerint de kevés ilyen van; azok is jó öreg vasak már és ráadásul nem is lehet mindig "kapni"... Amit meg lehet időnként azzal meg kompatibilitási gondok vannak (Win10x64 story...)
Ugyanakkor szerencsére rendelkezem azokkal a műszaki készségekkel és ismeretekkel amelyek egy ilyen eszköz megépítéséhez szükségesek, szeretek is barkácsolni, szóval nosza! A végső elszámolás során kiderült, hogy 9.000,- Ft alatt maradt a "beruházás"... Ennyiért azért nem sok MIDI Router-t talál az ember sem az e-bay-en sem más apró oldalakon...
2. Start... A kiindulási alap Davide Bucci MIDI Splittere volt. Nagyon egyszerűen, kevés és olcsó alkatrészből megépíthető 1 IN/2 OUT eszköz amiben a 16 csatorna egyenként felprogramozható bármely 4 állapotra (sehova, A-ra, B-re, A+B-re menjen ki). Ugyanitt Davide felvázolt egy lehetséges továbbfejlesztést is ami 6 kimenetet kezel - lévén ennyi szabad port van az áramkörben található PIC16F876-os micrchip-en... No én ez utóbbinak estem neki azzal a kiegészítéssel, hogy a régebben megépített MIDI Patchbay-emben használt Thorsten Close féle merger-t is "hozzágondoltam"...
3. Az építés...
Magának a router-nek a megépítése nem okozott gondot. Ráadásul annyira egyszerű az egész, hogy én speciel még nyomtatott áramköri lapot sem készítettem hozzá - próbapanelen "drótoztam" be mindent. Nem szép, nem elegáns de gondoltam prototípusnak elmegy...
A PIC chip-ek felprogramozására egy K150-es "óccó" kínai cuccot használtam. A "firmware"-ek assembly nyelvű szerkesztgetéséhez, fordításához pedig az MPLAB software-eket (free).
Miután alaposan kibővült a firmware kódja a későbbiekben az eredeti 4MHz-es órajel kristályt kicseréltem 8MHz-esre. Ez az általam választott PIC chip esetén már kétszeres "overclock" több ezzel foglalkozó fórumban is megerősítették, hogy 10-ből 9 chip simán elketyeg 8MHz-en is... Próba -> szerencse!
4. Tesztelés
Voltak problémáim az elejétől kezdve. Elsőként a display nem akart úgy működni ahogyan kellett volna aminek az volt az oka, hogy az általam beszerzett RC1602B-GHY-CSXD kijelző nem teljesen kompatibilis a HD44780 kijelzőkkel - a felső 4 bitet nem volt szabad földre kötni, csak az LCD5-öt ráadásul a kibővített megszakítási rutin "belelógott" a "képernyő memória" területére. De ezeken hamar túl lendültem...
Másodikként azzal adódott problémám, hogy hogyan vezessem be a merger TTL szintű kimenetét a router USART bemenétére úgy, hogy az ne okozzon bit tévesztéseket. Ám ezt is hamar megoldottam
A harmadik problémával már jó sokáig kínlódtam mire rájöttem, hogy nem is elektronikai - illetve nem elsősorban az.
5. A firmware
Az eredeti router (splitter) firmware rém egyszerűen működött. Ebből adódott aztán a hibája is...
Davide abból indult ki (sajnos tévesen), hogy minden MIDI üzenet egy status bájttal kezdődik. A státusz bájtoknak a legfelső bitje mindig 1. Davide firmware-je ezt vizsgálta; s ha a legfelső bit 1 volt, kimaszkolta az alsó 4 bitet ami megadta a MIDI csatorna számát. Ezt az adatot felhazsnálva kiolvasta a PIC chip EPROM-jából, hogy a felhasználó az adott csatornát mely kimenetekre tervezte küldeni, beállította ennek megfelelően a PIC chip kimeneteinek státuszát majd kiküldte rajta/rajtuk soros kommunikációval az adott bájtot. Az ezt követő bájtokat az előző állapotnak megfelelően küldte ki feltételezve, hogy amíg a legfelső bit nem 1, addig az utolsó státusz bájthoz tartozó adat bájtokról van szó... Csakhogy van egy kis bukta a dologban, amit a MIDI Running Status "műintézmény" okoz... Szó szerint kinőtt a szakállam mire rájöttem, hogy EZ AZ ÉN PROBLÉMÁM is!
Át kellett írnom a firmware-t. Bevezettem 3 új állapotot... 1. System Exclusive Status
0xF0-át bevételezve a router e status-ba helyezi magát és minden egyes bájtot ami e System Exclusive Start és egy System Exclusive End (0xF7) üzenet között van "broadcast-ol" - kiküldi minden kimenetre (beleértve a kezdő és befejező státusz bájtokat is). Azért volt szükség ennek az állapotnak a bevezetésére, mert egy system exclusive üzenetben adatnak számít minden ami a kezdő és lezáró státusz bájt között van függetlenül attól, hogy egyébként mit jelentene - így a 0x80 is adattá avanzsál, holott a legfelső bitje 1, tehát alapból Note on üzenetnek számítana...
2. Long message
Vannak olyan System Common üzenetek amelyek nem 1 hanem 2 vagy 3 bájtból állnak...
Pl.: MIDI Timing Code (+1 adat), a Song Position Pointer (+2 adat) és a Song Select (+1 adat) üzenetek. Mivel a System üzeneteket broadcast-olja a router, hogy azokat minden eszköz megkaphassa értelemszerűen az említett 3 System Common üzenet adatbájtjait is broadcast-olnia kell! Ehhez volt szükség a Long message statusz bevezetésére...
3. MIDI Running status
Leprogramozni 100x egyszerűbb és gyorsabb mint elmesélni a running status lényegét! Csak be kellett vezetni egy plusz tárolót amiben az utolsó Channel message ült, illetve törlődött egy-egy System Common vagy sysex üzenet után... Ha pedig a router egy olyan adatbájttal találkozott amit nem előzött meg státusz bájt, akkor e puffer által beállított kimenetekre küldi azokat. Ha pedig státusz bájt nélküli adattal találkozik ÉS nincs running státuszban (sem pedig system exclusive statátuszban), egyszerűen eldobja, ignorálja az adott bájtot...
Fenti finomítások bevezetése után a kis DIY MIDI Router-em kifogástalanul működik!
Majdnem minden eszközzel... ugyanis van egy ALESIS iO2Express hangkártyám amivel nem akar megbarátkozni. Az oka prózai: a router-emben 6N138-as optocsatolókat használok a MIDI bemenetek illesztéséhez - ezek azonban csak 5V-os MIDI rendszerek esetén elegendőek - 3.3V-os MIDI rendszerek már nem tudják hibátlanul, maradéktalanul megvillantani az optocsatolóban lévő LED-et, így más adat jön ki a csatolóból mint ami bemegy... Ki kellene cserélnem a két 6N138-as optocsatolót PC900-asokra. De ezt inkább majd később teszem meg...
Tanulságok:
1. Mivel egyre több és több a 3,3V-os MIDI rendszerű eszköz ideje minden új MIDI eszköz fejlesztés/építés során elfelejteni a jó öreg (6N137/)6N138-as optocsatolókat!
2. Ha Davide eredeti 2 kimenetes verzióját építed is meg, akkor is használd az én firmware verziómat - sok kellemetlen, furcsa, értelmezhetetlen hibajelenségtől kíméled meg magad.
3. Ha MIDI eszközt programozol sosem elégedj meg az alapfunkciók kezelésével - mint az kiderült a kivételek nem csak a szabályt erősítik...
4. Olcsó húsnak nem mindig híg a leve!
5. Jól tettem, hogy belevágtam... amilyen idegesítő volt olykor, pont olyan szórakoztató is az egész! És van egy olyan MIDI Router-em ami - eddig - még senki másnak!
6. Tudom most még csúnya - de idővel szépen beépítem egy rendes 1U méretű rack dobozba
Lehetséges fejlesztések, tervek...
Sajnos a 2 soros kijelző/2 nyomógombos kezelőfelület eléggé behatárolja az editálási lehetőségeket, mégis érdemes elgondolkodni 1-2 dolgon ami - reményeim szerint - még belefér(het) a PIC16F876 műveleti idejébe:
- MIDIChannel re-mapping (X csatornáról érkező adatok átirányítása Y csatornára). A megvalósítás abszolút hasonló lehetne a jelenlegi csatorna-> kimenet hozzárendeléshez...
- MIDI filter... Egyes üzenetek "kiszűrése"
a) csatorna alapon (adott csatornán érkező egyes üzenetek szűrése -> 2 lépcsős kiválasztás: csatorna és üzenet);
b) kimenet alapon (adott üzenetek szűrése adott kimeneteken; ez is hasonlóan nézne ki mint most a csatorna hozzárendelés)
c) átgondolandó, hogy mely üzenetekről legyen szó - ugyanis a szerkesztés kényelmetlen lehet nagy számú lehetőség esetén... Ráadásul sokkal nagyobb korlát magának a PIC chip-nek a memória kapacitása...
Kérdés
LiPI
Sziasztok!
Építettem egy MIDI Router-t...
1. Miért?
1.1 Nos, a jelenlegi set up-omban van két szinti amit multitimbrálisként használok (FA-06, MC-808) és van 3 amit monotimbrálisként (Blofeld, D-05, RADIAS [na jó ezt van hogy 2-3 timbrálisként]). A "főkarmester" az MC-808; a remek kis pattern szekvenszerét felhasználva vezérelném vele a többi szintit mint "hangmodult".
A klasszikus MIDI THRU Box technika azért nem volt megfelelő számomra, mert az FA-06-on ki kellett mute-olnom azokat a csatornákat amiken a monotimbrálisként használt vasak ülnek. Ez így azonban minimum 3, esetenként 4-5 csatorna kiesését is jelentette az FA-06-on. Persze ezeket a track-eket felhasználhattam volna layer-ekhez (volt amikor ez is előfordult) azonban az élő előadáshoz ennyivel kevesebb timbre-ével, hangszínnel rendelkeztem volna...
Most azonban az MC-808-ról hiába megy ki a szekvencia a monotombrális Blofeld, D-05, stb. vasak felé - az FA-06-hoz már nem jutnak el ezek az üzenetek így az FA-06 megmaradhatott 16 multitimbrális eszköznek!
1.2 "Ok, de miért nem vettél egyet?"
Az a helyzet hogy próbáltam.... kerestem olyat ami képes számítógép közbeiktatása nélkül is működni (ja, nem említettem hogy DAWLESS workflow-ról beszélünk!) és/vagy megfelelően konfigurálható az igényeim szerint de kevés ilyen van; azok is jó öreg vasak már és ráadásul nem is lehet mindig "kapni"... Amit meg lehet időnként azzal meg kompatibilitási gondok vannak (Win10x64 story...)
Ugyanakkor szerencsére rendelkezem azokkal a műszaki készségekkel és ismeretekkel amelyek egy ilyen eszköz megépítéséhez szükségesek, szeretek is barkácsolni, szóval nosza! A végső elszámolás során kiderült, hogy 9.000,- Ft alatt maradt a "beruházás"... Ennyiért azért nem sok MIDI Router-t talál az ember sem az e-bay-en sem más apró oldalakon...
2. Start...
A kiindulási alap Davide Bucci MIDI Splittere volt. Nagyon egyszerűen, kevés és olcsó alkatrészből megépíthető 1 IN/2 OUT eszköz amiben a 16 csatorna egyenként felprogramozható bármely 4 állapotra (sehova, A-ra, B-re, A+B-re menjen ki). Ugyanitt Davide felvázolt egy lehetséges továbbfejlesztést is ami 6 kimenetet kezel - lévén ennyi szabad port van az áramkörben található PIC16F876-os micrchip-en... No én ez utóbbinak estem neki azzal a kiegészítéssel, hogy a régebben megépített MIDI Patchbay-emben használt Thorsten Close féle merger-t is "hozzágondoltam"...
3. Az építés...
Magának a router-nek a megépítése nem okozott gondot. Ráadásul annyira egyszerű az egész, hogy én speciel még nyomtatott áramköri lapot sem készítettem hozzá - próbapanelen "drótoztam" be mindent. Nem szép, nem elegáns de gondoltam prototípusnak elmegy...
A PIC chip-ek felprogramozására egy K150-es "óccó" kínai cuccot használtam. A "firmware"-ek assembly nyelvű szerkesztgetéséhez, fordításához pedig az MPLAB software-eket (free).
Miután alaposan kibővült a firmware kódja a későbbiekben az eredeti 4MHz-es órajel kristályt kicseréltem 8MHz-esre. Ez az általam választott PIC chip esetén már kétszeres "overclock" több ezzel foglalkozó fórumban is megerősítették, hogy 10-ből 9 chip simán elketyeg 8MHz-en is... Próba -> szerencse!
4. Tesztelés
Voltak problémáim az elejétől kezdve.
Elsőként a display nem akart úgy működni ahogyan kellett volna aminek az volt az oka, hogy az általam beszerzett RC1602B-GHY-CSXD kijelző nem teljesen kompatibilis a HD44780 kijelzőkkel - a felső 4 bitet nem volt szabad földre kötni, csak az LCD5-öt ráadásul a kibővített megszakítási rutin "belelógott" a "képernyő memória" területére. De ezeken hamar túl lendültem...
Másodikként azzal adódott problémám, hogy hogyan vezessem be a merger TTL szintű kimenetét a router USART bemenétére úgy, hogy az ne okozzon bit tévesztéseket. Ám ezt is hamar megoldottam
A harmadik problémával már jó sokáig kínlódtam mire rájöttem, hogy nem is elektronikai - illetve nem elsősorban az.
5. A firmware
Az eredeti router (splitter) firmware rém egyszerűen működött. Ebből adódott aztán a hibája is...
Davide abból indult ki (sajnos tévesen), hogy minden MIDI üzenet egy status bájttal kezdődik. A státusz bájtoknak a legfelső bitje mindig 1. Davide firmware-je ezt vizsgálta; s ha a legfelső bit 1 volt, kimaszkolta az alsó 4 bitet ami megadta a MIDI csatorna számát. Ezt az adatot felhazsnálva kiolvasta a PIC chip EPROM-jából, hogy a felhasználó az adott csatornát mely kimenetekre tervezte küldeni, beállította ennek megfelelően a PIC chip kimeneteinek státuszát majd kiküldte rajta/rajtuk soros kommunikációval az adott bájtot. Az ezt követő bájtokat az előző állapotnak megfelelően küldte ki feltételezve, hogy amíg a legfelső bit nem 1, addig az utolsó státusz bájthoz tartozó adat bájtokról van szó... Csakhogy van egy kis bukta a dologban, amit a MIDI Running Status "műintézmény" okoz... Szó szerint kinőtt a szakállam mire rájöttem, hogy EZ AZ ÉN PROBLÉMÁM is!
Át kellett írnom a firmware-t. Bevezettem 3 új állapotot...
1. System Exclusive Status
0xF0-át bevételezve a router e status-ba helyezi magát és minden egyes bájtot ami e System Exclusive Start és egy System Exclusive End (0xF7) üzenet között van "broadcast-ol" - kiküldi minden kimenetre (beleértve a kezdő és befejező státusz bájtokat is). Azért volt szükség ennek az állapotnak a bevezetésére, mert egy system exclusive üzenetben adatnak számít minden ami a kezdő és lezáró státusz bájt között van függetlenül attól, hogy egyébként mit jelentene - így a 0x80 is adattá avanzsál, holott a legfelső bitje 1, tehát alapból Note on üzenetnek számítana...
2. Long message
Vannak olyan System Common üzenetek amelyek nem 1 hanem 2 vagy 3 bájtból állnak...
Pl.: MIDI Timing Code (+1 adat), a Song Position Pointer (+2 adat) és a Song Select (+1 adat) üzenetek. Mivel a System üzeneteket broadcast-olja a router, hogy azokat minden eszköz megkaphassa értelemszerűen az említett 3 System Common üzenet adatbájtjait is broadcast-olnia kell! Ehhez volt szükség a Long message statusz bevezetésére...
3. MIDI Running status
Csak be kellett vezetni egy plusz tárolót amiben az utolsó Channel message ült, illetve törlődött egy-egy System Common vagy sysex üzenet után... Ha pedig a router egy olyan adatbájttal találkozott amit nem előzött meg státusz bájt, akkor e puffer által beállított kimenetekre küldi azokat. Ha pedig státusz bájt nélküli adattal találkozik ÉS nincs running státuszban (sem pedig system exclusive statátuszban), egyszerűen eldobja, ignorálja az adott bájtot...
Leprogramozni 100x egyszerűbb és gyorsabb mint elmesélni a running status lényegét!
Fenti finomítások bevezetése után a kis DIY MIDI Router-em kifogástalanul működik!
Majdnem minden eszközzel... ugyanis van egy ALESIS iO2Express hangkártyám amivel nem akar megbarátkozni. Az oka prózai: a router-emben 6N138-as optocsatolókat használok a MIDI bemenetek illesztéséhez - ezek azonban csak 5V-os MIDI rendszerek esetén elegendőek - 3.3V-os MIDI rendszerek már nem tudják hibátlanul, maradéktalanul megvillantani az optocsatolóban lévő LED-et, így más adat jön ki a csatolóból mint ami bemegy... Ki kellene cserélnem a két 6N138-as optocsatolót PC900-asokra. De ezt inkább majd később teszem meg...
Tanulságok:
1. Mivel egyre több és több a 3,3V-os MIDI rendszerű eszköz ideje minden új MIDI eszköz fejlesztés/építés során elfelejteni a jó öreg (6N137/)6N138-as optocsatolókat!
2. Ha Davide eredeti 2 kimenetes verzióját építed is meg, akkor is használd az én firmware verziómat - sok kellemetlen, furcsa, értelmezhetetlen hibajelenségtől kíméled meg magad.
3. Ha MIDI eszközt programozol sosem elégedj meg az alapfunkciók kezelésével - mint az kiderült a kivételek nem csak a szabályt erősítik...
4. Olcsó húsnak nem mindig híg a leve!
5. Jól tettem, hogy belevágtam... amilyen idegesítő volt olykor, pont olyan szórakoztató is az egész! És van egy olyan MIDI Router-em ami - eddig - még senki másnak!
6. Tudom most még csúnya - de idővel szépen beépítem egy rendes 1U méretű rack dobozba
Lehetséges fejlesztések, tervek...
Sajnos a 2 soros kijelző/2 nyomógombos kezelőfelület eléggé behatárolja az editálási lehetőségeket, mégis érdemes elgondolkodni 1-2 dolgon ami - reményeim szerint - még belefér(het) a PIC16F876 műveleti idejébe:
- MIDIChannel re-mapping (X csatornáról érkező adatok átirányítása Y csatornára). A megvalósítás abszolút hasonló lehetne a jelenlegi csatorna-> kimenet hozzárendeléshez...
- MIDI filter... Egyes üzenetek "kiszűrése"
a) csatorna alapon (adott csatornán érkező egyes üzenetek szűrése -> 2 lépcsős kiválasztás: csatorna és üzenet);
b) kimenet alapon (adott üzenetek szűrése adott kimeneteken; ez is hasonlóan nézne ki mint most a csatorna hozzárendelés)
c) átgondolandó, hogy mely üzenetekről legyen szó - ugyanis a szerkesztés kényelmetlen lehet nagy számú lehetőség esetén... Ráadásul sokkal nagyobb korlát magának a PIC chip-nek a memória kapacitása...
Szerkesztette LiPILink to comment
Share on other sites
válasz erre a kérdésre
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.