TK.

implemented in V4.071 Best Regards, Thorsten.

A new release is available: MIDIboxSEQ V4.071 ~~~~~~~~~~~~~~~~~ o if not in song mode, the Rew/Fwd buttons can now be used to select the step view. o the MIDI router provides the new destination "Track". If this destination is selected, incoming MIDI events will be routed to the MIDI port and channel of a track depending on the incoming MIDI channel number. Usecase: MIDI events, such as CC or Notes, should be sent from a master keyboard or MIDI controller to synths which are assigned to different port and MIDI channels in the track configuration. Just select the track with the MIDI channel on your keyboard/controller, the router will take care that the events reach the right destination. o it's now possible to send a CC when a track has been selected. This feature allows to synchronize the track selection with a DAW. It has to be configured in the MBSEQ_HW.V4 file (search for TRACK_CC in hwcfg/*/MBSEQ_HW.V4) @Alex: sorry, your requested feature to control AOUT channels via NRPN needs some more time. Best Regards, Thorsten.

This should work without code modifications. Just configure the MIDI forwarding to MIDI IN3/OUT3 with the integrated MIDI router. It isn't possible to share a SD Card between two cores. There is no need to deal with master/slave settings. The second core just behaves like an independent device. It makes sense to use dedicated MIDI IN/OUTs for both cores. Best Regards, Thorsten.

Hi Alex, the requirements for the cable length are less restrictive, since in distance to the MBHP_CORE_STM32 module, the MBHP_CORE_LPC17 module has buffered outputs for the serial outputs. Best Regards, Thorsten.

Hi Thomas, just create bookmarks for these pages. You will be able to switch between the bookmarks in the appr. page - or you can add up to 16 dedicated bookmark buttons to your MIDIbox. :) I like this idea and will add it to the next version. :) Best Regards, Thorsten.

Hi Ole, yes, this "starlike" wiring should work. Best Regards, Thorsten.

Hi Rick, I guess that the SEND* pins have to be connected to DOUTs, and the RET pins to DINs. There are 12 SEND pins (0..11) for "break", and 12 SEND pins (0..11) for "make". But the MBHP_DIO_MATRIX module only provides 12 output pins. The solution would be to chain two MBHP_DIO_MATRIX modules, and to configure two keyboards. Because each keyboard can only scan 16 rows (but you need 24 rows) By increasing the note_offset value of the second keyboard, you will get a continuous note range. Best Regards, Thorsten.

-> MIDIbox NG: http://www.ucapps.de/midibox_ng.html no. MIDIbox64E would allow you to use Buttons functions, encoder and pot functions. But the configuration is much more complicated (e.g. you would have to re-compile the source code) than with MIDIbox NG (configuration done in a file on SD Card) Best Regards, Thorsten.

Hallo, momentan verkauft Fairlightiii ein paar MBHP_CORE_LPC17 Platinen: (er kommt aus Frankreich, deshalb schneller versand) 4 DINX4 Module sollten reichen DOUTX4 Module: wenn Du noch mehr gates brauchst, koenntest Du im MBSEQ_HW.V4 File bis zu 8 DOUT shift register dafuer einrichten (-> +64 Gates!) Deshalb besorge Dir lieber 4 DOUTX4 Module Fuer die Gates an J5 und J28 solltest Du Dir noch zwei 74HCT541 besorgen, siehe auch: http://www.ucapps.de/mbhp/mbhp_core_lpc17_output_buffers.pdf Gruss, Thorsten.

I've to check this at my side. Currently I can only answer this question: Please check your MIDI router configuration, maybe you are forwarding events from IN1 to USB1? But as mentioned above, I've to doublecheck at my side if banks are working correctly in conjunction with motorfaders, I haven't tested this. Best Regards, Thorsten.

In the meta handler you are sending MIDI events to MIDI OUT. But actually you want to control an internal function of MIDIbox64, like if it would receive a SysEx string (or program change) at MIDI IN, right? The most simple way would be: MB64_META_Handler movf MIDI_EVNT1, W goto MB64_PATCH_Change Best Regards, Thorsten.

The backlight LEDs are directly connected between Vdd (anodes) and B- (cathodes), there is no SW control for the brightness. Did you already try to adjust the "Luminance" trimpot P1 on the MBHP_CORE_LPC17 module? Best Regards, Thorsten.

Do you have the same issues with the Korg driver? -> Best Regards, Thorsten.

The shift registers are scanned each 250 uS, means: with 4 rows the worst-case latency is 1 mS, with 8 rows 2 mS, with 16 rows 4 mS So - regardless of the row configuration, the latency is ignorable, you won't notice it. The number of columns don't increase the latency, because they are read during a single scan. Best Regards, Thorsten.

No, the documentation is correct: with "J5_ENABLED 1" the clock pulse is available at J28.SDA, and the start/stop signal is available at J28.SC Best Regards, Thorsten.

Hi Stefan, I've no explanation for this wrong behaviour. And my big problem: the only KS0108 GLCD that I own is currently connected to a MBHP_CORE_STM32 module, so that I can't test the changes. :-/ However, it sounds like the CLCD variant was connected (again), therefore I reverted the changes (MIOS_LCD_Init not called anymore before testing the GLCD flag). http://www.ucapps.de/mios/midibox_lc_v1_6g.zip It would be helpful if you could test the change at your side (again). Only main.inc, USER_Init has been changed: - call MIOS_LCD_Init removed - default check for GLCD flag now based on type number - you've to turn "#if 0" to "#if 1" to overrule the PIC ID header selection Best Regards, Thorsten.

With a bit of luck the Korg driver will work under Win98, which would be a good replacement for the non-working GM5 driver: http://www.korg.co.uk/downloads/driver/dl_driver.asp If you really want to go for the MIDI Router: there is no need to comment out the DIN/DOUT/LCD/etc. sections, because they won't be called during runtime if no DIN shift register is connected. Best Regards, Thorsten.

No - USER_SR_Service_Finish is called each mS after the shift register scan. By clearing the SR registers in this hook it's ensured that the pulse will only be active for one update cycle (= 1 mS) I won't add new features to PIC based firmwares anymore. Programming in assembler is too cumbersome and error prone... Best Regards, Thorsten.

In theory you could do this in http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FLPC17xx%2Fmios32_usb_midi.c MIOS32_USB_MIDI_PackageSend: add "package.cable = (package.cable + 1) % 5" at the top MIOS32_USB_MIDI_PackageReceive: add "package->cable = (package->cable + 1) % 5" at the bottom. You have to recompile and install the modified bootloader first before you will be able to use such a change in your application. -> make in bootloader/src first, thereafter make in bootloader/updater A perl installation is required to generate the bootloader/updater/bsl_image_* files No guarantee that it will work! (could be that I overlooked something) It should be clear, that Bootloader HOLD mode won't work thereafter anymore, because the bootloader will listen to a non-existing USB cable. Much more code changes would be required to get this working, but I won't have the time to support you on such a topic (for a nice-to-have, but not necessary feature from my point of view) Best Regards, Thorsten.

You can create the MBSEQ_GC.V4 file in the root directory with the Filebrowser. It's ok when it only contains the "MultiPortEnableFlags 0x011031" line Alternatively enter "store" in the MIOS Terminal - this should generate the GC file as well! Best Regards, Thorsten.

Saubere Arbeit! Und ein ziemlich grosses Display! :) Best Regards, Thorsten.

Hi Antonio, you would have to add following snipped into the source code (src/main.inc) after the USER_SR_Service_Finish label: USER_SR_Service_Finish clrf MIOS_PARAMETER1 movlw 0x00 ; first SR call MIOS_DOUT_SRSet movlw 0x01 ; second SR call MIOS_DOUT_SRSet movlw 0x02 ; third SR call MIOS_DOUT_SRSet ;; etc... add more MIOS32_DOUT_SRSet based on the same scheme if desired Best Regards, Thorsten.

Hi Jo, there is a major blocking point which will prevent us from implementing this properly in MIOS32: there isn't enough code space available in the bootloader range for a USB descriptor which enables 5 USB Ports. With this assumption I never considered that "service functions" are accessed from an USB port other than USB0. -> it will never work properly under all conditions! Best Regards, Thorsten.

Which error message is print by the Filebrowser exactly? And do you see an error message in the MIOS Terminal as well? Which one exactly? .MIO file: please pack it into a .zip file, and then attach it to this thread. Best Regards, Thorsten.

Thanks for your understanding! Please keep this thread updated whenever you find new infos - because from my point of view there is no reason why this shouldn't work (beside of .xpm conversion issues with a script that I wrote 18 years ago - take it as it is, and try to workaround any conversion issues) Best Regards, Thorsten.