jimhenry

My compliments to you Thorsten. The MIDIbox and MIOS are absolutely brilliant! ;D The more I learn about them, the more impressed I am. The Switch Matrix application is coming together beautifully. I now have an 8x8 matrix, table driven, supporting on/off events and push button events. Does anyone have a need for toggle events? I have the display showing the last button change and the MIDI message sent in response. I think those displays should be always available because with a large number of switch inputs, the ability to see what the MIDIbox is receiving as input is almost essential. It is also extraordinarily helpful to immediately see what MIDI message is sent in response to a button change to verify the table setup. To minimize the load on the processor from the display, I put the display in USER_Timer and added a counter so the display is only looked at once every 256 mSec. There is sometimes a just noticeable lag between a button change and a display. My thought is that the display is primarily for "static" testing and does not need to be realtime. Does anyone see any problems with this approach? If no one sees any shortcomings with what I have described, I'll clean up the code and make it available for others to test.

Mouser has a dual ganged 10K linear motorized pot: 316-1020-10K. Maybe there is someway you could replace one of the pots with a 500K audio pot. Or gang a 500K audio pot on the shaft?

It is confirmed that setting the MSB before sending the event solves the MIDI_EVNT0 problem. I left the MSB clear in the table so that the table can be written with a SysEx in the future if desired. I should have read the comments more carefully. :-[

I have the MIDI message table working to a point where I could use some guidance. Consider this code that I am using: ;; copy 3-byte entry to MIDI_EVNT* tblrd*+ movff TABLAT, MIDI_EVNT0 tblrd*+ movff TABLAT, MIDI_EVNT1 tblrd*+ movff TABLAT, MIDI_EVNT_VALUE movlw 0x9f movwf MIDI_EVNT0 ;; send MIDI event and exit call MIDI_EVNT_Send First, it seems that a call rather than a goto is needed for MIDI_EVNT_Send. Does that look right? Where I am really stumped is that something seems to go wrong with setting MIDI_EVNT0 from the table. If I add the two lines just before the call to force the value into MIDI_EVNT0, then MIDI messages are produced as expected. Without those two lines there is no MIDI output. I am baffled as to how the load of MIDI_EVNT0 from the table could be preventing MIDI output. What can I do to figure this out? I notice that a flag is set to produce LCD output to show what input point is closed but there is no display support and a message is given on the LCD that there is no realtime display. I tried grafting in the display from MIDIO128 but it seemed like that interferes with the input somehow. Is there some reason why this example can't support a realtime display? Or do I just need to try harder?

Further development of this idea is being discussed in this thread: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=midification;action=display;num=1088098331 Thorsten has now posted a second example which I believe represents an example "which uses a seperate shift register chain (which is captured more frequently than the "normal" chain) in order to minimize the latency."

I've been told that silver oxide is conductive so perhaps that won't be a problem. I've been told by the same person that the arcing that occurs when the contact is broken because of the inductive kickback of the magnet coils keeps the contacts clean. I do know that the 75 year old Wurlitzer console that I help maintain doesn't seem to ever have contact problems. Wish I could say the same for my 40 year old Rodgers with gold contacts. :( I don't think 12 volts rather than 5 is the issue. It is more likely inductive versus non-inductive switching and there's nothing you can do about that. I recall reading a suggestion to add a resistive load so that some meaningful current (100 mA?) was being switched. Another approach would be to use switch contacts of the type used to control swell shades. That will probably give you about a dozen inputs which will reduce the flood of MIDI commands. I reduce expression input to a dozen steps in the Miditzer to mimic swell shades. Recently I noticed that some sounds don't seem to react well to that. I realized that while swell shades have discrete steps, they also have considerable inertia so they are more continuous in effect than the 12 step switch input would suggest. So perhaps you need that flood of commands. Are you sure it will be a problem? If you decide it is a problem, you might be able to reduce the range produced by the analog input. For example, instead of 0-127 use 0-12 and then make whatever receives the expression input more sensitive. Of course, you don't really want to go to 0 for expression because no organ can be turned off by expression control.

I have created sm8x8_presets.inc which is available at: http://www.theatreorgans.com/jimhenry/SwitchMatrix/sm8x8_presets.zip Thorsten please look it over when you have a chance and let me know if I got this right. Will there be a problem with the DIN_MODES table growing to 256 bytes for a 16x32 matrix?

OK, I agree that makes sense. Am I understanding what you have coded so far in http://www.ucapps.de/mios/sm_example2_v1.zip correctly if I conclude that for the moment you are just computing a Note Message based on the pin number? And support of a table like midio_presets.inc is to be added? Were you planning on going that far or do you want to hand that off to John or myself? Would it be of help if I were to create midio_presets.inc type tables for the configurations that will be supported initially? What configurations will be offered initially? 8x8 and 32x16 presumably. Anything else? (Terminology wise should we refer to DINxDOUT or DOUTxDIN for the matrix configuration?)

Hi John, Yes, you understand the stop configuration idea correctly. It is a static channel assignment scheme. For theatre organs, 15 "ranks," which might include tuned percussions, plus traps works quite well. For classical organs that could be limiting. The idea is that you obtain organ like control of MIDI synthesizers without having to configure things. Just as a MIDI Note message is self contained, saying play this pitch and that channel, the stop messages are self-contained saying map this input channel to that output channel with this transposition. In both cases, Bank and Program changes can be sent to define what the significance of the channels is. The major contribution is that single MIDI Input Channel can control multiple MIDI Output Channels in a musically powerful way. There is a tension between defining things in a way that you can just plug them together and play and defining them in a way that the pieces have to be configured to play together. MIDI supports both approaches and each has its place. If you want to define a virtual pipe organ with a lot of ranks (MIDI Instruments) that are unlikely to be played at the same time, you want to do a dynamic assignment of instruments to channels. My scheme isn't useful for that because it has no notion of what ranks are. My scheme is only useful where there is a way to control the assignment of ranks to channels outside of the relay, a fixed one to one mapping being by far the easiest way to handle that. I could envision a MIDI Controller with stops that have labels like "8' Ch3." The performer could send a MIDI file that sets the instruments on the channels which then determines what "8' Ch3" sounds like. It might be bagpipes at one time and an electric guitar at another. The stop might have controls that determine what the stop means. The real goal is to abstract the idea of organ stops to a general MIDI controller.

I took another step up the bottom end of the MIDI Box learning curve last night and setup my DIN with the MidiIO128 project. Thorsten, you have done a fantastic job with the MIDI Box! Everything worked just as it should on the first try. It's a real thrill to connect a jumper wire and hear a piano note come out of the computer! ;D I'll stuff my DOUT board and setup the sm2 example in the next few days in a vain attempt to keep up with Thorsten on this project. I think it would be great if the Switch Matrix project could use the same approach to the event tables as IO128. It looks like IO128 supports all the MIDI Out events I need. If no one else want to take on modifying the IO128 SysEx support for Switch Matrix, I'll do it. I don't know Perl so it may take a little while for me to get everything done. But I'm pretty good at modifying programs in languages I don't know so I think I'll be OK.

This is slightly off topic but it is close and I think those of you participating in this discussion will be among the few who will quickly grasp what I am suggesting. I am planning to create a MIDI "organ relay" that can receive MIDI Note Messages and Stop Messages and produce MIDI Note Messages that reflect the logic that would be performed by an organ relay. Perhaps this could eventually be integrated into this project or another MIDI Box project. For now, it will be implemented on a PC. The Stop Messages would be controller messages, possibly a pair of General Controllers like 5 & 6. 4 bits of the value in the third byte would be an output channel. The fundamental operation of the MIDI Relay is to remember the Stop Message and setup a mapping of the Input Channel of the Stop Message to the Output Channel in the value of the Stop Message. A pair of controllers are used so that one of the pair sets the stop mapping and the other clears the mapping. The remaining 3 bits of the value define a transposition for the mapping. It would be nice to have 7 bits to define transpositions of -63 to +64 notes. However I can't think of any way to fit that into the framework of a 3 byte MIDI message generated by a stop. (This is where this become somewhat related to the topic of this thread.) So I am thinking of using the 3 bits to define transpositions of -3 to +4 octaves, 64' to 1/2' stops in organ terms. I am thinking another pair of controllers would be dedicated to mutation stops with the 8 transposition values mapped onto the mutation pitches commonly found in organs. A third pair of controllers would be dedicated to trap stops, primarily for theatre organs. This is a mapping of the OR of all Note Messages on the Controller Channel to Channel 10 with the Note given by the Controller Value. A fourth pair of controllers might be dedicated to couplers. These work exactly like the first pair of controllers but the controllers control a relay stage in front of the relay stage controlled by the 6 controllers described above. The coupler relay stage has to default to a unison mapping of course. Any thoughts on this approach to handling the stops?

Per points out the value of being able to readily reprogram the MIDI messages produced by the digital inputs. Thorsten indicates that there is enough memory to support even 1024 input points with a straightforward table. I think it is a good use of memory to make the configuration of the input to MIDI message translation easy. It ought to be consistent with IO128. John S, are you persuaded that we don't need to be tricky to conserve memory?

Yes I have. My scheme doesn't provide for different on/off values in the MIDI messages. Most messages could probably get by with 0 as the value of the off message. However the expression message probably requires arbitrary values of 0-127 for both on and off. Back to the drawing board. What is a reasonable number of bytes to use for the tables?

John, It's a clever scheme but it won't work for me. :( I'm probably pretty unique in that regard. My problem is that I won't be able to make the notes consecutive. The first and second touch contacts use the same common wire and that is immutably set by the mechanical construction. I could arrange things so the low order bit indicated first or second touch and bits 1 to 3 would be note offset. Not too hard to handle with code but terribly special cased. How about this variation on your idea: There is an input table that has 2 bytes for every input point. I think 512 input points is a reasonable maximum. (That means that's all I think I will ever need. ;) ) So this would be a 1024 byte table. The contents of each entry in the input table would be 4 bit event pointer, 4 bit channel, and 7 bit value. The 4 bit event pointer is a pointer into one of two 16 by 2 byte tables. One table is for the contact changing to closed and the other table is for change to open. Each 2 byte entry in the event tables is a MIDI event message prototype. The first 4 bits are the MIDI event. The next 4 bits could be a channel offset (or maybe a mask?) but would normally (always?) be 0. The channel is provided from the input table and possibly modified by the event prototype. The second byte is the value for the second byte of the MIDI message, where high bit set means not used. The last byte of the MIDI message is the value from the event table. Is 1,088 bytes a manageable amount for the tables to define the MIDI messages? Have I missed any MIDI events that could plausibly be needed but can't be generated by this scheme?

Nice work with the keyboard and fantastic report on the latency Thorsten! Is it possible that this could be table driven as it is in IO128? There will of course be many keys that are Note On/Off but there will also be stops where there is not so much standardization. I am developing a concept where there can be some standardization of a Stop On/Off message that provides the information needed by the receiving device to properly implement the stop. But even if these concept is proven, I'm sure there will be many who have other needs. There will also be trem tabs which hopefully can be Modulation Messages but there are some issues to be worked out on that. Swell shoe contacts will produce Expression controller messages. In short, it's a big mess!

I've drawn schematics for 16x32, 16x16, and 8x32 arrays which are available here: http://www.theatreorgans.com/jimhenry/ScanMatrixVer01.pdf Let me know if anything more is needed.

This sounds like a plan to me. I'll commit to doing a diode matrix of 16x32. Perhaps John S would want to define a matrix of half this size as a second configuration? Should it be 16x16 or 8x32? I'll do a schematic for my system. John S I can do a schematic for a smaller system too if you like. Can the analog input capability be left in? It doesn't matter to me, my swell shoes also provide contact closures. But I think there will be people who want to use various types of continuous controllers along with a large number of digital inputs for an organ type MIDI controller. Thorsten, I'll be more than happy to take the documentation off your shoulders. Just point me at what you consider to be the best example of documentation for this type of project and I'll do something equivalent.

I think I see the source of your latency estimates John S. "A 1 ms capturing cycle is used by the SRIO handler for the DIN and DOUT module." So the easy way to implement the diode matrix is to write a row select on one cycle, read a row on the next cycle, and so on. My first thought on achieving lower latency is to write something at the SRIO handler level specifically to use a DIN and DOUT together for matrix input. At a minimum it should be possible to do the row select and the read in one cycle. If settling time is needed after a row select, read and then select the next row. I do see now why using 2 DINs for a wider row reduces latency with this approach. But pushing the envelope, would it be possible to read an entire 32x32 matrix in a handler called every millisecond? If not, any guesses as to the maximum number of rows that could be read? It would seem that four rows (128 input points) should be possible as that will take only a bit longer than reading 4 DINs. By limiting this project to diode matrix input and MIDI output, presumably eight rows can be done at a time because there is no conventional DOUT required. So it would seem that we can have at least an 8x32 (256 input) matrix with 1mS latency, a 16x32 with no more than 2mS, and 32x32 at 4mS. This sounds pretty good.

This thread in the MIOS programming area is relevant to this discussion as well: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios;action=display;num=1084564072

The number I recall hearing bandied about for acceptable latency on keyboard input is 10 mSec. Â Bear in mind that whatever the MIDI output is driving will have latency too. Â So the MIDI Box should strive for even less than 10 mSec latency. Â We need to be very careful about creating too much latency in the key input. I believe that the 10 mSec figure actually lumps together latency issues and jitter issues. Â I think only the keenest of ears can sense 10 mSec delay from pressing a key to hearing a sound. Â But 10 mSec of variability in the time between pressing a key and hearing a sound I believe can be perceived as a "sloppy" action. Â Notes that are supposed to be sounding together start to have distinct attacks. Â Not that I could hear any of this. Â But there are performers who have said things to me that suggest they can hear these kinds of things. Â Just to provide a point of reference, at 120 bpm a sixty-fourth note is just over 30 mSec long. You seem to suggest that adding additional depth to the matrix (using more DOUT selected rows) adds substantial latency. I find that surprising since my superficial understanding was that both DIN and DOUT are extensible shift registers. Â My assumption is that row selection will be accomplished by loading a single row selection bit to DOUT and then shifting it one position to select the next row. Â I assume there is also some overhead each time a new row is loaded to the DIN shift register. Â 32x32 involves 32 DOUT shifts & DIN loads while 16x64 involves only 16 shifts & loads. Â Both require the same number of DIN shifts. Â So the difference between 32x32 and 16x64 should be 16 shift & load operations. Is the overhead of a DOUT shift & DIN load really about 1 mSec? Are you including key debouncing in your latency estimates? I agree that putting the diodes at the key contacts and reducing the keyboard cabling to 16 wires is a big advantage IF you have to cable the keyboards. Â If you are dealing with a console that already has cabling to the keyboards, as I am, it becomes irrelevant. Â In the later situation, avoiding multiple commons per keyboard becomes more important. Â Splitting the Wurlitzer common bus doesn't look like it will be too hard. Â Splitting it to 4 groups of 32 contacts seems acceptable (remember 122 contacts per manual on this one). Â I'm less enthusiastic about making 8 groups of 16. Â If I had only 61 contacts under a manual and a difficult to split common bus I would definitely think using a second DIN board to avoid splitting the bus would be a small price to pay. Â To me the big advantage of a diode matrix is using 1 Core and to a lesser extent the use of fewer DIN/DOUT boards. I fully agree that between you and I we should be able to allow Thorsten to work on other things. Â I can't imagine he has any shortage of projects. Â Looks like I should get busy and really start learning some of the nitty gritty of the MIDI Box.

I think those are very sound observations Thorsten. My theatre organ emulator, the Miditzer, isn't at all configurable for exactly the reasons you have stated. People sometimes ask about it but much less than I expected. Of course, I keep promising to improve that aspect so maybe that keeps them quiet. ;) I counted up the input points I'll need for a 2 manual Wurlitzer console, which is a pretty big job because of the second touch contacts, and 512 is more than enough. Making 16x32 and 8x64 configurations will probably satisfy almost everbody. My own effort will be 16x32 so we won't even be able to test an 8x64 until someone else steps forward with that requirement. Whoever codes this, and I assume that will be me if John Swenson doesn't want to do it, should probably keep in mind the possibility of other matrix dimensions. But that possibility goes out the window if it hinders the task at hand.

This is a continuation of the discussion started by John S in the Pipe Organ Conversion to MIDI thread. There he made the excellent suggestion that using a diode matrix approach like the one shown on the MIOS download page in the sm_example_v1 for keyboard input simplifies keyboard wiring. He suggests that TK's example could be easily expanded to support 1024 inputs using 1 Core, 1 DIN, and 1 DOUT. A question for those more familiar with the workings of MIOS, aside from the issue of parts count, is there any advantage to a 32x32 matrix as compared to a 16x64 matrix? I ask because it may be that some applications will not be able to easily split the common bus under the keys. If this project could support a 64 bit wide DIN, then splittling the bus could be avoided at the cost of a second DIN card. Is it practical to make the DIN width and the DOUT depth configurable so that they can used however needed, probably with an upper limit of 1024 inputs to keep the input to MIDI translation table simple? Jim Henry

John S, thank you for reminding us of the diode matrix approach. I think you are absolutely correct that this is a superior approach to MIDIfication of an organ console as compared to multiplication of DINs and Cores. It looks especially attractive to me as I will be MIDIfying an original Wurlitzer theatre pipe organ console where the keys (including the pedals) have second touch. That means there are two seperate key closures that have to be detected per key. But both of the two contacts under each key use the same common. So I already have a start at rearranging the common bus side for a diode matrix. Would it advance the development of the diode matrix project if I were to draw up the necessary matrix for my project? I am a programmer, although not PIC (yet), and pretty handy with hardware too. Let me know what I can do to be most useful. I have all the MIDI Box pieces that will be required already. Jim Henry www.MidiTheatreOrgan.com (Just call me John H for the purposes of this discussion. ;D )

From the way Hammond presets are described, I believe that they are equivalent to a combination action. Hammond used a bottom octave of piano keys with reversed colors rather than pistons to activate the presets (combinations). I think at least some of the Hammond presets could be set by the user although I seem to recall it being fairly difficult. It is a blind action in that the drawbars don't move but the piano key action is radio button like in that the keys latch down to indicate which preset is selected. The low C is the preset cancel as I recall. Hopefully a Hammond user can either confirm or correct this information.

You might also want to post the question under Midification which is an area more specifically focused on adding MIDI to keyboards.