Jump to content

MIDIbox NG Release + Feedback


TK.
 Share

Recommended Posts

I forgot to commit this file - it's available now.

 

 

Great! :smile:

I will release a new version with EVENT_KB (will allow to define a velocity curve via a map) + calibration for AINSER inputs tomorrow. 

 

Best Regards, Thorsten.

Cool, though I have to buy a new MCP3208 to try this. I accidentally destroyed two of them today...  :sad:  :sad:

 

Link to comment
Share on other sites

  • Replies 353
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

V1.018 is available:

 

MIDIbox NG V1.018
~~~~~~~~~~~~~~~~~

   o added EVENT_KB. See cfg/tests/kb_*.ngc for usage examples

   o new LCD formats: %N prints the note name based on the specified MIDI event,
     and %n based on the event value

   o new meta event: SwapValues - it swaps the primary and secondary value of an event.
     E.g. on a note event, velocity can be swapped with the key value.
     A usage example can be found in cfg/tests/kb_4.ngc, where the key and velocity
     value should be output by separate CV channels

   o AIN/AINSER configuration: added pinrange parameter.
     It allows to specify individual ranges for the connected pots to calibrate
     the physical min/max limits.

   o SCS configuration: added SCS num_items and lcd_pos parameters

 

 

Please note: after the installation of this update some WARNINGs about non-available KEYBOARD parameters could be print.

These parameters (ain_* and midi_*) are obsolete, please remove them from your .NGC file

 

To users who are already testing the keyboard functions: this is a new configuration example:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fkb_1.ngc

 

Best Regards, Thorsten.

Link to comment
Share on other sites

I tried the AinSer-support for the mod- and pitchwheel and it worked great.

 

But one small problem remains: the pitch-wheel is center-detended of course, and it uses a spring mechanism to return the potentiometer to the middle after you moved it. This is working quite well but it isn't 100% accurate, resulting in pitchbend values lesser or greater than 0. 

 

I'd think that every pitch wheel construction suffers from these (very) small pot movements, I wonder how other manufacturers handle this...

 

Is there a way to solve this in software? Something like an extended deadband: all pitchbend values from normally, say -512 to + 512 should now output pitchbend=0. Would that be possible?

 

Cheers

Lars

Link to comment
Share on other sites

Hi Lars,

 

my assumption was, that by using some clever min/max values it would be possible to shift the middle position into the 7bit based deadband which sends pitchbend=0 so that no additional measure is required.

 

It sounds like the variance is much higher than expected (I don't have such a variance with my own Pitchwheel)!

Before implementing the wrong counter measure (if any required), could you please enable debug mode ("set debug on"), let the pitchwheel spring to the middle position and write down the resulting 12bit value.

Please do this test at least 10 times (movement from both sides) - I would like to know all measurement results.

This test doesn't make sense before the min/max values have been specified with the AINSER command, because they will change the scaling.

 

Sidenote: this test requires an USB connection to display the debug messages!

 

 

V1.019 is available:

MIDIbox NG V1.019
~~~~~~~~~~~~~~~~~

   o added "Autoload" function: whenever a .NGC file has been uploaded via the
     MIOS Filebrowser, it will be automatically loaded, so that "load <file>" 
     doesn't need to be entered in the MIOS Terminal anymore.


   o EVENT_LED_MATRIX: now expects the 'colour' parameter to address the
     red (colour=0), green (colour=1) or blue (colour=2) LED.

     Note that it's still possible to control the LEDs from a single incoming
     MIDI message, e.g. by assigning the 3 EVENT_LED_MATRIX entries to the
     same CC number.

     But now it's also possible to address the LEDs independent from each other.


   o LEDs can now be dimmed with 16 brightness levels over the value range.
     This feature has to be enabled with dimmed=1 in the EVENT_* definition.
     Configuration example: cfg/tests/dimled.ngc

   o LEDs in a matrix configuration can be dimmed as well. The dim range is the
     same (0..15), but the effective dim level is limited by the number of 
     scanned rows:
        - 4  rows: only 8 levels (0..1, 2..3, 4..5, 6..7, 8..9, 10..11, 12..13, 14..15)
        - 8  rows: only 4 levels (0..3, 4..7, 8..11, 12..15)
        - 16 rows: only 2 levels (0..7, 8..15)
     Configuration example: cfg/tests/dimled_m.ngc

   o the new MIOS Terminal command "lcd" allows to directly output a (formatted)
     string to the LCD(s).
     E.g. try "lcd @(1:1:1)Hello World!"

     Note that terminal strings can also be sent via SysEx from a DAW:
     F0 00 00 7E 32 00 0D 00 <ascii-text> 0A F7


     Accordingly, this SysEx string will print "Hello World!" as well:
     F0 00 00 7E 32 00 0D 00 6C 63 64 20 40 28 31 3A 31 3A 31 29 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 0A F7

 

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Hey,

here are the values I measured. The pinrange was set 1700:2880 before, which gave me reliable pitch values from +8128 to -8192.

I was alternating between up and down movements.

 

 

2274

2284

2271

2278

2280

2280

2269

2284

2283

2276

2268

2295

2283

2269

2286

2268

2266

2283

2287

2283

2275

2260

2273

2262

2257

2278

Link to comment
Share on other sites

Thanks for the measurements!

 

The values vary between 2257 and 2295, which means that the tolerance window has to be 38, but after the 7bit conversion we would only have a tolerance window of 32

In order to solve this, I will add a function which enables a tolerance window of +/- 48 around the center position.

This would be exactly the same change that I already did for MBKB :)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

V1.020 is available:

 

MIDIbox NG V1.020
~~~~~~~~~~~~~~~~~

   o added "rgb" parameter.
     See cfg/tests/rgb_*.ngc for various examples.

   o added "spread_center" option to AIN/AINSER calibration.
     See cfg/tests/kb_1.ngc for an usage example.

   o reduced memory consumption of EVENT_* definitions

   o added MIOS Terminal commands: "show id" and "show hw_id"

 

 

@rvlt: please try:

 

AINSER pinrange=1:<pitchbender-min-value>:<pitchbender-max-value>:spread_center

 

 

in your .NGC file - it will be interesting if this solves the problem! :smile:

 

Best Regards, Thorsten.

Link to comment
Share on other sites

@TK.

A Button assigned as "08" doesn't work and gives out a error in comandline of MIOS Studio.

 

A button assigned as "01"-"07" works. Same for Button and LED "8" - witch is recommended..

Every 8 Buttons or LED added shows the same behavior. Like 8, 16, 24, 32, 40, 48, 56, 64, 72 i didn't test more...

 

for readability i appreciate the "01" form, because it makes the aligning more adequate for my eyes. 

 

I double checked it with 2 Cores, to me it seams to be a App thing... It seams to be so since midibox_ng_v1_018.

Link to comment
Share on other sites

  • 2 weeks later...

Hey,

 

I need some help with my configuration-file.

I try to change the CC which is send by a motorfader via the MF_NG module. Here is my file:

 

 

 

# Reset to default
RESET_HW


# MOTORFADERMODUL
MF n=1 enabled=1 midi_in_port=IN1 midi_out_port=OUT1 config_port=USB2 chn=1


# EVENTs
EVENT_BUTTON id=101 meta=SetBank range=1:1 button_mode=OnOnly
EVENT_BUTTON id=102 meta=SetBank range=1:2 button_mode=OnOnly
EVENT_MF id=3  hw_id=1 fwd_to_lcd=1  type=CC  chn= 1 cc= 118 bank=1
EVENT_MF id=4  hw_id=1 fwd_to_lcd=1  type=CC  chn= 1 cc= 120 bank=2

 

I have two buttons connected to a DIN at pin D0 and D1. I know, that they are working, because if I assign CCs to them, the monitor in MIOS is showing them to me.

But here nothing happens. It doesn't matter if I press a button or not. The fader is still sending CC# 118.

The MF_NG is working in Motormix Emulation - Mode.

Is it part of the emulation, that the fader is sending CC# 0 and CC# 32 besides the CC I define in the NGC?

 

Thanks in advance!

Link to comment
Share on other sites

I've to check this at my side.

 

Currently I can only answer this question:

 

 

Is it part of the emulation, that the fader is sending CC# 0 and CC# 32 besides the CC I define in the NGC?

 

Please check your MIDI router configuration, maybe you are forwarding events from IN1 to USB1?

 

But as mentioned above, I've to doublecheck at my side if banks are working correctly in conjunction with motorfaders, I haven't tested this.

 

 

Best Regards, Thorsten.

Link to comment
Share on other sites

I tested motorfader banks at my side and they are working.

 

BUT: while doing this, I found two "imperfections" (nasty bugs) in the MBHP_NG_MF firmware: the LSB wasn't correctly handled in Motormix/Mackie HUI mode, and the touchdetection sometimes prevented faders moves, although this should be disabled if the touch sensor mode is not disabled.

Both issues are fixed in mbhp_mf_ng_v1_004 -> http://www.ucapps.de/mbhp_mf_ng.html

 

Back to MBNG: here is my test configuration: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_banks.ngc

 

I noticed in your configuration that you've defined:

EVENT_BUTTON id=101 meta=SetBank range=1:1 button_mode=OnOnly
EVENT_BUTTON id=102 meta=SetBank range=1:2 button_mode=OnOnly

Since no hw_id is specified, these events listen to DIN input 101 and 102

 

But then you are writing: "DIN at pin D0 and D1."

 

 

Could it be, that you actually wanted to configure:


EVENT_BUTTON id=1 meta=SetBank range=1:1 button_mode=OnOnly
EVENT_BUTTON id=2 meta=SetBank range=1:2 button_mode=OnOnly

 

 

or:

EVENT_BUTTON id=101 hw_id=1 meta=SetBank range=1:1 button_mode=OnOnly
EVENT_BUTTON id=102 hw_id=2 meta=SetBank range=1:2 button_mode=OnOnly

 

Best Regards, Thorsten.

Link to comment
Share on other sites

A new version is available.

 

MIDIbox NG V1.021
~~~~~~~~~~~~~~~~~

   o support for the "single_usb" option, which can be enabled with the
     bootloader update application V1.012 ("set usb_single 1")

     Use this option if you are working with a Windows PC which can't handle
     the 4 USB ports correctly (e.g. stucking MIDI, Filebrowser operations are failing, etc.)

   o added .NGS file which allows to store and restore values into
     up to 128 snapshots (0..127).
     The snapshot can be changed in the "Snap" menu in the SCS

   o the "Snap" menu also allows to dump all events (e.g. after a new
     snapshot has been loaded)

   o added new (hopefully selfexplaining) meta events:
     SetSnapshot, DecSnapshot, IncSnapshot, CycleSnapshot, LoadSnapshot,
     SaveSnapshot and DumpSnapshot
     Note that multiple meta commands can be assigned to an event, e.g.
     to set, auto-load and dump a snapshot from an encoder write:
     EVENT_ENC ... type=Meta meta=SetSnapshot meta=LoadSnapshot meta=DumpSnapshot

   o added "no_dump" parameter to EVENT_xxx
     It specifies if an EVENT_xxx should be sent during a DumpSnapshot.

     no_dump=1 is set for EVENT_RECEIVER and EVENT_KB and events which are using
     type=Meta by default.
     If such events should be part of the dump, set no_dump=0

     For all other events/types no_dump=0 is set by default, set no_dump=1 if
     they shouldn't send MIDI events on a snapshot dump.

   o new label printf-control "%S" prints the snapshot number 0..127

 

 

Best Regards, Thorsten.

Link to comment
Share on other sites

I'm deeply into building an absolute beast of a midibox NG.

It has a SRIO chain consisting of 2 x DOUTx4 modules, a DINx4 module, followed by 4 x Fairlightiii 8x2 Encoder LED rings PCBs.

After attaching the 3rd and 4th Fairlightii PCB, all the LED rings started to flicker!

I soldered in-line a 100R resistor on the SCLK signal (bottom resistor in Thorstens photo). I didn't insert the other resistors shown below, just the one on the SCLK.

This fixed it! :frantics:

 WooHoo!

A workaround could be to insert the resistors directly into the cable:
mbhp_srio_cable_termination.jpg
I should nominate this picture for I fixed It ;-)
Link to comment
Share on other sites

Thanks tk! Your configuration is working! Nice!

But there is one fader, that is moving slower than all the others and another fader makes trouble and is very loud. Its moving down perfect, but up it stucks after a few cm. I think I need to check the connections again.

And another thing comes up: If I use the bank buttons, sometimes one or more fader is / are not moving to its other position. It sticks were it is. This happens randomly on all faders....

Maybe I should build another MF board. I'm not sure, if it's really working like it should.

Link to comment
Share on other sites

But there is one fader, that is moving slower than all the others and another fader makes trouble and is very loud. Its moving down perfect, but up it stucks after a few cm.

 

You can compensate this by using different MinDutyUp/Down and MaxDutyUp/Down values for the affected faders.

The values can be changed with the MBHP_MF_NG tool in MIOS Studio, after the right values have been find press the "Send" button to store the new settings permanently in EEPROM.

 

 

And another thing comes up: If I use the bank buttons, sometimes one or more fader is / are not moving to its other position. It sticks were it is. This happens randomly on all faders....

 

could it be that you haven't updated the mbhp_mf_ng firmware to v1_004 yet?

 

Best Regards, Thorsten.

Link to comment
Share on other sites

You've to calibrate the faders individually for best results.

Calibration is required due to (slight) mechanical differences.

Therefore my recommendation: use the calibration tool to get the "best looking curves".

 

 

 

I already updated to 1.004.

 

But the described effect matches exactly with the one which has been fixed in 1.004

Or did you disable the touch detection? Then this would explain the effect as well!

Please enable it.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 2 weeks later...

A new version is available:

 

MIDIbox NG V1.022
~~~~~~~~~~~~~~~~~

   o support for run scripts.
     See also the new manual page: http://www.ucapps.de/midibox_ng_manual_ngr.html

   o the new SysEx command ^label has been added. It allows to insert the ASCII code
     of a label string into a SysEx stream.
     See also cfg/tests/syxlabel.ngc

   o big GLCD font now correctly handled by ^txt and ^txt56 SysEx command

   o line number now displayed on errors in .NGC, .NGL or .NGR file

   o various bugfixes and improvements

 

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Is there an equivalent to the snapshot_at_poweron function in MB_NG yet? I'm looking for a possibility to send the values of my analog pots and switches after startup...

 

I played around with the snapshots and assigned a switch to the dump function in my default.ngc:

EVENT_BUTTON id=  4  type=META    meta=DumpSnapshot

 

 

 

this indeed sends a snapshot, but all values are set to 0.  

if I start turning pots and dump the snapshot again, it works.

 

What am I doing wrong here?

 

----

 

For an automatic snapshot dump after boot, I could do the following:

 

- set up a "virtual" button id (e.g. 20) in my default.ngc with the meta event stated above

 

- in my default.ngr I could put this:

trigger BUTTON:20

 

 

 

 

Is this the proper way to do this? Or is there already a more easy way that I'm not aware of?

Link to comment
Share on other sites

- in my default.ngr I could put this:
trigger BUTTON:20

Is this the proper way to do this? Or is there already a more easy way that I'm not aware of?

From what I understand, the .ngr is a way of making anything you want happen at startup (and much more..)

It looks like an easy way to me.

Alternatively: I'm not familiar with your use case, but generally I've found setting the "value=" property to an active value is like triggering it, which takes place on startup.

Edited by Duggle
Link to comment
Share on other sites

Thanks Duggle,

 

maybe easy wasn't the right word, it is actually super easy to do. I just wanted know if there is already an existing poweron-snapshot function.

 

re. the value-property: it doesn't work well with analog pots because the value you send doesn't correspond to the real pot.

 

Seems that for the snapshot dump to work you have to move an analog pot  to write it's value to some kind of buffer(?). If you don't do it the buffer is empty (values=0).  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...