TK.

Hi Nervrem, great work so far - building the case is usually the most time consuming job! :) First of all I've to say that most MIDIbox projects are currently overworked for the new MBHP_CORE_LPC17 module, since it has so many advantages (e.g. you wouldn't need an external MIDI interface anymore, just use the USB-MIDI provided by the new core module) I already started to overwork some documentation to prewarn about the transition (e.g. I moved old MBHP modules which are not relevant anymore to a special "expired" page), but it will still take some weeks until the documentation is up-to-date again, and of course it will also take some additional weeks until the projects are ready for an official release. Therefore: if you want an up-to-date project, please wait for the release of MIDIbox NG, which will support the features of MIDIbox LC as well (and more). The parts should be ok Each encoder requires 2 DIN pins -> 8*2+30 buttons = 46 pins = 6 shift registers = 2 DINX4 For 37 LEDs you will need two DOUTX4 modules as well. You will need ribbon cable ("Flachbandkabel") See also this guide: http://www.midibox.org/users/jim_henry/building_a_midibox_lcd_cable.pdf No, but you should reserve an extra button for changing to a second button/LED assignment layer where you can select alternative functions. See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_lc_v1%2Fsrc%2Flc_io_table.inc (the function is called ID_MBLC_HOLD_LAYER) This will also be provided by the upcoming MIDIbox NG The new MBHP_MF_NG module is a standalone solution for controlling the motorfaders. The accuracy and flexibility is much better compared to the solution which is integrated into MIOS, as the PIC is doing nothing else than controlling the fader. In addition the calibration of each individual motorfader is much easier now, as it's supported by a GUI which is integrated into MIOS Studio. But: the MBHP_MF_NG module is not supported by the old PIC based MBLC, and I'm not planning to support this anymore as my own MBLC is already stuffed with a MBHP_CORE_LPC17 (MBHP_MF_NG will be connected to the third or fourth MIDI IO pair of MBHP_CORE_LPC17) You don't need it for MBLC (and it isn't supported anyhow) Maybe somebody else can help here. yes Best Regards, Thorsten.

Awesome work! Do you allow me to add this tune to the MBFM demos at my website? :) Best Regards, Thorsten.

Please ensure that you are using the latest MIOS32 Bootloader v1.007 and the latest MBSEQ version v4.049 - does it still happen? As a sidenote: it's now also possible to enable MSD mode from the MIOS Terminal (just type "msd") USB MIDI won't work anymore until you are rebooting the box, but it's a nice possibility to mount the SD Card without clicking to the Disk page ;) Best Regards, Thorsten.

I was able to reproduce the "error 10" issue after a lot of trials - the error simply happens if the USB device name hasn't been customized, Win7 doesn't like empty names... Since USB device name changes are permanent and won't be overwritten by bootloader updates, this issue was really hard to find ;) I also checked the SysEx issue with some new debugging methods, but without success: it's clearly a legacy driver issue. E.g. when I'm using MIDI-Ox and sending some MIDI events to trigger SysEx messages. The SysEx streams sent by the Core (regardless if STM32 or LPC17) get stucked after ca. 256 bytes, and they will be passed again (permanently) after the core has sent 256 additional bytes to the host. Since this issue can be reproduced with different USB driver implementations (STM32/LPC17) and different MIOS32 based buffer sizes, and since it can be reproduced outside MIOS Studio, it's very likely an issue in the Microsoft driver. Thanks again Gridracer for this great hint about the Korg driver. I made this topic sticky, and the workaround will be documented on my homepage soon! Best Regards, Thorsten.

vcfool: drum recording mode has to be adapted to the most recent changes (TODO) However, v4.049 provides following features: MIDIboxSEQ V4.049 ~~~~~~~~~~~~~~~~~ o support for MIDI OUT4 and MIDI IN4 Provided by MBHP_CORE_LPC17 module only. MIDI OUT4 is available at J4B.SD MIDI IN4 is available at J4B.SC o fixed USB issue under Win7 if the interface name hasn't been customized in bootloader [/code] Best Regards, Thorsten.

MIOS32 Bootloader V1.007 is available under http://www.ucapps.de/mios32_download.html With version v1.005 and v1.006 an empty USB device name was passed to the host if it hasn't been customized after the update. Windows7 doesn't like this - it reported "error 10" and didn't install the driver. After bootloader update, it's also required to install the most recent version of the application, therefore all apps have been re-released. If you build the binary by yourself: please update the SVN tree! Best Regards, Thorsten.

An enhanced MIDI/USB-MIDI/OSC Router which allows scripting is on my TODO list. The plan is to write a simple scripting language in a way so that it can be re-used for MBNG, but it would be easy to provide a standalone version as well of course... In order to configure the router, two lists have to be created. One list defines MIDI event formats, such as @1 NoteOn x x @2 NoteOn C-3 x @3 CC 1 x @4 CC x1 x2 @5 NRPN 123456 @6 PitchBend @7 SysEx F0 00 00 7E 4F 01 x1 x2 * F7 [/code] And a second list which defines the routing and wildcard replacement, such as [code] # USB1 All Channels > OUT2 All Channels % USB1 > OUT2 # USB1 Channel 1 > OUT2 Channel 1 % USB1.1 > OUT2.1 # USB1 All Channels > OUT2 Channel 1 % USB1 > OUT2.1 # USB1 Channel 1 CCs > OUT2 % USB1.1@4 > OUT2 # USB1 Channel 1 Modwheel CC > OUT2 Channel 16 % USB1.1@3 > OUT2.1 # CCs received from any port will be forwarded to OUT4 % ALL > OUT4 # Receive 14bit PitchBender from IN1, convert to NRPN and send to OUT2 % IN1@6 > OUT2@5 # Receive 14bit PitchBender from IN4, convert to SysEx and send to OUT4 % IN4@6 > OUT4@7 It might look a bit cryptic, but the advantage of this syntax is, that it forces the user to code the routing so that it can be easily parsed and translated with very low latency. For MBNG the even definitions can be re-used for button/LED/encoder/pot assignments. Another advantage is, that the routing can be changed independent from event definitions. This would allow (beside of reading definitions from SD Card) limited support for runtime editing on control surface based on the SCS (Standard Control Surface, see MIDIO128) Editing events on this interface would be too time consuming, but routing could be changed quickly without mounting the SD Card on a computer. Later an advanced version could even allow filtering and pipelining! :) # Forward all events from IN4 except for CC Modelwheel to OUT4 % IN4!@3 > OUT4 # and convert ModWheel to PitchBender % IN4@3 > OUT4@6 # pipelining % IN4@3 | dosomeprocessingstuff | dosomemoreprocessingstuff > OUT4 [/code] Best Regards, Thorsten.

OUT4 and IN4 were placeholders. Since you are not the first one who asks for this, I finally enhanced the UART driver for OUT4 and IN4. It will be available for MBHP_CORE_LPC17 at J4B (which is intended as second IIC port, but can be alternatively used as fourth MIDI port) MIDI Out is available at J4B.SD, MIDI IN at J4B.SC The fourth MIDI IO isn't supported by MBHP_CORE_STM32 The pull-up resistors can be removed, but this isn't necessary: If you are using an optocoupler circuit, and already soldered R10/R9: add another 2.2k in parallel to R10, this results into 1.1k which is ok Best Regards, Thorsten.

I will try to reproduce this soon by installing different bootloader versions. With v1.005 I had to change the descriptors for MacOS Lion, before this change it was slightly invalid (but allowed to use a COM driver in parallel), now it should be fully compliant... strange. I hope that this hasn't made it incompatible to Win7 (on the other hand: it works on my Win7 business laptop) Best Regards, Thorsten.

Shipped today: Ilmenator Protosx Smidirin Chrisk Stools Sold out! :) Best Regards, Thorsten.

Shipped today: Altitude Raphael discotsoutsouni Waiting for money: kok6 Sidmonster In Stock: 0 GM5 chips (sold out) 34 PCBs (+2 reserved) Best Regards, Thorsten.

They are from Gold Phoenix Best Regards, Thorsten.

Thank you for this information. I'm a bit surprised, but removed the reference to the 74HCT595 from the schematic before trying to understand the reason. ;) Background: other users probably never noticed issues, since the 74HC595 is recommended in the part list, simply because the 74HCT595 can't be ordered from Reichelt. Even I only own 74HC595 devices and was never able to test this with a 74HCT595. On the other hand I was reading somewhere that 74HCT is more suitable for conversion to TTL level (5V)... I also checked input level requirements, and output level ranges, it looked plausible. Apparently I overlooked something... However, in the last months it has been proven with the STM32 module, that the 74HC595 works fine for 3.3V -> 5V level conversion. Therefore it's now the only recommended solution. Best Regards, Thorsten.

Thank you for providing a long-term source for the new board! :) Best Regards, Thorsten.

These are really great news! Once more people have confirmed that this solution is working, I will document this at the MIOS Studio page. :) Btw.: which bootloader version are you currently using - was the "error code 10" also reported by older versions, or is this a new issue? Best Regards, Thorsten.

The PCBs are sold out now! I will ship in ca. 1..2 days once I got the money from everybody. Meanwhile I also created a Reichelt Orderlist which can be downloaded from http://www.ucapps.de/mbhp_mf_ng.html Best Regards, Thorsten.

Yes, since it's very unusual that one side doesn't display characters anymore, it's very likely trash now. :-/ Best Regards, Thorsten.

thanks for the input! :) I replaced C3 by 1000 uF, and added C4=100 nF Best Regards, Thorsten.

Wow, really!?! :) This was a "blind" change without testing on a WinXP computer, I'm glad that this solves the issue :) Best Regards, Thorsten.

V4.048 is available for download now. :) From the ChangeLog: MIDIboxSEQ V4.048 ~~~~~~~~~~~~~~~~~ o CC and PitchBender values only send on value changes anymore to save MIDI bandwith on high-speed tracks o Step record: simplified usage of poly mode. Now the step is automatically cleared when all keys were released and new notes are entered. o Step record: duration (note length) will now be recorded as well! o Live record: some improvements for the "forward MIDI" option o MSD mode (SD Card Reader) can now also be enabled with the "msd" command in MIOS Terminal o Move step: doesn't overwrite new selection anymore [/code] Best Regards, Thorsten.

Yes - after two hours trying to install/patch a newer xcircuit version, I gave up and created these schematics with the old version: http://www.ucapps.de/mbhp_i2s.html Best Regards, Thorsten.

Hi, this feature isn't supported in MBSEQ V3 It is supported in MBSEQ V4 (-> live page) - here you can even apply MIDI effects on incoming events :) Best Regards, Thorsten.

I guess that he tries to use the USB interface, but the upload fails. And it seems that it doesn't fail with a common MIDI interface (this was a helpful test) Sparx: could you please try this new bootloader version v1.006: http://www.ucapps.de/mios32/mios32_bootloader_v1_006.zip I increased the buffer sizes, and a helpful debug message is print if less bytes are received than expected. Is the upload working with this version? Are messages print in the MIOS Terminal? (if yes: which ones exactly?) Best Regards, Thorsten.

Could you please try it on a different computer? This would be important to get an understanding if the issue is related to the computer itself, or to the core module. Best Regards, Thorsten.

Which operating system are you using? How is the core powered? Does it also happen if your are booting the core in BSL Hold mode (J27 jumper stuffed) Does it also happen when you are using an USB hub with external PSU, or if you power the core via J1 (remove J17 jumper in this case) Best Regards, Thorsten.