TK.

These are good news indeed! It means that the two 10bit based calibration tables could be stored into the embedded flash memory of the PIC, so that no additional SW or HW is required. What I also could provide is a small perl script which generates a look-up table based on given points: Build process would be: - adapt and generate the table in/with the perl script -> this will generate an include file - rebuild the mbhp_mf_ng firmware with a PIC assember - upload the new firmware (.hex file) with MIOS Studio The whole update process will take ca. 30 seconds... fast enough to try out various settings. Required tools: perl (scripting language), gputils (PIC assembler), text editor And if you would install "gnuplot" on your computer as well, the perl script would spit out a diagram with the calibration curve as shown above It's a pulse of n*1 uS (n = touch sensor sensitivity value) which is triggered each mS I'm unsure if/how this could be filtered. You could start with caps against ground at pin #27 (RD4) of the PIC (this is the pulse output) Best Regards, Thorsten.

This LCD should work. I would propose to install the lcd_interconnection_test, which can be downloaded from http://www.ucapps.de/mios_download.html See the README.txt of this .zip package for test procedure details. Note that D0..D3 won't output the voltage, because PIC18F4685 accesses the LCD in 4bit mode Best Regards, Thorsten.

It's definitely not possible to feedback the CS parameters to an external device or to LED rings, regardless if they are driven by MBSID itself or values are output via MIDI. Too much code would be required, I'm not really interested to implement this, and I'm even not sure if there would be enough code memory free for such a feature... Best Regards, Thorsten.

Ok, this explains why I haven't noticed this issue yet... I will check this soon. Best Regards, Thorsten.

As mentioned before, USB host mode doesn't fit into the 16k bootloader range, there is no need to try this out - it won't work. Accordingly, code upload via USB host won't work as well. Bootloader update application != bootloader. So: whenever you want to upload code via MIDI, you've to connect the STM32F4 USB port directly to your PC Best Regards, Thorsten. P.S.: I just have improved the MIOS32_DONT_USE_USB_HOST switch, so that it excludes parts of the STM32F4 driver - bootloader should fit into memory again (with support for USB MIDI Device mode only...)

That's very unlikely, because this caused a short circuit for the complete unit. It's possible to damage a LCD if it's plugged in the wrong direction into the socket, but I guess that you haven't done this. Which LCD are you using exactly? (I remember that Wilba provided two different types) Best Regards, Thorsten.

Ok, so this only doesn't work with drum tracks, but it works with common tracks, right? Best Regards, Thorsten.

Compile & upload this application: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_midi_4x4%2F Third MIDI port working? -> compare the mios32_config.h file of this application with your one. Third MIDI port not working? -> hardware connections wrong Best Regards, Thorsten.

Yes and no. Yes: a code upload won't be possible, because the Bootloader doesn't support USB Host (not enough memory available in the 16k boot section) No: MIOS Studio contacts the core via SysEx messages, which should also be possible via a USB device which is connected to your PC/Mac via another MIDI interface. I just tried following setup: - MBHP_CORE_STM32 USB connected to a GM5x5x5 - MIDI IN1/OUT1 of the GM5x5x5 connected to MIDI OUT1/IN1 of a second GM5x5x5 - the second GM5x5x5 is connected to my Mac After a robustness update in the MIOS32 USB MIDI Host driver a Query and terminal access are possible! :smile: Please update your repository to get the changes Best Regards, Thorsten.

Ok, I will add a function which allows to disable all track and layer mutes They are working at my side. Could it be that you are using a special track configuration without velocity parameter layer? Best Regards, Thorsten.

Since you know how to build MIOS32 applications by yourself, it's sufficient to update the SVN snapshot :) Best Regards, Thorsten.

It was an interesting experiment anyhow. Yes, of course it works :smile: But if the STM32F4 Discovery board is powered by the Debug USB Socket, the Micro-USB will only output ca. 4.3V which is not enough for the GM5 Solution: plug a 5V PSU to J2 of the MBHP_CORE_STM32F4 module, and let the USB PWR jumper J17 stuffed: All 5 MIDI IOs of the GM5 are recognized, and can be used for MIDI message processing. Best Regards, Thorsten.

@3: not relevant anymore, because you confirmed that the animation stops after 3 seconds... MIOS is installed @1: the most likely reason why the LCD doesn't work No, there is no concrete target temperature - the voltage regulators get hot, that's normal! Best Regards, Thorsten.

This was a nice challenge for the weekend: I implemented a driver for USB MIDI Host mode into MIOS32 for STM32F4 :smile: (LPC17 and STM32F103 don't support USB Host mode...) Tested with following devices: CME X-Key: Waldorf Blofeld: MIDIbox (here MIDIbox SEQ V4L): Ploytec GM5x5x5 USB MIDI Host mode just replaces USB MIDI Device mode via the USB OTG socket. The update will be available with all future MIOS32 applications, it's always available without special configuration. A special USB Micro-B -> USB 2.0-A adapter is required to connect the MIDI device. Such an adapter is for example available at Reichelt (DELOCK 83183) for 5 EUR: http://www.reichelt.de/DELOCK-83183/3/index.html?&ACTION=3&LA=446&ARTICLE=126860&artnr=DELOCK+83183&SEARCH=DELOCK+83183 Pluck this adapter into the Micro-USB socket of the STM32F4-Discovery board, reset (or power-cycle) the core, and MIOS32 will automatically switch to USB Host mode. Limitations: - USB hubs are not supported, the MIDI device has to be connected directly. - USB based Power-Supply is weak (limited to ca. 200..300 mA), which means that it might be required to power the MIDI Device with an external PSU - the MBHP_CORE_STM32F4 module has to be powered from the USB debug socket Please let me know if you are interested to beta-test this enhancement, I could provide a preliminary version of a MIOS32 application. Best Regards, Thorsten

Hi Sebastian, filter ranges will be more time consuming than processing more than 16 MIDI router nodes. The number could be increased in the mios32_config.h file, e.g.: #define MIDI_ROUTER_NUM_NODES 32 this requires to recompile the application. Do you know how to do this? Best Regards, Thorsten.

This sounds like you are complaining me that encoders can't be "simulated" via SysEx or NRPN... :-/ It shouldn't be so difficult to add a pragmatic solution as long as it doesn't need to be documented, because I guess that you are they only guy who is interested on such a remote control... Note that feedback won't be possible (too difficult to implement) - means: you won't be able to send the current values to MBNG, e.g. for LCD display or LED ring updates. Best Regards, Thorsten.

Hi, the LCD behaves this way if: 1) it isn't connected properly (e.g. because of bad solder joints) 2) it isn't compatible to the 4bit access mode (no problem if you got the LCD from Wilba) 3) you haven't installed MIOS yet - this has to be done before the MIDIbox SID application will be installed If you are unsure, just install again the latest (public beta) versions which are linked here: But you are saying that the LEDs are somehow animated - this is the normal behaviour during boot. After ca. 3 seconds the animation will stop, right? If it does stop: then MIOS and the application has been installed correctly - the error must be somewhere else (probably topic 1) It's normal that the voltage regulators get hot, therefore they have a heat sink Best Regards, Thorsten.

For MBNG the limit has been relaxed to 32 DINs and 32 DOUTs Btw.: meanwhile there are also new methods which allow to connect the modules over long distances by using RS-422 like line drivers: http://www.ucapps.de/mbhp/line_drivers.pdf Not really, RaspPi has been made to run Linux, and no "bare metal" applications which give you direct (fast!) access to many IO pins and interfaces. MBHP_CORE_STM32F4 is superior for MIDIfication purposes compared to such SoC architectures. Best Regards, Thorsten.

Thank you! :) Best Regards, Thorsten.

There is actually a very smart way: read the newbie documentation... ;-) -> http://www.ucapps.de/mios32_bootstrap_newbies.html Quote: Depending on the OS you are using at the host side (Windows, MacOS, Linux) it might be required to restart MIOS Studio in order to connect to the "safe" USB interface port. Best Regards, Thorsten.

Yes, this is planned - I'm waiting for SmashTV, but he is currently extremely busy. Best Regards, Thorsten.

Ah, you are using the MBHP_MF_NG module standalone (without a MIOS32 based module where MIDIbox NG could run) - in this case forget my idea. Microcontrollers typically have an embedded flash memory. For a LPC17 or STM32F4 enough flash would be available, for the PIC we've two problems: it's much more time consuming to add code there (especially since the firmware is implemented in assembly language), and there is much less flash memory. Not enough for individual tables for all faders. The SD Card approach would only work, if a table could be loaded into RAM, but as mentioned earlier, neither a PIC, nor a typical MIOS32 compatible microcontroller (which you are not using anyhow...) would have enough for your intentions. This would require an interpolation routine which consumes too much CPU time on a PIC, especially when multiple faders have to be handled in parallel. In order to overcome the execution speed limitation, somebody would typically precalculate tables based on these "points" and store it in RAM... if enough would be available. Ok, if somebody would spend some hours or (depending on his programming skills) days on this topic, he could be able to achieve this regardless of the hardware limitations. But actually I'm not really interested on such a topic by myself, and sparetime is also not sufficiently available for such a "private" solution for you... In other words: I'm not trying to find a perfect solution, just something which consumes as less as possible effort at my side. Best Regards, Thorsten.

I created a quick&dirty documentation for the MBHP_MIDI_IO module today which also has a link to the Reichelt BOM (for Europeans who only order the PCBs): http://www.ucapps.de/mbhp_midi_io.html Outside Europe it's better to order the kits in SmashTV's shop Best Regards, Thorsten.

Great that this is finally solved :) I already feared that something was wrong in the release process... Btw.: is there a recording of your live show available? I'm very interested after listening to the sequences so often :thumbsup: Best Regards, Thorsten.

I just got an alternative idea - we could hard-code the tables into the MIDIbox NG application. In this case it will be programmed into flash memory. It would still require to compile the version at your side (because you've to adapt the tables) - with the MIOS32 toolchain based on this flow: http://www.midibox.org/dokuwiki/doku.php?id=macos_mios32_toolchain_core Currently there is around 200k free, but this would only be sufficient for 6 individual tables (mapping 14bit values) But: if the mapping tables would only consider 10bit resolution, the memory consumption would only be 2k per table Which means that individual tables for all faders are feasible. I guess that you wouldn't change a difference compared to 14bit anyhow, because the PIC ADCs convert at 10bit resolution. Best Regards, Thorsten.