TK.

Hi, ok, in your first posting you wrote about 8 joysticks, and AINX2 means that the half of a AINX4 module is enough for this setup - just a hint for people who make the PCBs by themself. However, having more than necessary inputs doesn't hurt and could be usefull for the experimental phase. :) Yes, just write me a mail later. It's just a quick change in the firmware. Best Regards, Thorsten.

Hi, ok, in your first posting you wrote about 8 joysticks, and AINX2 means that the half of a AINX4 module is enough for this setup - just a hint for people who make the PCBs by themself. However, having more than necessary inputs doesn't hurt and could be usefull for the experimental phase. :) Yes, just write me a mail later. It's just a quick change in the firmware. Best Regards, Thorsten.

Ok - no pots, but encoders; it's ok :) Best Regards, Thorsten.

Ok - no pots, but encoders; it's ok :) Best Regards, Thorsten.

Es freut mich zu hoeren, dass nun alles funktioniert :) Gruss, Thorsten.

Es freut mich zu hoeren, dass nun alles funktioniert :) Gruss, Thorsten.

This time from Matti (Finland). The great surface (on the right side!) has been made by himself with 3mm aliminum and endcheecks of Gaia-mahogany. Check also his homepage: http://gamedude.klaanit.net/~mle/

This time from Matti (Finland). The great surface (on the right side!) has been made by himself with 3mm aliminum and endcheecks of Gaia-mahogany. Check also his homepage: http://gamedude.klaanit.net/~mle/

Dimitris: I will support a 40x2 LCD anyhow, but this solution isn't the best, since 15 characters have to be removed. :-/ The graphical LCD should contain a ks0107b / ks0108b controller. Thats a very common chip for cheap displays. It cannot handle with characters by itself; the command set supports "set address" and "write 8-pixel" and thats all. However, I will get my display end of week and will check the performance :) Best Regards, Thorsten.

Hi, there is a very trivial and fast solution which allows you to solve the problem with little effort from my side, and thats the lookup-table method. It works on this way: the controller gets the x and y position of the joysticks and fetches the corresponding radius and angle from two large tables with 128x128 values. 2*128*128 = 32kByte --- thats exactly the capacity of a BankStick. :) Which modules are required for this project: a core module a JDM module (but you could also ask your friends to burn the PIC) a AINX2 (-> 16 inputs, premade PCB not available) or AINX4 (-> 4 inputs, premade PCB available) a BankStick a modified MIDIbox64 firmware which converts the values automatically a special dump file for the BankStick, which can be transfered via MIDI and the joysticks of course Best Regards, Thorsten.

Hi, there is a very trivial and fast solution which allows you to solve the problem with little effort from my side, and thats the lookup-table method. It works on this way: the controller gets the x and y position of the joysticks and fetches the corresponding radius and angle from two large tables with 128x128 values. 2*128*128 = 32kByte --- thats exactly the capacity of a BankStick. :) Which modules are required for this project: a core module a JDM module (but you could also ask your friends to burn the PIC) a AINX2 (-> 16 inputs, premade PCB not available) or AINX4 (-> 4 inputs, premade PCB available) a BankStick a modified MIDIbox64 firmware which converts the values automatically a special dump file for the BankStick, which can be transfered via MIDI and the joysticks of course Best Regards, Thorsten.

Yes, definitely! :) On this way we can save a lot of unnecessary pots/buttons/LEDs and the poly mode configuration (where all three voices should have the same values) will be easier. And all pots will get an optional soft-overtake feature in order to prevent parameter jumps. :) Best Regards, Thorsten.

Yes, definitely! :) On this way we can save a lot of unnecessary pots/buttons/LEDs and the poly mode configuration (where all three voices should have the same values) will be easier. And all pots will get an optional soft-overtake feature in order to prevent parameter jumps. :) Best Regards, Thorsten.

Hi Frank, thanks again for testing! :) The LED-ring-pattern (0-3) is selected by logic itself, it's coded in the returned CC and therefore cannot be assigned to the encoder like in other ENC_MODE_*'s. However, you are able to change the LED pattern itself. Best Regards, Thorsten.

Hi Frank, thanks again for testing! :) The LED-ring-pattern (0-3) is selected by logic itself, it's coded in the returned CC and therefore cannot be assigned to the encoder like in other ENC_MODE_*'s. However, you are able to change the LED pattern itself. Best Regards, Thorsten.

...but please keep in mind that I'm planning a special firmware for a dedicated SID control surface which allows to control the SID parameters more ergonomically. I will publish the final layout for the panel w/ pots/encoders/display/buttons/LEDs in january, when I've time enough to think about a perfect solution. Not every parameter will become it's dedicated pot or button, some can be combined, and together with a LCD<->pot/encoder/button interaction tweaking the sounds will finally make more fun! :) In the meantime you could use the Java editor and maybe a MIDIbox with 16 pots or more to access the most important parameters w/o the mouse. Best Regards, Thorsten.

...but please keep in mind that I'm planning a special firmware for a dedicated SID control surface which allows to control the SID parameters more ergonomically. I will publish the final layout for the panel w/ pots/encoders/display/buttons/LEDs in january, when I've time enough to think about a perfect solution. Not every parameter will become it's dedicated pot or button, some can be combined, and together with a LCD<->pot/encoder/button interaction tweaking the sounds will finally make more fun! :) In the meantime you could use the Java editor and maybe a MIDIbox with 16 pots or more to access the most important parameters w/o the mouse. Best Regards, Thorsten.

Here are the new files with more dedicated features for the LC emulation: http://www.ucapps.de/midibox16e/midibox16e_v1004pre2.hex.zip http://www.ucapps.de/midibox_mf/midibox_mf_v1000pre2.hex.zip http://www.ucapps.de/midibox/mk_syx.zip New features: o support for LED-rings in LC emulation o support for MIDIbox Link (only tested in LC mode yet) o LED shift registers can be mapped to different functions Currently both firmwares can only be configured with the mk_syx script. From the .ini files: ################################################################################ # MIDI Merger: enable the merger in order to forward the incoming MIDI # events to the MIDI Out. A must if you would like to plug a keyboard # on the MIDI In, or if you want to cascade MIDIboxes # Allowed Keywords: # disabled don't use merger at all # enabled merges all external with internal events # mblink_fp MIDIbox Link Forwarding Point: like a common MIDI merger, # but internal events will be framed so that a MIDIbox Link # End Point can distinguish between a event which has been # sent by a common MIDI device and events which have been # generated by a MIDIbox # mblink_ep MIDIbox Link End Point: merges only external events # from a MBLink FP (Forwarding Point) ################################################################################ [MIDI_MERGER] enabled See also this posting: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1038961702 ################################################################################ # LED Map: assignes the LED shift registers to the Button Shift # registers or special values # Currently following values are supported: # 0 Default Setting (see Map below) # 1 Button Shift Register 1 (Button ID #1-#8) # 2 Button Shift Register 2 (Button ID #9-#16) # 3 Button Shift Register 3 (F1-F4 and Navigation Buttons: ID #17-#24) # 4 Button Shift Register 4 (Button ID #25-#32) # 5 Button Shift Register 5 (Button ID #33-#40) # 6 Button Shift Register 6 (Button ID #41-#48) # 7 Button Shift Register 7 (Button ID #49-#56) # 8 Button Shift Register 8 (Button ID #57-#64) # 9 Internal Bank (1 of 8) # 10 External Bank (1 of 8) # 11-15 reserved # 16 MIDI Status received for Button ID #1-#8 ([MIDI_LEDS] must be enabled!) # 17 MIDI Status received for Button ID #9-#16 ([MIDI_LEDS] must be enabled!) # 18 MIDI Status received for Button ID #17-#24 ([MIDI_LEDS] must be enabled!) # 19 MIDI Status received for Button ID #25-#32 ([MIDI_LEDS] must be enabled!) # 20 MIDI Status received for Button ID #33-#40 ([MIDI_LEDS] must be enabled!) # 21 MIDI Status received for Button ID #41-#48 ([MIDI_LEDS] must be enabled!) # 22 MIDI Status received for Button ID #49-#56 ([MIDI_LEDS] must be enabled!) # 23 MIDI Status received for Button ID #57-#64 ([MIDI_LEDS] must be enabled!) # 24-31 reserved ################################################################################ [LED_MAP] LED_SR1 = 1 # (Button ID #1-#8) LED_SR2 = 2 # (Button ID #9-#16) LED_SR3 = 3 # (F1-F4 and Navigation Buttons: ID #17-#24) LED_SR4 = 4 # (Button ID #57-#64) LED_SR5 = 5 # (Button ID #25-#32) LED_SR6 = 6 # (Button ID #33-#40) LED_SR7 = 7 # (Button ID #41-#48) LED_SR8 = 8 # (Button ID #49-#56) A more practical example can be found in the midibox16e_lc.ini and midibox_mf_lc.ini files Some words to the LC emulation with multiple core modules: the LC_EMULATION_ID should only be set for the last MIDIbox in the chain - the "MIDIbox Link End Point". All other MIDIboxes should work in common mode and configured as "MIDIbox Link Forwarding Point" Example: a chained MIDIbox16E and MIDIbox MF should be configured on this way: # MIDIbox16e .ini file # ... [MIDI_MERGER] mblink_fp # ... [LC_EMULATION_ID] 00 # ... # MIDIbox MF .ini file # ... [MIDI_MERGER] mblink_ep # ... [LC_EMULATION_ID] 10 # or 14 for Mackie Control emulation # ... Best Regards, Thorsten.

Here are the new files with more dedicated features for the LC emulation: http://www.ucapps.de/midibox16e/midibox16e_v1004pre2.hex.zip http://www.ucapps.de/midibox_mf/midibox_mf_v1000pre2.hex.zip http://www.ucapps.de/midibox/mk_syx.zip New features: o support for LED-rings in LC emulation o support for MIDIbox Link (only tested in LC mode yet) o LED shift registers can be mapped to different functions Currently both firmwares can only be configured with the mk_syx script. From the .ini files: ################################################################################ # MIDI Merger: enable the merger in order to forward the incoming MIDI # events to the MIDI Out. A must if you would like to plug a keyboard # on the MIDI In, or if you want to cascade MIDIboxes # Allowed Keywords: # disabled don't use merger at all # enabled merges all external with internal events # mblink_fp MIDIbox Link Forwarding Point: like a common MIDI merger, # but internal events will be framed so that a MIDIbox Link # End Point can distinguish between a event which has been # sent by a common MIDI device and events which have been # generated by a MIDIbox # mblink_ep MIDIbox Link End Point: merges only external events # from a MBLink FP (Forwarding Point) ################################################################################ [MIDI_MERGER] enabled See also this posting: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1038961702 ################################################################################ # LED Map: assignes the LED shift registers to the Button Shift # registers or special values # Currently following values are supported: # 0 Default Setting (see Map below) # 1 Button Shift Register 1 (Button ID #1-#8) # 2 Button Shift Register 2 (Button ID #9-#16) # 3 Button Shift Register 3 (F1-F4 and Navigation Buttons: ID #17-#24) # 4 Button Shift Register 4 (Button ID #25-#32) # 5 Button Shift Register 5 (Button ID #33-#40) # 6 Button Shift Register 6 (Button ID #41-#48) # 7 Button Shift Register 7 (Button ID #49-#56) # 8 Button Shift Register 8 (Button ID #57-#64) # 9 Internal Bank (1 of 8) # 10 External Bank (1 of 8) # 11-15 reserved # 16 MIDI Status received for Button ID #1-#8 ([MIDI_LEDS] must be enabled!) # 17 MIDI Status received for Button ID #9-#16 ([MIDI_LEDS] must be enabled!) # 18 MIDI Status received for Button ID #17-#24 ([MIDI_LEDS] must be enabled!) # 19 MIDI Status received for Button ID #25-#32 ([MIDI_LEDS] must be enabled!) # 20 MIDI Status received for Button ID #33-#40 ([MIDI_LEDS] must be enabled!) # 21 MIDI Status received for Button ID #41-#48 ([MIDI_LEDS] must be enabled!) # 22 MIDI Status received for Button ID #49-#56 ([MIDI_LEDS] must be enabled!) # 23 MIDI Status received for Button ID #57-#64 ([MIDI_LEDS] must be enabled!) # 24-31 reserved ################################################################################ [LED_MAP] LED_SR1 = 1 # (Button ID #1-#8) LED_SR2 = 2 # (Button ID #9-#16) LED_SR3 = 3 # (F1-F4 and Navigation Buttons: ID #17-#24) LED_SR4 = 4 # (Button ID #57-#64) LED_SR5 = 5 # (Button ID #25-#32) LED_SR6 = 6 # (Button ID #33-#40) LED_SR7 = 7 # (Button ID #41-#48) LED_SR8 = 8 # (Button ID #49-#56) A more practical example can be found in the midibox16e_lc.ini and midibox_mf_lc.ini files Some words to the LC emulation with multiple core modules: the LC_EMULATION_ID should only be set for the last MIDIbox in the chain - the "MIDIbox Link End Point". All other MIDIboxes should work in common mode and configured as "MIDIbox Link Forwarding Point" Example: a chained MIDIbox16E and MIDIbox MF should be configured on this way: # MIDIbox16e .ini file # ... [MIDI_MERGER] mblink_fp # ... [LC_EMULATION_ID] 00 # ... # MIDIbox MF .ini file # ... [MIDI_MERGER] mblink_ep # ... [LC_EMULATION_ID] 10 # or 14 for Mackie Control emulation # ... Best Regards, Thorsten.

Germans say "Not macht erfinderisch" (if you really desire for a solution, you will make the best inventions ;-)) The software handler for the graphic LCD requires some memory to save the bitmaps and characters, I will try to integrate this into the MIDImon firmware since it already has some free space for such extensions. Yes, the MIDIbox NG will also support graphic displays in form of a PlugIn Best Regards, Thorsten.

Hi Pete, thats a simple job for the MIDIO128 --- with digital inputs. Reed switches are working like common buttons, they just close a connection. Therefore they can be connected to the DIN module without additional components. Best Regards, Thorsten. P.S.: don't forget to take a photo from your project for my MIDIbox gallery! :)

Hi Pete, thats a simple job for the MIDIO128 --- with digital inputs. Reed switches are working like common buttons, they just close a connection. Therefore they can be connected to the DIN module without additional components. Best Regards, Thorsten. P.S.: don't forget to take a photo from your project for my MIDIbox gallery! :)

Hi, your inputs are welcome! :) Your website is very interesting; hard to believe that such issues have not been fixed yet, in spite of your detailed descriptions. It seems that Steinberg isn't interested in improving the Houston driver anymore (or in other words: the devlopers left the company or they are doing something else), on the other hand it would be interesting of the integration of Mackie Control into Cubase really succeeded. Ok, you will test it :) I'm interested if the faders are really sending MIDI values with a 10-bit resolution (what is the minimum increment value when the fader is moved softly), and if the faders are moved with the same resolution from the application (I don't think so). Also the sending speed would be interesting; I mean: how much values will be sent when a fader is manually moved up and down very quickly (this could be recorded in a MIDI file to have a time reference and compared with my results). Btw.: I read on your website: and the top 5-6mm of travel is 'dead' (so 6dB is reached around the half-way point between 4 and 6dB on the Houston's front panel). I noticed the same with the LC emulation when the faders control the volume, which is displayed in dB. When I assign the fader to a MIDI value instead, the whole range is used for values between 0-127 My recommendation is to wait 2 or 3 weeks, until more people have tested the new firmwares and until all issues have been solved. Two core modules should be ok for a simple emulation without v-pots Best Regards, Thorsten.

Hi, your inputs are welcome! :) Your website is very interesting; hard to believe that such issues have not been fixed yet, in spite of your detailed descriptions. It seems that Steinberg isn't interested in improving the Houston driver anymore (or in other words: the devlopers left the company or they are doing something else), on the other hand it would be interesting of the integration of Mackie Control into Cubase really succeeded. Ok, you will test it :) I'm interested if the faders are really sending MIDI values with a 10-bit resolution (what is the minimum increment value when the fader is moved softly), and if the faders are moved with the same resolution from the application (I don't think so). Also the sending speed would be interesting; I mean: how much values will be sent when a fader is manually moved up and down very quickly (this could be recorded in a MIDI file to have a time reference and compared with my results). Btw.: I read on your website: and the top 5-6mm of travel is 'dead' (so 6dB is reached around the half-way point between 4 and 6dB on the Houston's front panel). I noticed the same with the LC emulation when the faders control the volume, which is displayed in dB. When I assign the fader to a MIDI value instead, the whole range is used for values between 0-127 My recommendation is to wait 2 or 3 weeks, until more people have tested the new firmwares and until all issues have been solved. Two core modules should be ok for a simple emulation without v-pots Best Regards, Thorsten.

Hi Frank, today (ooops - yesterday) I built a nice 32 LED/Button module which allows me to play with the LC emulation more ergonomically: I finally noticed the same strange behaviour and found a way to fix it. With the new release, it is possible to map the LED shift registers to different functions, so that you can decide if the LEDs should only be controlled by the button handler, or only from the host application via MIDI. Remark: all buttons should be in On/Off mode, Logic/Cubase handle the toggle function by itself, and sometimes the LEDs flash on special events. I.e., the mute LEDs are flashing in solo mode) LCD display: I will try it next week. It makes sense to support both solution: a cheap & dirty 40x2 LCD driver, and a graphic display solution (which also isn't perfect but still cheaper when a dedicated 55x2 LCD) Best Regards, Thorsten. Best Regards, Thorsten.