Speed up scanrate of NG by kicking out other scanroutines?

MIDIbox NG
1

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

Thank you very much!

Best,
Chris

2

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

3

Sure. But this is way not enough. 

4

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.

5

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? 

6

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 :wink:

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!

7

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 :wink:

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.

8

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

thanks again!

9

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

10

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?! 

11

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

12

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

13

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