LiPI

Én annó pont így csináltam TR + CME UF6 + AX3G-vel

Egyébként az előd sorozatok hangbankjainak importálásával van tapasztalatod? Gondolok itt a 3rd party hangbankokra a motif xs/xf-ekhez...

Egyetértek

Ahhoz képest (fals felmérés alapján "piacgyenge" termék) elég gyorsan reagáltak... De komolyan, irónia nélkül... No meg ezek szerint hagytak bőven tartalékot a DSP-ék kihasználása terén ha megtehették, hogy "na akkor még ezt, meg na még azt gyömöszöljük bele teljesítmény romlás nélkül"

Ja értem! Ok! Nem új VA szintézis, csak a meglévő kiegészítése további lehetőségekkel... Gondolom az új Extended LFO értendő alatta, meg az új "Mini" fx-ek... Viszont a pattern szeki "eljövetele" az ami "eladhatóvá teszi" részemre a hangszert Ennek hiánya miatt döntöttem pár hónapja a moxf mellett...

az új VA szintézis alatt mit értesz? sehol sem találom a leírásokban, csak az új FX-eket

Ez igaz, de közben nem szabad megfeledkezni arról hogy maga a MIDI egy viszonylag lassú soros átvitel - így ha bele is fér az adott eszköz memóriájába a 42000 MIDI esemény, késleltetheti más esetleg fontosabb esemény megjelenését a "dróton" mivel azon egyszerre csak egy csatorna egy eseménye tud átfutni... Ha még ráadásul sorba is van fűzve 2-3 eszköz MIDI THRU láncon át a probléma hatványozottan jelentkezik és bizony vájtfülűek hamar kiszúrják a késéseket - főleg valamilyen ritmikus csatornán (dob, arp, stb...)

Én nem real time venném fel mert marha sok felesleges CC keletkezne - lévén "felvenné" a poti teljes útját ide-oda az adott ppm szerint... Kézzel beírnék kettőt micro edit módban (bal és jobb) majd copy-paste x-szer... Rengeteg MIDI eseményt megspórolsz vele...

MIDI Running Status Azért, hogy időt spóroljanak a MIDI átvitel során kitalálták ezt a Runnig Status dolgot... Példa: ha lenyomok egy hármashangzatot majd felengedem ez menne ki a dróton: 91 3C 75 (note on) 91 40 77 (note on) 91 43 72 (note on) 91 3C 00 (note on nulla velocity-vel->note off) 91 40 00 91 43 00 vagy ez: 91 3C 75 91 40 77 91 43 72 81 3C 75 (note off nem nulla velocity-vel) 81 40 77 81 43 72 ugyanez Running Status alkalmazásával: 91 3C 75 40 77 43 72 3C 00 40 00 43 00 vagy 91 3C 75 40 77 43 72 81 3C 00 40 00 43 00 Jól látszik, hogy ha egymás után ugyanazok a status byte-ok jönnének (91/81) akkor azokat nem küldi ki az eszköz ismételten, hanem csak az adat byte-okat; feltételezve hogy a fogadó device tudja mi az a running status... Időben ez: running status nélkül: 256 x 3 x 0.96 = 737.28ms running status alkalmazásával: (1 + 256 x 2) x 0.96 = 492.48ms. A különbség egy negyed másodperc - épp ezért találták ki ezt a "gyorsító mechanizmust" 🙂 Csakhogy! A running status-t megszakítja minden üzenet ami F0(sysex start) és F7(sysex end) között van, így az összes MTC, Tune request, SongPosition Pointer(!) és Song Select üzenet. Nem szakítja meg viszont a system real time üzenet (F8 CLK, FA START, stb...)!!! Persze van rá ajánlás is, hogy hogyan kell mindezt leprogramozni: ;A recommended approach for a receiving device is to maintain its "running ;status buffer" as so: ; - Buffer is cleared (ie, set to 0) at power up. ; - Buffer stores the status when a Voice Category Status (ie, 0x80 to 0xEF) is ; received. ; - Buffer is cleared when a System Common Category Status (ie, 0xF0 to 0xF7) ; is received. ; - Nothing is done to the buffer when a RealTime Category message is received. ; - Any data bytes are ignored when the buffer is 0. Nos, a firmware-em alapból bizony nem így működött 😛 Eddig úgy működött, hogy ha adatbyte-ok jöttek akkor az utoljára beállított csatorna->port kiosztás szerint küldözgette ki az adatokat a portokra - nem vizsgálva ki fia borja az adott adat. Ha viszont a running status-ú adat byte előtt "beesett" egy F8 (CLK) akkor minden portra kiküldte a következő byte-okat is míg nem találkozott egy újabb csatorna üzenettel, mert nem vizsgáltam a running status állapot információt és nem állítottam vissza a portokat broadcast-ról split-re a legutóbbi csatorna üzenetnek megfelelően... Így kaphatta meg a blofeld a 2-es csatornán pl. azokat az egyébként nem neki szóló adat byte-okat amik teszem azt a 3-as csatorna running status adatai voltak elvileg. Következmény: egy pl. a 3-as csatorna Modwheel üzeneteihez tartozó adatsort (ahol a CC+csatorna byte csak az első mozzanatnál ment ki) a blofeld (mivel nem tudta hogy nem neki szól) szépen alkalmazta running status-ú note on üzenetekként... hisz' megkapta... Tahát gyakorlatilag 2 probléma is volt a firmware-ben: 1. broadcast üzenet után nem állítottam vissza a port-ok on/off statuszát 2. running status nem volt figyelve - emiatt (és a broadcast hiba miatt együttesen) pl. F8 után minden device megkapta a running status-ú adat byte-okat - akár neki szóltak akár nem. Nálam az MC-808 a master sequencer... Az MC-808 adja a master CLK-ot is a többi eszköznek. Csakhogy ha az MC-808-on be van kapcsolva a Sync Out, akkor nem csak az F8-akat küldi ki (ami nem befolyásolná a dolgokat túlságosan) hanem ezeket is: • Timing Clock: F8 • Stop: FC • Start: FA • Song Position Pointer: F2 • Continue: FB Az F2 Song Position Pointer pedig bizony beleszól a running status-ba! - törli a running status-t, vagy legalábbis törölnie kellene... Ha belegondolok, hogy egy F8 MIDICLK üzenet bárhol beeshet, akár két adatbyte között is! és én egy F8 után nem állítottam vissza broadcast-ról split-re a portokat.... minden adatbyte előtti MIDICLK után mindenki megkapta az azt követő adatbyte-okat amiket értelemszerűen running status-ú "üzenetként" interpretált 😛 😕 "Röviden" ez volt a probléma... Közben ha már... bevezettem egy sysex state figyelést is - sysex alatt ugyanis -elvileg- semmi más nem jöhet, tehát minden megy broadcast-ba a következő 0xF7-ig akár adatnak tűnik akár másnak... 0x00 és 0xf6 között bármi lehet a sysex start és stop között... Ugyanakkor mivel a sysex start törli a running status-t, ciki lenne ha emiatt eldobná az adatbyte-okat mert nem tudná hogy sysex közben van 😀 Már csak annyi probléma van a cuccal, hogy 6N138-as optocsatolókat használók a midi bemenetekhez - ez azonban csak az 5V-os midi rendszerekkel működik jól - 3.3V-os rendszerekhez PC900-as vagy H11L1 kell(ene)... Később talán ki is cserélem Most örülök hogy megy mindennel a cuccaim közül kivéve az Alesis io2Express hangkarit

Közben meg lett a válasz.... MIDI running status.... Miután ezt leprogramoztam minden gond egycsapásra megoldódott Tökéletes lett a cumó!

Sziasztok! Építettem egy MIDI router/splitter-t eme leírás alapján... Az alap felépítmény egy PIC16F876-os microchip-el működik. Ebben vam maga a firmware is. Én magam kiegészítettem a dolgot ezzel a mergerrel ami hosszú évek óta kifogástalanul működött már a -szintén DIY- MIDI patch bay-emben. Tápnak egy mobiltelefon töltőt tettem rá... A splitter firmware-ét annyiban módosítottam, hogy ha 0xF0-nál nagyobb értékű byte érkezik a MIDI-n keresztül (nem csatorna üzenetek: System Real Time, System Common, stb) akkor megnézi hogy hány byte-os üzenet jött (1-2-3) és annak megfelelően számolja a következő 1 vagy 2 adatbyte-ot és azokat is "broadcast-ra" küldi - tehát függetlenül a csatorna kiosztástól kiküldi minden OUT portra. Alapból ugyanis a firmware úgy működött, hogy megnézte a beérkezett byte legfelső bit-jét. Ha ez 0 akkor az egy adat, ha 1 akkor egy status byte. Ez utóbbi esetben a byte "alsó" fele magát a midi csatornát tartalmazza - ezt használja a port táblázat indexeléséhez. Na most ha egy F8 MIDI CLK üzenet jött akkor azt csak a 9-es csatornára küldte ki ami nekem nem felelt meg. Első körben ezt az üzenetet broadcast-oltam, aztán szépen lépésenként minden módosítás után tesztelve bővítettem a "logikát" olyanra hogy most már pl. a Song Pointer üzenet is szépen kimegy minden portra az azt követő 2 byte-al együtt... Ezzel a részével nincs is gond! (A system exclusive üzenetekkel külön nem foglalkozom - de erről majd később, csak ha valakit kifejezetten érdekel...) Maga a setup így nézne ki: PCR-800 (1-16) -> Splitter IN A MC-808 (1-16) -> Splitter IN B Splitter OUT A -> Korg RADIAS(1,3,10) Splitter OUT B -> Waldorf Blofeld (2) Splitter OUT C -> Edirol UM-1 mkII. (1-16) DAW felé ha kellene Splitter OUT D -> Roland D-05 (4) Splitter OUT F -> Roland FA-06 (5-16) Minden szép és "csaci ragyi" csak... Elindul a szekvencia az MC-808-ról. Bemegy a splitter-be. Az annak rendje módja szerint továbbítja az üzeneteket oda ahova valók a MIDI csatornáknak megfelelően, illetve "broadcast-olja" pl. a MIDI CLK-ot (0xF8). A probléma a következő: 1. PCR-800-on Channel AfterTouch-ot generálva az 1-es MIDI csatornán note-on üzenetekként jelenik meg a Blofeld-en (2-es csatorna) 2. "Beragadnak" hangok - olyan mintha note-off üzeneteket "elnyelne" a rendszer - pedig nem. Mind a MIDI THRU-n, mind az OUT C-n PC-vel monitorozva (MIDIOX) látom hogy kiment az a fránya note off, csak éppen nem veszi tudomásul az eszköz. De sajnos tök random hogy mikor-melyiket 😕 Amire már gondoltam: 1. firmware Átnéztem oda-vissza. Megnézte egy másik programozó kollégám is - logikai hibát ő sem talált benne. PC-n simulátorban futtatva (is) tökéletesen teszi a dolgát - igaz csak egy-egy byte-al tudom szimulálni - "byte özönnel" nem. Ráadásul, a teszteken sorozatosan átment az UM-1-et használva ehhez a teszterhez. 32000 byte-ot kiküldve és a különböző portokon várva vissza mindig jó volt az UM-1-el. ALESIS io2express esetén már soha sem futott le hibátlanul, ezért jött a következő gondolat: 1.1 MIDI kábel... Cseréltem ilyenre-olyanra, gyárira, sajátra, rövidre, semmi.... mindig ugyanaz... Megjegyzem a kábeleimmel ezeddig soha semmi gond nem volt... de azért az ördög nem alszik, hát ezt az utat is véágigjártam. 2. elektronika... A MIDI IN része a dolognak szabványosnak mondható. 220 ohmos ellenállás, dióda, optocsatoló stb... 6N137 és 6N138-as optocsatolókat(**) használok - ezek már beváltak sok éve a MIDI PAtch bay-emben és számos thru box-ban amit építettem. Ráadásul; a.) ugyanazt a mergert használom amit a patch bay-ből szedtem ki (ahol is tökéletesen tette a dolgát), b.) a merger rész nélkül (egy bemenetet használva csak) sem múlt el a jelenség -> nem a merger a "hibás"; Az mondjuk már gyanús, hogy a MIDI THRU-ra kötve is jelentkeznek a problémák(*), ugyanakkor ez segített kipipálni a firmware gond lehetőséget... A MIDI THRU-hoz ugyanis semmi köze a PIC chip-nek - az pusztán logikai kapukkal van "kiosztva"... A MIDI OUT -al kapcsolatban több dolgot is kipróbáltam de minden esetben ugyanúgy jelentkezett ugyanaz a hiba: más byte megy ki mint aminek kellene... Csatoltam az OUT-okat az eredeti kapcsolásnak megfelelően a 74LS00-ás IC NAND kapuinak kimeneteire közvetlenül. A 74HC245-ös octalbus-on keresztül is (a LED-ek helyett MIDIOUT-nak használva a portjait). Próbáltam "átvezetni" 74HC14-es Schmidt triggeren keresztül is (természetesen két-két kaput használva egy-egy kimenethez) de ez sem vezetett eredményre, noha a már sokat emlegetett MIDI Patch bay-emben ez a verzió tökéletesen működik... Arra is adtam esélyt, hogy maga a PIC chip sérült esetleg a tesztek során - vettem még egyet de azzal is tök ugyanaz a helyzet... Arra is gondoltam hogy a 4MHz-es órajel esetleg kevés arra hogy időben kiszolgáljon minden megszakítási kérelmet (bár elvben ez kizárt mert a MIDI "csak" 31,250 baud sebességű) - most 8MH-z-es kristály adja az órajelet, de ez sem oldotta meg a problémát. A soros adatok feldolgozása során sem jelentkezik hiba (frame error)... ami azt jelenti, hogy a PIC chip UART-ja szinkronban van a MIDI jelek sebességével... de mint mondtam már a MIDI THRU-nál is jelentkezik a gond, amiben a PIC benne sincs... A sokat emlegetett patch bay-em egy ethernet switch házába lett beszerelve, annak tápegységét használva... Gondoltam kipróbálom azzal a táppal is - nem változott a helyzet... Egy szó mint száz, ne kíméljetek! Várom az ötleteket, meglátásokat szerintetek hol/mi lehet a hiba? Az is sokat segít ha csak "hangosan gondolkodtok" a problémán! Hátha olyasmi jut eszetekbe ami nekem eddig nem... Szerk (*): ha a bemenetek optocsatolóival lenne gond és bithibák kerülnének elő a splitter jelezné a soros kommunikáció hibáját (frame error) - mert gondolom a véletlenszerű bithiba nem korlátozódna kizárólag byte-on belülre... Ráadásul az UM-1-el mint mondtam tökéletesen működik minden (szerk: ez nem volt igaz, sajnos nem azt teszteltem amit kellett volna vele)... ugyanakkor ott van a "rozsdás bökő", hogy már a MIDI thru sem jó... Szerk.: (**) Időközben kiderült, hogy ez azonban csak az 5V-os midi rendszerekkel működik jól - 3.3V-os rendszerekhez PC900-as vagy H11L1 kell(ene)... Később talán ki is cserélem (Most örülök hogy megy mindennel a cuccaim közül kivéve az Alesis io2Express hangkarit ) Természetesen feltúrtam a netet hasonló probléma után kutatva. Találtam is hivatkozásokat amelyekből kiderült hogy egyes esetekben MIDI kábel gond volt, más esetben egy-egy kontroller koszos potija miatt küldött ki "zajból" generált CC üzenetet az adott eszköz, de hangkártyák/MIDI csatolók is széles palettán képesek arra amire az io2express - így ezzel a részével meg is tudnék békélni - de hogy 3 gyártó 3 különböző vasa is produkálja ugyanazt a hibát (amit a patch bay-emmel meg nem) arra enged következtetni hogy a splitter elektronikája szivat de rendesen... (Szerk.: ha valaki ilyesmivel találkozik majd egyszer gondoljon majd a 3.3V vs 5V-os MIDI rendszerek közötti átjárásra!)

Tény és való és el is ismerem, hogy azért egy modx vagy moxf processzor teljesítmény igénye nem hozható egy lapon az általam emlitettekkel... No és főleg a Waldorf után mondom, inkább a stabil polifónia fok mint a párhuzamosan használható MIDI portok!

Majdnem minden szintim képes egyszerre használni a két portot... A Roland ezt "soft-thru"-val megoldotta. Az FA-ban (és Integra-ban is) is de már az mc-808 is tudta... A RADIAS és a Blofeld pedig alapból képes párhuzamosan kezelni a két felületet (USB+DIN MIDI). Szerintem ez inkább csak a Motif örökség továbbvitele mint technikai akadály... Afféle "a 'yamaha-sok' ezt szokták meg, hát hagyjuk így továbbra is" hozzá állás... No meg gyártási ktsg. Megsporolnak igy vagy 5$-t termekenkent és sok kicsi sokra megy

Ezt mondjuk már a MOX editor is tudta VST presetként el volt mentve az editor "állapota" - más kérdés , hogy betöltéskor kellett trükközni... szinkronizálni a hangszert az editor beállításaihoz... vagy valami ilyesmi már nem emlékszem pontosan... Arra viszont igen, hogy sokszor szívtam azzal, hogy a DAW (S1) "ráült" az device-re és onnantól maga a VST editor nem tudta azt nem hogy használni, de nem is "látta"... Természetesen túrtam fórumot megoldást keresve és magamat sem tartom 1.0-ás usernek de az adott DAW-al (S1) sajnos ez egy ilyen bukta volt (NEM minden DAW müxik így, Cubase-el pl. nem volt probléma, csak hát én meg nem azt használtam )... Így aztán nem is igen használtam "VST-ként" a hangszert, megelégedtem azzal, hogy az adott songsetup-ra kiküldtem a note és CC üziket...

Ahogy a mai zenékben sem a 80-as évek sikereihez képest 14-16 éves gyerekeim zenéit (akaratlanul is) hallva (nem hallgatva) alig alig van különbség közöttük... Vagy csak én öregszem "ennyire" ? ps.: bocs hogy ilyen régi hozzászóláshoz nyúltam vissza...