MIDIbox NG Release + Feedback

[TK.]

To all fans of .NGR files: please join the beta testing for execution from RAM: http://midibox.org/forums/topic/19728-request-for-beta-testers-ngr-script-execution-from-ram/

Best Regards, Thorsten.

[TK.]

I noticed that the last firmware version was released more than one year ago! Time to release a new one officially (after more than 20 beta versions):

MIDIbox NG V1.033
~~~~~~~~~~~~~~~~~

   o with this release, .NGR scripts running on a STM32F4 are directly executed from RAM in a compressed
     format, and therefore they are significantly faster, so that they could even be used for timing
     critical operations.

   o added basic support for SPI_MIDI
     This feature requires an update to MIOS32 bootloader v1.018
     In the bootloader update app, enter "set spi_midi 1" to enable the SPI MIDI device at J16 (RC2 chip select line).
     This will also disable the OSC ports via MBHP_ETH module, which is normally connected to this port.

   o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module).
     The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since
     each RGB LED can consume up to 20 mA!)

     Following meta event commands are available:
     - RgbLedClearAll (clears all LEDs)
     - RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255)
     - RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100)
     - RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100)

    Most simple way to test a LED strip: enter following command in MIOS Terminal
       ngr exec_meta RgbLedRainbow:9:100
    (don''t forget to wear sunglasses, or start with brightness 20!!! ;-)

   o added EVENT_RGBLED
     See cfg/test/rgbled_1.ngc for usage examples

   o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLED

   o SRIO num_sr=<value> reconfiguration works correctly with DIN/DOUT matrices now

   o added "inverted=1" to EVENT_BUTTON and EVENT_LED

   o .NGR file: added "load <setup>" command which allows to switch to another setup (.NGC, .NGS, .NGR, ... files)

   o implemented new meta command "SendEvent" which allows to remote control one or more events from a single event
     within a given value range and direction.
     See cfg/test/metalrn.ngc for a usage example

   o implemented new meta command "LearnEvent" which allows to learn SendEvent based controller assignments during runtime.
     See cfg/test/metalrn.ngc for a usage example

   o added new meta command "SaveDelayedSnapshot:<seconds>"
     It will request to store a snapshot after at least the given seconds.

   o added new event type "NoteOnOff", which will send a NoteOff event immediately after NoteOn (resp. actually it will
     send Note On with velocity 0 for runtime event optimisation)

   o added possibility to calibrate the delay_slowest values for each individual key of a keyboard.
     New terminal commands:
     - set kb <1|2> key_calibration on: delay values will be measured (method described at the MIDIbox KB webpage)
     - set kb <1|2> key_calibration off: captured delay values will be used: (<measured-delay> * delay_slowest / 1000)
     - set kb <1|2> key_calibration clean: shows the captured measurement values
     - set kb <1|2> key_calibration_value <key> <value>: allows to modify a calibration value directly
     - kb <1|2> delays: shows the measured delay values

   o keyboard calibration values are stored in a new file: .NGK, and can also be edited there

   o bugfix for DELAY_MS

   o bugfix for fwd_id to a non-existing ID with specific value

   o bugfix for maps with duplicated values

   o bugfix for sporadic file access errors reported during snapshot restore

The documentation has been updated as well

Best Regards, Thorsten.

Edited November 24, 2015 by TK.

[Zam]

Hello TK

Tks !

I just do the update

Look fine for the moment with my config.

The ngc ram is a good thing, now I don't hesitate to use meta runsection to emulate button/led pattern toggle (MCU automation mode in my use case)

So now the 1.34pre1 begin ?!? with 10bit CV map/table

My project is really growing up, I will update soon in the correct forum section.

Best

Zam

 

 

[Zam]

Hi again

Just thinking about new if_ * parameter for .NGC

if_more=

if_moreequal=

Best

Zam

[TK.]

Just write "if whatever > something then" resp. "if whatever >= something then"

Best Regards, Thorsten.

[Zam]

Just write "if whatever > something then" resp. "if whatever >= something then"

Best Regards, Thorsten.

you mean this for .NGR or .NGC ?

Best

Zam

[TK.]

If you mean the EVENT based conditions specified in the .NGC file, please give me an example where this makes sense (and I might give you a counter example ;-)

Best Regards, Thorsten.

[Zam]

:)

To light two LED with aftertouch and MCU protocole

Copy/past from my config, showing channel 6 led meter (for some hardware reason it's the only one fader loaded at this time)

aftertouch use value 0 to 15 for ch 1, value 16 to 23 for ch two etc... ch 6 is value 80 to 95

-------------------------

# this one dim the LED 44 (yellow) with 15 step (value 95 never happen...)

EVENT_LED     id=440 hw_id=44  type=Aftertouch fwd_id=sender:1860 range=80:95 dimmed=1

#this one light the led 45 (red) for max level
EVENT_SENDER  id=1860 hw_id=1860 fwd_id=led:45:127 if_equal=94

#with this one It will be possible to light the led 45 with the last two value

EVENT_SENDER  id=1860 hw_id=1860 fwd_id=led:45:127 if_moreequal=93

-------------------------

my counter example is way bigger with the little advantage of 2 bright level for red led

It work well too with 3 map for 3 led( for one channel), I don't try with more but no reason it don't work.

---------------------------

MAP60  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

MAP61  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  7 15 15 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 \
        0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

#yellow
EVENT_LED     id=440 hw_id=44  type=Aftertouch range=MAP60 dimmed=1
#red
EVENT_LED     id=450 hw_id=45  type=Aftertouch range=MAP61 dimmed=1

------------------------------

Best

Zam

 

 

[Zam]

Hi TK

I have a bug report.

Look like AINSER send strange value, it's a melt of jitter (lot of close value) and completely out of range value (like +8000 for PB data)

I try to debug this since two day at hardware side...thinking of something bad with all test/change I perform on it.

But I just try the last thing that have change since last time it work fine, I put back V1_033pre15, and everything work fine again

So something is wrong with AINSER in the V1_033

My confing is AINSER + AOUT_NG at J19 (lineRX) used as servo to PB

Best
Zam

[TK.]

There is no AINSER related change between pre15 and the current version.

See also: http://svnmios.midibox.org/comp.php?manualorder=1&repname=svn.mios32&compare[0]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1&compare_rev[0]=2211&compare[1]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1&compare_rev[1]=2243&comparesubmit=Vergleiche+Pfade

Could you please check if one of the examples (such as cfg/tests/ainser64.ngc resp. ainser8.ngc if you are using the unmuxed PCB) is working at your side?

Best Regards, Thorsten.

[Zam]

Hi TK

I perform new test today, I have to say that pre15 also have some problems, but not that huge as 1_33, so there is a difference somewhere, maybe at DAW side then ?!?

My idea now is maybe about PB feedback, maybe V1_33 is little slower and conflict with updated fader data from DAW.

I aslo notice in debug mod that when I touch one fader (that's an NGC "if" condition to send PB value) some other AINSER input also receive value change (even deactivated with # at NGC and grounded at hardware side) and the value jump erratically between fixed value like 16, 32, 256, 64, 1024, like it was a scaling from 7bit to 10bit ???

I just see I let the "num_pins=8" (from previous proto with AINSER64) but don't seem to change what happen

I will check with ngc test file too.

Best

Zam

 

[Zam]

Ok problem solved!

Tks to point me to try the basic test NGC.

Was then way simple to track the pb with few events (my NGC become little complicated)

So it's at hw side, I was able so see that pressing a button (without any event associate) completely corrupt J19 (AIN+AOUT) transmission and sending random AINSER value to the core.

At my analogue side everything is deep clean, with jitter under the mV range, then I remember I unsolder 0 and 5v between line RX and TX at sub25 cable, to avoid ground loops and voltage drop at lineRX with this poor cable, I already have a solid 0-5V cable in // to power the 64D I/O and 8A I/O at RX side

Well, I just resolder this 3 wire and everything is fine !!! the mess is somewhere at RX/TX line with interaction between both SPI data

What still puzzle me is why the impact was not the same with different OS versions !!! is there some modification about how line RX/TX is handled ?

Anyway it work now :)

Best

Zam

[novski]

Hi

Are there any known problems with the File Editor and new software? (eg. bootloader v.1.018 & NG 1.033)
I powered up my midibox project and whanted to change some stuf so i noticed that the newest MIOS_Studio seamse to scramble up the Text in the Browser
So i thaught to update the Bootloader wold solve, but that doesn't help. Seams like the two first in the List of my Files are scrambled like that:

I was able to download and Replace the false characters my problem is solved now, i make this post is just to let you know.

Regards, Novski

[TK.]

Hi,

there are no known problems, and I'm using the file editor whenever I'm working on MBNG, and I never noticed such an effect.

Note that the file editor works independent from the bootloader, the communication interface is implemented in the application.

It seems that after each quote (") two ÂÂ are added, except for the LCD command, where we see a different scheme.

Could it be that you edited the file with a different editor (which inserted these characters for some reasons) and then uploaded to the SD Card?

Best Regards, Thorsten.

[novski]

15 hours ago, TK. said:

Hi,

there are no known problems, and I'm using the file editor whenever I'm working on MBNG, and I never noticed such an effect.

Note that the file editor works independent from the bootloader, the communication interface is implemented in the application.

It seems that after each quote (") two ÂÂ are added, except for the LCD command, where we see a different scheme.

Could it be that you edited the file with a different editor (which inserted these characters for some reasons) and then uploaded to the SD Card?

Best Regards, Thorsten.

Hi, TK. Thanks for the answer.

Well since i made those files about 6-8 Months ago i realy can't remember if i made them with Textwrangler. (the editor i normaly use for any code edits on my mac...)
But what i can certanly say is that those files worked with the previous version.

Right now i don't have enough time to experiment with older versions (and i don't see older releases on ucapps.de) but, if you point me to previous versions of MIOS_Studio, Bootloaders and MB_NG i will try to find out wich version works an wich one doesn't, in the new year...

By the way i wish everyone and specialy all Midibox Gurus who helped me so much, a happy new year!
Regards, Novski

[TK.]

A new version is available:

MIDIbox NG V1.034
~~~~~~~~~~~~~~~~~

   o Support for interpolation tables:
     MAPs can now apply linear interpolation between data points.
     This allows to quickly define curves without the need to enter the values for the complete range.
     E.g. previously it was required to enter 128 values to create a curve for a CC controller,
     now it's mostly sufficient to define the same with 3..4 data points. MBNG will interpolate
     the values between these points.

     Interpolation tables can be defined with following commands:
     MAP<n>/BYTEI and MAP<n>/HWORDI

     A BYTEI map can define up to 64 datapoints with 8bit resultion,
     and a HWORDI map can define up to 32 datapoints with 16bit resolution.

     Usage examples can be found under cfg/test/map* and cfg/test/kb_2.ngc

     See the user manual for further explanations.

   o Support for 16bit maps: with MAP<n>/HWORD 16bit values can be mapped.

   o label "std_rgbled" renamed to "std_rgb" to avoid error message

   o Cursor handling on SysEx based GLCD output should now work correctly if the big font is activated

Best Regards, Thorsten.

 

[Zam]

Hi TK

I'm just lost my voice!!! 16 bit map

I report ASAP, I believe I will work late on this tonight.

Man...thank you

Zam

[FantomXR]

Awesome!!!

[Zam]

first report Ain seems to work fine

have strange things with my button led NGR patter, but I don't look deep and it's another topic

Just don't see Aout/CV in the supported hw, I will try now , maybe with sender/receiver?

Best

Zam

[TK.]

CV: if you need special changes for your usecase, please let me know

Best Regards, Thorsten.

 

[Zam]

Just now, TK. said:

CV: if you need special changes for your usecase, please let me know

Best Regards, Thorsten.

 

Yes, my system is bidirectional I "need" the map to also work for Aout, in fact I will use the exact same PB map for in and out

Best

Zam

[TK.]

I need more details to find a solution...

Could you please create a minimal .NGC file which demonstrates the control loop?

Best Regards, Thorsten.

[Zam]

################################################################################

AINSER n=1 enabled=1 muxed=0 cs=1 resolution=10bit
AINSER pinrange=1:4:4088

MAP122/HWORDI 0:0 160:320 319:570 535:1014 1026:1803 1515:3207 2019:5703 2479:7605 3037:10141 3521:12053 4047:16383

EVENT_AINSER  id= 1  hw_id=1  ain_mode=direct  type=PitchBend  chn= 1  range=map122  value=0  if_equal=button:8:1

################################################################################
AOUT type=AOUT_NG cs=0 num_channels=8

MAP123/HWORDI 0:0 320:160 570:319 1014:535 1803:1026 3207:1515 5703:2019 7605:2479 10141:3037 12053:3521 16383:4047

EVENT_CV  id=1  type=PitchBend  chn=1  range=map123  value=0

 

---------------------------------------------

Here it is, map 122 and 123 are inverted (i'm not sure about this?)

My map is fast done, 5dB then 10dB step according to fader real attenuation

The point is to have DAW and real fader attenuation matching, the sended data to DAW work fine.

This is for one fader, MCU protocole

Button 8 is just the touch sensor to send data only when touched

 

Best

Zam
 

[Zam]

Ok the button/led pattern problem is spotted, it is linked with the map in 1.034

I use a map and 2 button toggle mode to swap 4 interactive state (2led/2button), calling meta script, like an "complex" radio function

automation Off/read/write-touch/write-latch

map is a simple two value -MAP100 1 2-

I just realise the whole function pattern where inverted so I try  -MAP100 2 1-  and it work like before !!!

 

here is NGC for one button/led pattern (have 8 like this in total)

Quote

 

MAP100 1 2

##########
#read
EVENT_BUTTON  id=5   type=Meta   range=map100  meta=RunSection:1   button_mode=Toggle  value=2
EVENT_LED     id=3

##########
#write
EVENT_BUTTON  id=6   type=Meta   range=map100  meta=RunSection:2   button_mode=Toggle  value=2
EVENT_LED     id=6

 

and corresponding NGR part

Quote

 

########################################################
#Fader 1
#Read

if ^section == 1

  if BUTTON:5 == 1
   change LED:3 127
   change LED:6 0
   send NoteOn USB1 1 0x4a 127
   send NoteOn USB1 1 0x18 127
   send NoteOn USB1 1 0x18 0
   send NoteOn USB1 1 0x4a 0
   change BUTTON:6 2
  endif

  if BUTTON:5 == 2
   change LED:3 0
   change LED:6 0
   send NoteOn USB1 1 0x4a 127
   send NoteOn USB1 1 0x18 127
   send NoteOn USB1 1 0x18 0
   send NoteOn USB1 1 0x4a 0
   change BUTTON:6 2
  endif

 exit
endif

############################
#Write

if ^section == 2

  if BUTTON:6 == 1
   change LED:6 127
   change LED:3 127
   send NoteOn USB1 1 0x4b 127
   send NoteOn USB1 1 0x18 127
   send NoteOn USB1 1 0x18 0
   send NoteOn USB1 1 0x4b 0
   change BUTTON:5 2
  endif  

  if BUTTON:6 == 2
   change LED:6 127
   change LED:3 0
   send NoteOn USB1 1 0x4e 127
   send NoteOn USB1 1 0x18 127
   send NoteOn USB1 1 0x18 0
   send NoteOn USB1 1 0x4e 0
   change BUTTON:5 2
  endif

 exit
endif

 

Best

Zam

[TK.]

Quote

Yes, my system is bidirectional I "need" the map to also work for Aout, in fact I will use the exact same PB map for in and out

Yes, you need a reversed map, and in addition it has to be considered that the CV outputs are working at 16bit resolution. Which means, the outgoing values have to be 16bit instead of 12bit, so just multiply by factor 16

Try this one:

MAP123/HWORDI 0:0 320:2560 570:5104 1014:8560 1803:16416 3207:24240 5703:32304 7605:39664 10141:48592 12053:56336 16383:64752

Quote

I just realise the whole function pattern where inverted so I try  -MAP100 2 1-  and it work like before !!!

This was related to a stupid bug in the firmware: after upload it tries to find the specified EVENT value in the map to get an index (map_ix, can also be displayed with "show id BUTTON:5" in MIOS terminal).

It searched from the second item, the first was ignored.

Now fixed in this version:
-> http://www.ucapps.de/mios32/midibox_ng_v1_034b.zip

Best Regards, Thorsten.