TK.

Finally somebody discovered the STM32F4 Discovery adaptions... :wink: Yes, I used this evaluation board to check if it's worth to spend some more time for a proper MBHP integration. Please don't expect a public release this year, because in order to do it right many hardware related topics have to be considered; especially some hardware conflicts have to be solved (more about this topic below). Currently I don't have so much time to continue with this due to various business trips around the world. I will probably continue in September. On the other hand, hackers with some background knowledge would already be able to use this board for own experiments with MIOS32. For a kickstart: here the precompiled bootloader <removed> New page: http://www.ucapps.de/mbhp_core_stm32f4.html What is working so far: - system init, timers, interrupts, FreeRTOS, etc. - accessing the onboard LEDs - USB MIDI and UART based MIDI - code upload via MIOS Studio - I2S (@Niklasni: yes, even the onboard DAC is running, I tested it with apps/tutorials/024_i2s_synth) - SD Card access (but with common SPI) - SRIO - IIC (accessing the MBHP_IIC_MIDI module) What is not implemented yet: - ADC (because I haven't started with the adaption yet) - LCD (low prio, have to find some free pins which are not used for other purposes) - SW based SPI for J19 (have to find free pins, or maybe I will use a HW SPI for this..) and that's all ;-) Applications which are already running without issues (aside from the missing ADC, LCD and J19 support): - MIDIbox SEQ V4 - MIDIbox NG V1 - MIDIO128 V3 - MIDIbox CV V2 so - no real show stopper. But the hardware connectivity will be a challenge, because unfortunately some important pins - especially for UARTs - are allocated by onboard resources. E.g. although the chip contains 6 UARTs, many of them can't be used bidirectionally due to these conflicts. I don't understand, why ST doesn't integrate some more internal multiplexers for alternative connections... In other words: the usage of this board will have some limitations. The main advantage that I see: not only higher speed, but especially much more RAM! 192k instead of 64k (LPC1769, STM32F1) makes a big difference. I'm especially happy that MIOS32 applications like MBNG and MBSEQ can be easily upgraded with an inexpensive core module replacement in future! The onboard DAC and Cortex-M4 based DSP capabilities are also great for synths or Fx units of course, but I'm unsure if I will go into this direction by myself. Best Regards, Thorsten.

Hi Cesar, I've no experience with the CS10. No, you could buy a PIC with preprogrammed Bootloader and MIOS from SmashTV's shop: http://www.midibox-shop.com Once you built the core, you only have to upload the MBCV application anymore to complete the installation. Best Regards, Thorsten.

Pulses are very short (only 1 mS) - did you consider this? I just checked the Manual page, it works at my side. Or did you mean something else? Best Regards, Thorsten.

Hi Dave, I'm surprised, because when no SD Card is connected, the (MAX525) based AOUT module is selected by default. Please have a look into the DEFAULT.CV2 file (you can open it with the MIOS Filebrowser). Under "Misc Configuration" you will find the AOUT_Type, which has to be set to AOUT: # Misc. Configuration AOUT_Type;AOUT Sidenote: AOUT_NG users would set it to: # Misc. Configuration AOUT_Type;AOUT_NG After this change, enter "load default" in the MIOS Terminal to load the changed setup Yes, it should work this way! You could enter following commands into the MIOS Terminal to set a AOUT pin: caliaout 1 middle caliaout 1 max caliaout 1 min caliaout off I just have tested this at my side - it (still) works. :smile: Btw.: if you have a SCS (Standard Control Surface with 2x20 LCD, 1 encoder and 6 buttons), you could also test the calibration from in the AOUT page Best Regards, Thorsten.

Hi, yes, there is a simple way: you could replace the 470 ohm resistor R21 by 1k, this should increase the voltage range (see also LM317 datasheet how to calculate the resulting voltage range) this is very strange! It sounds like a faders have a resistance which is higher than 10k? Best Regards, Thorsten.

Hi, you could ask SmashTV to help you with the programming: http://www.midibox-shop.com Or maybe it's easier if he would sell you a preburned PIC16F88 Best Regards, Thorsten.

Hi, you could use another LED to test this. See also this schematic: http://www.ucapps.de/mbhp/mbhp_usb_gm5.pdf Just connect the cathode via a 220 resistor with ground, and the anode with pin 13 of the GM5 chip. You don't need to solder this connection, just tap it on the pin while GM5 sends some data. Best Regards, Thorsten.

Wow! The guy doesn't know what he is selling there! ;-) Good catch! Best Regards, Thorsten.

You are the first who reports this; actually nobody reported issues with the updated USB handler yet, especially when the "single USB" option is activated if Windows doesn't like multiple USB ports. Could it be that due to experiments in the past the Windows USB driver is wrongly configured (or corrupted)? What happens, if you uninstall the driver (can be done somewhere in the windows hardware settings, right-click on the MIOS32 USB device and remove it)? After the driver has been removed, just disconnect the USB cable, and connect it again. Windows should re-install the driver thereafter with proper settings. Best Regards, Thorsten.

Hi George, this is strange! Are you using a special USB MIDI driver (could be problematic), or the M$ legacy driver which comes with WinXP? It would also be interesting, if the upload is working if the core is in "boot hold" mode (close jumper J27, re-connect the USB MIDI cable, and re-open MIOS Studio) Btw.: which MBSEQ V4L version is currently installed on your core? Best Regards, Thorsten.

No, especially for users of the legacy-frontpanel which doesn't provide group LEDs and buttons, the LEDs have to display the group in this screen. It's consistent from my point of view: the track buttons select the group in this page, accordingly the track LEDs should display the according function as well, otherwise this wouldn't be consistent. So: no special treatment between legacy and wilba's frontpanel, nothing special to configure or understand, no hidden switches and no obscure options to be set in the HWCFG file. Best Regards, Thorsten.

SI is an uncritical signal, because it goes from a single 74HC165 output to a single input of the core, and it's already at 5V... SC and RC are the critical outputs from the core, because they go to multiple 74HC595 and 74HC165 pins Best Regards, Thorsten.

Hi, No, you don't need these pull-up resistors if the MBHP_MF_NG module is permanently connected to your MBNG yes! If you use this configuration example, the application can be uploaded via the USB3 port (because it has been configured as "config_port"): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_cc.ngc Best Regards, Thorsten.

"BLM J9 SI" doesn't need to be buffered, remove this line. J8 and J9 RC and SC are both output pins, it seems that you handled one RC and one SC line as inputs instead - change this connection. I would propose to have a look into the MBHP_CORE_LPC17 schematic again, it's a very simple circuit! Best Regards, Thorsten.

Could it be that you haven't found this page yet: http://www.ucapps.de/midibox_osc.html :smile: MIOS Studio contains an OSC monitor as well. It also allows you to send OSC messages. But take care: it seems that I haven't reserved enough stack memory for the OSC thread. OSC messages are sent without issues, but once an once MBNG receives a matching event, the application will crash. I will fix this in the next release. > Is there a way of "inserting" a monitor to observe a 2-way interaction? (I'll have to experiment) I'm using the integrated UDP monitor of the MBNG app for this purpose. This monitor is described under http://www.ucapps.de/midibox_osc.html as well Best Regards, Thorsten.

Yes, and various usage models are supported. They are listed here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fsyxtxt.ngc -> http://www.asciitohex.com Best Regards, Thorsten.

I haven't continued to work on the MBSID V3 firmware in the last years, because of more interesting projects where I see more potential. Best Regards, Thorsten.

You could use the same 74HCT541 based buffer circuit like known from the MBHP_CORE_LPC17 module: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf Btw.: this chip would also allow you to buffer J19 for your AOUT module properly. Best Regards, Thorsten.

Hi Joerg, welcome on board! Yes, we know each other from the time where I grew up in Hesse! I guess that you are planning to build a MIDIbox SID, right? :) MIOS Studio is a Juce based application, I fear that they don't support "vintage" operating systems anymore. On the other hand, it works well with all popular OS today. Best Regards, Thorsten.

Working again in v1.026 Best Regards, Thorsten.

@Norbert: hopefully this release will help to solve the issue :) MIDIbox NG V1.026 ~~~~~~~~~~~~~~~~~ o support for nrpn_format=MsbOnly (e.g. for MBSEQ V4 NRPNs) o new EVENT parameter ain_sensor_mode: With ain_sensor_mode=NoteOnOff, AIN and AINSER events, which are assigned to Note events, send velocity 0 before a new Note is sent with velocity > 0 to avoid hanging notes. With ain_sensor_mode=None (default if no sensor mode specified), Note events will be generated as a continuous stream like CCs Best Regards, Thorsten.

Did you already notice this page: http://www.ucapps.de/mios8_c.html ? There is an example how LEDs can be controlled via MIDI. Best Regards, Thorsten.

actually I don't like such hidden double functions (and other users don't like them as well). In addition, I think that by selecting the 4 tracks at one with the common track buttons will take less than 2 seconds, and should be more intuitive. Is this really wanted? Actually I thought, that there are people who always use follow mode by default. In this case, such a notification would be annoying won't work properly in slave mode, where the sequencer still follows the master clock position. Therefore I disabled this (intentionally) Best Regards, Thorsten.

Cool! :) The VU meters are still on my TODO list. They are received as aftertouch events, but I have to implement a special pattern mode to decode them properly. Best Regards, Thorsten.

You won't be able to get rid of the jitter, it's caused by the bad analog supply of the LPCXPRESSO. Since you are using a second core with a MBNG as well, you could use a AINSER8 or AINSER64 based analog input instead -> much better results! Best Regards, Thorsten.