TK.

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.

In theory it is possible, but it's a lot of work and no success guarantee. You probably won't be able to simply take over performance hungry synth features which might be added by somebody else, therefore it's normally a more clever to spend +14EUR for a second core. Best Regards, Thorsten.

Yes, a lot of features have been added to the Jam page in the last months. :) If you want to get immediate feedback of the recorded notes, you've to enable the "Fwd." switch (-> MIDI forwarding) Best Regards, Thorsten.

I'm glad that we solved this! :) Best Regards, Thorsten.

I adapted the sample rate so that it matches with the original project. This is probably the better way anyhow, e.g. to get equal envelope slope times. Currently the waveform calculation takes 35 uS on a STM32F4, it's triggered each 113 uS, which means that the CPU is only loaded by ca. 30% However, I'm not planning to extend the synth from my side, I only did the adaption in order to allow somebody else to take this as a basis for further developments. :smile: A prebuild binary is now on the server as well (-> release/STM32F407VG/project.hex) You can download the files with a subversion client (google for good clients which are provided for your preferred OS) Once you installed the client, take following URL: svn://svnmios.midibox.org/mios32 Alternatively check this page how to install the toolchain, so that you are able to build the firmware by yourself: http://www.ucapps.de/mios32_c.html Best Regards, Thorsten.

Alright - no problem, this was a nice challenge (something like a text adventure ;-) Desoldering will be extremely time consuming, and there is a higher danger that tracks will be damaged and the circuit won't work anymore without fixes. It's probably easier if you would cut some tracks with a sharp knife, and re-connect them with short wires. Best Regards, Thorsten.

I've an assumption: there isn't a problem with the smaller footprint, but the circuit behaves like if the upper two pins of the button are not connected internally. If you follow the D0 track in the schematic, you will see what I mean: it goes from U2 to GP7, GP5, GP3 and GP1 via the buttons. The datasheet says that the internal connection exists: https://www.e-switch.com/system/asset/product_line/data_sheet/143/TL1100.pdf (pin 3/4 and 1/2 are connected together), but somehow this isn't the case at your side...? You could check if this assumption is true by soldering a short wire at the upper two button pins of all GP buttons (start with GP7, and check if GP5 is working thereafter) No wire is required for the two lower pins. Best Regards, Thorsten.

Could you please do an electrical continuity check? E.g. with an ohmmeter or a "beeper". See also following schematic where I marked the interesting measurement points for the GP1 button: direct download: http://www.ucapps.de/tmp/wilba_pcb_check_matrix.png All 5 "D0" points should be connected, as well as the 4 marked "M5" points. In addition it would be interesting if the "din_testmode" shows a message if you connect D0 of U2 (this is a 74HC165) with M5 of U7 (this is a 74HC595) with a short cable. This should trigger the "Pin M5 D0" message. Best Regards, Thorsten.