TK.

I definitely would like to have such a feature as well, but haven't found a way to react on the cursor up/down movements in a single-line TextEditor object yet. Does anybody know how this could be done? Best Regards, Thorsten.

This needs some work in the display output routine in MBNG_EVENT_ReceiveSysEx() It will be difficult to find a proper solution which even covers your special case, but I could think about this in April. Best Regards, Thorsten.

Hallo Rolf, schau Dir mal meine Routine an: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_enc.c Hier gibt es noch zusaetzliche Plausibilitaetschecks, die sicherstellen, dass bspw. bei einer schnellen Drehung in eine bestimmte Richtung keine Events fuer die entgegengesetzte Richtung generiert werden. Dies koennte bspw. bei einer Prellung passieren, aber auch dann, wenn man den Encoder (viel) zu schnell dreht (ich scanne i.d.R ebenfalls mit 1 mS) // INC // plausibility check: when accelerator > 0xe0, exit if last event was a DEC // if non-detented encoder: only do anything if the state has actually changed Die verschiedenen Encoder-Typen sind unter http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_enc.h definiert. Die Codes definieren auch, auf welche Flanken getriggert wird: // if Bit N of ENC_MODE is set, according ENC_STAT triggers Do_Inc / Do_Dec // // Bit N 7 6 5 4 // ENC_STAT 8 E 7 1 // DEC <- <- <- <- // Pin A ____|-------|_______ // Pin B ________|-------|___ // INC -> -> -> -> // ENC_STAT 2 B D 4 // Bit N 0 1 2 3 // This method is based on ideas from Avogra Es hat sich herausgestellt, dass die ALPS STEC12E08 von Reichelt mit dem Code "0x22" unzuverlaessig arbeiten, mit "0x88" jedoch bestens zurechtkommen. Gruss, Thorsten.

Alright, now it's clear (you should have mentioned this earlier): since the MB64_PATCH functions also send the meta event, you will get an infinite loop. I remember that I had the same problem with the snapshot SFB, and I remember that I solved this by implementing a request flag mechanism in main.inc to ensure, that the patch is only sent once. So, new approach: write MB64_META_Handler bsf MB_STAT2, MB_STAT2_PWR_SNAPSHOT_REQ return if you want to request the MB64_PATCH_SendCurrent call or write MB64_META_Handler bsf MB_STAT, MB_STAT_SNAPSHOT_REQ return if you want to request the MB64_PATCH_Send call The USER_Tick function in main.inc will check this flag, call the appr. function if it's 1, and clear the flag thereafter. Best Regards, Thorsten.

The individual CS lines have been tested, they are working. For my it sounds like the DOUT shift register isn't connected correctly, or that the configuration in the bootloader setup is wrong. Please describe exactly what you did: - your LCD configuration in the Bootloader setup - the hardware connections - tests that you already did - and describe the observations Without this input, remote diagnosis isn't possible! Best Regards, Thorsten.

yes - in all of my demo .NGC files I used a much higher offset value. After reading the documentation I realized, that I haven't mentioned why I did this... I think that the logic should be clear meanwhile. LED:1..256 address the DOUT pins With led_emu_id_offset it's possible to emulate LED functions with a LED matrix. If you set the offset to <=256, it will shadow DOUT pins functions, which is normally not desired. I hope that this forum works as enhanced documentation for such very special setups if somebody comes across the same problem. Best Regards, Thorsten.

Well, you've used the led_emu_id_offset wrongly anyhow. In order to improve the understanding, I added following note to the description of led_emu_id_offset (http://www.ucapps.de/midibox_ng_manual_ngc.html): In order to avoid conflicts with LEDs which are directly connected to DOUT pins (and which are accessed with LED:1 .. LED:256), it's recommended specify emulated ids outside this range, e.g. led_emu_id_offset=1001. Best Regards, Thorsten.

Where should I hide the information? (resp. where would you search for it?) Best Regards, Thorsten

Just call MB64_PATCH_SendCurrent what's wrong with this function? Or do you want to send the current patch? Then call MB64_PATCH_Send The code is located in mb64_patch.inc (for your inspiration) Best Regards, Thorsten.

It sounds more like a Windows (or computer) issue, for which I don't have diagnosis tools. And since I'm not a windows programmer, I also wouldn't be able to provide an alternative solution (such as a dedicated USB driver). There are certain things you could try out: - try to download the file multiple times, does it always stuck at 50%? - install the GM5 USB MIDI driver, does it help? - maybe a different SD Card? - try it on a different computer - any luck? If this doesn't help, then the only way how you can get reliable SD Card access is via an external SD Card reader. Such readers typically cost ca. $5..$10, so it would be an inexpensive workaround. Best Regards, Thorsten.

Interesting! gcc outputs a warning if I would write variable_x = CONST_A /Users/TK/svn/mios32/trunk/modules/keyboard/keyboard.c:307:5: warning: suggest parentheses around assignment used as truth value But since parentheses are sometimes used in such expressions as well, the programming error wouldn't be recognized (no warning). Seems that I should change my habits as well ;) Best Regards, Thorsten.

fine! :) Best Regards, Thorsten.

yes, all C preprocessor features should be available, inclusive constant expressions Best Regards, Thorsten.

What I meant was, that you could also write: DOUT_MATRIX n=1 rows=8 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 sr_dout_b1=4 led_emu_id_offset=1001 EVENT_LED id=1001 hw_id=1001 bank=1 rgb=15:0:0 value=100 EVENT_LED id=1002 hw_id=1002 bank=1 rgb=15:3:0 value=100 EVENT_LED id=1003 hw_id=1003 bank=1 rgb=15:7:0 value=100 # And then for LEDs in the second bank: EVENT_LED id=1101 hw_id=1001 bank=2 rgb=0:15:0 value=100 EVENT_LED id=1102 hw_id=1002 bank=2 rgb=3:15:0 value=100 EVENT_LED id=1103 hw_id=1003 bank=2 rgb=7:15:0 value=100 # this maps LED functions to the "LED hardware" which is assigned to hw_id=1001.. via led_emu_id_offset=1001 (the hw_id assignments for the first three EVENT_LED statements are only mentioned for demonstration purposes - actually they could also be omitted, because if hw_id is not specified, the hw_id is automatically set to the id value) Could you please check if this also fails if led_emu_id_offset is set to a much higher value, e.g. 1001 as proposed? yes Best Regards, Thorsten.

Thanks a lot for your contribution! :smile: I tested the new option with my cannibalized Korg Microkontrol keyboard, it's working fine! So, I took over your code almost 1:1, and only changed back the default delay values to the "less elaborated" ones to get a good starting point for all keyboard types. I also updated the documentation based on your input: http://www.ucapps.de/midibox_kb.html And I released a new version: MIDIbox KB V1.009 ~~~~~~~~~~~~~~~~~ o support for the "single_usb" option, which can be enabled with the bootloader update application V1.012 ("set usb_single 1") Use this option if you are working with a Windows PC which can't handle the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.) o support for Note Off velocity (implemented by Jo aka. Nlate). This feature has to be enabled with the release_velocity parameter. In addition, some suitable delay values have to be specified, such as: set kb 1 release_velocity on set kb 1 delay_fastest_release 100 set kb 1 delay_fastest_release_black_keys 80 set kb 1 delay_slowest_release 1000 One thing puzzles me a bit: why are you writing "0xff == prev_row" instead of "prev_row == 0xff"? Both expressions should be equal, but the original expression is better to read (from my point of view) Best Regards, Thorsten.

Alright, try again with the Bootloader Update package V1.012 (to enable the single_usb option) and with MBNG V1.021 Don't use the GM5 driver anymore, the windows legacy USB MIDI driver works fine with a single USB port. Something came in my mind while reading your report: is the SD Card still working reliable after all the experiments? E.g. if the directory wasn't updated correctly - maybe even unrelated to the USB issues - maybe due to a power issue - then corrupted filepointers could lead to the effect that two directory entries point to the same (physical) file. Therefore I would propose to format the SD Card again after the application updates to ensure that a corrupted filesystem won't lead to wrong assumptions at your side Best Regards, Thorsten.

A new version is available. MIDIbox NG V1.021 ~~~~~~~~~~~~~~~~~ o support for the "single_usb" option, which can be enabled with the bootloader update application V1.012 ("set usb_single 1") Use this option if you are working with a Windows PC which can't handle the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.) o added .NGS file which allows to store and restore values into up to 128 snapshots (0..127). The snapshot can be changed in the "Snap" menu in the SCS o the "Snap" menu also allows to dump all events (e.g. after a new snapshot has been loaded) o added new (hopefully selfexplaining) meta events: SetSnapshot, DecSnapshot, IncSnapshot, CycleSnapshot, LoadSnapshot, SaveSnapshot and DumpSnapshot Note that multiple meta commands can be assigned to an event, e.g. to set, auto-load and dump a snapshot from an encoder write: EVENT_ENC ... type=Meta meta=SetSnapshot meta=LoadSnapshot meta=DumpSnapshot o added "no_dump" parameter to EVENT_xxx It specifies if an EVENT_xxx should be sent during a DumpSnapshot. no_dump=1 is set for EVENT_RECEIVER and EVENT_KB and events which are using type=Meta by default. If such events should be part of the dump, set no_dump=0 For all other events/types no_dump=0 is set by default, set no_dump=1 if they shouldn't send MIDI events on a snapshot dump. o new label printf-control "%S" prints the snapshot number 0..127 Best Regards, Thorsten.

A new version is available: MIDIboxSEQ V4.072 ~~~~~~~~~~~~~~~~~ o support for the "single_usb" option, which can be enabled with the bootloader update application V1.012 ("set usb_single 1") Use this option if you are working with a Windows PC which can't handle the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.) Best Regards, Thorsten.

The actual arp features of MBSEQ V4 are not accessible from the MBSEQ V4L UI, and I'm not planning to add support. However, a new version is available: MIDIboxSEQ V4L.072 ~~~~~~~~~~~~~~~~~~ o support for the "single_usb" option, which can be enabled with the bootloader update application V1.012 ("set usb_single 1") Use this option if you are working with a Windows PC which can't handle the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.) Best Regards, Thorsten.

Of course, you can use the remaining matrix pins for other purposes, but they can only send Note Events for obvious reasons. .MIO file: please try with MIDIO128 V1.015 and the "single_usb" option enabled (has to be enabled from Bootloader Update App V1.012) Changelog: MIDIO128 V3.015 ~~~~~~~~~~~~~~~ o support for the "single_usb" option, which can be enabled with the bootloader update application V1.012 ("set usb_single 1") Use this option if you are working with a Windows PC which can't handle the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.) Best Regards, Thorsten.

Update V1.012: http://www.ucapps.de/mios32_download.html It supports the new "single_usb" option as a workaround for some Windows installations. Details: http://www.ucapps.de/mios32_bootstrap_newbies.html This option also requires a new application release for all projects which have 4 USB ports enabled by default: - MIDIbox NG: V1.021 and higher - MIDIO128: V3.015 and higher - MIDIbox SEQ: V4.072 and higher - MIDIbox SEQ Lite: V4L.072 and higher - MIDIbox KB: V1.009 and higher Best Regards, Thorsten.

I found two "imperfections" (nasty bugs) in the MBHP_NG_MF firmware: the LSB wasn't correctly handled in Motormix/Mackie HUI mode, and the touchdetection sometimes prevented faders moves, although this should be disabled if the touch sensor mode is not disabled. Both issues are fixed in mbhp_mf_ng_v1_004 -> http://www.ucapps.de/mbhp_mf_ng.html Best Regards, Thorsten.

I tested motorfader banks at my side and they are working. BUT: while doing this, I found two "imperfections" (nasty bugs) in the MBHP_NG_MF firmware: the LSB wasn't correctly handled in Motormix/Mackie HUI mode, and the touchdetection sometimes prevented faders moves, although this should be disabled if the touch sensor mode is not disabled. Both issues are fixed in mbhp_mf_ng_v1_004 -> http://www.ucapps.de/mbhp_mf_ng.html Back to MBNG: here is my test configuration: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_banks.ngc I noticed in your configuration that you've defined: EVENT_BUTTON id=101 meta=SetBank range=1:1 button_mode=OnOnly EVENT_BUTTON id=102 meta=SetBank range=1:2 button_mode=OnOnly Since no hw_id is specified, these events listen to DIN input 101 and 102 But then you are writing: "DIN at pin D0 and D1." Could it be, that you actually wanted to configure: EVENT_BUTTON id=1 meta=SetBank range=1:1 button_mode=OnOnly EVENT_BUTTON id=2 meta=SetBank range=1:2 button_mode=OnOnly or: EVENT_BUTTON id=101 hw_id=1 meta=SetBank range=1:1 button_mode=OnOnly EVENT_BUTTON id=102 hw_id=2 meta=SetBank range=1:2 button_mode=OnOnly Best Regards, Thorsten.

Ok, in order to bring these windows issues to an end, I will integrate a new bootloader option into MIOS32 which enforces the usage of a special descriptor which only specifies a single USB port. This should allow to enable the workaround without the need to recompile the application. Best Regards, Thorsten.

implemented in V4.071 Best Regards, Thorsten.