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

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

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

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

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

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

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

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

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

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

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.

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

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/

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!