TK.

MIDIbox KB

184 posts in this topic

Hey,

sometimes especially when doing a glissando I get stucking notes. I can avoid this by using MIDIbox NG and set the number of shift registers to a higher value f.e. 6 or 8. But this on the other side lowers the velocity-resolution and I normally want to use the KB app for the keyboard. Do you have also those problems? I have that with different keybeds (all FATAR).

And another question: MIDIbox KB features an option that is named ain_bandwidth. I can not see such kind of option in NG. May I overlook something? Because: If I connect a expression pedal to my NG, play the keyboard and move this pedal, I get also a lot of stucking notes. I think that the DAW (or the NG-app) is stressed too much because of all this informations.

Thanks!

Edited by FantomXR

Share this post


Link to post
Share on other sites

Hey,

sometimes especially when doing a glissando I get stucking notes. I can avoid this by using MIDIbox NG and set the number of shift registers to a higher value f.e. 6 or 8. But this on the other side lowers the velocity-resolution and I normally want to use the KB app for the keyboard. Do you have also those problems? I have that with different keybeds (all FATAR).

Edited by nlate
reply

Share this post


Link to post
Share on other sites

Hi Christian

I got the same issue during testing of my modifications of the code. Imho the reason for that is caused by the debouncing routines in the fct: KEYBOARD_NotifyToggle() e.g. the code
...
 // debounce processing
  if( kc->scan_velocity ) {
    if ( !kc->scan_release_velocity ) {
      ....
    }

The routine doesn´t check all possible states, which could occure if the naked keybed is just played on a table. During glissandos some keys can bounce back so quickly that they accidently retrigger the make contact.
This effect is minimized on buildin keybeds by the (red) felt strip at the backend and near the turning point of the keys.
My code with the modified debounce check is a) not error-free and b) not in a publishable condition.
So I can´t fix your issue a.t.m.
Sorry and regards,
Jo

Share this post


Link to post
Share on other sites

Hey!

I'm not sure if this is really the reason for the stucking notes because a note is normally not triggered when just the make contact is active. Also the break contact needs to be active to create a note on.

I think it's more a problem due to the inverted diodes on the keybed. I need to set din_inverted to 1 if I want to use this keybed (it's an old Fatar TP/8S from a Roland A70). I also discovered, that the velocity-resolution is much lower on din_inverted 1 as on other boards which don't have the inverted diodes. It get's even more dramatic when using NG instead of KB. In NG I have only about 10 velocity steps with this keybed....

I checked the schematic of the keybed and it should be possible to simply cut and turn the diodes so I can use din_inverted 0. Maybe this solve those issues.

Thanks,
Chris

Share this post


Link to post
Share on other sites

Hi Chris,

I built a custom keyboard with inverted diodes, and had the same issue in NG. The solution was a massive rewriting on the nlate mentioned debounce processing code. It works now perfectly without any stacking notes. I will upload my modified routines to the playground as I get close to my PC.

Norbim

1 person likes this

Share this post


Link to post
Share on other sites

Hi Chris,

I built a custom keyboard with inverted diodes, and had the same issue in NG. The solution was a massive rewriting on the nlate mentioned debounce processing code. It works now perfectly without any stacking notes. I will upload my modified routines to the playground as I get close to my PC.

Norbim

This sounds awesome!! Thanks!

Share this post


Link to post
Share on other sites

Sorry I cant upload at the moment to my playground, but attached the diff. I modified the keyboard.c only in modules/keyboard. Here is my keyboard spec from the NGC file:

# keyboard configuration
KEYBOARD n=1   rows=10  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 din_inverted=1  break_inverted=1  din_key_offset=32 scan_velocity=1 scan_optimized=0  note_offset=0 make_debounced=1 delay_fastest=20  delay_fastest_black_keys=0  delay_slowest=500


Hope this helps.

Norbim

 

keyboard.c.diff

Share this post


Link to post
Share on other sites

Hey,

thanks for the file! I'll try to compile the app tomorrow! 

I'll keep you posted.

Best,
Chris

Share this post


Link to post
Share on other sites

Sorry I cant upload at the moment to my playground, but attached the diff. I modified the keyboard.c only in modules/keyboard. Here is my keyboard spec from the NGC file:

# keyboard configuration
KEYBOARD n=1   rows=10  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 din_inverted=1  break_inverted=1  din_key_offset=32 scan_velocity=1 scan_optimized=0  note_offset=0 make_debounced=1 delay_fastest=20  delay_fastest_black_keys=0  delay_slowest=500


Hope this helps.

Norbim

 

keyboard.c.diff

Hey!
I checked that and compiled it. I have the problem that no Note Off is send when I release a key. Any suggestions?

 

//edit: Okay. I did "set kb 1 release_velocity on" and it works ;) Thank you very much! I wonder if I can disable the release-velocity because I don't use it. But like I said. If I switch it off, there will be no note-offs generated :(
Ah! Now I understand. There are two options:

1.) Set release-velocity on, set make-debounced off: High velocity-resolution but sometimes notes will send a velocity value of 1 when pressed (even when it's pressed much harder). This behaviour is random!
2.) Set release-velocity off, set make-debounced on: Lower velocity-resolution, but all notes play like they should.

Edited by FantomXR

Share this post


Link to post
Share on other sites

Yes, the code was worked out for the second case only, because I need only this option. I know it is not an universal solution, even I'm sure it will not work with non inverted diodes. I soldered my diodes the wrong way by mistake, and it was easier to alter the code than change 138 diodes....

One thing that surely works in NG is break_is_make on  for organ style playing.

Edited by norbim1

Share this post


Link to post
Share on other sites

Okay! Thanks for the code! This is definitely better than before :-)

maybe TK will spend a bit time on this and can improve the app if we kindly ask him ;-)

Share this post


Link to post
Share on other sites

@norbim1: Which values do you use for SRIO num_sr=  and debounce-cycle?

Edited by FantomXR

Share this post


Link to post
Share on other sites

Sorry for the late answer:

SRIO num_sr=2 debounce_cycles=0

# keyboard configuration
KEYBOARD n=1   rows=10  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 din_inverted=1  break_inverted=1  din_key_offset=32 scan_velocity=1 scan_optimized=0  note_offset=0 make_debounced=1 delay_fastest=20  delay_fastest_black_keys=0  delay_slowest=500

Share this post


Link to post
Share on other sites

Btw.: please update the repository - yesterday I noticed that in MBNG the KEYBOARD_Periodic_1mS() function was running in the wrong task (background instead of APP_Tick())
This could cause random velocity values if LCD messages are print as well.

Best Regards, Thorsten.

 

Share this post


Link to post
Share on other sites

Updated, but caused a HardFault. I have to check my working copy and the tool chain, because I have just changed to W7 from good old XP. It works with the prebuilt ng_v1_033_pre16 (excluding the modified KB handler) without HardFault, so I'm afraid the fault is at my side. Will check tomorrow.

Norbim

Finally I've successfully built. Ngr from memory works fine.

 

Edited by norbim1

Share this post


Link to post
Share on other sites

Hey TK,

in the past two weeks I ran pretty much into the problem, that the keys of the keybed do not react equally...some are more sensible than others and vice versa. I could go and create a velocity-map for every key but as you can guess this would be a lot of code and a lot of stuff to do.

I'd like to ask you if you think it might be possible to somehow control delay_fastest / slowest for every key instead of the whole keyboard. Or does that require a lot of changes / addons in the code?

Thanks!

Share this post


Link to post
Share on other sites

For the records: Christian and I worked out a calibration mode which is now available in the repository.

More details about the calibration procedure at the MBKB webpage soon.

Best Regards, Thorsten.

Edited by TK.

Share this post


Link to post
Share on other sites

Hello everyone !

I've just started building my midibox kb project(with a fatar tp40 keyboard), i have some question regarding the connection of a sustain pedal and aftertouch strip to the Ainser8 module.

I have some trouble reading the ASCII shematics and by reading the thread it seems i need a 1k resistor, but i'm not sure where to put it.
Is there some schematic available?

I'm think about :  the + of my sustain pedal > 1k resistor > J6.A1, and the ground to Vs. Am i right?

 

For the aftertouch strip, i' dont have any idea, i have 2*4 strip.

Thanks!

 

Aurélien.

Share this post


Link to post
Share on other sites

Connect the tip to 5V and the shaft via a 1k resistor to GND. Put the analog input of the AINSER right before the resistor. 

 

5V -----/ ---- 1k-----GND

                I

                ---> A0

 

BTW it doesn't matter if the tip is connected to 5V or the shaft. You can easily invert the values inside NG (should work in KB too) if the pedal works the wrong way around. 

Edited by FantomXR

Share this post


Link to post
Share on other sites

I never checked out aftertouch deeply. But as far as I know you need only three of the four pins. 5V, GND and the analog input signal. Search the forum. Someone gave some great informations about it here in this thread if I remember correctly.

And the reason why you have two of those strips is that the black and white keys have separate aftertouch strips. 

Share this post


Link to post
Share on other sites

Please read the documentation on ucapps. It's all there.

You can approach this by using NG instead of KB. 

Share this post


Link to post
Share on other sites

So wanting to start a KB project but wondering where do I get a CORE_LPC17 Module PCB? Thanks.

Share this post


Link to post
Share on other sites

or alternatively is it possible to build a MIDIbox KB with an MBHP_CORE_STM32F4 for the core? The docs make it sound like its only with a CORE_LPC17

so confused...

Edited by djversus

Share this post


Link to post
Share on other sites

In principle it should work, here's an STM32F4 build of the latest version of MBKB v1:

project.hex

As discussed above, MBNG should be fine (and be easier to configure).

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now