jb

At least some answers to your questions, I will try to make a picture this evening. I did exchange chips of DIN/DOUT without any result, and reconnected dubious wires. The cable's of the only manual I now have connected are less then one meter. I use a small adapter as power supply far away from the pcb's. The pcb's come from the MIDI shop in Germany. I use the usual gray computer flatchcable. The extra keys are consistent, in the sense that some chords are allways accorded with an extra key (continuously being turned on and off). I was thinking about testing with a voltage meter, but to me it seems a bit difficult to interpret when changing over time (I do not have an oscilloscope).

Today I tried a new PIC, made no difference. I checked all cables, improved some connections with only one manual attached, still no difference. When I use the 'simple' (slow) scanmatrix driver, there is no problem at all. I only have problems with sm_fast and code based on the sm_fast driver. So, it can hardly be a hardware problem (with some of the cables or anything else) since this would also occur with the 'simple' driver, both drivers result in the same DOUT/DIN activity isn't it? I would like to try the code with an older MIOS (for example 1.8), but only 1.9 is available for download.

Thanks to all for your replies. Well, I shortly indicated adding an extra manual in the first post. To be precise: I added the manual some months ago, connecting wires to DIN/DOUT. Had no time to update the software to support the added manual, so kept playing for months without using the extra manual. Everything worked perfect during these months. Last week I had time, and as a first step updated MIOS, from then I have the problem with the already existing manuals. To be absolutely certain to exclude any influence I disconnected the added manual. As I mentioned in my first post, I do see a pattern: 'the extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1'. I haven't looked at it for several days now, hopefully a fresh mind will turnout to be helpful... @jimhenry: I am very much interested in your project, I am certainly willing to test it. Depending on the current state I might collaborate, but I do not have a lot of time available.

I added a manual, so an additional 8x8 matrix to a DOUT and DIN. Everything worked okay, I could not play the new manual since the program does not support it. Then I upgraded Bootloader/MIOS and got into problems. I removed the new manual from the DOUT/DIN pins: does not make any difference.

Thanks for your attempts to reproduce it. I will try your suggestion. I suspect the new version of MIOS, since this is the only thing that changed, the hardware did not change and worked fine for years. The only other possibility I see, is that the update of MIOS/bootloader is faulty. I have no PIC burner so I ordered a new one.

I have diodes, in fact the same circuit of diodes connected to the keyboard functioned very well for several years, I did not change anything of it. Since I updated mios I have these problems with the fast matrix driver (not with the simple one).

The extra midi events are keys, that are not pressed. So it cannot be related to debouncing of my switches (?).

Aproximately two years ago I midified an old analog organ successfully, it worked flawlessly during these years. Now I am adding an extra keyboard and switches. I updated to the new MIOS version, and I am using the 32x32 code of QBAS. I modified the SM_NotifyToggle such that it sends MIDI events accordingo to my situation. However I encountered a serious problem: when playing more than 1 key at the same time, in some cases extra MIDI events are sent, especially when playing three keys. This never occurred before updating to the new MIOS. When playing certain chords a continuous stream of extra MIDI events are send consisting of a note on event followed by a note off event, than note on, note off, etc. The extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1. I removed all manuals and switches, but one (that always worked) en the problem remains, even when I upload the old example code for an 8x8 matrix, the original QBAS code, or the new code sm_example2_v1b (fast with debouncing). However, with the new code (not fast) of sm_example1_v2b the problem completely disappears, everything works as it always did. So it seems that all fast matrix code with the new MIOS version generate this problem.

thanks, in an old example app I discovered the definitions of the macro's.

I installed the new programming platform, and the examples compile fine. Now, I want to make use of the 32x32 scanmatrix code of QBAS (see http://www.midibox.org/forum/index.php/topic,8557.0.html) within the new programming platform. The gp complains about a lot of syntax errors and refers to lines with IFSET/IFCLR. I have learned from the forum that with the change to gp these macro's are not supported anymore, but I cannot find how to change them. Hopefully, someone can explain me this. An example of the problematic code is: ;; branch depending on current DIN value IFSET SM_SRIO_PORT_DIN, SM_SRIO_PIN_DIN, rgoto SM_BUTTON_HANDLER_SHIFT_1 SM_BUTTON_HANDLER_SHIFT_0 ;; do nothing if DIN pin already 0 IFCLR INDF0, bit_number, rgoto SM_BUTTON_HANDLER_SHIFT_Cont N.B. I have a lot of experience with C and can understand a bit of asm (and make simple modifications).

You need to add electronic switches, something I do not have experience with. For pedals reed switches and magnets are commonly used. To create a MIDI out you need one Core module, one DIN module, one DOUT module. This enables you to use scan matrices. You can look at the example code, a wiring diagram is available there. I changed the scan matrix example code such that it can scan two keyboards and pedal. Using the example code you can get one manual working, if you are this far you can contact me for the modified source code to be loaded in the core module. The whole project assumes some experience with electronics, but is not very difficult.

I just will let everyone know, that within some days a successfully midified an old analog electronic organ (Heyligers). I converted the keyboards and pedals to scanmatrix. The code of the fast driver available for download (sm_example2_v2.zip) did not work properly, that is: with some combinations (not all) of 4 or more keys MIDI events are repeated while the keys are hold down. It might be to the de debouncing routine, however I do not have enough knowledge of assembler to figure this out. I therefore used the code of sm_example1_v2.zip. I use one DOUT register, and one DIN register for each manual/pedal. The fourth DIN shift register is used for the stops. With my knowledge of higher level programming languages and some reading on the internet about assembler it was possible to hack the code of sm_example1_v2.zip in such a way that it reads the contacts of 4 8x8 scanmatrices. In fact I placed all code dedicated to reading the first DIN register in macro's. It works fine, and fast enough, that is no latency is noticed when playing on the organ. If someone is interested in my quick hack just let me know.