TK.

I don't understand the actual problem, but to answer your questions: For which purpose do you want to set the router configuration? No, MIOS Studio can only display the messages which are received/sent from/to the selected MIDI IN/OUT port. It can't display the messages which are received/sent at the core side. Best Regards, Thorsten.

Thanks for the hint! :) I was already aware, that cortex-m4 is currently not selected. The reason is, that the current MIOS32 toolchain consists of an older gcc version which doesn't support this CPU type. We've to update the toolchain to a newer gcc version first before doing this change in common.mk. As long as this hasn't been done (it will require some kind of "qualification" for existing apps, because a compiler change typically causes SW issues; e.g. it happened recently http://midibox.org/forums/topic/13137-midibox-seq-v4-release-feedback/?p=157642'>here) just install any other toolchain and change common.mk locally (like you already did) Best Regards, Thorsten.

yes, because it takes more time to load a patch from EEPROM or BankStick (ca. 20..100 mS) than new MIDI events can be received (each 640 uS) This problem can't be solved at the firmware side, it's a hardware limitation. Best Regards, Thorsten.

The new assignments are working at my side without problems. the old mixer map content will get lost as long as you don't store it. need more details how to reproduce this. more details required as well... Best Regards, Thorsten.

Thanks for the feedback! :) Best Regards, Thorsten.

The configuration name isn't stored in the EEPROM. In other words: it isn't possible. Best Regards, Thorsten.

I can't reproduce this, it works at my side. So: how can I help you? Your .ngc file would be useful to know, and more details about your hardware setup, and what you tried out so far. Best Regards, Thorsten.

Hi, for the MBNG application this is normal, the LED is toggled with a very high frequency so that it looks like it's permanently lit. So, the issue is probably not related to the core module. Are you sure, that the ribbon cable is connected correctly? E.g. as far as I remember, a continuous stream will be generated if the cable is cable is plugged in the reversed direction into the socket. These pictures might help to doublecheck this (they are for a different module, but with the same socket polarity): http://www.ucapps.de/mbhp/mbhp_dio_matrix_7.jpg http://www.ucapps.de/mbhp/mbhp_dio_matrix_8.jpg Best Regards, Thorsten.

Because PC keyboards don't have inbuilt LEDs for each button? Best Regards, Thorsten.

Hi, (note that I've no time to give explicit help till September) A .NGR script would give you much more control over the bank handling, especially the new "set_active" command. This is a beta feature, a precompiled binary (and some details) can be found in this thread: Hope this somehow helps (although it probably didn't answer your question) Best Regards, Thorsten.

Hi, (note that I've no time to give explicit help till September) it looks like the pitchbender sending routine expects either a 7bit (range 0:127), or a 14bit value (range 0:16383). Other value ranges are not properly handled. I could change this sooner or later, but until then please use a 14bit value range. (crossing my fingers, that this one is working - currently I can't test it...) Best Regards, Thorsten.

I never tried it with a PIC18F4620 by myself. Which setup file are you using? It would be especially helpful to know, if the WAVETABLES_IN_RAM switch is enabled or not, and how it works if you take the inverted value. Best Regards, Thorsten.

Hallo Roman, zwei Dinge verstehe ich nicht: warum verwendest Du fuer den range=64:64 zwei Events? Und warum werden diese beiden Events dann an zwei weitere Events weitergeleitet? Momentan bewirkt Deine Konfiguration folgendes: BUTTON id=1: Button #1 sendet (und empfaengt) CC#68 Wert 0 BUTTON id=16: Button #16 sendet (und empfaengt) CC#68 Wert 64 und leitet den Wert an SENDER id=16 weiter BUTTON id=15: Button #15 sendet (und empfaengt) ebenfalls CC#68 Wert 64 und leitet den Wert an SENDER id=15 weiter Die beiden Sender sollen nun aus dem Button Wert 64 irgendwie ein on/off ableiten - doch warum so umstaendlich? Fragen ueber Fragen... ;) Ich wuerde es ja bei BUTTON id=1 und id=15 belassen, und die LEDs direkt mit diesen Events schalten (via fwd_id=LED:7 bzw. fwd_id=LED:8) Ein Button Event kann ja auch Werte empfangen - insofern sehe ich hier kein Problem. Gruss, Thorsten.

In MIOS8/MIOS32 muss man den Encoder-Handler nicht von Hand programmieren, das ist schon alles eingebaut. Hier das Programmierbeispiel fuer MIOS8: http://www.ucapps.de/mios_c_send_enc_rel.html Und hier fuer MIOS32 (just for completeness): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F014_enc_relative%2Fapp.c Im MIOS8 Tutorial die ENC_NotifyChange Funktion ersetzen durch: void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam { MIOS_MIDI_TxBufferPut(0x90); // Note On at MIDI Channel #1 MIOS_MIDI_TxBufferPut(incrementer > 0 ? 0x3d : 0x3c); // different note depending on direction MIOS_MIDI_TxBufferPut(0x7f); // full velocity } Gruss, Thorsten.

Hallo Roman, einen Keller haette ich nun auch gerne... ;) Meinst Du wirklich 1.012 (die letzte offizielle Release) oder 1.013? Ich kann mich daran erinnern, dass 1.012 das "single_usb" Flag falsch angezeigt hat. Es koennte also sein, dass es aktiv ist, in Wirklichkeit siehst Du jedoch das aktuelle "fast_boot" flag. Dies wurde in dieser (noch nicht releasten) Version gefixt: http://www.ucapps.de/mios32/mios32_bootloader_v1_013_pre2.zip Gruss, Thorsten.

Hi, you've to setup a negative delay for the track which sends the CC (this is possible in Logic Studio since many years, I don't know if Reaper provides a similar function). If such a delay (in mS) can't be defined, then just send the CC one 128th note earlier. The CC especially has to be sent before the MIDI clock, otherwise MBSEQ V4 can't change the pattern on-time for obvious reasons. Best Regards, Thorsten.

Still looks correct, still would need some testing at my side (which I can't do this week...) Well, do you rely on the mackie protocol, or are you able to send your own (customized) SysEx strings in the DAW? Best Regards, Thorsten.

Alright, could you please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_027_pre2.zip A snapshot now passes values like if they have been received from a MIDI IN. I must admit, that I haven't tested this change - but I guess that you wanted to try out a quick solution ;) Best Regards, Thorsten.

Hm, strange... would probably need some debugging at my side, but this can take some time. On the other hand: as a workaround you could try to define two SysEx commands: one for the upper, another one for the lower line. Which EVENT definition are you currently using? Best Regards, Thorsten.

Very cool! I will make this topic sticky, because many people asked for a solution in the past, and your approach looks so simple! Also thanks for the video which perfectly demonstrates the advantage. :) Best Regards, Thorsten.

Hi Bibi, the formatting could take some seconds, how long did you wait? Unfortunately I would need your SD card with the original content in order to reproduce the issue for the case that the formatting routine doesn't work under certain conditions. Best Regards, Thorsten.

Hi Andy, STM32 is a bit different compared to LPC17, therefore probably the confusion. In distance to LPC17, the STM32F1xx family supports open drain mode for UART outputs, which is the preferred option for MIDI (because a MIDI line is a current loop). Accordingly, no buffer should be used, instead just create exactly this circuit: http://ucapps.de/mbhp/mbhp_core_stm32_midi3_extension.pdf Btw.: you will also notice, that MIDI OUT3 is on J5B.A6 for STM32, while it's on J5B.A7 for LPC17. For LPC17 actually no buffer is required as well, but certain (vintage) MIDI equipment doesn't work properly at 3.3V voltage level (although MIDI data transmission shouldn't rely on the level, only on the current draw...). So, for the case that you want to support LPC17, and if a free buffer is available, then connect the input to J5B.A7, the output to the "data pin" of the MIDI OUT socket via 220 Ohm, and the "supply pin" of the MIDI OUT socket via 220 Ohm to 5V. Best Regards, Thorsten.

This is the schematic which shows the 74HCT541 based level shifter at J28: http://www.ucapps.de/mbhp/mbhp_core_lpc17_output_buffers.pdf The usage of this chip is not only recommended for voltage adaption, but also to protect the LPC17 IO pins against short circuits. Best Regards, Thorsten.

It seems that the MIDI output of your keyboard somehow violates the MIDI protocol, otherwise I've no explanation why two (independent) MIDI parsers can't handle the stream correctly and raise an error message. It could also be, that MIDI-Ox is a more tolerant - but for proper merging 100% compliancy is required. Which MIDI keyboard are you using exactly? And could you please search for alternative MIDI monitors? Maybe one of them displays the MIDI stream in a way which allows to identify the violation. (for the case that you own a STM32 or LPC17 based core: I could give you a monitor which displays the incoming data in text format in the MIOS terminal) Best Regards, Thorsten.

Cool! :) The interface is set to AOUT by default now, and the annoying performance debug message is disabled as well. Best Regards, Thorsten.