TK.

Thanks for the reminder, but it isn't implemented yet The firmware is currently in a phase where I had to do some hotfixes and need feedback from users if the existing functions are still working correctly. Please help me to test the latest firmware with your MIDIbox: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre7.zip Best Regards, Thorsten.

Another guide can be found in the "First Steps" tutorial: http://www.ucapps.de/midibox_sid_manual_fs.html Topic "Wavetable sequencer" Best Regards, Thorsten.

Are you still trying to run the v2 firmware on a PIC18F452? This can't work, because this chip has only 1/3 of the memory of a PIC18F4685, which means that a majority of the firmware is missing (I'm surprised that anything is working... ;-) So: once you are using a PIC18F4685, patches can be uploaded with the SysEx Librarian which is integrated into MIOS Studio. Best Regards, Thorsten.

Andy, please don't tease us so much, we are waiting for some pictures of the prototype! :) Best Regards, Thorsten.

Hi, please follow the guidelines which can be found at this page: http://www.ucapps.de/mbhp_core_lpc17.html Topic "Installing the MIOS32 Bootloader". It recommends the usage of an older version, download link is in the guide. yes, the device address is selected with jumpers, so that exactly the same firmware can be flashed into the PICs. See also http://www.ucapps.de/mbhp_iic_midi.html Topic "Configuration and Interconnections" the fuse settings are embedded in the .hex file, your programming software should automatically take them. Just to doublecheck: which fuse settings are displayed by the programmer when you are loading the .hex file? Best Regards, Thorsten.

The circuit behaves the same way like the standard low-active button matrix: http://www.ucapps.de/mbhp/mbhp_din_8x8buttons.pdf It doesn't matter if the diodes are at the upper or lower side of the button... Only the polarity is important, and it's matching with my schematic. The error is somewhere else... Best Regards, Thorsten.

Is your switch matrix working with high-active, or low-active signals? A more complete schematic would help. Best Regards, Thorsten.

I added a "--duggle" flag which will allow to collect your special request before turning them into official features. Currently it only avoids the rescan message. Suppressing all notification pop ups: this isn't a "tiny feature" anymore, because actually you request an alternative textual messaging interface... this would result into a lot of code changes & testing for different modes (GUI, GUI with batch jobs at startup, pure textual batch mode) I also don't know how to print colours under Windows... Quick request, huge work at my side for something that I wouldn't use by myself -> rejected. Or you are only asking to avoid the "Batch job complete" message? According to the source code it will only pop up if "--batch" hasn't been specified in the command line: } else if( job.startsWithIgnoreCase("quit") ) { if( runningInBatchMode() ) { #ifdef _WIN32 std::cout << "Press <enter> to quit console." << std::endl; while (GetAsyncKeyState(VK_RETURN) & 0x8000) {} while (!(GetAsyncKeyState(VK_RETURN) & 0x8000)) {} #endif JUCEApplication::getInstance()->setApplicationReturnValue(0); // no error JUCEApplication::quit(); } else { AlertWindow::showMessageBox(AlertWindow::InfoIcon, T("Info"), T("All batch jobs executed."), String::empty); } Windows users have to press the enter key in order to ensure that status messages won't get lost (because Windows will close the window afterwards). So: do you want to avoid the need to press a key in order to get all status messages because you are sure that they are not relevant in your case? Or do you only want to avoid this if the GUI is started with a batch job during startup, but not in "--batch" mode? Best Regards, Thorsten.

It should be possible in conjunction with an external I2S DAC: http://www.ucapps.de/mbhp_i2s.html Best Regards, Thorsten.

Ooof.. this means that the complete documentation has to be overworked (pictures, etc.) Any other people request this extension? Best Regards, Thorsten.

Most files under mios32/LPC17xx define IO pinnings which maybe have to be adapted depending on the board layout. Best Regards, Thorsten.

Based on your observations it looks like MIOS32_TIMER_ReInit (unintentionally) triggers an interrupt. Which core module are you using? And does it also happen if MIOS32_Timer_ReInit() is only called on interval changes? E.g. write: static u32 lastInterval = 0; u32 interval = 50000; // could also be a global variable, controlled by app if( interval != lastInterval ) { lastInterval = interval; MIOS32_TIMER_ReInit(1, interval); } Best Regards, Thorsten. Best Regards, Thorsten.

The signal level at digital input pins is usually 5V, pulled up by 10k resistors -> logic level 1 By closing a switch/button, this input will be connected with ground through the diode -> logic level 0 The diodes ensure that one button doesn't influence the signal level of other buttons. Best Regards, Thorsten.

The communication should also work with OSC messages sent via the MBHP_ETH module: -> http://www.ucapps.de/midibox_osc.html Best Regards, Thorsten.

I need more information to understand (and/or reproduce) the problem. - how is the core module supplied? Did you already check voltages (e.g. ca. 5V between Vs and Vd at the DIN/DOUT modules?) - could you please show a picture of your hardware? This may describe more than 100 words... ;) - enter "set debug on" in MIOS terminal, then trigger the crash - which messages are displayed? - your .NGC file might also help to understand the configuration. Best Regards, Thorsten.

great! :) Best Regards, Thorsten.

Hi, the conversion is working, but I guess that you haven't configured the MBHP_MF_NG module correctly yet. It's required to select the "Emulated Motormix" protocol, see also http://www.ucapps.de/mios_studio/mios_studio_mbhp_mf_ng_tool.png I also recommend you to use a different config_port. Currently you've selected USB1, which means that the original event (two CCs once you selected the right protocol) will be forwarded to USB1 together with the NoteOn event. But actually you only want to forward the NoteOn event, right? So, itÄ's better to use USB2, USB3 or USB4 as config port Best Regards, Thorsten.

*IMPORTANT*: you've to enable the "spi_midi" switch in the bootloader as described here: http://www.ucapps.de/mios32_bootstrap_newbies.html Without this option MIOS32 won't start the communication with the KissBox OEM! The MIDI routing is done in APP_MIDI_NotifyPackage(), currently you will find following code: void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package) { switch( port & 0xf0 ) { case SPIM0: { MIOS32_MIDI_SendDebugMessage("SPIM%d: %08x", port & 0x0f, midi_package.ALL); if( midi_package.type == 1 ) { // -> kissbox messages are sent to terminal TERMINAL_KissboxReceiveMsgPackage(midi_package); } else { // -> all other messages are forwarded to the USB port MIOS32_MIDI_SendPackage(USB0 + (port & 0x0f), midi_package); } } break; default: if( midi_package.type >= 8 && midi_package.type <= 0xe ) { MIOS32_MIDI_SendPackage(SPIM0 + (port & 0x0f), midi_package); } } } which means: whenever MIDI messages are received from SPIM0..SPIM15, a debug message will be print out, and the MIDI message will be forwarded to USB0..USB15 whenever MIDI messages are received from any other port, such as USB or UART, they are forwarded to the SPI So, the MIDI1..4 -> SPI forwarding should already work In order to forward SPI to MIDI1..4, just replace USB0 by UART0 -> done However, if there is a functional problem with the KissBox OEM, Benoit has to help you on the troubleshooting; MIOS32 just handles the SPI transfer, but the more complicated part is at the KissBox OEM side. Best Regards, Thorsten.

The brightness won't be good enough with this method, because (I assume) that you still want to multiplex the LEDs. It's possible to set the RGB value of all LEDs which belong to the DOUT matrix row with up to 8 dim levels (actually a feature that you requested some time ago!), but hues for individual LEDs of a meter are not supported. See also mbng_matrix.c: if( item->flags.led_matrix_pattern == MBNG_EVENT_LED_MATRIX_PATTERN_LC_AUTO ) { if( item->rgb.ALL ) { MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.r); MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.g); MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, item->rgb.b); } else { MBNG_MATRIX_DOUT_PatternSet_LC(matrix, item->flags.colour, row, item->value, NUM_MATRIX_DIM_LEVELS-1); } it would be required to overwork the concept how patterns are defined The RGB pattern feature would also cost some memory, therefore it could only be supported for STM32F4 Alternatively just hack your ideas into the code ;-) Best Regards, Thorsten.

Hallo, hast Du bei Deinem Monitor die richtige Baudrate und das richtige Protokoll eingestellt? (31250 baud, 1 start bit, 8 bits payload, 1 stop bit, keine paritaet) Gruss, Thorsten.

It looks like the synth app is running. The goom synth has to be configured via CCs to output some audible sound. The other users might be able to help you on this, here the corresponding thread: Best Regards, Thorsten.

Hi Duog, this was easy to implement in the dedicated "MIDIbox LC" application, but somehow it conflicts with the concepts behind MBNG. There are actually two problems, one has been solved. 1) (the solved one): meter values have to be decoded, and they have to be animated (!) - the protocol expects that each 300 mS the meter value is decremented by 1 until 0 is reached again. Mackie implemented this to save some MIDI transfer overhead. This is implemented in mbng_event.c (search for LCMeter) and can be used for LED matrices 2) (the unsolved one): animated bars haven't been considered in the display output routine. An extension is required which handles the meters like a frequently updated display element. It's probably easier just to provide such a feature as a single, configurable display element with following parameters: X/Y position, number of bars to be displayed, horizontal or vertical representation, offset between the bars Best Regards, Thorsten.

It might be possible for V4L with some (simple) app extensions, but not for V4 since Lemur can't display LCD contents. The virtual MBSEQ V4 runs only under MacOS. Unfortunately it doesn't work anymore with the latest MacOS changes due to a incompatibility with PYMIDI. Actually it should be rewritten so that it uses Juce as a framework, so that it would also run under Linux and Windows, but this is some work (and I'm still searching for a skilled programmer who could take it over :smile:) Best Regards, Thorsten.

Hi, did you also upload the hwcfg/wilba/MBSEQ_HW.V4 file into the root directory of the SD Card? Without this special configuration neither buttons, nor LEDs will work. strange! The timeout indicates that something is received, but that the incoming MIDI stream is corrupted. Does this even happen if no MIDI device is connected to the board? This board has to be connected to J4A - are you sure that the ribbon cable is connected correctly? Which app are you trying exactly? It seems that it hasn't been prepared for STM32F4 Best Regards, Thorsten.

See also http://www.ucapps.de/midibox_seq_manual_fp.html - search for "ALL" NEW since v4.074: if the ALL button is active (regardless if pushed or not), and the encoder of an unselected step is moved, the editor will generate a ramp between the selected step and the moved encoder. Another possibility for this behaviour could be a lose contact on your ALL button, so that it isn't permanently active when you are pushing it. In this case values will only change with relative increments. Best Regards, Thorsten.