TK.

This is the wrong connection: 14 RS Pin 14 is a low-active RES (reset) input, which should be connected to Vdd (+5V) D/I (data/instruction, pin 16) has to be connected to RS instead. VEE: let it open Best Regards, Thorsten.

Ok, in this case it makes sense to try "TEST MIDI2" of the troubleshooting guide: http://www.ucapps.de/howto_debug_midi.html Is the MIDI data still loopbacked through the optocoupler? Best Regards, Thorsten.

I'm also a Mac User, and I don't use Xcode for app development. All you need is the terminal + a good editor (such as xemacs) + MIOS Studio. :smile: Best Regards, Thorsten.

Outcome: the usage of serial registers for the additional E lines was indeed the best solution, because the scalability is better than with multiplexers (e.g. a 1-to-16 MUX like the 74HCT4514), which would lead to many variants depending on the number of outputs (e.g. you are planning to use 20 LCDs, accordingly two multiplexers would be required...) This approach also means, that a common MBHP_DOUTX4 can be used to provide the E lines for 32 additional CLCDs Instead of chaining the shift registers with IC2 (which is in the critical timing path - software wise... - it's better to separate data from selection lines), the shift registers have to be connected to J28 of the MBHP_CORE_LPC17 module. This port has already the right pinout. I implemented the extension into the app_lcd/universal driver today. Maximum number of LCDs: 64 (limited by the size of the "display_available" variable only, but it's very unlikely that somebody will add more than 64 LCDs in future...) Up to 2 MBHP_DOUTX4 modules can be chained at the J28 port to get up to 62 E outputs. The first and second E line are still available at J15A/B Configuration: has to be done from the MIOS32 Bootloader Update app, it allows to set the number of LCDs in X and Y direction. X means, that multiple LCDs can be combined to a single "line" like known from MBSEQ V4 - e.g. it's possible to combine 4 2x20 LCDs to a 2x80 line. Test application: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmios32_test%2Fapp_lcd%2Fclcd_multi%2F It initializes and stimulates all LCDs as specified in the bootloader configuration. MBNG hasn't been enhanced yet, but I will do this soon. In future it will take the "LCD layout parameters" specified in the Bootloader once more than 2 LCDs are specified (means: the user has explicitly changed the configuration) Hardware-wise I'm unsure if additional buffers are required for the data lines. It depends on the capacitive load at the data bus, how many LCD modules can be driven by a single IC2 of the core module. Fortunately the output data of this shift register can be replicated, e.g. for a group of 8 LCDs - in this case, the serial inputs of IC2 have to be connected in parallel to the additional 74HC595's With such a configuration, the D7 data lines of all LCDs still have to be connected together for the feedback to P1.19, which is used to poll the busy state of the selected LCD. In order to prevent short circuits between the data output shift registers, it could make sense to add diodes to each "feedback line". P1.19 has a pull-up during the polling loop, busy=0 is the "active value", which means that the anode should show to P1.19 Best Regards, Thorsten.

That's Linux... (however, on MacOS we've sometimes similar incompatibility issues - fortunately not with the MIOS32 toolchain). IMPORTANT: the codesourcery release is not qualified for some MIOS32 applications, such as MIDIbox SEQ V4 The "newlib" implementation can introduce unwanted delays and/or higher memory consumption. Therefore we created an own toolchain with a certain newlib release which is acceptable - and shouldn't change it anymore. The source code of the whole toolchain can be downloaded from: http://www.midibox.org/mios32_toolchain/ Please use this one. Best Regards, Thorsten.

yes - it depends on the operating system, how the DAW displays the ports. Best Regards, Thorsten.

MIOS Studio 2 isn't based on Java anymore (no need to use Mandolane or similar), and it works perfectly under Windows and MacOS "as is". Before continuing debugging: could you please confirm that you are using this version: http://www.ucapps.de/mios_studio.html Because your descriptions are indeed matching with the observations somebody would make if he would use MIOS Studio 1 under MacOS Best Regards, Thorsten.

MBNG provides 4 separate USB Ports, which can be selected as dedicated interfaces in your DAW. So, no need to use MIDI IN/OUTs (e.g. connected to a GM5x5x5) for this purpose :smile: Best Regards, Thorsten.

Yes, there is a simple and secure way: - create a "dummy" session (or just copy your current session into a new one with the "Save as..." function), and change to this dummy session - enter the Disk page (Utility->Disk) - select "Session Export" - at the left side, select the name of your original session - at the right side of the export page, select "Type: Songs", the source song number and the destination song number - enter EXPORT -> done If you make an error, you will have a full backup with your dummy session. It could be deleted later once you are sure that all songs have been transferred correctly. Best Regards, Thorsten.

Finally the MIDIbox FM V1 panel is running with the latest (and greatest) Ctrlr 1209 release under Windows and MacOS :smile: Download links: Best Regards, Thorsten.

Finally the MIDIbox SID V2 panel is running with the latest (and greatest) Ctrlr 1209 release under Windows and MacOS :) Download links: Best Regards, Thorsten.

Just define one of the tracks as the guide track: From the User Manual: the optional Guide Track defines the loop length of a song position. Once the last loop has been played, all tracks will be synchronized to step 1. This allows to program breaks with a step length which is independent from the measure. Best Regards, Thorsten.

Ich sehe nur die linke Haelfte des Logfiles... Probierst Du es mal mit der gputils Version 1.0.0? -> http://sourceforge.net/projects/gputils/files/gputils-win32/ Gruss, Thorsten.

I will release a new panel tomorrow which is (finally) compatible with the latest Ctrlr version! :) Best Regards, Thorsten.

For those who will ask for a complete documentation in future... :shifty: Best Regards, Thorsten.

LRE8x2x4 is based on Fairlightiii's PCB: http://www.midibox.o...id=fairlightiii 4 modules are chained, so that 64 rotary encoders with LED rings are available. Power consumption: ca. 720 mA (it's still possible to supply this construction from a USB hub with 1A PSU) This MIDIbox NG is based on: a MBHP_CORE_LPC17 modulea SD Card to store the configuration (and later also the snapshots)four LRE8x2 PCBsan optional SCS, e.g. to switch between 4 banks and to store snapshots (in future) Configuration file: lre8x2x4.ngc Special notes: the .NGC file configures the ledrings for ULN2803 based Transistor Darlington arrays which will invert the selection lines for the LED rings. If you've built the PCB without the transistor arrays (which actually don't really improve the brightness), then please change the "DOUT_MATRIX ... inverted=1" definition to "DOUT_MATRIX ... inverted=0", otherwise the LED rings won't work correctly! Best Regards, Thorsten.

This is the proof: that Jerome created an excellent PCB design! :smile: (at least) 4 modules can be chained without termination, additional buffers or any other measures. And they are scanned without any robustness issues! Power consumption: ca. 130 mA per module (for both LED types I'm using) Together with the MBHP_CORE_LPC17 module + backlit LCD (200 mA) this results into ca. 720 mA -> the construction can still be powered from a USB hub with 1A PSU Best Regards, Thorsten.

please note that 2.5mcd is probably a typo at the Reichelt webpage, see also: I guess that the mcd value is much higher, therefore I recommend at least 10 mcd (and I'm very interested on the outcome with different LEDs) We should start a Black- and Whitelist! ;) Best Regards, Thorsten.

Hi Ralph, after startup, MIOS initializes the basic resources, calls Init() (to initialize additional resources), then USER_LCD_Init, then it displays the copyright message, and finally DISPLAY_Init is called. For your case, it could make sense to re-initialize the display during runtime, e.g. in Tick() E.g. with: void Tick(void) __wparam { static char init_done = 0; if( !init_done ) { init_done = 1; // switch to my own LCD driver MIOS_LCD_TypeSet(0x07, 0x00, 0x00); } } Best Regards, Thorsten.

Cool! :) MBNG has an integrated feedback protection. The forwarding algorithm differs between "received" and "internally generated" events. Best Regards, Thorsten.

Genau so funktioniert das Geschaeftsmodell von Reichelt! ;-) Gruss, Thorsten.

Hi, it doesn't matter, because the BLM port can be selected in the MIDI configuration menu. See also http://www.ucapps.de/midibox_seq/cs4/midi4.gif Note that on the MBHP_CORE_LPC17, J5B.A7 is MO3, and J5V.A6 is MI3 (swapped compared to MBHP_CORE_STM32) MI1/MO1 is the preferred choice, because the MIDI IN connection will go through the optocoupler. MI2/MO2 could be used for a TTL level connection (without optocoupler) Best Regards, Thorsten.

Ok, I see two problems: 1) unrelated, but first: LED:5/6 are permanently active once BUTTON:5/6 has been pressed, because "button_mode=OnOnly" is specified. The corresponding LED would turn off if you would use "button_mode=OnOff" (or just don't specify the button_mode 2) the radio grouping works correctly from my point of view. E.g. use MBNG standalone (ensure that your DAW doesn't send feedback values), switch between the banks and select either BUTTON:7 or :8 Then switch again between the banks - you will notice that the bank will hold the selected value. But if your DAW sends a feedback value, we've a conflict, because all buttons/LED EVENTs will receive the "cc=16 chn=11" value regardless of the bank selection (which is intended) - and this causes the effect, that button/LEDs of some banks will be deselected - only a single button/LED will be activated. The only solution I see is to use different CCs (or channels) for the different radio groups Best Regards, Thorsten.

Hallo Alexander, ich stehe gerade auf dem Schlauch: welche Tabelle meinst Du genau (es gibt so viele... ;)) Am Fileformat kann ich uebrigens nicht mehr aendern, ansonsten wuerden aeltere Konfigurationsfiles nicht mehr funktionieren. Die Ausgangs-Bezeichnungen am DOUT Modul entsprechen den Datenpins am 74HC595 Shiftregister. Aus historischen Gruenden (>10 Jahre) befindet sich der erste Ausgang auf der linken Seite, und somit auf Pin D7. Daran haben sich viele (erfahrenere) MIDIboxer bereits gewoehnt, es nun fuer die MIDIO128 zu aendern waere fatal. Als Kompromiss koennte ich die Rows von R7..R0 statt von R0..7 zaehlen, hilft das weiter? Gruss, Thorsten.

It's feasible! I added it to the Wishlist in the CHANGELOG.txt Since I'm currently busy with some other topics, it could take some days/weeks until I will find the time to integrate this feature, but it won't be forgotten! :) Best Regards, Thorsten.