TK.

Hi, yes, you can use the same board, but since LPC17 Tx pins are working at 3.3V level (and not in push-pull mode), you've to change some resistor values: R3, R5, R8 and R10 have to be 47 Ohm. And J1:Vd has to be connected to 3.3V Best Regards, Thorsten.

No spam, keep up the great work - I enjoy each new video! :smile: Best Regards, Thorsten.

This is strange indeed! I will check this tomorrow - if I haven't success, I will add a debug mode which will give you some logs for further debugging. yes, very likely. This isn't intended, I will change this. You can never have enough diodes for the next projects! However, fixed ;) Best Regards, Thorsten.

Yes, I second Pete's hint: the cursor addresses are different compared to "common" LCD sizes. But the cursor mapping has to be done at the application side, e.g. via MIOS32_LCD_CursorMapSet See also: http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#g1d34ecba2a96a80c9bb8b1ee757b4fdf So: if your application doesn't use $MIOS32_PATH/modules/scs, the proposed define won't help. In your application you can either do this statically by calling MIOS32_LCD_CursorMapSet w/o conditions, or you could request the configured LCD dimensions from the bootloader section. Use this MIOS32_LCD_ParametersGet function for this purpose: http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#gd2ee61cebc910769c800afe4c6e281bd This will return following parameters: http://www.midibox.org/mios32/manual/structmios32__lcd__parameters__t.html Best Regards, Thorsten.

Ok, please try this firmware: http://www.ucapps.de/mbhp/mbhp_mf_ng_v1_005.zip Once installed, follow the instructions of this README.txt: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmbhp_mf_ng%2Ftools%2FREADME.txt I will officially release this version if you can confirm that it's working at your side. Best Regards, Thorsten.

Ok, this obsoletes all other questions and now I understand what you did. This of course reduces the scan frequency by x * 1 mS, results into 32 mS (as you've mentioned) and if you are saying that there is a HUGE improvement then let it like it is, everything else will overcomplicate the project. I've to add that this was a clever idea! I haven't expected that the pulse is weak enough so that it will be filtered out on lower frequencies! :) This hasn't been forgotten... but please be a little bit more patient. Before giving you any code I've to test it, because everything which hasn't been tested typically doesn't work due to unexpected reasons, especially when I'm doing changes in code that I wrote many years ago! You can try this in the terminal: perl -version perl isn't installed if this command won't be found. There is no limitation, because the perl script will do the calculation work, the PIC will only process pre-made tables. Best Regards, Thorsten.

No, totally wrong... Without going into too much detail: this would work in MIOS32 projects where the SRIO is scanned via SPI, but it doesn't work on a PIC where the SRIO is scanned directly from the PIC via bit-bangning. This is done each mS, the number of SRIOs doesn't change this. And if somebody would try to reduce the timer period for the bit-banging routine, the PIC would be busy with scanning the SRIO, but wouldn't be able to do anything else (-> no motor control). So, forget this change please, embedded programming is sometimes not straightforward, you've to consider many limitations to come to a compromise which works in reality. I think that on a PIC the touch sensor handling can't be optimized anymore. MIOS_SRIO_NumberSet doesn't set the scan frequency, it sets the number of SRIO components modulo 16 Which means: 32 % 16 = 0 -> no SRIO is scanned anymore, no noise... but also no touchsensor scans, right? but you can compile in the terminal, right? (I don't use Xcode by myself, too complicated ;-)) Best Regards, Thorsten.

Juce ist the best choice for cross-platform; it's freely available, but meanwhile also used in commercial products. Best Regards, Thorsten.

Thanks! I removed this artifact - the file selection & program/verify is explained two pictures above. Best Regards, Thorsten.

Wow, der Sound ist wirklich super! Best Regards, Thorsten.

Implemented in V4.084 (select current track with NRPN MSB=127) Best Regards, Thorsten.

Implemented in V4.084 Best Regards, Thorsten.

V4.084 is now available for download: http://www.ucapps.de/mios32_download.html Changes: MIDIboxSEQ V4.084 ~~~~~~~~~~~~~~~~~ o the STM32F4 variant of the firmware supports USB Host mode! See also o If Force-to-Scale is enabled, the edit screen shows the forced keys at the lower line. The original value is still displayed at the upper right line. o Live Page: FTS (Force-To-Scale) not applied on drum tracks anymore o Options Page: added new option which enforces Force-To-Scale for BLM16x16+X Grid Edit mode o Euclid Generator Page: velocities are re-generated automatically whenever VelN or VelA value is changed o the optional RECORD button now toggles between RECORD and EDIT page (previously it only switched to the RECORD page) o Song page: new action "Unmute all" will unmute all tracks and parameter layers o Mixer: in the UTIL->Options page it's now possible to define if CC1, CC2, CC3, CC4 should be sent after or before the Program Change event. o NRPN MSB=127 allows to modify parameters of the currently selected track Best Regards, Thorsten.

The operation via USB is working fine, but I never tried it via the camera connection kit. Are you able to send & receive MIDI events from other iPad apps? If not: there is a general problem with the camera connection kit. Best Regards, Thorsten.

No changes are required in any config file. IIC1*...IIC4* (the Asterisk) indicates, that the communication with the appr. IIC MIDI chips was failing. Please use the iic_midi diagnosis app for further debugging at the hardware side (connections, soldering joints, etc...) It can be found at the bottom of this page: http://www.ucapps.de/mios32_download.html Test procedure: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fiic_midi%2FREADME.txt Best Regards, Thorsten.

It's a trivial challenge, but with the danger that certain users could get the wrong impression that it's a useful option for existing applications ;) I wouldn't use it by myself... Best Regards, Thorsten.

WARNING: unsupported parameter in DOUT_MATRIX n=1 ... sr_dout_row=1 means: the sr_dout_row parameter doesn't exist. means: there is no shift register assigned to drive the rows. means: it makes sense to read in the documentation which parameter allows you to assign the shift register -> http://www.ucapps.de/midibox_ng_manual_ngc.html means: thereafter there is a higher chance that the LED matrix will work. Best Regards, Thorsten.

Btw.: the EVENT_LED "trick" isn't understood at my side, it should work properly without. And if now even such a simple DOUT matrix configuration doesn't work at your side (it looks correct), something seems to be totally wrong. Could it be, that you are using an (old) .NGR script which may overwrite certain configurations? You've edited the right file, and always checked that MBNG didn't report any error or warning during the upload & execution? Or you are using a modified firmware build which causes such problems? Which core module are you using btw.? Best Regards, Thorsten.

If you are not able to execute the Makefile, try to execute following command in the mbhp_mf_ng_v* directory directly: gpasm -p p18f452 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy setup_mbhp_mf_ng_standard.asm Best Regards, Thorsten.

Buy me a board, help to write the documentation and support the users who notice compatibility problems (e.g. missing or conflicting pins) with the recommended board, which is the regular STM32F407 STM32F4DISCOVERY I think that the "bigger" version is only interesting for a small number of persons who are aware of the compatibility issues, can handle that and write their own applications (so, people like you ;-)) Best Regards, Thorsten.

Thanks! Novski will send me his board, so that you will be able to use yours soon :) Best Regards, Thorsten.

The STM32F401 is very limited, most major applications (such as MBNG, MBSEQ) wouldn't fit into the small flash memory. However, before you throw it away, you could send it to me so that I can provide (and test) a MIOS32 variant for this chip for the case that somebody want's to use it for less complex applications like MIDIO128 Best Regards, Thorsten.

Try another hardware module (e.g. MBHP_DIN and DOUT module) after the beer ;) Best Regards, Thorsten.

Now documented in the header of this page: http://www.ucapps.de/midibox_ng_manual_lcd.html Best Regards, Thorsten.

The schematic looks correct. Maybe an electrical problem? Are you able to remove the button matrix from the remaining circuit? Then just connect the row selection signals (IC1 Pin 7, 6, 5) with the column inputs at IC2 with a cable, one after another. Each connection should trigger an individual MIDI event. If this doesn't work, connect an alternative DIN and DOUT module (or a MBHP_DIO_MATRIX if available) and check the same. This ensures that the matrix configuration is correct, and that you know where to continue debugging... Best Regards, Thorsten.