TK.

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.

Mit dem MIDIbox NG Design wird sich das alles ganz einfach einbinden lassen, beim jetzigen Design muesstest Du selbst tief in die Firmware eingreifen, um diese Anforderungen zu erfuellen. Wenn ich ja selbst die Notwendigkeit dafuer haette, wuerde ich mal schnell eine entspr. Option einbauen... aber ich favorisiere momentan die Logic Control emulation. :) Gruss, Thorsten.

Yes, you need some buttons. Btw.: if you are living in germany, it's cheaper when you just order the PCBs from Mike, and the parts together with the pots, buttons, LEDs, LCD at Reichelt. The orderlists can be found on the appr. MBHP pages. Best Regards, Thorsten.

No, this isn't possible, since the MIDIbox SID is also some kind of virtual synthesizer which requires a lot of CPU power (the 6 LFOs, 2 envelope generators, portamento, arpeggiator, etc. are software implemented features, running with 16, partly with 32 bit resolution!). So, every SID requires its own core Best Regards, Thorsten.

No, the LC emulation doesn't require a PIC18F, it is just an option of the common MBMF and MB16E firmware which enables a new handler for the Mackie password sequence; when Logic is started, it requests for the password, gets an answer and voila: a special window pops up which shows a new LC device. The motorfaders have to send PitchBender events, the encoders CC in a special Mackie format, the buttons just note events, the LCD prints messages which are sent by Logic, however - the performance is already great with just two PIC controllers :) So, for a LC-like surface, two cores are required, one for the motorfader, another for the encoders. Each core module support s 64 buttons and 64 LEDs, so the whole system can feature 8 motorfaders, 16 encoders, 16 led-rings, 128 buttons, 128 LEDs... Currently I'm trying to work out an evaluation enviromment for myself (based on the existing MIDIboxes) in order to determine if everything works correctly and to setup the configuration scripts; later I will build a special case for all the stuff just for my private pleasure ;-) Best Regards, Thorsten.

Shit, I planned it as surprise ;-) Since yesterday Logic regognizes the MIDIbox MF and MIDIbox 16E as Logic Control Unit - Motorfaders, encoders and buttons are working well, the display also works but as I don't own a 2*55 LCD, I cannot see the whole screen... :-/ However, the experimental support for LC will be released soon. Best Regards, Thorsten.

I just have managed to get the interaction between the SID and the new editor running - here are all relevant files which are necessary for the update: Firmware: http://www.ucapps.de/midibox_sid/midibox_sid_v1.2.zip Editor: http://www.midibox.org/midibox_sid/jsynth_017_with_mbsid_rel2b.zip (1.5MB) Sounds: http://www.ucapps.de/midibox_sid/example_patches_v2.zip First you should bring the new firmware into your PIC, otherwise the editor will not be able to communicate with the SID. If java isn't installed on your computer yet, it's time to download it now: http://java.sun.com - click: the J2SE button the J2SE download button J2SE 1.4.1 and click on the appr. version of your operating system - take the JRE (runtime environment) if you only want to use the editor and don't plan to program code After java is ready, unpack the jsynth archive, go into the directory and click on the "run.bat" file or just type "java JSynthLib" within a command shell. Now the editor pops up (hopefully) go into the Config->Preferences menu, MIDI-tab, select the MIDI driver (Windows: WireProvider) and MIDI devices go into the Config->Synths menu and check if the MIDIbox SID driver has been notified. If not, add it manually. Check also if the MIDI In/Out port of your MBSID is set correctly Create a new library (Library->new) Create a new patch (Patch->new) Right-Click on the patch and select "Edit" Have fun! :) --- if your MBSID is connected correctly, all parameters should be directly changed when you move a slider. The editor comes also with a MIDI-Through function which allows you to play notes on a keyboard and to change sound parameters at the same time Finally unpack the example_patches_v2.zip archive and load the all.patchlib file - it contains 15 sounds. The librarian allows you to load, play, modify, save the patches More detailed informations regarding the jsynth editor can be found here: http://www.overwhelmed.org/jsynthlib/ Don't forget to send me your favourite selfmade sounds! :) Best Regards, Thorsten.

Yes, the existing modules are compatible - nothing will be changed in the first months except for the PIC and the firmwares Best Regards, Thorsten.

Hi, das haengt wirklich von Deinen individuellen Beduerfnissen ab - was moechtest Du mit den Core-Modulen denn so alles anfangen? Gruss, Thorsten.

Hi, all the available controllers for audio objects are documented in the Logic manual, chapter 5 (Basics about the Environment concept) Best Regards, Thorsten.

I found a nice Java library which allows me to write a powerfull MIDIbox SID editor, running on every operating system which supports Java: Windows, Mac OS, Linux, Solaris, etc... http://www.overwhelmed.org/jsynthlib/ It comes not only with some components for the editor panel, but also with a SysEx librarian - nice to manage all the sounds :) Although I never programmed in Java before, I was able to create a complete panel in few hours :) However, the SysEx structure and MIDI interaction has not been programmed yet, but it will follow in the next days or weeks - we'll see :) Best Regards, Thorsten.

Alright - this error message can be caused by a lot of reasons. Either your windows version isn't able to stimulate the COM port due to protection reasons (in this case you have to enable the API checkbox in the hardware setup), or something is wrong with the hardware wiring --- here you really have to follow the instructions given on the http://www.ucapps.de/mbhp_jdm.html page step by step. As I wrote, the voltages don't have to be reached exactly, it's more important that all wires are connected correctly (check especially the numbers of the RS232 connector pins, if it is a female and not male connector, if the diodes are in the right direction, etc.) Best Regards, Thorsten.

Der Gameport an Soundkarten & Mainboards liefert leider nicht genuegend Strom um die LEDs zu betreiben (i.d.R. maximal 100 mA), aber fuer das Core/DINX4-Modul und die Encoder sollte es reichen. ---- Unfortunately the gameport isn't a good replacement for a power supply, since the maximum current load is about 100 mA - however, for a core/DINX4 module and some encoders this should be ok. ---- Gruss, Thorsten.

Perfect! :) Regarding Cubase: some years ago I've worked with cubase on my Atari and used the "studio module" function which enabled me to create a panel with a lot of knobs, buttons and faders in order to control my synth via CC. I just found an interesting article about the progress in the last years: http://www.sospubs.co.uk/sos/feb01/articles/cubasenotes.asp It seems that the module technology is mainly used to exchange SysEx data now, but CC controller (the simplest protocol ;-)) should still be possible. And it should also be possible to create a panel with knobs and faders - if Steinberg hasn't skip this feature! The name writes, that studio modules have to be created with "dmaker" which is located somewhere on the CD. Since I don't own cubase (and don't plan to buy it in the next years...) I cannot help - but it would be great if somebody would be so friendly :) Best Regards, Thorsten.