Speed up scanrate of NG by kicking out other scanroutines?

[FantomXR]

Hey people,

some of you already know that I'm very interested in getting the keyboard-handling as smooth as possible. Some of you also know too that the higher scanrate of the KB-app allows a much higher velocity-resolution than in NG. NG is very limited in this case and only allows a few (like 10-20) velocity-values. What I'm trying to achieve is, to modify NG in that way that the scanrate of the digital I/Os respective the I/Os where the keyboard is connected to is higher to get a better velocity resolution. The reason for that is, that NG allows a much easier way to modify the keyboard parameters and also due to the SD-card it's very easy to make a backup of your configuration. I had it now a few times, that (for whatever reason) MB_KB was reset. 

So I took a closer look at the source code of what is going on under the hood in NG. As far as I can see the Period-Scanning is in both apps NG and KB 1ms. 

I'd like to know what blocks NG to give the digital I/O scanning a higher scanrate. Are there any other routines running in background that I can simply disable if I don't need them? I'll do some test the next days but if anyone can give some hints on this, I'd be happy to read them! ;-)

Thank you very much!

Best,
Chris

[latigid on]

First up, did you try to reduce the number of shift registers? Already this speeds up the scanning.

[FantomXR]

Sure. But this is way not enough. 

[TK.]

In src/mios32_config.h you could change the number of DOUT pages from 32 to 1:

#define MIOS32_SRIO_NUM_DOUT_PAGES 1

This will increase the scan rate by factor 32

Compile will fail with:

src/mbng_matrix.c:53:3: error: #error "not prepared for != 32 pages - many variable types have to be adapted!"
src/mbng_matrix.c: In function 'MBNG_MATRIX_DOUT_NotifyReceivedValue':

the appr. "#error" line has to be removed

It says, that all LED_MATRIX related functions won't work anymore, such as LED rings

Best Regards, Thorsten.

[FantomXR]

Hey TK,

thanks for that detail! That sounds good! I'll try that now!

What does "Page" mean? How many DOUTs will be supported if I set this to 1? 

[FantomXR]

Alright... I tried it! But without any changes. I get the following velocity values only:

1, 8, 18, 28, 39, 49, 59, 69, 79, 89, 100, 110, 120, 127

As you see there is kind of "logic" behind that... but I think you go with me if I say that 14 steps out of 127 is not that much ;)

Here is my test configuration:

RESET_HW

KEYBOARD n=1   rows=12  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 \
               din_inverted=0  break_inverted=0  din_key_offset=32 \
               make_debounced=1 \
               scan_velocity=1  scan_optimized=0  note_offset=28 \
               delay_fastest=50  delay_fastest_black_keys=0  delay_slowest=200

EVENT_KB id=1  type=NoteOn chn=1 key=any use_key_number=1 range=0:127

SRIO num_sr=2

 

//edit: Alright, I set scan_optimized=1 and I get a lot more velocities! Great! Are there any other ways to speed up the scanrate or is that going to deep? ;) 

Thanks already for that!

Edited January 11, 2017 by FantomXR

[TK.]

Yes, you could remove unusued functions from APP_SRIO_ServiceFinish() in src/app.c

E.g.

• remove SCS functions if the SCS isn't connected to DIN pins.
• remove MBNG_MATRIX_GetRow() if no BUTTON_MATRIX is used
• remove MIOS32_ENC_UpdateStates if no encoders are connected

That's all what can be improved, the additional overhead is caused by the application itself, at the end you would come to a downstripped version like MIDIbox KB ;-)

However, if it turns out that the removals from APP_SRIO_ServiceFinish help, then I could add runtime options to disable certain functions in future so that no recompile is required.

Best Regards, Thorsten.

[FantomXR]

Alright! Great! I'll check that out in detail and will let you know how it worked out!

thanks again!

[aurel33]

If it can helps, I'm using midibox ng and i'm getting 24 different values on fatar tp 40m, but i'm using the map feature.
I also used MidboxKb for a long time and i was sometimes getting some stuck notes. Then i switched to midibox ng when the MAP feature was added, everything is now working great, i really can't explain the problem i had with with midiboxkb.

# reduce number of SRs for faster scan

# with 2 SRs the scan takes ca. 500 uS instead of 2.5 mS

SRIO num_sr=2

 

# keyboard configuration

KEYBOARD n=1   rows=12  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 \

               din_inverted=0  break_inverted=0  din_key_offset=40 \

               scan_velocity=1 scan_optimized=1  note_offset=21 \

               delay_fastest=60  delay_fastest_black_keys=0  delay_slowest=300 \

make_debounced=0

 

# using an interpolation map to define the velocity curve

MAP1/BYTEI  0:0 40:24 71:52 100:85  127:127

 

 

# send MIDI event with mapped velocity value

EVENT_KB id=1  type=NoteOn chn=1 key=any use_key_number=1 range=0:127  kb_velocity_map=map1  kb_transpose=0

1
4
7
17
19
22
25
29
33
37
41
45
53
57
63
67
73
89
95
102
109
116
122
127

Edited January 22, 2017 by aurel33

[FantomXR]

20 hours ago, aurel33 said:

If it can helps, I'm using midibox ng and i'm getting 24 different values on fatar tp 40m,

Why do you limit your velocity to only 24 steps?! 

[aurel33]

I don't limit anything, i've just reported 24 different velocity values in midiboxng with my settings.

[FantomXR]

Okay, but why do you use a map with just 24 values? You loose a lot of the dynamic range of a keybed. Also I think it's better if you use the integrated interpolation-technique to adjust the velocity. It's way more easy and way less work ;-) 

[aurel33]

I don't use a MAP with 24 values, i'm using the interpolation MAP as described in my setup :

 #using an interpolation map to define the velocity curve

MAP1/BYTEI  0:0 40:24 71:52 100:85  127:12