TK.

I can't recommend the usage of the Alps K faders, they are louder than for example a RSAON11M9 - I only used them to ensure, that the firmware can also handle faster faders, which were problematic with the previous solution. So: RSAON11M9 is still a good choice. Best Regards, Thorsten.

I can't really give you detailed answers to your questions - I'm not an expert in this area Thanks Pete for helping out! Best Regards, Thorsten.

The "compression" is now part of V1.020 - up to 16 bytes can be saved per item. In your .NGC file you can save even more bytes by moving the encoder labels to the .NGL file! You could address them with "^e1" ... "^e64" - this will dramatically reduce the memory consumption. :smile: Best Regards, Thorsten.

V1.020 is available: MIDIbox NG V1.020 ~~~~~~~~~~~~~~~~~ o added "rgb" parameter. See cfg/tests/rgb_*.ngc for various examples. o added "spread_center" option to AIN/AINSER calibration. See cfg/tests/kb_1.ngc for an usage example. o reduced memory consumption of EVENT_* definitions o added MIOS Terminal commands: "show id" and "show hw_id" @rvlt: please try: AINSER pinrange=1:<pitchbender-min-value>:<pitchbender-max-value>:spread_center in your .NGC file - it will be interesting if this solves the problem! :smile: Best Regards, Thorsten.

This would be the text output to CLCDs - strange! What happens if you add: bsf MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCD after "call MIOS_LCD_TypeSet"? Best Regards, Thorsten.

electronic magazines! :smile: There were much better ones than today at the time I started anno 1990, such as Elrad which was never replaced by something comparable. Best Regards, Thorsten.

Hi Stefan, the KS0108 GLCD driver is already part of MIOS, the "official way" to select this driver would be through the PIC ID header as explained here: http://www.ucapps.de/mios_bootstrap_experts.html Considered, that this requires a PIC programmer (or a modified change_id application), I propose you an alternative way: you could select the GLCD type in the application as well. Just add following lines at the beginning of USER_Init in main.inc: USER_Init ;; select LCD type #1 (KS0108) movlw 0x00 ; if 0: non-inverted CS, if 1: inverted CS# movwf MIOS_PARAMETER1 movlw 0x00 ; here you could forward an additional parameter movwf MIOS_PARAMETER2 movlw 0x01 call MIOS_LCD_TypeSet Best Regards, Thorsten.

Hi Ajax, did you already try to set "BLM_SCALAR_Port 0x11", and to use the second USB MIDI Port for the communication with the virtual BLM? Or: could it be, that you don't see the 4 USB MIDI Ports after the installation of the latest MBSEQ V4L Release? If you only see a single USB MIDI Port: Did you already update the USB Interface definitions in the Audio/MIDI Setup of MacOS? Best Regards, Thorsten. Update: I just noticed, that the V4L update which enables 4 USB-MIDI ports hasn't been released yet. You will find it here: http://www.ucapps.de/mios32/midibox_seq_v4l_071_pre2.zip After the update, you have to: - enter the Audio-MIDI-Setup of MacOS - disconnect the core module from USB - delete the interface in the Audio-MIDI-Setup - connect the core module to USB again Thereafter you should see an interface with 4 USB MIDI Ports: Best Regards, Thorsten.

Hi, yes, this can seriously overload the interconnection cables between LPC17 and DOUT modules + the ground plane of the LPC17 module. It shouldn't be loaded by more than 1A I would add additional wires "star-like" between the ground terminals of the DOUT modules (J1:Vs) and the ground of the 12 VDC PSU. Let the ribbon cables between DOUT modules and LPC17 connected as they are. This ensures that there is also a ground connection between LPC17 and DOUT modules (which is required). But the main current will flow from the SAMS through the ULN2803s and the additional cables directly to the PSU (and not through the LPC17 module). Best Regards, Thorsten.

Thanks for the measurements! The values vary between 2257 and 2295, which means that the tolerance window has to be 38, but after the 7bit conversion we would only have a tolerance window of 32 In order to solve this, I will add a function which enables a tolerance window of +/- 48 around the center position. This would be exactly the same change that I already did for MBKB :) Best Regards, Thorsten.

No, a page file can't be used, most informations have to be directly available in RAM (e.g. so that banked items can receive MIDI values regardless if they are selected or not). But I'm planning to compress the stored events (values which haven't been changed don't need to be stored). This will reduce the memory consumption by more than 50% Btw.: you are currently using two different ids (1001 upwards and 1 upwards) for LEDs - this isn't required. Just start led_emu_id_offset with 1001 Best Regards, Thorsten.

Why are you taking EVENT_BUTTON and why are you taking button_mode=Toggle when only the LED function itself is desired? See also the first example which demonstrates the usage with EVENT_LED: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=/trunk/apps/controllers/midibox_ng_v1/cfg/tests/rgb_1.ngc Do you need an example with EVENT_LED and banks, or is the usage clear now? Btw.: sometimes it helps to activate "set debug on" to understand the dataflow Best Regards, Thorsten.

Did you set the led_emu_id_offset as mentioned above, and are you using LED instead of LED_MATRIX meanwhile? Are you using buttons or not? Do you want to use button_mode=Toggle or not? Best Regards, Thorsten.

Hi Matthias, nice videos! :) To the device ID: after you've changed it to 126, you also have to select the right device ID in MIOS Studio (above the Query button) Note: actually it isn't required to change the device ID if MIOS Studio communicates via USB to the core, because each core has a dedicated MIDI port. Device IDs are only useful if you would chain the cores. Shadows on the LED rings: this seems to be a soldering error around the ULN2803. I can reproduce exactly the same effect when I'm lifting pin #9 (ground) of the ULN2803. Best Regards, Thorsten.

DOUT_MATRIX command: add "led_emu_id_offset=1001" EVENT_BUTTON commands: replace LED_MATRIX by LED Best Regards, Thorsten.

Twin-X has modified the firewall configuration - SVN should work again! :) Best Regards, Thorsten.

Twin-X has modified the firewall configuration - SVN should work again! :) Best Regards, Thorsten.

No, customized chords are not supported. You've to initialize the track for 16 parameter layers (-> EVENT page). Then most layers are already assigned to Notes. The most simple way to enter the chords is in Step Recording Mode (enable the Poly option!) Alternatively play two chords from a single track, one with a high, another with a low octave. This can be configured in the EVENT page as well. Most comfortable editing: change to the Layer View (-> SELECT + Layer View in the EDIT page) Another alternative option: just use a drum track to trigger predefined notes - it's even possible to transpose a drum track! :-) Best Regards, Thorsten.

Hi Nick, please check this schematic again: http://ucapps.de/mbhp/mbhp_8xsid_c64_psu_optimized.pdf There is no SC->SC connection But there is a MD->MD connection... Best Regards, Thorsten.

Unfortunately the strange firewall protection will prevent you from updating the SVN. :-( Here is a temporary binary release: http://www.ucapps.de/mios32/midibox_ng_v1_020_pre1.zip Bank Change: currently I don't see a way to select banks from external MIDI keys, because there is no mechanism to convert the key number to a "value" which then will be forwarded to a SetBank meta event. However, here an example how you could change the bank from a CC: EVENT_RECEIVER id=1 type=CC cc=0 fwd_id=SENDER:1 EVENT_SENDER id=1 type=Meta meta=SetBank Best Regards, Thorsten.

It seems that Twin-X has installed a new firewall protection which is sensitive to the SVN port 3690 Whenever you are accessing SVN, your IP will be blocked for at least one hour. I can reproduce this at my side as well... the server was still accessible from my mobile network. I informed Twin-X about this issue, hopefully it will be possible to exclude the SVN port from this mechanism! Best Regards, Thorsten.

Don't panic, you are not crashing the server! :) It seems that Twin-X has installed a new firewall protection which is sensitive to the SVN port 3690 Whenever you are accessing SVN, your IP will be blocked for at least one hour. I can reproduce this at my side as well... the server was still accessible from my mobile network. I informed Twin-X about this issue, hopefully it will be possible to exclude the SVN port from this mechanism! Best Regards, Thorsten.

I replaced the "unicolour" feature (+ meta events) by a rgb parameter which can be specified in the EVENT_* definition. Usage examples: rgb values directly defined for 64 LED events: rgb_1.ngcrgb values forwarded to LEDs via button events: rgb_2.ngcrgb values defined in banked button/led events: rgb_3.ngcBest Regards, Thorsten.

Hi Rick, I believe that 12 rows is the correct value, because the number of selection lines must be dividable by 2 (one selection line for break, the other one for make) Also the schematic shows 12 rows... I adapted the command description accordingly, the calculation example was probably too confusing. Let us know if the MBKB firmware is working at your side! :smile: Best Regards, Thorsten.

There are no constraints for the width... unfortunately you forgot to pass the most important part: the .inc file with the header definitions. Probably only the header values are wrongly set. Best Regards, Thorsten. P.S.: please don't distribute .rar files, they are hard to use on operating systems != Windows