TK.

Nothing changed, this feature is already available in MBSEQ V3. But of course, due to the high variety of functions (and alternative solutions), there are always certain features worth to discover :) Best Regards, Thorsten.

No, it isn't 1:1, see also http://www.ucapps.de/mbhp/mbhp_lcd_mios8.pdf and http://www.ucapps.de/mbhp/mbhp_core_v3.pdf What surprises me: when you are running the lcd_interconnection_test and measure the voltages, you should notice the discrepancy! Best Regards, Thorsten.

When you swap J2:A0 and J2:A1, you also have to swap the motor control outputs (J3 and J4) It's a servo loop... Best Regards, Thorsten.

What do you mean with "nothing happened"? You've triggered different MIDI notes, but always measured 0V at the LCD pins? Best Regards, Thorsten.

Does the voltage at RA0 against ground toggle between 0V and 5V? Best Regards, Thorsten.

All values are in the expected range, even B- (which is the backlight voltage) I've no idea what else could cause the problem. Best Regards, Thorsten.

There are so many helpful C courses available in the internet... did you ever google for "C kurs"? E.g. I entered "C kurs arrays", and this was the first hit: http://www.peace-software.de/ckurs8.html However, if you want to write a value into all items of an array, write: { int i; for(i=0; i<10; ++i) NteBuf0 = 0; } Best Regards, Thorsten.

Unfortunately it isn't possible to control all parameters with MBNG, because this application doesn't allow you to change individual bits of a SysEx parameters (e.g. for waveform control). Programming the logic in a dedicated C based application is the only way for a perfect solution for this synth beast ;) Best Regards, Thorsten.

Did you already try the lcd_interconnection_test? Best Regards, Thorsten.

You can't upload a program in USB Host mode, because the upload takes place in the bootloader! Upload process: - MIOS Studio requests a reset, so that the bootloader will be started - Once the bootloader replied (which again can't work in host mode), MIOS Studio starts to upload the code Hope that this clarifies the reason why it doesn't make much sense to continue on this topic... While I developed the USB host mode, I always uploaded the application via USB MIDI in Device mode. It wasn't a big deal to: - remove the USB host cable - plug-in the USB device cable - press the black reset button so that MIOS32 reboots in device mode - press the upload button in MIOS Studio. Of course, under MacOS I've the big advantage that I don't need to restart MIOS Studio when the USB MIDI Device was temporary not available. If you are working under Windows, it might be required to restart MIOS Studio... Alternatively you could initiate the upload from the command line (see "mios_studio --help") to automate this. Or consider to develop your application without a USB Host connection, find another way to connect your MIDI device during the implementation phase, and use it only when you are not working with a computer (e.g. while making music... ;-) Best Regards, Thorsten.

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.