TK.

Hi, with the MB64E application this seems to be feasible. The USB keyboard option is a nice idea! It would be very nice, if you would document your design in the Wiki later, because many people have introduced their dedicated live controller in the past, but the build process was never written down, and is therefore lost as source of information for others, who are planning to do something similar. Best Regards, Thorsten.

Hi, you will find my answer here: http://www.midibox.org/dokuwiki/doku.php?id=midibox64_e_patchmode Best Regards, Thorsten.

Hallo Jack, die ueberarbeitete (assembler basierte) USB Firmware fuer den PIC18F4550 ist bereits fertig und laeuft stabil. Jemand aus dem Forum entwickelt gerade einen neuen Windows Treiber, der wesentlich performanter als der Legacy M$ Treiber sein wird. Linux und Mac User koennen wie bei MBHP_USB den normalen USB MIDI Treiber verwenden. Gruss, Thorsten.

yes, no idea... the 74LS165 should be ok, but I could also be wrong. With the srio_interconnection_test you could at least ensure, that the connections to the module are ok Best Regards, Thorsten.

From your posting it's not clear to me, if you've already checked it without connecting the MIDI In or not... Some possible reasons: bad soldering joint, broken MIDI cable (which sometimes works, sometimes not), problem with your PC MIDI driver, problem with your PC software. When you read this troubleshooting section, you will find a lot of strange reasons for failures... maybe this helps! Best Regards, Thorsten.

Mittlerweile hat das Projekt den Status erreicht, in dem ich es mal praxisnah testen kann. So sieht mein momentanes Routing aus: Manche Browser schneiden das Bild an der rechten Seite ab - hier die komplette version: http://www.ucapps.de/midi_router/midi_router_default.gif Und so der Code in router.c (meiner Meinung nach ist es noch einigermassen ueberschaubar :) ///////////////////////////////////////////////////////////////////////////// // These functions are called from the MIDI parser when a new package has been // received. They can be modified to customize the routing // // evnt0, evnt1, evnt2: the bytes of the MIDI event which has been received // // ptype: package type // - 0x02 two-byte system common message like MTC, Song Select, etc. // - 0x03 three-byte system common message like SSP, etc. // - 0x04 SysEx starts or continues // - 0x05 SysEx ends with following single byte // - 0x06 SysEx ends with following two bytes // - 0x07 SysEx ends with following three bytes // - 0x08 Note Off // - 0x09 Note On // - 0x0a Poly-Key Pressure // - 0x0b Control Change // - 0x0c Program Change // - 0x0d Channel Pressure // - 0x0e Pitch Bend // - 0x0f single byte like MIDI Clock/Start/Stop/Continue ///////////////////////////////////////////////////////////////////////////// void ROUTER_Rx_INT0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // Core MIDI IN, connected to my PC // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_INT0, ptype); // forward data to the MIDI OUTs of all IIC slaves ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC0: connected to my MIDIbox SID // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC0, ptype); // forward data to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC1(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC1: connected to my MIDIbox FM // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC1, ptype); // forward data to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC2(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC2: connected to my MIDIbox SEQ // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC2, ptype); // forward MIDI clock/start/stop/continue to all IIC modules if( evnt0 >= 0xf8 && evnt0 <= 0xfc ) { ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2); } if( (ptype >= 0x08 && ptype <= 0x0e) && ((evnt0 & 0x0f) >= MIDI_CHN9) ) { // directly forward MIDI channel #9..#16 messages to MIDIbox SID and MIDIbox FM only ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); } else { // forward all other events to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } } void ROUTER_Rx_IIC3(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { unsigned char transposed_note; // IIC3: connected to my Yamaha AN1x // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC3, ptype); // if note on/off at channel #16 has been received, change it in the // following way: // - send notes < C-4 to MIDIbox SID (IIC0), Channel #9 // - send notes < C-4 to MIDIbox SEQ (IIC2), Channel #1, transposed by 2 octaves // - send notes >= C-4 to MIDIbox FM (IIC1), Channel #13 if( (ptype >= 0x08 && ptype <= 0x09) && ((evnt0 & 0x0f) == MIDI_CHN16) ) { if( evnt1 < 0x3c ) { // evnt1 contains note number, 0x3c is C-4 ROUTER_Tx_IIC0(ptype, (evnt0 & 0xf0) | MIDI_CHN9, evnt1, evnt2); transposed_note = evnt1 + 2*12; while( transposed_note > 127 ) // avoid invalid notes, transposed_note -= 12; // transpose back until note number <= 127 ROUTER_Tx_IIC2(ptype, (evnt0 & 0xf0) | MIDI_CHN1, transposed_note, evnt2); } else { ROUTER_Tx_IIC1(ptype, (evnt0 & 0xf0) | MIDI_CHN13, evnt1, evnt2); } } // forward data (also) to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } [/code] Die USB Option kommt hier nicht zum Einsatz, dies wird ein separates Projekt (da MIOS auf dem PIC18F4550 aufgrund diverser Silicon Bugs nicht sauber laeuft) Bei USB gibt es dann 8 zusaetzliche Rx/Tx Kanaele, die man ebenfalls beliebig "verdrahten" kann. Gruss, Thorsten.

No, in this case there is no loopback - did you check this? Best Regards, Thorsten.

yes this heavily depends on the memory consumption of the data structure which stores the "virtual" states/positions The example is really simple (it should help to get a general understanding of the approach) and doesn't provide mapping. Please note that this example exists twice, one assembly based version, and a C based version Best Regards, Thorsten.

Hi, this could be a loopback problem, maybe you've enabled a forwarding option (MIDI In -> MIDI Out) in your software. If the merger of the MIDIbox is enabled as well, the data will be loopbacked endless Best Regards, Thorsten.

Stryd One: In order to avoid name conflicts, I've added a "stryd_one_..." prefix before your links. Example: [[stryd_one_MBSeq|MBSeq]] (the text behind the | is the description which will be displayed) I've also removed user_gallery and usergalley, since they are redundant. Currently I propose to add your names to the mainpage Best Regards, Thorsten.

It's very simple, you only need to insert an internal link into a page in order to create a new page. Example: after login click on the "edit this page" button. Insert [[blogs]] somewhere in the mainpage (where it makes sense). After this change has been saved, you can click on the Blogs link in order to view and edit this page... Best Regards, Thorsten.

Yes - and if the remaining 6 pins of second DOUT are not used, you could take the MIOS_DOUT_SRSet function as well (but this is your decition - it doesn't save that much cycles) Best Regards, Thorsten.

Short question: did you also create the DOUTX2 module? Is it already connected to the core? Because somebody just reported, that this PCB has two bugs, they lead to a short circuit Best Regards, Thorsten.

Currently I can only say, that this needs to be evaluated. This is a long process, just consider, that I've to upgrade my own MIDIboxes by PIC18F4620 + I2C slaves, I've to modify the applications, and I've to make some music in order to say: yes, it works ok for daily work This is a process which can take some months The MBHP_IIC_MIDI module is just the first step... Best Regards, Thorsten. P.S.: I decided to use a PIC16F derivative, because most PIC18F* have an anoying IIC bug! (-> BF flag erratum)

No, they "prepare" the incoming data in form of packages, the master has to poll for updates. This is a complex topic which cannot be explained in a few number of lines (therefore: please wait for the documentation). There is a I2C specification available on the Philips website which helps to understand the common approach Best Regards, Thorsten.

Short answer: an even more powerful method is the use of the I2C protocol. In the last days I've worked out just another demonstrator, which shows, that this protocol is not only useful for accessing EEPROMs and LCDs from a MIOS core, but also to exchance data with other microcontrollers (see http://www.ucapps.de/mbhp/mbhp_iic_midi.pdf and http://www.ucapps.de/mbhp/mbhp_iic_midi_preview.jpg - this is a II<->MIDI bridge which allows to control multiple MIDI interfaces from a "master" core via I2C I will write some documentation and especially programming examples to this project after my holidays. In the meantime you could work on the I2C slave routines for Atmel (for PIC I can provide a tested template) - MIOS already provides MIOS_IIC_* functions for I2C master accesses (an OS change is not required) Another hint: Duggle has worked out a PIC based application for PS/2->MIDI some time ago, you could contact him in order to prevent double-effort. I think that a modification for PS/2<->I2C isn't that difficult Best Regards, Thorsten.

Wenn ich bis morgen (Samstag) das DOUTX2 Layout nicht gefixed habe, bitte nochmal melden. Zur 909: hierfuer gibt es eine Loesung, die in diesem Artikel gepostet wurde (wichtig: Hallucinogen's Hinweis auf den Schreibfehler beachten!) http://www.midibox.org/forum/index.php?topic=2701.0 Fuer diesen Tip verpflichte ich ich nun, die Erweiterung im Wiki zu dokumentieren! (zur not auch auf Deutsch, jemand anderes kann es immer noch uebersetzen) Gruss, Thorsten.

The SRSet function is just the fastest way to change 8 bits at once. This is useful when setting patterns (-> time multiplexed circuits, like LED digits or LED rings), and it's useful if the state of digital outputs is mirrored somewhere in the application (useful if you want to switch between two or more "layers") Best Regards, Thorsten.

Hi, First I must say, that I'm happy about the fact, that you've looked into the ucapps.de website before asking these questions. I can read this between the lines, and I think it must be highlighted, because most people just ignore the existiting documentation (thus I mostly don't feel motivated to bring it up-to-date) yes, thats correct. The ain64_din128_dout128 application demonstrates these capabilities. This is just a simple example application, but it works sufficient so long your PC software is able to "learn" MIDI events. thats partly correct. The restrictions exist, because I wanted to prevent an update of existing tools (not written by myself). But in general it's possible to write a new application which gets use of all capabilities provided by MIOS. A lot of combinations are possible, and I hope that sooner or later the users will provide their fully customizated controllers to the community. there is a hidden feature in the MB64E application which allows you to get use of the AINs, as well of the motorfader feature (see ChangeLog and comments in main.asm file) Exactly! (with MIOS 0-1023: 10 bit resolution) In general you have to take into account, that the serial DIN chain is scanned each millisecond. This is fast enough for buttons/switches/encoders, since the resulting reaction (normaly a MIDI event) isn't much faster (the transfer of a 3-byte MIDI event takes 960 uS). So, your question is a little bit too abstract. What kind of data do you want to handle with the DIN pins exactly? How fast does it change? Yes, this page http://www.midibox.org/dokuwiki/doku.php?id=midiboxlc contains a link to the Logic Control spec yes, but I must say, that these terms are mixed very often in MIDI controller specs. Even in the MIDIbox LC application, I've called the rotary encoder "Jog wheel" to keep it aligned with the Logic Control spec. Normaly it should be differed between a jog wheel, which is just a multi-state switch, and datawheels/rotary encoders, which are techically called "quadrature encoders". Best Regards, Thorsten.

Der Regulator war falsch gepolt (linkes und rechtes Bein vertauscht). Vergleiche die Schaltung mal mit dem PCB Layout des Core Modules - der 7805 hat das gleiche Pinning wie der 7809. Am linken Beinchen wird die Eingangsspannung angelegt, in der Mitte ist Masse, auf der rechten Seite die regulierte Ausgangsspannung. Gruss, Thorsten.

Zum bauen eines neues .hex Files kannst Du den MPASMWIN auch direkt aufrufen, das ist einfacher und weniger fehleranfaellig (ich traue dem Wizard nicht). Eine Anleitung gibt es hier: http://www.ucapps.de/howto_tools_mpasm.html Mit deiner derzeitigen Variante wird es ein Problem geben (welches dann auch im main.err File erscheinen wird): das Label USER_MPROC_NotifyReceivedEvent existiert nun zweimal, es darf aber nur einmal gesetzt werden. Ein Label ist nichts anderes als ein Verweis auf eine Adresse. Ein weiteres Problem: MIOS springt auf USER_MPROC_NotifyReceivedEvent, wenn ein neues Event empfangen wurde. Von dort aus wird die Funktion CV_MIDI_NotifyReceivedEvent aufgerufen, anschliessend verzweigt das Programm zu "USER_Tick". Der Code dahinter wird also niemals aufgerufen. Stattdessen muesstest Du den zusaetzlichen Code also vor das rgoto setzen. Oder noch besser, direkt unter das USER_MPROC_NotifyReceivedEvent Label (also vor dem call und vor dem rgoto) - dies ist auch der Grund, warum ich das Label in meinem Codeschnippsel angegeben habe Gruss, Thorsten.

Hi Goule, there are several possibilities. By using the MIOS_DOUT_PinSet function, you can address the appr. outputs with pin number 8-15. With the MIOS_DOUT_SRSet function, you can write all 8 pins with a single function call - the SR number is 1 in this case (we are counting from 0) A pintable can be found here: http://www.midibox.org/dokuwiki/doku.php?id=din_dout_pintable Best Regards, Thorsten.

It could be a short which is hard to find. You can ensure that the RD3 pin (pin #22) is still working by lifting it from the socket, so that it doesn't have contact with the PCB anymore. Is it possible to switch between 0V and 5V now? Best Regards, Thorsten.

Das ist uebel! Es wird Zeit, dass ich im Wiki mal eine Blacklist aufsetze, auch die Soundblaster Audigy hat Probleme (die sich jedoch mit einem Treiberupdate beheben lassen) Theoretisch gaebe es die Moeglichkeit, die Blocklaenge auf bis zu 8 Bytes herunterzusetzen. Doch leider habe ich gerade die Sourcen zur aktuellen MIOS Studio Version nicht parat - Adam moechte noch ein paar Schoenheitskorrekturen anbringen, bevor er sie mir schickt.... Gruss, Thorsten.

By adding following code to the debug trigger hook: USER_MPROC_DebugTrigger goto SID_BANK_FormatStick [/code] it's possible to trigger the format function via SysEx (e.g. with MIOS Studio :)) Best Regards, Thorsten.