MIDIbox NG Release + Feedback

[TK.]

Hi *,

this thread informs you about the latest release, and gives you the possibility to write down your feedback (bug reports, questions about existing features, suggestions for new features, etc...)

MIDIbox NG is in beta state!
Not all planned features are implemented, but the existing functions should (hopefully) work stable.

The latest build for MBHP_CORE_STM32 and MBHP_CORE_LPC17 can be downloaded at:
-> http://www.ucapps.de/mios32_download.html

List of planned/implemented features (press refresh button in your webbrowser to display the latest state):
-> http://www.ucapps.de/midibox_ng.html

Documentation (in progress):

• Hardware
• LCD Hardware
• First Steps
• .NGC Configuration File
• .NGL Configuration File
• .NGR Configuration File
• Standard Control Surface
• The complete Documentation ;-)

Best Regards, Thorsten.

[Marxon]

Ja ist denn heut schon Weihnachten?

[FantomXR]

Is it normal, that the ICs of my DIN are getting very hot after upgrading to NG?

[TK.]

Is it normal, that the ICs of my DIN are getting very hot after upgrading to NG?

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.

[Duggle]

Some questions:

• How about LCD display of dynamic text as in patch name(s) contained within a received Sysex message?
• Previously the 16SR limit was advised rather than forced. I have a project (in development, still after ~2 years!) that uses long chains, a linear LED display for keyboards, not so suited to matrix wiring. I assume it will still be possible to use MIOS32 functions to address long(er) chains of SR's? (when integrated into a NG framework device ,that is)

thanks!

[TK.]

Some questions:

• How about LCD display of dynamic text as in patch name(s) contained within a received Sysex message?

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)

Previously the 16SR limit was advised rather than forced. I have a project (in development, still after ~2 years!) that uses long chains, a linear LED display for keyboards, not so suited to matrix wiring. I assume it will still be possible to use MIOS32 functions to address long(er) chains of SR's? (when integrated into a NG framework device ,that is)

thanks!

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.

[TK.]

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.

[Duggle]

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! :)

Normally the signal integrity potential problems can be solved/prevented by:

• Good layout and wiring (e.g wire clock in a point to point (not star) manner, reduce the area of the loop formed by the signal path and it's ground return,etc.)
• drivers and termination.
  
  • I notice the LPC17 core has a 541 driver. That's good, but I predict that potential problems may be caused by the fast edge transitions onto the transmission line of DIN/DOUT connections. The fix is very simple: a (typical) 100 Ohm resistor in series with the signals at the output of the driver. This helps in a couple of ways: it slows down the edge transitions by enough to reduce excitation of resonant modes(ringing). It also provides a closer match of driver to line impedance resulting reflections getting absorbed rather than reflected -> reduced or eliminated line ringing.
  • The STM32 core has an open drain and 220R pullup driving the line. The effect of this can be seen pictured in this article The rising edge (driven by the 220R pullup) is fine, but the falling edge ( driven by the port pin drain) shows the signs of ringing. Since I wrote the blog article, I've discovered the best termination that fixes this is a diode in parallel with the series termination resistor at the driver source. In other words a 220R resistor in parallel with a signal diode (anode towards the driver, not the line). The affect of this is that a high is driven onto the line by the 220R pullup (passing through the diode) and a low is driven through the 220R series termination resistor.
  • Its a bit late to change/improve the PCB layout of 16LED ring PCB, but I think the way to drive a large string of these modules is with the termination schemes I've just outlined.

To guide newbies, it may be possible to explicitly state the conditions where it is possible to exceed the 16SR limit. That is, you can use nn of module yy with xx cm of standard ribbon, terminated in such and such way.

Anyhow it's a subject area I can see myself involved with a lot in the future. I'm interested in taking the keyboard display in the direction of 6 (or so) octaves of RGB. To get good colour resolution and variable brightness and invisible flicker, It may be necessary to address the DOUT chain with higher frequency updates (even faster clock rate, if it be necessary) so I'll be headlong into signal integrity issues, sooner or later!

[novski]

@Duggle: Am I going right that you mean pin 11 (Y7) on the 541 (IC1) by LPC17 Core?

Edited December 17, 2012 by novski

[Duggle]

@Duggle: Am I going right that you mean pin 11 (Y7) on the 541 (IC1) by LPC17 Core?

Yes, and also (more importantly) pin 12 which is the clock. The clock is distributed to all SR's in the chain (the data line is re-transmitted between each SR, so less prone to integrity problems, RST line won't cause problems either ), so it's much longer, more prone to problems such as ringing, which can introduce extra transitions and corrupt data in the SR's.

[FantomXR]

TK, you are awesome.

Programming was never so easy! I read through the first steps and everything seems pretty obvious.

[TK.]

Thanks for the valuable input! :)

[*]I notice the LPC17 core has a 541 driver. That's good, but I predict that potential problems may be caused by the fast edge transitions onto the transmission line of DIN/DOUT connections. The fix is very simple: a (typical) 100 Ohm resistor in series with the signals at the output of the driver. This helps in a couple of ways: it slows down the edge transitions by enough to reduce excitation of resonant modes(ringing). It also provides a closer match of driver to line impedance resulting reflections getting absorbed rather than reflected -> reduced or eliminated line ringing.

I fully agree that this measure will help.

A workaround could be to insert the resistors directly into the cable:



I should nominate this picture for I fixed It ;-)

Ok, so in the next release 32 SRs will be enabled, and I also increased the number of "virtual button/LED functions" to 1024 (considered that button/led matrices are connected)

[*]The STM32 core

...won't be supported from my side anymore to simplify the documentation ;-)

Programming was never so easy! I read through the first steps and everything seems pretty obvious.

Thanks - seems that this is the right balance between technical details and user experience! :)

Best Regards, Thorsten.

[novski]

TK, that doesn't match with my understanding of the description of Duggle.

I just took out my multimeter to check and found out, that you hooked a resistor in RC1,RC2 and SC.

You didn't solder a Resistor in the Y7 output (SO). Why?

best regards

novski

[TK.]

You didn't solder a Resistor in the Y7 output (SO). Why?

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.

[Duggle]

Great TK, I assume what wasn't working (reliably) now is?

If I'm correct regarding the signals going to the SR's, the RS line is non critical as it's transition latches the register data to the output pins (in the case of DOUT), and samples the input pins into the register (in the case of DIN). If there is bounce on this line it does not change anything.

[sTM32 core]...won't be supported from my side anymore to simplify the documentation ;-)

Does this mean no source code for STM32, or no documentation? It's just that I've been doing an additional side project with what I'm calling a "MiniCore" .

It involves the STM32 chip soldered to a LQFP SMD adaptor board. It's small, very cheap $0.90, plus $6.90 for the STM32F103RET6.

Its best suited for projects where you don't necessarily need heaps of I/O options connected to the core.

Anyhow, it works great with MIOS32 so I guess that is enough (heaps,actually!!!). It will come to light when I post details of my novel take on BLM (coming soon!). If NG can be used on this MiniCore platform it would be a bonus.

Oh yeah, I have a method of soldering the LQFP that I recon even the greenest newbie could successfully do! (It involves solder, iron, wick, and flux paste).

[TK.]

Great TK, I assume what wasn't working (reliably) now is?

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)

If I'm correct regarding the signals going to the SR's, the RS line is non critical as it's transition latches the register data to the output pins (in the case of DOUT), and samples the input pins into the register (in the case of DIN). If there is bounce on this line it does not change anything.

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.

Does this mean no source code for STM32, or no documentation?

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.

[FantomXR]

at first: I'm very happy, that many many things are working out of the box... the programming is self explaining... nice!

but allow me just a few questions...

a.) Where to set the LEDs of a LED-ring? For testing I've connected just 8 LEDs.

I tested with main stage and even MIDIfeedback works great (very very nice...).

b.) I need to turn the encoder on and on again till I get to the maximum of the assigned pot in main stage. I used the "Inc00Speed_Dec40Speed"-mode so I think there is no more speed. Is there a chance to get faster to the maximum?

c.) My encoders (EC11) are detended. As fas as I can see, removing it is not easy... I read the article in the wiki about it but I'm not sure, if it works the same way on mine. Anyway: The encoder just sends a signal after the "second" click....so: Turn - Send... Turn - Nothing... Turn - Send, etc. It is possible to send an event every step I do?

So long: THANKS!

Edited December 17, 2012 by FantomXR

[TK.]

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.

[Duggle]

That's great to know!

For large and performance critical stuff I am, and will, use LPC17 for obvious reasons. Its nice to have the possibility of smaller, cheap, and simple processor where appropriate.

[TK.]

a.) Where to set the LEDs of a LED-ring? For testing I've connected just 8 LEDs.

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.

b.) I need to turn the encoder on and on again till I get to the maximum of the assigned pot in main stage. I used the "Inc00Speed_Dec40Speed"-mode so I think there is no more speed. Is there a chance to get faster to the maximum?

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).


c.) My encoders (EC11) are detended. As fas as I can see, removing it is not easy... I read the article in the wiki about it but I'm not sure, if it works the same way on mine. Anyway: The encoder just sends a signal after the "second" click....so: Turn - Send... Turn - Nothing... Turn - Send, etc. It is possible to send an event every step I do?


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.

[FantomXR]

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.

Of course they are connected in a matrix. Sorry for not mentioning that.

I did not see these patterns in the encbanks file. But I will have a closer look on it.

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"

-> 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).

Thanks! I will check this out!

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

Yes, I did. But there was no improvement. I will check again later.

And another question: What is a SCS? I know it stands for Standard Control Surface. Is that a standard like mackie control?

Edited December 18, 2012 by FantomXR

[TK.]

I did not see these patterns in the encbanks file. But I will have a closer look on it.

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 ;-)

And another question: What is a SCS? I know it stands for Standard Control Surface. Is that a standard like mackie control?

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.

[FantomXR]

Great! Thanks!!

I need to buy a LCD today :) my order on taobao is not shipped yet.

[novski]

HI

I feel a little bit silly but i can't manage to load the first step of the Manual. :rolleyes:

load hello doesn't change anything on my display. MIOS Studio shows: [6491.557] Patch 'hello' loaded from SD Card!

And the File Browser ->see att.

???

:whistle:

Edit: -> didn't push save... please forgive me!

Edited December 18, 2012 by novski

[TK.]

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.