EVENT_KB problem with din_inverted=1?

[mumblecake]

Hi,

 

I'm running in circles and was hoping that someone could shed some light on my problems.

 

I have an old keyboard which runs with inverted diodes (only came to life after I changed the DIO_MATRIX jumper to pull down ... thank god for TK's foresight to put that in!).

 

I took the ngc example for the keyboard driver, changed the din_inverted to 1 and nothing happened. I did not get any midi signals in the mios studio. I could clearly see the signals going in on the din on my osciliscope. I changed the debug mode to on and finally started to see some action. The debug information was clearly showing the key presses.

 

I now changed din_inverted back to 0 (which is meaningless as it is scanning on a high of the DO rather a low). Now when pressing the keys I started to see occasional midi messages. I'm not too bothered that I didn't see all messages as it was clearly the wrong mode. I should however see something when I'm running the correct mode. It seems that the EVENT_KB never gets fired when running the correct mode.

 

Does anyone have any idea, as I'm pretty much clueless (Pure guessing without even having the slightest clue of the software architecture .. is the keyboard event manager out of synch with the matrix scanning when running in inverted mode ... am I really the first one using this with an inverted diode keyboard?)

 

thanks a lot in advance for your help

 

best regards

 

Mathis

 

edit: I figured I better provide the used ngc in the (highly likely) case that I've just done something immensely stupid:

 

RESET_HW

# keyboard configuration
KEYBOARD n=1   rows=8  dout_sr1=1  dout_sr2=2  din_sr1=1  din_sr2=2 \
               din_inverted=1  break_inverted=0  din_key_offset=32 \
               scan_velocity=1  scan_optimized=0  note_offset=28 \
               delay_fastest=5  delay_fastest_black_keys=0  delay_slowest=100

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

 

# the ports bit was just something I added in my desperation

Edited September 2, 2014 by mumblecake

[TK.]

Hi,

 

just to ensure: are you using a keyboard with break contacts?

If not: please turn off the velocity option with "scan_velocity=0", otherwise no MIDI event will be sent as long as the corresponding break input isn't activated.

 

Best Regards, Thorsten.

[mumblecake]

Hi,

 

just to ensure: are you using a keyboard with break contacts?

If not: please turn off the velocity option with "scan_velocity=0", otherwise no MIDI event will be sent as long as the corresponding break input isn't activated.

 

Best Regards, Thorsten.

 

Thank you Thorsten

 

my "immense stupidity" has been unveiled. I was sitting here for hours thinking "it must be something simple" ... and it was.

 

I made myself familiar with most of the keyboard attributes but missed this one and had no idea what it was doing.

 

Problem solved!

 

Thanks a lot again (also for the pull up/down jumper on the DIO_MATRIX ... I would have climbing up the walls if that hadn't been in there)

 

Mathis

[mumblecake]

I have now a new problem.

 

It seems that the KB driver is designed for the keyboard to be in sections of n x 8 which means that the left part of a keyboard is generally on the first din chip and the right part is on the second.

 

My keyboard operates on a n x 16 matrix so it is now mapping keys 9-16, 25-32, etc to the din_offset location and squeezing the other keys 1-8, 17-24, etc together. I think it's possible to remap the keys by using meta events for the different ranges and transposing as required.

 

Is there maybe an option to disable this interleaving behaviour?

 

thanks a lot

 

Mathis

[TK.]

Hi Mathis,

 

there won't be a generic solution for such a special scrambling, but I could add a simple note mapping function similar to the velocity mapping into the firmware as demonstrated here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fkb_2.ngc

 

Would this solve the problem? Then I could enhance the firmware by this function quickly.

 

Best Regards, Thorsten.

[mumblecake]

Hi Thorsten,

 

thank you very much. I think that would help indeed. Would that be a lot of effort? The alternative attempt I was going to make was to grab out the keys in group of 8 using event_kb with different ids and transpose them accordingly.

 

Before you go to great lengths I would like to give that a shot first.

 

Just a quick question: The range of input keys seems to be limited to 128 (all examples show: range = 0:127). Is it not possible to capture the full 256 keys with two DIN and two DOUT modules defined in the kb driver?

 

thank you very much

 

best regards

 

Mathis

[TK.]

Yes, it makes sense to do experiments with the given possibilities.

 

 

The range of input keys seems to be limited to 128 (all examples show: range = 0:127). Is it not possible to capture the full 256 keys with two DIN and two DOUT modules defined in the kb driver?

 

Well, it's limited because in a "Note" MIDI message we can only differ between 128 different notes per channel.

 

Has your keyboard really 256 keys? Or is this because of the unusual matrix mapping... or are we speaking about multiple keyboards?

 

Btw.: since it doesn't provide velocity anyhow, you could alternatively handle it like a common DIN_MATRIX, which gives you a bit more flexibility. E.g. it allows to define individual EVENT_BUTTON for each key, so that you can define dedicated note numbers and MIDI channels.

 

Best Regards, Thorsten.

[mumblecake]

Hi Thorsten,

 

yes they are indeed 2 keyboards + pedal board ( 61 + 61 + 32 keys)

 

I have a look into the din matrix. Looking through the mappings on my keyboard I'm stunned ... they must have been drunk when they designed that. It's crazy!

 

I really want to avoid a bespoke software version (aka maintenance hell if too many of those code fragments accumulate) and will have a look at the DIN matrix solution.

 

thanks a lot

 

best regards

 

Mathis 

[mumblecake]

I have done the mapping and it turns out that it is in a pattern of (if you number the keys from left to right: C=1 C#=2 D=3 D#=4 ...):

 

16   1   15   2   14   3   13   4   12   5   11   6   10   7   9   8

 

I have attached the resulting ngc file (had to rename it to txt as the forums software would otherwise not let me upload) for the interested one.

 

A question towards latency. With the kb driver I would have to expect a latency of ~3ms for a full keyboard.

 

Is this comparable when using the din matrix driver instead (after all it must handle a lot more events in comparison to the one kb event which handled all inputs)?

 

Is there a latency advantage when using one 8x16 matrix (both keyboards) + one 4x16 matrix (pedalboard) in comparison to one 16x16 matrix (I've done the former in my ngc file)?

 

thanks a lot for all your help and input

 

best regards

 

Mathis

ORGAN.txt

[mumblecake]

Measuring with the oscilloscope a din matrix scan cycle for 8 rows takes ~3.5ms. Am I right to think that 16 rows would take about 7ms and having one 8 row matrix + one 4 row matrix should stay at 3.5ms (giving the advantage to separating manuals and pedalboard)?

 

thanks a lot

 

Mathis

[TK.]

Hi Mathis,

 

yes, your assumptions are correct.

 

I just noticed that the number of scanned SRIOs isn't configurable.

By default, the MBNG firmware will scan 32 DIN and 32 DOUT shift registers with each update cycle, but I guess that you don't use more than 4 DIN shift registers, which means that if the number would be configurable, so that only 4 SRs are scanned, you would be able to scan the keyboards with an update rate of ca. 0.5 mS

 

You could already try this out by changing the MIOS32_SRIO_NUM_SR value in src/mios32_config.h

 

Best Regards, Thorsten.

[TK.]

I just have added a new parameter to the .NGC file.

 

Just upload this prebuilt binary: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip

 

Now you can reduce the number of scanned SRs with (for example):

SRIO num_sr=4

in your .NGC file

 

Best Regards, Thorsten.

[mumblecake]

I just have added a new parameter to the .NGC file.

 

Just upload this prebuilt binary: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip

 

Now you can reduce the number of scanned SRs with (for example):

SRIO num_sr=4

in your .NGC file

 

Best Regards, Thorsten.

 

Hi Thorsten,

 

that's big news, not just for me I would think!

 

thank you very much, I will see to testing this new build asap.

 

best regards

 

Mathis

[mumblecake]

Hi Thorsten,

 

I played around a bit now and have to say that it works like charm. Absolutely brilliant. I'm trying to better understand what num_sr means: Does a number of num_sr=4 mean that four DI and four DO chips get scanned or is it two and two?

 

I have three more DIN and DOUT boards that need addressing. Does that increase my shift register count by 12 (four per board)?

 

thank you very much. My worry of latency certainly isn't one anymore

 

best regards

 

Mathis

[TK.]

Great! :smile:

 

 

I have three more DIN and DOUT boards that need addressing. Does that increase my shift register count by 12 (four per board)?

 

yes and no ;-)

 

num_sr defines how many bytes have to be bidirectionally transferred over the SPI interface and processed by MIOS32.

The number depends on the DIN and DOUT shift register chain length.

The longest chain defines the amount of bytes which need to be transfered.

 

So:

if the DIN chain is longer than the DOUT chain, you set the number of DIN shift registers.

if the DOUT chain is longer than the DIN chain, you set the number of DOUT shift registers.

if the DIN and DOUT contains an equal number of shift registers... ok, I think that you get the point now ;)

 

Best Regards, Thorsten.

[mumblecake]

Hi TK,

 

thank you very much for the explanation. Yes, it is indeed clear now. Less clear is however why I was so worried about a 5ms latency when I was completely oblivious to the fact that I would get a whopping 28ms latency from my soundcard.

 

I think at some point I will need to invest into a better proper ASIO soundcard (atm using a x-fi titanium with ASIO4ALL drivers ... creative drivers don't work properly) ;)

 

thank you very much again. I start to see light at the end of the tunnel of this project.

 

best regards

 

Mathis