[EVENT_KB problem with din_inverted=1?]

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

[EVENT_KB problem with din_inverted=1?]

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

[EVENT_KB problem with din_inverted=1?]

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

[My organ midification project]

Hi Thorsten,

 

re logic I have now read a great deal through the ngc and ngr documentation. It looks very much like the ngr scripts would be doing pretty much what I want. Question though is, when I run the script via a defined meta event, and the meta event is fired again while the script is still executing, will it enqueue the script so that it will start immediately again after the previous one has finished? Also is the script blocking so that no other script can execute or that the AI/DI/DO data acquisition gets blocked (can't imagine the latter)?

 

cheers

 

Mathis

 

edit: I've also noticed that the smallest amount of rows for a scan matrix seems to 4. Does that mean I can reduce the amount of DIO matrix modules to three?

 

edit 2: ohh, I get it. You can only define one script file which can contain multiple scripts which are selected by chosing the section. Still the question if the script gets re-enqued when the trigger is fired while it is still running or if the trigger gets ignored in this case.

[My organ midification project]

Thank you Thorsten and John (also for the extensive message detailing your past experiences and considerations!)

 

In order to reduce the scan time it seems crucial to keep the number of matrix rows to a minimum.

 

I can drive each manual as two separate 2*16 matrices. Making with two manuals and pedalboard overall five 2*16 matrices. I take it the best approach here would be to use a separate matrix DIO board for each, so 5 matrix DIO boards (making 10 DI and 10 DO chips ... 22 to go).

 

The 31 piston switches + 43 stop inputs (74 DI channels) are accommodated by another 3 DIN module (adding another 12 DI chips)

 

The 43 SAMs (86 DO channels) are then controlled by another 3 DOUT modules (adding another 12 DO chips) regardless of how they are buffered on the other end.

 

The Pot of the swell pedal should go directly to an AI channel of the Core module

 

so overall:

 

LPC17 core

5 x matrix DIO module

3 x DIN module

3 x DOUT module

 

Does this look about right and does one core module really support all those modules.

 

With all matrices having been reduced to two row matrices, can I expect a latency of less than 1ms or is that calculation too naive?

 

I also wanted to ask if the scripting language allows to include proper logic?

 

Considering the midi signal for one of the stop switches. Let's assume that the switch is off. This signal is set by the respective DI channel of that switch and sent out via midi to the computer.

 

The computer now wants to change the switch from off to on and sends out the changed midi signal. At the controller I would now like to do some logic choices. When ever the state of the computer midi signal changes, one of the 2 associated AO channels needs to be engaged for about 100ms but only if the latest DI channel reading is different from the computer midi signal.

 

A few examples:

 

Switch is off. I manually switch it on. This sends out a changed midi signal to the computer. The computer will repeat the changed signal and send it back. As the switch is already in the requested position I don't want any of the output channels to engage.

 

Switch is off. I press a combination button and the computer subsequently sends out the change request. As the switch is not yet in the desired position I want the correct AO channel to engage for 100ms to automatically change the switch position.

 

Is this kind of logic involving direct signals and in-/out going midi signals as well as states of previous iterations possible? I would probably also have to include a timeout until the switch can get automated the next time (~150ms to make sure that the switch is stable in it's new position and doesn't immediately gets switched back). Will there be a significant overhead?

 

As always your thoughts are highly appreciated.

 

thank you very much

 

best regards

 

Mathis

[My organ midification project]

Hi Thorsten

 

thanks for your reply. There is still a limit of 16 DI registers per controller in place isn't there. So if I split up the matrix into less rows I would need to go towards two controllers wouldn't I. Will send some PMs out to the people that have stated that they have successfully driven SAMS with midi box hardware and will post my findings here for other people that might run into the same problem.

 

Off topic: do you think that this might be a future platform for midibox?

http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/

[My organ midification project]

Hi,

 

I have just acquired a stripped out rodgers organ + pedalboard which I would like to use for an organ midification project. I have been roaming this forum for about a month, trying to collect the information and wanted to ask if you could give me some advice and make me aware of caveats which I hadn't considered yet.

 

The organ consists of:

 

2 x 61 key manuals: each in 4*16 diode matrix

pedalboard: 2*16 diode matrix

43 stop tabs (SAMS)

31 piston switches

1 swell pedal

 

I think I will need:

Control module: LPC17 + LPCxpresso

Manuals + pedalboard: DIO matrix board

stop tabs + piston switches: 3 * DIN Module

SAMS action: 3 * DOUT module (switching to the on state uses one channel, switching to the off state uses another: 2 * 43 channels, are the line drivers rated for enough current?)

swell pedal/Pot: should be accomodated by core module

 

Does this look about right? Does one core module support all this. What latency/conversion times would I have to expect. Re latency I read about the midibox kb project which is in development but I'm not sure if this is simply a firmware update or also different hardware or if it is applicable at all to what I want to do.

 

I was thinking of using the manuals in a 16*16 matrix. With both manuals and pedalboard I am at the moment 10*16 but I want the option of extending by a manual in the future and I assume that it is not easily possible to scan in numbers which are not powers of two anyway.

 

I wonder if you could also give me an indication of how much programming I would likely face (something I'm not worried about). In particular the SAMS might be tricky in that I need to control the two lines per channel via one midi signal. On an off-on trigger edge the on coil would need to get engaged for 100-200ms and on an on-off edge the off-coil. Does anyone have experience how easy it is to configure midi out in Hauptwerk anyway ... might be lost cause after all.

 

I would really appreciate your feedback.

 

thanks a lot!