TK.

Hi, No, because MIDI has no collision control, and also no handshaking protocol to ensure that MIDI events don't get lost. So - it doesn't make much sense... and therefore you actually would need a MIDI merger if you want to handle such a setup properly. I'm not sure if I understood the question correctly.... The first core has only a single MIDI OUT. As a forwarding point it will send incoming data, but also it's own generated data to the MIDI OUT. The optocoupler is not stuffed to avoid a short circuit under certain circumstances. Best Regards, Thorsten.

Ok, understood. Yes, the usage of CAN would simplify the wiring, and it would allow to communicate between the cores with reduced latency. But the integration of MBNet into the application is a low-prio task for me. It will require intensive testing at my side, and currently you are the only guy who would really use this approach due to the restrictions of your DAW. Therefore I'm thinking about a solution which already exists, and still would be sufficient for your usecase. The "MIDIbox Link" approach was the best solution for PIC based cores, which had only 1 MIDI IN and OUT -> chaining the cores, and tunneling MIDI events from forwarding points to the endpoint was the only solution for a bidirectional communication. LPC17 has 4 MIDI IN and OUT ports, this allows a better strategy for such a purpose, which still has acceptable latencies. And here it is: Under the assumption that: we need a fast communication path between the first core (connected to the host via USB) and the other cores, MIDI OUT3 of the first core sends the same data to all MIDI IN3 of the remaining cores. The selection of MIDI events has to be done with the channel number in this case (e.g. Core1 only listens to channel 1, Core2 to channel 2, etc...)The latency would be 1 mS per MIDI event to Core2/3/4 (*) the backpath to the host would mainly transmit MIDI events generated from motorfader or button movements. Latency doesn't really matter here, and we also don't have to expect so much MIDI traffic. Therefore for such a path we could use a chained arrangement. In the example above I chained MIDI IN4/OUT4 of the cores (*)the MBHP_MF_NG modules would have to be connected to MIDI IN2/OUT2 (not shown in this picture) via the normal MIDI interface. In theory you could connect them at TTL level as well, like the core-to-core interconnections), but the advantage of the optocouplers would be the galvanic isolation, e.g. between the PSU you are using for the motorfaders, and the LPC17 core supply which could come from the USB port. This would avoid the danger for jittering values at high resolution, and it would avoid ground loops.(*) in theory we could even increase the baudrate of the MIDI3/4 interfaces, e.g. 10 times faster -> 100 uS per event... or even faster. In this case we would reach the same performance like the CAN based solution!The attractive point on this solution is, that it doesn't require firmware enhancements. The MBNG application already gives you all functions to realize such a routing! I've prepared MBNG for 255 LCDs - but the electrical connections will be a challenge, because you won't be able to connect them in parallel without decoupling and "amplifying" the signals. Also the selection lines would have to be multiplexed - somehow - this will be difficult to handle. The RAM for the LCDs is limited to 512 characters (/edit: for CLCDs 1024 characters), which means that 64 2x16 LCDs could be handled, or 32 2x16 LCDs, or 25 2x20 LCDs, or 12 2x40 LCDs (I don't want to count the GLCD combinations ;-)) The LCD size configuration isn't implemented yet - and currently it's especially only possible to use 2 (G)LCDs with up to 64x4 characters. I will work on a more flexible configuration next year. The electrical part will be a challenge - it will probably require dedicated solutions depending on the LCD types being used. So: only recommended for experts who know how to develop the appr. circuits, and would directly implement & test the LCD driver by themself. /edit: discussion about displays will be continued here: Best Regards, Thorsten.

EC11 encoders send only 15 ticks per rotation - thats the problem. However, in V1.003 I made the acceleration mode (provided by MIOS32) configurable. Previously we only had the Auto mode, which selected the acceleration depending on the value range... MIDIbox NG V1.003 ~~~~~~~~~~~~~~~~~ o added "enc_speed_mode" parameter to EVENT_ENC Valid modes are Auto (speed automatically adapted according to the value range), Slow:0 .. Slow:7 (divides the increments), Normal (no special measure) and Fast:0 .. Fast:7 (accelerates the increments) A configuration example can be found under cfg/tests/encspeed.ngc [/code] Direct link to configuration example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencspeed.ngc It allows to test all available modes if 16 encoders are connected. If you've less encoders, just copy&paste at least the Fast:* examples into your .NGC file. There isn't much more that I can do at the software side. :-/ /Edit: meanwhile we've V1.004: [code] MIDIbox NG V1.004 ~~~~~~~~~~~~~~~~~ o some minor code cleanup Ok, during the cleanup I found out, that incoming MIDI events to AINSER parameters were not correctly forwarded... ;) This is fixed in V1.004 - probably the last release before christmas. Best Regards, Thorsten.

I could allow to set the default fast mode directly with the ENC command... but I think that there is actually a different problem which has to be determined first before doing such countermeasures (which are only compromises) Which encoder are you using exactly - did you buy it from Reichelt? Resp. do you have a datasheet? Best Regards, Thorsten.

Somehow I've the feeling that you don't listen to my proposals... I don't know, why you still want to chain LPC17 modules if there are more elegant solutions available which will lead to a faster and easier handling! Let's focus separate USB-MIDI connections, bundled to a single MIDI interface on your host. Meanwhile I guess that you are not a MacOS user, so here is the solution for Windows: - use a virtual MIDI cable, such as this one: http://www.tobias-erichsen.de/software/loopmidi.html - use a patchbay, such as this one: http://www.hermannseib.com/miditrix.htm After the installation of the virtual cable, you've a MIDI IN/OUT connection for your DAW. Connect the LPC17 modules, thereafter start MIDItrix Now just interconnect all MIDI OUTs of the LPC17 cores to the MIDI IN of the virtual cable And all MIDI INs of the LPC17 cores to the MIDI OUT of the virtual cable -> done I fear that if you don't go this route, you will be lost in an overcomplicated setup, and you will be unable to debug it if you don't know the technical backgrounds. Such a simplified setup also means, that you could use a dedicated LPC17 core per MF module + 8 LCDs The performance will be excellent due to the dedicated USB MIDI connections to your PC (you can bundle them with a USB hub of your PC hasn't enough USB ports) Where do you not agree with such a solution? Best Regards, Thorsten.

Yes, of course - a too long cable can cause such "communication failures" on the MBHP_CORE_STM32, because the interface works only at 3.3V The PIC based MB6582 works at 5V instead. Possible workarounds: - use a shorter cable... - or use a 74HC541 as a 3.3V -> 5V level shifter. See also the MBHP_CORE_LPC17 schematic: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf Best Regards, Thorsten.

This option is already implemented and working! :) A simple configuration example can be found here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_cc.ngc And a more complex example where motorfaders are sending Pitchbend instead of CC here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Flogictrl.ngc Such a configuration is already possible (in theory), but to be honest: it doesn't make much sense! You are adding unnecessary latencies between the host and core modules, and between MF_NG and the core module which controls the faders. It will also much more difficult for you to debug the core modules, e.g. to upload new configuration files, when you don't have a direct USB connection between host and core. Isn't your DAW able to handle multiple USB MIDI ports? If not: you could merge the USB MIDI ports at the host side, and route them to a virtual bus. Under MacOS I recommend the MIDI Patchbay which is simple to use, and very robust (I'm using it in very exotic setups ;-)) Best Regards, Thorsten.

...you forgot to put the MBHP_CORE_LPC17 module into your bag (as I will do during my christmas travelings) :twitch: I've enhanced the "First Steps" tutorial; now it also describes: toggle buttons buttons and LEDs in radio groups encoders LED Rings Banks -> http://www.ucapps.de/midibox_ng_manual_fs.html (press the "Reload" button of your webbrowser if you don't see the updates) Pots/Faders/Motorfaders are fully supported by the firmware, but not described in the tutorial yet. Please consult the configuration examples in the cfg/test directory instead, and the .NGC spec of course! Best Regards, Thorsten.

Ha - you experienced the Phrase Mode! :) Inside the Song page, press the Select button, and then GP9 (the button under "Phrase Mode") -> this will switch to Song mode. Best Regards, Thorsten.

Actually a "Song" can be used for two different purposes: it can either sequence pattern changes, or it can be used to "fire" pattern presets + mutes + tempo + mixer map + ... This is called the "Phrase mode"; it splits a song into 16 parts (A..O) so that different setups can be "fired" from a single song. For my own purposes, this is more useful than sequencing the patterns, because this allows to switch between preconfigured patterns "interactively" whenever I need them during a session. Probably it makes sense to implement both options (which could be configurable in the MBSEQ_HW.V4 file) Best Regards, Thorsten.

The actual reason was not that you have to save the file again, but that the event pool wasn't cleared on RESET_HW -> accordingly existing events triggered a text message which overwrote the "Hello World!". I had a different DEFAULT.NGC file and therefore didn't notice this. This is fixed in V1.002. In addition, following updates are available: MIDIbox NG V1.002 ~~~~~~~~~~~~~~~~~ o the patterns specified with LED_MATRIX_PATTERN are now reversed so that the bit orientation matches with the hardware. o reversed value ranges (min value greater than max value) now properly supported o support for ain_mode Direct/Snap/Relative/Parallax o incoming MIDI values can now trigger the output of EVENT labels if the "fwd_to_lcd" option is set to 1 in the related EVENT_* definitions. o support for "Radio Groups": button and LEDs can now be assigned to groups, which handle the same value over multiple elements. A configuration example can be found under: cfg/tests/radiogrp.ngc [/code] Best Regards, Thorsten.

Hi, with "bridged" you mean, that the CV outputs are at 0V (ground level) after power-on, right? Did you already try the integrated AOUT test of MBSEQ V4? Type "testaoutpin" in the MIOS Terminal to get more informations - this mode allows you to check the connections between core and AOUT_NG module. And just to doublecheck: the CV Configuration menu shows AOUT_NG, right? Best Regards, Thorsten.

Thats currently not supported, but could be added. Question is, if it would also useful if the program change would not only select a song, but also fire a phrase of the song. E.g. PC 0..15 would select Song 1, and fire phrase A with 0, B with 1, C with 2, etc... PC 16..31 would select Song 2, etc... Best Regards, Thorsten.

The encbanks file uses the predefined patterns. If you want to use different patterns (e.g. because of a different number of LEDs), you've to change the definitions with the LED_MATRIX_PATTERN command. Btw.: I just noticed, that patterns were stored (and defined) reversed - like on the PIC based MB64E: LED_MATRIX_PATTERN n= 1 pos= 0 pattern=0000000000000001 LED_MATRIX_PATTERN n= 1 pos= 1 pattern=0000000000000011 LED_MATRIX_PATTERN n= 1 pos= 2 pattern=0000000000000011 LED_MATRIX_PATTERN n= 1 pos= 3 pattern=0000000000000111 LED_MATRIX_PATTERN n= 1 pos= 4 pattern=0000000000000111 LED_MATRIX_PATTERN n= 1 pos= 5 pattern=0000000000001111 LED_MATRIX_PATTERN n= 1 pos= 6 pattern=0000000000001111 LED_MATRIX_PATTERN n= 1 pos= 7 pattern=0000000000011111 LED_MATRIX_PATTERN n= 1 pos= M pattern=0000100000111111 LED_MATRIX_PATTERN n= 1 pos= 8 pattern=0000000001111111 LED_MATRIX_PATTERN n= 1 pos= 9 pattern=0000000011111111 LED_MATRIX_PATTERN n= 1 pos=10 pattern=0000000011111111 LED_MATRIX_PATTERN n= 1 pos=11 pattern=0000000111111111 LED_MATRIX_PATTERN n= 1 pos=12 pattern=0000000111111111 LED_MATRIX_PATTERN n= 1 pos=13 pattern=0000001111111111 LED_MATRIX_PATTERN n= 1 pos=14 pattern=0000001111111111 LED_MATRIX_PATTERN n= 1 pos=15 pattern=0000011111111111 [/code] This confused a lot of users in the past, leading to the wrong assumption that they would have to reverse the LEDs on the hardware as well. Therefore with V1.002 the patterns will be stored/defined with a bit-orientation which matches with the hardware: [code] LED_MATRIX_PATTERN n= 1 pos= 0 pattern=1000000000000000 LED_MATRIX_PATTERN n= 1 pos= 1 pattern=1100000000000000 LED_MATRIX_PATTERN n= 1 pos= 2 pattern=1100000000000000 LED_MATRIX_PATTERN n= 1 pos= 3 pattern=1110000000000000 LED_MATRIX_PATTERN n= 1 pos= 4 pattern=1110000000000000 LED_MATRIX_PATTERN n= 1 pos= 5 pattern=1111000000000000 LED_MATRIX_PATTERN n= 1 pos= 6 pattern=1111000000000000 LED_MATRIX_PATTERN n= 1 pos= 7 pattern=1111100000000000 LED_MATRIX_PATTERN n= 1 pos= M pattern=1111110000010000 LED_MATRIX_PATTERN n= 1 pos= 8 pattern=1111111000000000 LED_MATRIX_PATTERN n= 1 pos= 9 pattern=1111111100000000 LED_MATRIX_PATTERN n= 1 pos=10 pattern=1111111100000000 LED_MATRIX_PATTERN n= 1 pos=11 pattern=1111111110000000 LED_MATRIX_PATTERN n= 1 pos=12 pattern=1111111110000000 LED_MATRIX_PATTERN n= 1 pos=13 pattern=1111111111000000 LED_MATRIX_PATTERN n= 1 pos=14 pattern=1111111111000000 LED_MATRIX_PATTERN n= 1 pos=15 pattern=1111111111100000 I hope that this change won't confuse you - therefore this warning ;-) No - the Standard Control Surface is available in most MIOS32 firmwares for runtime configuration without computer (resp. without the MIOS Terminal) See also the SCS description on the MIDIO128 page: http://www.ucapps.de/midio128.html E.g. it's possible to load/store configurations from this menu interface. In distance to MIDIO128 it won't be possible to change EVENT or hardware based configurations from the SCS - only the upcoming MIDI Learn function will allow to change/add events without the need to edit files on a computer. Best Regards, Thorsten.

As already mentioned in another thread (I guess by Ilmenator), LED rings require a DOUT_MATRIX configuration. See following schematic: http://www.ucapps.de/mbhp/mbhp_doutx4_ledrings.pdf A configuration example which gets use of LED Rings can be found here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencbanks.ngc With 8 instead of 11 LEDs, you also have to change the preconfigured patterns with the "LED_MATRIX_PATTERN" command. V1.001 handles detented encoders better than V1.000 If you still want to get faster encoders, assign the new "EncFast" meta event to a button. Configuration example: # use button 9 as "FAST" button EVENT_BUTTON id=9 type=Meta meta=EncFast range=0:5 lcd_pos=1:10:2 label="FAST%d" [/code] -> encoder movements will be 5 times faster whenever this button is pressed. But probably the changes in V1.001 are already sufficient (they have been tested with my MBSEQ V4 HW). Did you already try other enoder types, such as detented1, detented2 or detented3? The "type" has to be configured with the ENC command -> see http://www.ucapps.de/midibox_ng_manual_ngc.html Best Regards, Thorsten.

A new beta release is available: MIDIbox NG V1.001 ~~~~~~~~~~~~~~~~~ o maximum length of DIN/DOUT shift register chain increased to 32. This means that up to 256 digital inputs, and 256 digital outputs are available. o Number of virtual button and LED functions increased to 1024 o New meta event for speeding up ENC movements (EncFast, see .NGC documentation) o New meta events for emulating SCS buttons/encoder (see .NGC documentation) o Ethernet and OSC setup now stored with ETH/OSC commands in .NGC file o SysEx variables are now stored with a SYSEX_VAR command in .NGC file o EVENT_BUTTON_MATRIX and EVENT_LED_MATRIX now properly supported See cfg/tests/blm8x8.ngc for a simple configuration example [/code] Unfortunately the command format changes for ETH/OSC and SYSEX_VAR mean, that previously generated DEFAULT.NGC files will be incompatible (you will see some error messages after power-on). But I preferred to to change it now than never! To solve this, just store a new DEFAULT.NGC file by typing: [code] save default in the MIOS Terminal. The LED_MATRIX and BUTTON_MATRIX functions have been tested with the MBSEQV4 hardware! See also following configuration file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftk%2Fmbseq.ngc This file proves, that even exotic Button/LED matrix scramblings can be handled by MIDIbox NG! ;-) Best Regards, Thorsten.

Thank you very much! :) The change is in the repository now, and it will be available with the next release. Best Regards, Thorsten.

I can't confirm this, since I don't have a setup ready which would allow me to test longer SRIO chains. Currently I strongly focus the firmware development and test it with existing hardwares, such as MBSEQ, MB16E, MBLC The modified cable was only an idea how we could provide a simple solution without PCB re-design (which could take months till it's phased in - and many people would still own the previous PCB version - therefore no feasible ad-hoc option) You are probably right. On the other hand, spikes on the RS line could probably influence the SC line as well. This is just an assumption, as mentioned above I haven't checked this by myself. By adding resistors to both lines we should be at the safe side. The release package contains a binary for STM32, but I won't mention this in the MBNG documentation as a HW option, because the "if" and "whens" could confuse newbies too much. Main reason is, that the performance of STM32 is worse, so that the MBNG firmware doesn't show the same excellent latency than on a LPC17 core (in fact benchmarks are showing a performance of only ca. 50..60% of a LPC17 core). Another reason is, that since some months the MBHP_CORE_STM32 module can't be purchased from SmashTV anymore. However, for experts (like you) it shouldn't be a problem to handle this. Best Regards, Thorsten.

Hi, I can't add this, because the Librarian is not prepared to handle multiple SysEx blocks as a single patch. Such an enhancement would be too difficult and it isn't really worth the effort. Best Regards, Thorsten.

The serial output (SO) is a simple point-to-point connection between the '541 output and the serial input of the first shift register in the chain. So, only a single input pin is involved (-> low capacitive load) and the connection is short (-> low cable impedance). This is the big difference to the SC and RC line, which is loaded by the appr. input pins of all DIN and DOUT shift registers in the chain! Best Regards, Thorsten.

Thanks for the valuable input! :) ...won't be supported from my side anymore to simplify the documentation ;-) Thanks - seems that this is the right balance between technical details and user experience! :) Best Regards, Thorsten.

Meanwhile I've finished the major part of the .NGC file documentation, and I've also started with the "First Steps" tutorial which will be continued in the next days: First Steps .NGC Configuration File .NGL Configuration File Have fun! :) Best Regards, Thorsten.

Yes, under these circumstances I also recommend you to convert the MIDI notes instead of replacing the (perfectly working) keyboard scan hardware! The converter could either be MBHP_CORE or MBHP_CORE_LPC17 based, it doesn't really matter - actually even the PIC is too powerful just for this conversion job ;-) Best Regards, Thorsten.

I've no solution for this yet, but to ensure that this won't be forgotten I just have added this topic to the MBLC page. It will probably work in conjunction with a EVENT_RECEIVER which listens to multiple bytes instead only one - but this would blow up the memory storage format, because each EVENT would need to store the byte range. Once a solution has been found, the label could be inserted into outgoing SysEx, but also displayed on LCD with a special formatting directive (such as %t) This topic is still not forgotten (and on my TODO list). Let me evaluate this by myself first (e.g. with chained ) before giving a public advice. The go's and no-go's have to be documented properly at my side before newbie projects end into a disaster because of wrong assumptions. Addressing longer chains would be a more elegant solution than the introduction of a second SRIO chain, but it needs a certain awareness about the HW constraints. In any case, enhanced SRIO chains will always work if buffers are used between the DIN/DOUT modules - but there is no standardized way for this approach yet (no tiny MBHP module) -> but newbies always request this ;) Anyhow - the MBNG concept itself is prepared for both solutions! :) Best Regards, Thorsten.

No, this is definitely not normal, but it's also very likely not related to the firmware, but to your hardware. If you are not able to determine the root cause, please open a new thread in the troubleshooting section of this forum. It's especially important that you describe your hardware setup, otherwise remote diagnosis will be impossible. Best Regards, Thorsten.