TK.

Hallo Dmitry, hast Du das Problem mittlerweile geloest? Wahrscheinlich war der MIDI-Merger eingeschaltet, dadurch ist eine Rueckkopplung entstanden, die Cubase durcheinander gebracht hat. Gruss, Thorsten.

Hallo Dmitry, hast Du das Problem mittlerweile geloest? Wahrscheinlich war der MIDI-Merger eingeschaltet, dadurch ist eine Rueckkopplung entstanden, die Cubase durcheinander gebracht hat. Gruss, Thorsten.

Isn't the PIC delivered with the core module? This must be a fault! :-/ Best Regards, Thorsten.

http://www.ucapps.de/midibox16e.html (remove the buttons, the display, the LED-rings, the banksticks, some software features, and you have a pocket dial ;-)) Best Regards, Thorsten.

http://www.ucapps.de/midibox16e.html (remove the buttons, the display, the LED-rings, the banksticks, some software features, and you have a pocket dial ;-)) Best Regards, Thorsten.

Encoders with inbuilt buttons are coming with 5 pins: 3 for the encoders, 2 for the button function. I see no difficulties - the buttons have to be assigned on the following way: [BUTTONS] # Following Button events are documented in the logic control user # manual, chapter 13 "Control Surface Layout and IDs" # LC event: "select buttons" for the V-Pot section 1 = 90 20 7F @OnOff # select function of V-Pot 1 2 = 90 21 7F @OnOff # select function of V-Pot 2 3 = 90 22 7F @OnOff # select function of V-Pot 3 4 = 90 23 7F @OnOff # select function of V-Pot 4 5 = 90 24 7F @OnOff # select function of V-Pot 5 6 = 90 25 7F @OnOff # select function of V-Pot 6 7 = 90 26 7F @OnOff # select function of V-Pot 7 8 = 90 27 7F @OnOff # select function of V-Pot 8 Best Regards, Thorsten.

Currently the MBMF is working with a 8 bit resolution (=256 values). 10 bits (=1024 values) should also be possible, but only for sending (-> Pitch Bender events, NRPN). For receiving it makes no sense to work with such a high resolution, since the motors are moved so fast that differences of 10µm (10 cm / 1024 values) cannot be realised ;-) Best Regards, Thorsten.

Currently the MBMF is working with a 8 bit resolution (=256 values). 10 bits (=1024 values) should also be possible, but only for sending (-> Pitch Bender events, NRPN). For receiving it makes no sense to work with such a high resolution, since the motors are moved so fast that differences of 10µm (10 cm / 1024 values) cannot be realised ;-) Best Regards, Thorsten.

Hi Dave, for a confirmation you could contact Simeon, he modified the gerber files for "Advanced Circuits" (see his webpage: http://www.soundcreationsinc.com/midibox/) Best Regards, Thorsten.

Hi Dave, for a confirmation you could contact Simeon, he modified the gerber files for "Advanced Circuits" (see his webpage: http://www.soundcreationsinc.com/midibox/) Best Regards, Thorsten.

Hi Dan, yes, no hardware update is necessary for the MIDImon. :) Best Regards, Thorsten.

Hi Dan, yes, no hardware update is necessary for the MIDImon. :) Best Regards, Thorsten.

Hi, you don't have to wait for MIDIbox NG, since the preliminary releases of MB16E and MBMF can already handle with the complete Mackie HUI protocol :) In difference to the features which were already provided by the MIDIboxes, the LC emulation requires only a subset of them - the motorfaders just need to be moved on Pitchbender events, they must send Pitch Bender events, the V-pots must send the ticks based on a special formula, the LED-Rings react on different MIDI events, the buttons need to send Note events, the LEDs must react on Note events, the display must be accessible by the host software. Ok, and there is a special password sequence which was new to me. However, just another variant ;-) The intelligence is not in the MIDI controller, but in the host software... 16 Tracks are possible, but the protocol supports only 8 tracks per MIDI line. So, two MIDI In/Out pairs and 4 core modules are required. Cubase: is there somebody out there who wants to help me to determine if Cubase SX can already handle with the same protocol which is used by Logic Control? I don't own Cubase (and I don't want to see any cracked version in my Mailbox!!!) therefore I cannot test it. I need to know: is the Mackie Control driver already included in the official Cubase SX release? does this driver send any request over the MIDI lines during startup? Or is there a way to send a request manually? For LC, the request is "F0 00 00 66 10 F7" - do you see something similar? If you don't own an external MIDI monitor, you can track these requests by using MIDI-Ox in conjunction with MIDI-Yoke (a virtual MIDI device) Best Regards, Thorsten.

Hi, you don't have to wait for MIDIbox NG, since the preliminary releases of MB16E and MBMF can already handle with the complete Mackie HUI protocol :) In difference to the features which were already provided by the MIDIboxes, the LC emulation requires only a subset of them - the motorfaders just need to be moved on Pitchbender events, they must send Pitch Bender events, the V-pots must send the ticks based on a special formula, the LED-Rings react on different MIDI events, the buttons need to send Note events, the LEDs must react on Note events, the display must be accessible by the host software. Ok, and there is a special password sequence which was new to me. However, just another variant ;-) The intelligence is not in the MIDI controller, but in the host software... 16 Tracks are possible, but the protocol supports only 8 tracks per MIDI line. So, two MIDI In/Out pairs and 4 core modules are required. Cubase: is there somebody out there who wants to help me to determine if Cubase SX can already handle with the same protocol which is used by Logic Control? I don't own Cubase (and I don't want to see any cracked version in my Mailbox!!!) therefore I cannot test it. I need to know: is the Mackie Control driver already included in the official Cubase SX release? does this driver send any request over the MIDI lines during startup? Or is there a way to send a request manually? For LC, the request is "F0 00 00 66 10 F7" - do you see something similar? If you don't own an external MIDI monitor, you can track these requests by using MIDI-Ox in conjunction with MIDI-Yoke (a virtual MIDI device) Best Regards, Thorsten.

Sorry, this was a documentation error. I already changed it on some files, but possibly not everywhere. The correct SysEx string to change the device ID is: F0 00 00 7E 46 [DEVICE-NR](00) 0D 03 00 [NEW DEVICE](01) F7 Thereafter the MBSID should answer with: F0 00 00 7E 46 01 0F F7 Best Regards, Thorsten.

Sorry, this was a documentation error. I already changed it on some files, but possibly not everywhere. The correct SysEx string to change the device ID is: F0 00 00 7E 46 [DEVICE-NR](00) 0D 03 00 [NEW DEVICE](01) F7 Thereafter the MBSID should answer with: F0 00 00 7E 46 01 0F F7 Best Regards, Thorsten.

you can try it without any risk. Note that capacitances are added when they are connected in parallel. That means: you can leave the 470 pF caps on the board and solder other caps in parallel - e.g. two additional 1nF will result into 2* 1.47 nF Best Regards, Thorsten.

I finally found a simple and effective method against the feedback loop issue which appears when multiple MIDIboxes are chained and are running with an enabled MIDI merger. First idea was to create a special hardware interface (a physical "MIDIbox Link") which acts as a second MIDI connection between the MIDIboxes. But this hardware extension could be unstable against outside influences (EMC) and could lead to crashes at every little noise on the wires between the core modules. Only solution against this problem are additional hardware components, slower transfers and an error correction. However, today I tried out something different. I used the common MIDI chain and inserted "Begin" and "End" bytes in order to mark events which should leave the MIDI chain, and events which should be filtered out by the last node of the chain. In other words: all MIDI events which are generated by the core modules itself, will be tunnled to the "exit". Thats all - and it's working fine without any additional hardware. :) Here some pictures which make it more clear: Picture one shows the potential feedback problem when all mergers are enabled. This is sometimes necessary if (for example) 3 modules with motorfaders are connected together and the host software has to send the motorposition to all cores, and the MIDI events which are generated by the MIDIboxes have to be forwarded to the host. If the host software cannot filter out the selfmade events, it will forward them again and again until it gives up (and mostly until windows crashes :-/) The solution: every event which should be forwarded to the host software will be framed with a start and stop byte. The frame will be notified by the last core with disabled MIDI merger. Only the framed events will be forwarded by the last core (-> tunnled), all others will be filtered out. Here the MIDI wiring - note that there is only one path from core1 to core3 *through* the cores. And now the best: on this way, not only common MIDI events, but also other informations can be transmitted without reaching the host software at the end of the chain - for example LCD characters (only one LCD at core 3 for all core modules) or bankchange triggers. A nice new feature which can be realized very easily. I already have integrated the basics into the MB16E and MBMF firmware :) Best Regards, Thorsten.

I finally found a simple and effective method against the feedback loop issue which appears when multiple MIDIboxes are chained and are running with an enabled MIDI merger. First idea was to create a special hardware interface (a physical "MIDIbox Link") which acts as a second MIDI connection between the MIDIboxes. But this hardware extension could be unstable against outside influences (EMC) and could lead to crashes at every little noise on the wires between the core modules. Only solution against this problem are additional hardware components, slower transfers and an error correction. However, today I tried out something different. I used the common MIDI chain and inserted "Begin" and "End" bytes in order to mark events which should leave the MIDI chain, and events which should be filtered out by the last node of the chain. In other words: all MIDI events which are generated by the core modules itself, will be tunnled to the "exit". Thats all - and it's working fine without any additional hardware. :) Here some pictures which make it more clear: Picture one shows the potential feedback problem when all mergers are enabled. This is sometimes necessary if (for example) 3 modules with motorfaders are connected together and the host software has to send the motorposition to all cores, and the MIDI events which are generated by the MIDIboxes have to be forwarded to the host. If the host software cannot filter out the selfmade events, it will forward them again and again until it gives up (and mostly until windows crashes :-/) The solution: every event which should be forwarded to the host software will be framed with a start and stop byte. The frame will be notified by the last core with disabled MIDI merger. Only the framed events will be forwarded by the last core (-> tunnled), all others will be filtered out. Here the MIDI wiring - note that there is only one path from core1 to core3 *through* the cores. And now the best: on this way, not only common MIDI events, but also other informations can be transmitted without reaching the host software at the end of the chain - for example LCD characters (only one LCD at core 3 for all core modules) or bankchange triggers. A nice new feature which can be realized very easily. I already have integrated the basics into the MB16E and MBMF firmware :) Best Regards, Thorsten.

Hi Dan, it's almost perfect, but I would use the BankStick for the MB64 core, since the LC emulation works with one internal bank only - Logic (or the Mackie HUI unter Cubase SX) has it's own bank handling - tracks and functions can be directly selected with the mouse or with the LC buttons and assigned to the faders, V-pots and buttons. Fast & easy! :) I think that you don't need a display for the MIDImon, only the 8 LED digits of the MTC display. I've planned to release a new MIDImon version which interprets the LED-digit messages which are sent by the host software to LC. The power consumption of this system should be about 500-800 mA. So, if your wall adapter is strong enough, you can use it for all modules. Concerning the MIDI chain: it will not work in this way, because of a potential feedback loop problem. I noted that the LC protocol isn't resistant against this issue, since the LEDs are controlled with the same MIDI events like the appr. buttons. That means: when Logic wants to set a LED, it sends a MIDI event and some miliseconds later it will receive the same back and assume that the button which is assigned to this event has been pressed. Logic crashed sometimes because of this unwanted feedback. However, I found a solution which prevents such crashes - see the next posting (tunnled MIDI events). Best Regards, Thorsten.

Hi Dan, it's almost perfect, but I would use the BankStick for the MB64 core, since the LC emulation works with one internal bank only - Logic (or the Mackie HUI unter Cubase SX) has it's own bank handling - tracks and functions can be directly selected with the mouse or with the LC buttons and assigned to the faders, V-pots and buttons. Fast & easy! :) I think that you don't need a display for the MIDImon, only the 8 LED digits of the MTC display. I've planned to release a new MIDImon version which interprets the LED-digit messages which are sent by the host software to LC. The power consumption of this system should be about 500-800 mA. So, if your wall adapter is strong enough, you can use it for all modules. Concerning the MIDI chain: it will not work in this way, because of a potential feedback loop problem. I noted that the LC protocol isn't resistant against this issue, since the LEDs are controlled with the same MIDI events like the appr. buttons. That means: when Logic wants to set a LED, it sends a MIDI event and some miliseconds later it will receive the same back and assume that the button which is assigned to this event has been pressed. Logic crashed sometimes because of this unwanted feedback. However, I found a solution which prevents such crashes - see the next posting (tunnled MIDI events). Best Regards, Thorsten.

Did you change the MIDI channel or the Device ID? The MIDI channel allows you to select the channel for common MIDI events, so that different sounds can be played when more than one SID is connected to a MIDI chain. The device ID is the same for SysEx messages, it allows you to configure a SID module independent from the selected MIDI channel. The configuration of both "channels" is described in the Questions & Answers section of the MBSID page. Best Regards, Thorsten.

Here are some preliminary versions of MIDIbox MF and MIDIbox16E which can be used by everybody who already own one (or more) core module(s) in order to test the Logic Control Emulation mode. Also MIDIbox64 users can try the MB16E firmware to check if their host software regognizes the faked LC unit. Files: http://www.ucapps.de/midibox16e/midibox16e_v1004pre1.hex.zip http://www.ucapps.de/midibox_mf/midibox_mf_v1000pre1.hex.zip http://www.ucapps.de/midibox/mk_syx.zip the mk_syx archive contains two new sample initialization files midibox16e_lc.ini and midibox16e_mf_lc.ini --- just read the comments in these files. When you upload the firmware, the MIDIbox will *not* answer to LC queries from the host software until the LC Emulation ID has been set (this is done in the .ini file...). ID 10 stands for "Logic Control", ID 11 for "Logic Control XT". For Mackie Control emulation (-> Cubase SX users...) possibly another ID is required, but I cannot try it by myself; inputs are welcome! Checked features (with 2 core modules): emulation of 8 motorfaders working emulation of 8 V-pots, external controller and jog wheel working 128 buttons working - all specified commands in the LC spec can be triggered 128 LEDs working - the MIDIbox toggles the LEDs like specified LCD working (ok, I only tested a 2*40 chars display) - you see the selected tracks, the track names, the fader and v-pot values, fx settings... the LCD-messages are sent by the host software LED-Rings not supported yet (but will work with the final release) Note that the SysEx dump structure has been completely changed. By now, 8 internal banks instead of 6 are available, and up to 64 buttons and 64 LEDs can be connected to the core module. Together with a BankStick, 8*8 = 64 banks can be used :) The current version of vmidibox16e is *not* compatible with the new firmwares. Serge will adapt the editor in the next days. In the meantime you have to use the mk_syx.pl script (perl must be installed) to generate a .syx file, or you have to use the default files until then. The .syx files can be uploaded with MIDI-OX or vsysexbox Other new features: MB16E knows a new encoder mode LCEMU (for what damned thing should this be useful? ;-)) and MB16E/MBMF can handle with touch sensors. The touch sensitivity can be adjusted in a special submenu or in the .ini file. Connection diagram for the DIN module can be found here: http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf , a schematic will follow soon. Btw.: capacitive touch sensors (the cheapest way to realize a button function) are no dedicated motorfader features - in fact you could misuse 64 thumbtacks as button-replacement :) Have fun! :) I hope that Cubase SX users don't need an additional driver for MC emulation. Best Regards, Thorsten. P.S.: does anybody know a distributor for 2*55 character displays?

Hallo Jack, vor zwei Jahren habe ich es aufgegeben, jedes Projekt in zwei Sprachen zu dokumentieren, weil es einfach zu aufwendig ist, beide versionen up-to-date zu halten. :-/ Gruss, Thorsten.

Diesen Modus wird es mit der naechsten Release als Option geben :) Gruss, Thorsten.