TK.

If you mean the EVENT based conditions specified in the .NGC file, please give me an example where this makes sense (and I might give you a counter example ;-) Best Regards, Thorsten.

Just write "if whatever > something then" resp. "if whatever >= something then" Best Regards, Thorsten.

Hi, did you already try to access the PIC via MIDI by using MIOS Studio? If this isn't working, it could be related to a power supply issue - check the supply voltages of the PIC (a "hard-reset" resp. re-installation requires that the PIC is properly powered, but very likely the PIC will run again once you clarified the basic infrastructure) Best Regards, Thorsten.

An up-to-date list can be found in the user documentation: http://www.ucapps.de/midibox_seq_manual_hw.html Best Regards, Thorsten.

I noticed that the last firmware version was released more than one year ago! Time to release a new one officially (after more than 20 beta versions): MIDIbox NG V1.033 ~~~~~~~~~~~~~~~~~ o with this release, .NGR scripts running on a STM32F4 are directly executed from RAM in a compressed format, and therefore they are significantly faster, so that they could even be used for timing critical operations. o added basic support for SPI_MIDI This feature requires an update to MIOS32 bootloader v1.018 In the bootloader update app, enter "set spi_midi 1" to enable the SPI MIDI device at J16 (RC2 chip select line). This will also disable the OSC ports via MBHP_ETH module, which is normally connected to this port. o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module). The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since each RGB LED can consume up to 20 mA!) Following meta event commands are available: - RgbLedClearAll (clears all LEDs) - RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255) - RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100) - RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100) Most simple way to test a LED strip: enter following command in MIOS Terminal ngr exec_meta RgbLedRainbow:9:100 (don''t forget to wear sunglasses, or start with brightness 20!!! ;-) o added EVENT_RGBLED See cfg/test/rgbled_1.ngc for usage examples o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLED o SRIO num_sr=<value> reconfiguration works correctly with DIN/DOUT matrices now o added "inverted=1" to EVENT_BUTTON and EVENT_LED o .NGR file: added "load <setup>" command which allows to switch to another setup (.NGC, .NGS, .NGR, ... files) o implemented new meta command "SendEvent" which allows to remote control one or more events from a single event within a given value range and direction. See cfg/test/metalrn.ngc for a usage example o implemented new meta command "LearnEvent" which allows to learn SendEvent based controller assignments during runtime. See cfg/test/metalrn.ngc for a usage example o added new meta command "SaveDelayedSnapshot:<seconds>" It will request to store a snapshot after at least the given seconds. o added new event type "NoteOnOff", which will send a NoteOff event immediately after NoteOn (resp. actually it will send Note On with velocity 0 for runtime event optimisation) o added possibility to calibrate the delay_slowest values for each individual key of a keyboard. New terminal commands: - set kb <1|2> key_calibration on: delay values will be measured (method described at the MIDIbox KB webpage) - set kb <1|2> key_calibration off: captured delay values will be used: (<measured-delay> * delay_slowest / 1000) - set kb <1|2> key_calibration clean: shows the captured measurement values - set kb <1|2> key_calibration_value <key> <value>: allows to modify a calibration value directly - kb <1|2> delays: shows the measured delay values o keyboard calibration values are stored in a new file: .NGK, and can also be edited there o bugfix for DELAY_MS o bugfix for fwd_id to a non-existing ID with specific value o bugfix for maps with duplicated values o bugfix for sporadic file access errors reported during snapshot restoreThe documentation has been updated as well Best Regards, Thorsten.

Well done and nicely documented! :) The assembly code remembers me on the cycle accurate hacks that I did for MBHP_TV years ago - it's a nice experience to work on this level, as long as users don't start with enhancement requests ;-) But it seems that your solution is simple & powerful enough to satisfy requests at host level :) Best Regards, Thorsten.

Fine that the module is working now! :) To align the MIDI notes, please search in the documentation for "note_offset" and "din_key_offset": http://www.ucapps.de/midibox_kb.html Best Regards, Thorsten.

While reading your posting an idea came into my mind: the PIC device configuration (which comes with the MIOS bootloader) is preconfigured with a brown-out reset detection at 4.5V, which means if the supply voltage falls below this limit, the PIC will be reset, although it also works at lower ranges. I selected this high BORV setting to ensure, that for example an ongoing IIC EEPROM programming operation will be interrupted (by resetting the PIC) before the external device is outside the valid voltage range during power-off - this could lead to data corruption. But the BLM16x16+X doesn't access external EEPROMs, so actually the BORV could be lowered to 2.89V or even 2.14V Unfortunately this can only be done with a PIC programmer. Best Regards, Thorsten.

Notes shouldn't be wiped out as long as no key is played on the external keyboard. See also this video: https://www.youtube.com/watch?v=6gRD_GLHbJM Maybe this happened while you disconnected the keyboard, or changed the MIDI channel, so that MBSEQ didn't receive the Note Off events? Best Regards, Thorsten.

Does it make a difference if you replace the 8 100 ohm resistors by 220 ohm? 100 Ohm has been selected in the original circuit since the LEDs are driven from 3.3V pins - but in your case they are driven from 5V pins which could lead to these ghosting effects. Best Regards, Thorsten.

No, it won't help. The problem is, that the TPD has many DOUT shift registers, but only a single DIN shift register (as far as I remember). This results into an unbalanced serial output which leads to trouble when another module with DIN/DOUT registers (such as the BLM16x4) is connected. So - this kind of module will only work at the end of a serial chain, or with some buffering (and some luck) - it's a complex topic, I can't give you a fool-proven solution without further analysis (and I won't have the time for this anyhow... ;-) Best Regards, Thorsten.

Update: at the bottom of the MBHP_DIO_MATRIX page you will find additional pictures: http://www.ucapps.de/mbhp_dio_matrix.html Best Regards, Thorsten.

Meanwhile I also think that something is wrong with the cables, resp. the sockets (but this is hard to determine based on the snapshots). The notch of the J8/9 socket on the core module should show to the outer border, the same for the DIO module. Here a picture: @Christian: can you confirm that the socket orientation of your board is the same like for the original MBHP_CORE_STM32F4 module? Best Regards, Thorsten.

It makes sense to upload the MIDIO128 application to doublecheck, if the inputs are really not working, or if it's related to a configuration problem. By default and without any special configuration, MIDIO128 will send a dedicated note event whenever an input pin is connected to ground. Best Regards, Thorsten.

No special setup is required on the MIDI router. I'm no keyboard expert and therefore can't give you reliable information how to connect this particular hardware. But from the firmware side I think the most simple tests are the following: - turn off scan optimization (as mentioned above) - input test: connect a short cable from Vs (ground) to I0 -> up to 8 Note On messages should be sent. Note Off messages will be sent when the cable is removed. Repeat this test for the remaining inputs (J3:I0..I7 and J4:I0..I7) With this test, no proper break/make scheme is applied, and in worst case inputs stay at break and won't sent a note anymore - so, reset the core before repeating the next tests. - output test: instead of connecting I0 to ground, just connect it to O7/O6 via diodes (O7=make, O6=break; break has to be activated first; make sends the note). Only a single note on/off message should be sent. This can be repeated for the remaining output pairs. Best Regards, Thorsten.

Could you please check with the "testaoutpin" command if the control signals also go to the DIN/SCLK/FS pin of the TLV5630? (pin 2/3/4) - if this is the case, the problem must be on the AOUT_NG board. Check all supply pins (GND and VDD pins), something seems to be wrong there. If still no luck, we can't exclude that the chip is defective. Best Regards, Thorsten.

Added to the wish list Best Regards, Thorsten.

Problem happens when the MIDIbox SID firmware hasn't been installed on the slave cores. See also: http://www.ucapps.de/midibox_sid_manual_in.html CAN interface will only work if all connected cores actively listen to the bus. Cloning is only possible on further firmware updates Best Regards, Thorsten.

Hi, welcome on board! :) I added your request to the wish list. It's very unlikely that it will be available for MBHP_CORE_LPC17 because of reduced RAM, but it could be made available for MBHP_CORE_STM32F4 Best Regards, Thorsten.

Turn off the optimization to ensure that all pins are scanned while connecting Ox to Ix pins: set kb 1 optimized off Best Regards, Thorsten.

From the notch which is marked with a 1, count the pins counter-clockwise. You will notice that the 7th pin is marked with 7, which gives you the confidence that the 10th pin must be the 4th from the left side of the chip, counted downwards. Best Regards, Thorsten.

I added this to the other requests in the wish list - it will be some effort to integrate such a mode into the existing architecture and GUI, therefore a quick implementation is very unlikely. Best Regards, Thorsten.

At a first glance I don't see a configuration error. However, I think that this combination can lead to unstable SRIO transfers because of the high number of SRIOs and different chain lengths of the DIN/DOUT SRs. This would also explain, why the BLM acts strange. A prober solution to overcome this problem is MBHP_LINE_DRIVER: http://www.ucapps.de/mbhp_line_driver.html I don't know how exactly your hardware looks like, but if the TPD is close to the wilba frontpanel, then it's sufficient to connect the transmitter/receiver between TPD and BLM4x16 Best Regards, Thorsten.

This page describes how to format a SD Card from MBSEQ (sdcard_format command), and how to upload the right MBSEQ_HW.V4 file: -> http://www.ucapps.de/midibox_seq_manual_in.html Best Regards, Thorsten.

Currently there s no auto-save function, but by storing the patch the learnt messages will be persistent. This can be done from the DISK menu page (via SCS) or from MIOS Terminal Best Regards, Thorsten.