TK.

It would be interesting if your LCDs are working with following version: http://www.ucapps.de/mios32/midibox_seq_v4_070_pre1.zip The transfer speed to IC2 has been reduced, this solved a similar issue which has been noticed by Duggle. Best Regards, Thorsten.

Hallo Roman, freut mich, dass es so problemlos geklappt hat - das kommt selten vor! :) Zum Encoder: hat der eigentlich eine Rasterung? Falls nicht, wuerde ich die Encoder von Voti empfehlen Gruss, Thorsten.

Each track has a dedicated port/channel assignment. By changing to another pattern (e.g. manually in the PATTERN page, or automated from a song) you can change the MIDI port/assignments on the fly. This can also be done manually in the track configuration page without the danger for hanging notes. Best Regards, Thorsten.

This could work with conditional events, see also the third example in this posting: But I haven't got much feedback on the proposed usage yet... and I'm unsure if there are more cases which have to be considered... Best Regards, Thorsten.

Hallo Iswestija, die Bootloader-Version kann nicht so ohne weiteres ermittelt werden, im Normalfall ist das aber auch nicht notwendig. Der Bootloader laesst sich wie eine normale Applikation ueber MIOS Studio installieren - und wenn man nicht mehr weiss, welcher bereits installiert ist, laedt man die aktuelle Version auf - fertig. Dazu muss man noch nicht mal den Bootloader Hold Mode Jumper (J27) setzen - der ist nur fuer den Notfall. Um Dich nicht zu sehr zu verwirren, werde ich Dich nun nicht mit Details ueberhaeufen, sondern konkret sagen, was in Deinem Fall zu tun ist: Auf Deinem Core ist noch eine aeltere MBSEQ Version installiert, die auch nur zu einer aelteren Bootloader-Version passt. Im Bootloader hat es eine inkompatible Aenderung gegeben, mit der USB MIDI nun auch endlich unter Windows7/8 problemlos funktioniert. Die Aenderung erfordert eine besondere Updateprozedur, die nur fuer diesen speziellen Fall notwendig sein wird. Diese ist hier beschrieben: Schritt 1) den neuen MIOS32 Bootloader installieren: - mit MIOS Studio das passende .hex file von mios32_bootloader_v1_010.zip aufladen - ein paar sekunden warten, bis der Bootloader installiert wurde (das wird im Terminal angezeigt) - MIOS Studio schliessen - USB Kabel abstecken und ein paar Sekunden warten, dann wieder reinstecken - MIOS Studio oeffnen: der USB Port sollte gefunden werden Schritt 2) MIDIbox SEQ V4 installieren - wie gewohnt. Und falls Du unter Windows arbeitest, macht es Sinn, anschliessend auch noch den GM5 Treiber zu installieren. In Zukunft kannst Du dann (wieder) den Bootloader jederzeit ohne Raus/Reinstecken des USB Kabels updaten, und Inkompatibilitaeten zur MBSEQ Version sollte es auch nicht mehr geben (das passiert hoechstens alle drei Jahre ;-)) Gruss, Thorsten.

Somehow I knew that I shouldn't release this option before drawing a schematic. On the other hand the schematic takes significantly more time than the implementation of such a function! So, hopefully more clear: - if <= 8 displays are configured (CLDs: 2 displays), J28 won't be initialized at all, and it's free for other purposes (e.g. MBSEQ: to output CV gates, DIN clock and DIN Start/Stop) - if <= 12 displays are configured, all 4 J28 outputs will be used by the LCD driver to provide additional CS pins (CLCDs: E pins if <= 6 displays configured) - this saves some hardware! - if >= 13 displays are configured, CS (or for CLCDs: E if >= 7 displays configured) pins are provided by a shift register (chain) It should also be clear, that a CLCDs have a different interface than serial GLCDs. For CLCDs we can connect two E lines (equivalent to CS lines on serial GLCDs) to J15A and J15B - and this means, that additional E lines are starting at 3. For KS0108 based GLCDs we've a similar situation. For serial GLCDs such as DOGM and SSD1308 the J15 control pins (E, RS, RW) are used for different purposes, and data pins are used to select up to 8 GLCDs Sorry for such complicated dependencies, but I'm just trying to cover many cases which have been requested in the past. Sometimes it would really be easier just to say: no - it isn't possible! ;-) Best Regards, Thorsten.

This isn't really required. For serial GLCDs it doesn't make a difference, if only one or up to 8 displays are connected to the shift register, because the driver doesn't get a feedback from the available displays anyhow. For CLCDs it's a bit different, but still no issue: the driver gets a feedback, and it's able to determine if a CLCD is "always busy" resp. not connected. In this case the CLCD will be deactivated and won't be accessed anymore. So - why do you want to set such a special configuration? Best Regards, Thorsten.

No problem, I can add this to the next version... ...if you do me a favor and test your LCDs with a MBHP_CORE_LPC17 core again - it seems that Doug was able to reproduce the same issue with his CLCDs, and we probably found a solution! (More about this topic + firmware update tomorrow) Best Regards, Thorsten.

I will spend some thoughts on this topic this weekend. Currently we've a more important topic to discuss via email ;) Best Regards, Thorsten.

Hi Norbert, once more people successfully tested the keyboard scan with MBNG, I will go for the next step and make the MIDI event configurable via a new EVENT_KEYBOARD command, which works similar to MIDI_BUTTON or MIDI_DIN_MATRIX - this means, that mapping will be available as well. As a nice side effect this will also allow to map the velocity, e.g. to a curve defined in a MAP. :) @Lars: this will require some testing at my side. E.g. I've to check what happens if somebody connected a pot directly to J5.A0, and enables the output function by accident (e.g. while loading a certain .ngc file without knowing the content). In worst case this could damage the pin forever (but my hope is, that the internal impedance is high enough so that a short circuit protection is guaranteed) Your assumptions for the LED digits is correct, but they are not supported by the firmware yet! Best Regards, Thorsten.

I don't sell devices, and wouldn't have the time to build a new one - but others have. ;) Best Regards, Thorsten.

Hi, your assumptions are correct, and I just have doublechecked at my side, that with: the shift register at J28 will be enabled (it will be enabled once more than 12 LCDs are configured in x and/or y direction), and up to 16 SED1306 OLEDs will be addressed correctly. You could load cfg/tests/clcd_16.ngc configuration for testing purposes - it will print LCD1... LCD16 on all displays. A single cap and resistor should be ok for all displays. The capacity will be increased a bit, but with the 10 uF in parallel we've already a capacity which is more than 1000 times higher ;-) Hint for testing the displays without chip select lines: just connect them to 3.3V (J28:Vd) directly - this ensures that they will be initialized; and they will print the same message like the first display during startup. Best Regards, Thorsten.

Hallo Roman, in erster Naeherung hast Du alles richtig gemacht - der Rest kommt beim Buegeln! :) Gruss, Thorsten.

Hi Trey, welcome to the forum! :smile: You are not breaking rules with your request; the TAPR NCL license allows to sell up to 10 MIDIboxes per year, it's even allowed to ask for a compensation for the efforts. So: if anybody is interested to help out, please step forward! :smile: Since there are no complicated key combination which require visual feedback, I think that the firmware will work fine at your side without modifications. If you need certain additional functions, please let me know! E.g. maybe a special button combination could be helpful which quickly resets all modes and parameters to a known state for the case that you lost the orientation. Best Regards, Thorsten.

Hi Braintu, first of all: thanks for the compliments! :smile: A general statement to an alternative core module: just two days ago Fairlightiii introduced his plans for an alternative PCB to me. It's smaller (10x10 cm), and has an off-board MIDI IN/OUT circuit (provided as a second PCB for those who really need this - two PCBs can be combined for 4 MIDI IN/OUTs). It has an SD Card on board as well. I like it (sorry Ilmentator!) - not at least because I know that it will be perfectly documented in the Wiki, and supported by Fairlightiii. So, partly it matches with your idea, partly you are trying to reduce the part count even more by creating some kind of LPCXPRESSO replacement dedicated for MIOS32. But I fear that such a solution isn't attractive enough for most people. It isn't newbie friendly. Not only due to the SMD soldering, but also because somebody would need an external JTAG programmer to flash the bootloader into the chip, which increases the costs (and complexity) for people who don't own such an equipment yet. Best Regards, Thorsten.

Now available in v1.015 together with the cursor map and GLCD font changing feature for ^txt and ^txt56 SysEx commands Best Regards, Thorsten.

V1.015 is available: MIDIbox NG V1.015 ~~~~~~~~~~~~~~~~~ o support for GLCD_SSD1306_ROTATED o the ^txt and ^txt56 SysEx command now allows to map incoming characters to different cursor positions. An example can be found in cfg/templates/logictrl.ngc o independent from this map feature, ^txt and ^txt56 now also take lcd_pos=... and label=... into account to set the initial LCD and cursor position, at which the message will start. The label can be used to change the GLCD font before the characters will be print. An example can be found in cfg/templates/logictrl.ngc as well. Best Regards, Thorsten.

Yes - environment variables are not considered in the build dependencies, which means that a "make clean" is required whenever MIOS32_* variables have been changed. Best Regards, Thorsten.

No problem, I added a the display type 0x85: SSD1306_ROTATED The change is already in the repository, and will be released with the next MBNG version. You can use the v1.010 bootloader to select this type (0x85) - it will say "unknown", but the change will be accepted. Note that after changing the display type and uploading the MBNG update it will be required to power-cycle the core, otherwise the GLCD won't be initialized correctly (it has to be reset...) Best Regards, Thorsten.

Since the Ctrlr based "Program Manager" is still not available, you could use the MIOS Studio based SysEx Librarian: and then press the "Receive" button in the Ctrlr panel whenever a patch should be modified. To your complains about the panel compatibility over different Ctrlr versions: this can't be ensured, but it isn't in my hands... :-/ Best Regards, Thorsten.

As mentioned in http://midibox.org/forums/topic/17545-midio128-v3-mehr-dindout-ports-möglich-vergleich-zum-ng/?p=154493'>this (german) thread I will probably use the MAP feature to assign the cursor positions. This isn't implemented yet, but it will be available soon. It will also be possible to define the initial cursor/lcd position, and to define the font in a label attached to the EVENT_RECEIVER. Background: by using the "small" 3x8 font, this will allow to display the 2x56 message on a 240x64 LCD. Of course, also the "big" 24x16 font could be used to spread the message over even more screens. So: this will be available as well, and with the latest GLCD changes in V1.013 there is finally no conceptional blocking point for the implementation anymore. :) Best Regards, Thorsten.

Erratum: the keyboard won't be scanned if the parameters are loaded from the .NGC file. Workaround: enter one of the kb commands into MIOS Terminal which re-initializes the keyboard handler, such as: set kb 1 velocity on This issue will be fixed with v1.015 Best Regards, Thorsten.

Up to 64 SSD1306 displays are supported! :smile: The configuration is described at the bottom of this page: http://www.ucapps.de/midibox_ng_manual_lcd.html Currently the same AIN driver is integrated like in MBKB, which means that the calibration works the same way. The calibration values are stored in the _min/_max parameters. Once I got the confirmation that the keyboard handling is acceptable (*), I will replace the AIN based pitch/modwheel by a more generic approach (EVENT_AIN resp. EVENT_AINSER) so that also the more accurate AINSER inputs can be used. (*) Acul already confirmed that the keyboard handler works fine at his side - he doesn't recognize any latency! :smile: Best Regards, Thorsten.

The keyboard driver is now integrated into MIDIbox NG V1.014: I'm looking forward to your feedback! :) Best Regards, Thorsten.

A new version is available - let's check if MBNG is fast enough to scan velocity keyboards as well :) MIDIbox NG V1.014 ~~~~~~~~~~~~~~~~~ o the keyboard handler of MIDIbox KB has been integrated. The configuration commands are identical "set kb..." as documented at the MIDIbox KB page: http://www.ucapps.de/midibox_kb.html o keyboard parameters are also stored in the .NGC file, and can be configured from there. o please note that the latency is 10 times higher than in the MIDIbox KB application! Each row is scanned in 320 uS (instead of 32 uS). This has to be considered in the velocity delay configuration. delay_slowest should be 100 (instead of 1000), and delay_fastest should be 5 (instead of 50) o DOGM and SSD1306 GLCDs: support for more than 12 displays via DOUT shift registers connected to J28 A typical keyboard configuration would be: KEYBOARD n=1 rows=8 dout_sr1=1 dout_sr2=2 din_sr1=1 din_sr2=2 din_inverted=0 break_inverted=0 din_key_offset=32 \ scan_velocity=1 scan_optimized=0 note_offset=28 midi_ports=1000100000001000 midi_chn=1 \ delay_fastest=5 delay_fastest_black_keys=0 delay_slowest=100 \ ain_pitchwheel_pin= 0 ain_pitchwheel_ctrl=128 ain_pitchwheel_min= 1 ain_pitchwheel_max=254 \ ain_modwheel_pin = 0 ain_modwheel_ctrl = 1 ain_modwheel_min = 1 ain_modwheel_max =254 \ ain_sustain_pin = 0 ain_sustain_ctrl = 64 ain_sustain_min = 1 ain_sustain_max =254 Best Regards, Thorsten.