TK.

The schematic should be correct, but it doesn't explicitly specify the order of DOUT/DIN shift registers. Maybe they have a different order on your PCB? Then just change these definitions: DIN_MATRIX n=1 rows=4 inverted=1 sr_dout_sel1=1 sr_din1=1 DIN_MATRIX n=2 rows=4 inverted=1 sr_dout_sel1=4 sr_din1=2 DOUT_MATRIX n=1 rows=4 inverted=1 sr_dout_sel1=1 sr_dout_r1=2 sr_dout_g1=3 DOUT_MATRIX n=2 rows=4 inverted=1 sr_dout_sel1=4 sr_dout_r1=5 sr_dout_g1=6 If this doesn't help: ensure that at least v1.008 is installed. And you probably also want to check if it works better with inverted=0 (in this case, your LED/Button selection lines are swapped compared to my implementation) Another hint: the configuration doesn't forward button to LED events. The buttons should send Note events, the LEDs should react on the same note events (e.g. sent from the virtual MIDI keyboard of MIOS Studio) Best Regards, Thorsten.

Alternatively (the newbie solution - most simple wiring, no special PCBs required): - 1 MBHP_CORE_LPC17 module - a SD Card - 4 MBHP_DINX4 modules - an optional 2x20 LCD Best Regards, Thorsten.

Hi Alban, if you are planning to order the components from Reichelt, this button would be the best choice: http://www.reichelt.de/Kurzhubtaster/TASTER-3301B/3/index.html?;ACTION=3;LA=446;ARTICLE=27893;GROUPID=3278;artnr=TASTER+3301B Best Regards, Thorsten.

You are right, the displayed version number isn't correct (will be fixed with the next release ;) I don't see a simple way to replace MENU+SYSEX by another page. Maybe a bookmark would be sufficient? Best Regards, Thorsten.

Wow! If more people are interested, we should bring your driver into the repository! :smile: Best Regards, Thorsten.

With ULNs installed. I haven't tested it without (because I've no bridges ready), but I checked if it makes a difference if the resistors are replaced. Outcome: 220 Ohm resistors are a good value, 47 Ohm resistors don't make a big visual difference, but increase the power consumption. Best Regards, Thorsten.

I got the "Low-Cost LEDs" from Reichelt today, and the outcome was very good! The brightness is perfect, especially against spotlight! :smile: So: LED 3MM RT is the recommended LED For the US guys: can you recommend a similar part from Mouser? The mcd value should be at least 10 (than higher, than better) Here a direct comparison new vs. old LEDs: Best Regards, Thorsten.

Am besten in der MIDIbox NG Sektion des Forums, so dass die interessierten Bastler direktes Feedback geben koennen. Hier habe ich den Anfang gemacht: Am besten oeffnest Du einen neuen Thread mit dem Titel "Project: <name-deines-projekts>" Spaeter werde ich vom MIDIbox NG Manual aus die Artikel verlinken, so dass wir nicht die Uebersicht verlieren. ;) Dein .NGC File kannst Du uebrigens einfach in einen code-block setzen, und/oder in ein .zip packen und dann an den Thread anhaengen. Ja, das geht mit dem "button_emu_id_offset". Hier ist ein Beispiel fuer die 16x4 BLM: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm16x4e.ngc und hier fuer die 8x8 Matrix von Wilba's Frontpanel: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftk%2Fmbseq.ngc Gruss, Thorsten.

Hallo Alexander, gegenueber der MBNG hat die MIDIO128 den Vorteil, dass die Konfiguration einfacher gehalten ist - dafuer muss man jedoch auch mit den beschraenkten Mitteln auskommen. MIDIO128 hat auch einen integrierten MIDI File Player und Recorder - ein Feature, das gerade bei unseren Organisten sehr beliebt ist. MBNG ist hingegen universeller. So koennen bspw. neben "normalen MIDI events" auch NRPN und SysEx Daten verarbeitet werden. Im Gegensatz zur MIDIO128 werden Encoder, LED Matrizen, Motorfader und CV Ausgaenge unterstuetzt. Die LCD-Meldungen sind frei definierbar, es gibt Radio-Groups fuer Buttons/LEDs, Baenke, Wertetabellen, und und und... ;) MBNG deckt viele Anwendungsfaelle ab, die bisher direkt ausprogrammiert werden mussten. Insofern waere in Deinem Fall der Umstieg auf MBNG wohl die beste Loesung. :) Gruss, Thorsten.

Duo-LED and RGB LEDs connected to a DOUT matrix are properly supported in V1.008: MIDIbox NG V1.008 ~~~~~~~~~~~~~~~~~ o DIN_MATRIX with rows=4 now properly supported o DIN_MATRIX/DOUT_MATRIX: it's now possible to invert the rows as well: inverted=1 or inverted_sel=1 will invert the selection lines inverted_row=1 will invert the row pattern o configuration examples for the 16x4 Button/Duo-LED matrix are now available under cfg/tests/blm16x4*.ngc I tested it only with my 16x4 Button/Duo-LED matrix. @Ilmenator: could you please check if: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm16x4.ngc and http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm16x4e.ngc is working at your side? Best Regards, Thorsten.

Hallo Chris, das groesste Problem an dieser Aenderung ist der Applikationsname: "MIDIO128" soll ja 128 digitale Ein- und Ausgaenge implizieren. ;-) Softwaremaessig ist es ansonsten keine grosse Sache, die Anzahl der Shift Register zu erhoehen. Dies geschieht im mios32_config.h file, die Applikation muss anschliessend neu kompiliert werden. Hier etwas Vorkompiliertes: http://www.ucapps.de/mios32/midio128_v3_013_pre1_32sr.zip Hardwaremaessig musst Du nun besonders darauf achten, dass die Verbindungen zwischen den DIN/DOUT Modulen so kurz wie moeglich gehalten werden. Auch eine Terminierung koennte evtl. erforderlich sein - falls es also Probleme gibt (unstabile Werte, LEDs fangen an zu flackern, o.ae.) gib bitte bescheid - die erforderlichen Massnahmen sind noch nicht sauber dokumentiert. Gruss, Thorsten.

Hi Nexus, yes, this is possible by using the new introduced SetBankOfHwId meta event. See following example, where two encoders control the banks of two encoder rows independent from each other: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fbnk_2sel.ngc Instead of an encoder, you could also use buttons to set the banks, e.g. the "CycleBankOfHwId" meta event would only require a single button to switch between the banks (once the last bank is reached, it will switch back to the first bank) Best Regards, Thorsten.

This would be very difficult to integrate such an option on a generic way :-/ Exactly! ;-) It's especially difficult to find the right balance. Number of parameters vs. ease of configuration, number of features vs. memory consumption, etc. etc. Best Regards, Thorsten.

yes The increased latency will mainly affect the accuracy of the velocity values. Currently the measured delay ranges from 50...1000, with a 10 times slower scan we would only measure delays between 5..100 anymore. It depends on the outcome with your "velocity curve" implementation if a difference can really be notified. Best Regards, Thorsten.

Theoretically an alternative panel could be created with Ctrlr, which runs under Windows and MacOS. But since the development of this software is very turbulent, I would say that it isn't the right time to start with the yet. E.g. the panels that I created for MBSID and MBFM are not working with newer Ctrlr versions, it's extremely difficult to get bugfixes (which won't lead to new issues) and meanwhile even MacOS updates are not provided anymore - which makes it impossible for me to test the panel under similar conditions like under Windows. Lemur on iPhone: works, but you won't see the complete panel which makes it unusable. It would be better to search for an iPad1 - I'm still using it as well, the performance is more than sufficient! :smile: Best Regards, Thorsten.

yes, I've the same impression. :sad: Best Regards, Thorsten.

Yes, I could support the AINSER as well. But the remaining analog inputs won't be fully configurable, because such a function would conflict with the MBNG features where I did it better (than before ;). I also would like to evaluate, if the MBKB could be merged with MBNG - this would be the most simple way to maintain the project, and it would give us the highest flexibility. We would have the drawback that the minimum latency increases from ca. 130 uS to ca. 2 mS for a Fatar 61 Keyboard in worst case (to 1 mS if the optimized scan is used). The latency would be higher, since MBNG requires more headroom for all the other functions which are running in parallel. Would such a high latency be acceptable? Best Regards, Thorsten.

Hi Przemek, after my experiences with the Virus functions I think it's better if I only support synths which I own by myself anymore - so that I can test the implementation by myself. In long term I will probably take over the same "string based SysEx definition language" which I'm using in MIDIbox NG to simplify the customization. Then it could even be enhanced by users. :) Thanks! ;-) Main intention of this Librarian is to give MIDIbox SID/FM users a reliable way to upload/download patches - everything else is nice-to-have, but will be handled with very low priority by myself. Best Regards, Thorsten.

You guys challenge me... :wink: After doing the (simple) changes, I decided to remove the BANK command, and to replace it by the new "hw_id" and "bank" parameters in the EVENT command, because otherwise I fear that we will quickly loose the oversight. This results into a bit more writing effort, on the other hand it increases the flexibility - also unrelated to banks - since the hw_id (which addresses the hardware) is now totally independent from the "id" (which addresses the software function) In following test I ensured that Ilmenators proposal is basically working: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fbnk_2sel.ngc It modifies the bank of the upper/lower encoder row of the LRE8x2 independent from each other with the leftmost encoders. The selected bank is forwarded to a LED_MATRIX, which is an LED ring - but we could also pass it to LED digits once this option is available. In following test I ensured that Duggle's usecase is basically working: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fbnk_8sel.ngc The upper encoder row of the LRE8x2 board sends MIDI controllers, the lower row selects the bank of the encoder above. Instead of forwarding the bank value to a LED ring you could also pass it to a LED radio group of course (to your RGB LEDs) And instead of using encoders to select the bank, an EVENT_BUTTON ... meta=CycleBankOfHwId:<hw-id> should do the same job :sorcerer: Best Regards, Thorsten.

Based on the discussions in http://midibox.org/forums/topic/17542-bank-selection/'>this thread I changed the way how banks are handled in V1.007: MIDIbox NG V1.007 ~~~~~~~~~~~~~~~~~ o changed bank concept: the BANK command has been removed, instead the EVENT command got a new "hw_id" and "bank" parameter. A simple configuration example can be found under cfg/tests/encbanks.ngc More complex configuration examples under cfg/tests/bnk*.ngc o added meta=CycleBank (increments bank, resets to 1 if last bank reached) o additional new metas: SetBankOfHwId, DecBankOfHwId, IncBankOfHwId, CycleBankOfHwId The new handling with "hw_id" and "bank" is now also described in the User Manual: http://www.ucapps.de/midibox_ng_manual_ngc.html Best Regards, Thorsten.

To keep the oversight, I moved the discussion about the LED ring brightness to the http://midibox.org/forums/topic/17378-control-surface-pcb-for-16-encodersledrings-bulk-order/?p=154314'>original thread about the LRE8x2 PCB

No, the current isn't limited. With 220 Ohm I measure a voltage drop of about 2V, which means that the current drain is about 9.1 mA With 47 Ohm I measure a voltage drop of about 1V, which means that the current drain is about 21 mA But: the brightness doesn't really differ. As mentioned before, the results are much better on my initial MB16E construction (built 10 years ago) which uses low-cost LEDs with a high mcd value - this will solve the issue for the LRE8x2 board as well. Best Regards, Thorsten.

yes Best Regards, Thorsten.

I can confirm that the minimum output voltage is around 0.7V. I already tried lower resistor values - even 47 Ohm - but this doesn't change the brightness of the rectangular LEDs that are stuffed on my board. This experiment will be repeated once I got the new LEDs with a higher "mcd value" from Reichelt (see also ). Best Regards, Thorsten.

Alright, I've an idea how to handle this in the firmware, and will try it out this evening. The good point is, that the existing BANK definitions can still be used, but the actual selected element within a bank will be stored separately (in the event pool), and therefore can also be changed separately. It will even be possible to change the bank of multiple elements from a single button (or encoder or pot), since it's allowed to execute multiple meta events from a single element. More about this topic once my experiments are finished. Btw.: it is already possible to display the selected bank and parameter on the LCD, and in future it will also be possible to forward this information to a LED_MATRIX element which controls LED digits. Best Regards, Thorsten.