jimhenry

I am working with Moonskin on this project. I got to a point where I hit a wall on the code and needed to go back to square one but other projects had higher priority so this one is on hold until July. The basic idea, which is to rewrite the innermost scanning loop in a way that allows the matrix dimensions to be set dynamically , looks feasible. As you can imagine, there are a lot of counters and indices flying around and I have some error in keeping them all properly synchronized. Its the kind of code where I need a bit of uninterrupted time so I can keep a clear head while I sort everything out.

The Miditzer simply provides MIDI Out. It routes the MIDI to FluidSynth by default so people will get sound without having to do anything extra. If you route the MIDI Out to a MidiBox it can drive pipes. Per Schultz has done this for testing Wurlitzer parts as they were rebuilt. AFAIK no one has actually tried to use the Miditzer as the relay for a complete playing organ. While it is possible in theory, I would suggest you try it to decide if it is really going to be satisfactory in practice.

Only had a time for a quick glance at Eric's sticking points. One I can quickly help with... CD is the DOS command for "Change Directory". When you have the black box where you are typing commands, you are running DOS, the archaic predecessor of Windows. So you need to enter something like >cd "My Documents" figuring out the right incantation for the directory you want where I have "My Documents" can be tricky. What you want is the directory that midio128.ini is in. Sometimes I'll put the file in a simply named directory at the root level like C:\midibox to make life easy. Then the CD command would be >cd c:\midibox No quotes need because there is no space in the name.

The newbies who use MIDIIO128 for Miditzer virtual theatre organ projects are working on documentation in the Miditzer forum. Since their discussions probably have more Miditzer specific content than Midibox content I think their discussions are in the right place. As this documentation becomes stable I will see that it migrates to the Midibox documentation collection. In the meantime, see http://www.northparkmeadows.com/midio_mysteries.pdf. Any non-Miditzer users who are using MIDIIO128, particularly if for organ midification, are welcome to join the Miditzer Forum at http://www.VirtualOrgan.com/ and participate in the MIDI Electronics area to use the support available there for MIDIIO128.

Is the original electro-pneumatic relay not available?

I think I am in the group that should have upload permissions for the Wiki. I don't seem to be able to upload though. I am able to go through the motions and it looks like the upload occurs. I just don't find what I've uploaded after it is done. Stryd tried uploading for me a few months ago and he couldn't do it either. So maybe this is a bump of an issue that was previously sent in a private message. I'm trying to upload Assembling_a_MIDIbox_Core.pdf.

The Miditzer community is working on a document that takes you through MIDIfying an organ console using the MIDIO128 project. So far, for the hardware part they are using my Building a Core and Wiring an LCD documents. There is a new Loading and Configuring MIDIO128 section that they've added. You can see what they have come up with here: http://www.jbwebserver.net/mforum/uploads/20081102_011310_Midio_Mysteries.pdf http://www.jbwebserver.net/mforum/uploads/20081102_011349_Midio_Mysteries.pdf This kind of stuff should become part of the new and improved Wiki so let us know what we can do to help this effort.

jb send me a private message with your email address and I'll send you MIOS_v1_5b and MIOS_v1_7 for testing.

jb, I am working on a project based on sm_fast. My objectives are driven by the needs of those MIDIfying organ consoles. My ultimate goal is a matrix of up to 32x32 dimensions with configurability comparable to MIDIO128. The QBAS project, as best I understand it, differs from what I am doing because it provides velocity sensing, does not provide debouncing, and is not pin by pin configurable. I can't promise that I will have project debugged in a time frame measured in less than months. If you'd be interested in testing or collaborating let me know.

;; branch depending on current DIN value BRA_IFSET SM_SRIO_PORT_DIN, SM_SRIO_PIN_DIN, ACCESS, SM_BUTTON_HANDLER_SHIFT_1 SM_BUTTON_HANDLER_SHIFT_0 ;; do nothing if DIN pin already 0 BRA_IFCLR INDF0, bit_number, ACCESS, SM_BUTTON_HANDLER_SHIFT_Cont

With these two items added to the design criteria, two cores really looks like the best option. Why do you not want to go that way?

How many DIN and DOUT boards are you using? Are they in two chains or linked together as one long chain? Starting with the board closest to the Core as #1, what board are the problem inputs on? What pin numbers (0-31) on that board? Something that looks odd to me is the appearance of true Note Off MIDI Command bytes. As I recall, MIDIIO128 does not generate such bytes. Could you post the relevant portion of your INI file please? Just for fun, could you try using other values in the affected portion of the INI file. Copying the relevant portion for the notes an octave lower might be a good test. Are the wrong values as shown by MIDI-OX always the same? Are they the same in MIOS Studio? (Stryd, this probably belongs in Midification.)

This is this first time I've seen the term "SCANROW" and I found this site that seems to explain it: http://www.largonet.net/midiboutique/products/whatis/whatis.htm If I understand it correctly, SCANROW is simply the typical common bus keyboard with parallel inputs into the encoder as is done in the MIDIO128 project. An alternative is what might be called "wide matrix" which was suggested by Graham Wykes. I am investigating this with Graham. The idea is to use something like an 8x64 matrix that retains the 61 note keyboard bus but allows all the manuals to be multiplexed into one input. At the expense of adding diodes, you save shift registers. The wiring issues are not inconsequential. I am leaning toward the idea that the wiring may outweigh the MidiBox hardware meaning that ease of wiring should dictate the choice of the MidiBox arrangement.

Assembling a SmashTV Core kit: http://virtualorgan.com/virtualorgan/FileLib/Assembling_a_MIDIbox_Core.pdf

If all your existing MIDI is on one MIDI cable then you want to configure the MIDI In of the MIDIO128 MidiBox to be MIDI Merge so that your stops plus everything else is on one MIDI cable connected from the MIDI Out of the MidiBox to MIDI In on your computer. The MIDIO128 discussions will be found in the Midification area.

If DOUT is not needed and programming effort is not a concern, how about using the DOUT data pin as a second DIN data pin. Connect the second group of 4 DIN boards as you would a group of 4 DOUT boards. Then you can shift both 128 bit shift registers in with the same clocks and read 2 data bits on each shift. You should be able to read all 256 inputs in 1 mSec. Why don't you want to use a switch matrix? You can use 1 DIN and 1 DOUT and then connect them to a board that has the diodes and pin headers to look like the pin headers on a DIN board. Of course, AFAIK you still give up having a DOUT that you can use as such and there might also be timing issues with larger matrices since you still have to shift in all the input bits in the matrix.

A real pipe organ usually draws about 100 mA through a key (or pedal) contact to an inductive load, a solenoid coil. When the contact opens it sparks and that burns off dust and dirt that might settle on the contact. Contacts that switch substantial loads are sometimes termed "wet" contacts. When you are switch for a Midibox DIN, the input draws negligible current without sparking. These are termed dry contacts. It is more difficult to provide reliable dry contacts than wet. If you look at relays, you'll find that there are relays specially made for use in dry contact situations. (Just so I don't mislead anyone, relays don't like inductive loads because the contacts are usually fairly close when open which allows the inductive sparks to do more harm than good.) So you might find that you have to clean spring wire contacts on a regular basis when used as dry contacts. I've never tried it but Stabliant 22 (http://www.micro-tools.com/store/item_detail.aspx?ItemCode=22 might be helpful. To avoid the moving wire problem, the wire contacts (silver plated phosphor bronze is preferred) are provided on blocks having two or more spring contact wires. One is connected to the common bus the other(s) are connected as signal wires. A shorting bar, a strip of brass with a silver coated edge, is connected to the moving pedal to short together the spring contact wires. Magnets and reed switches are attractive for pedals because they are less expensive and more reliable than the spring wire contacts IF you can get the magnets aligned correctly with the reed switches. You have to experiment with this because the alignment is not a simple one based on aligning the parts. You have to put the magnet where the magnetic field will interact properly with the reed switch. Reed switches are not good for manuals because the keys are too close together.

What do people think of using a 1 x 40 pin header rather than 4 x 10 pin headers for the inputs and outputs on DIN and DOUT boards? This would allow the use of IDE hard drive cables for these connections like this one: http://www.monoprice.com/products/product.asp?c_id=102&cp_id=10227&cs_id=1022700&p_id=1245&seq=1&format=2 US$ 1.98 for 38 inches with 4 connectors. Not to mention all the ones in your scrap box for $ 0.

I think Stryd has a good idea here. With regard to the handling of MIDI In to a MidiBox we have established that at least MIDIO128 will translate 8n ** ** to 9n ** 00. Thus, as it stands, one needs to use 9n rather than 8n in the .ini configuration table because MIDIO128 will use 9n to search the table when it receives an 8n status byte. If the tools that make a SysEx file from the text .ini file parsed 8n and 9n to produce the same result in the table that is actually loaded on the MidiBox, then there is no need to "paper" this issue with comments. It doesn't affect what MIDI Messages MIDIO128 will recognize. Sending either 8n ** ** or 9n ** 00 to MIDIO128 will turn off the selected DOUT pin. There is an underlying subtlety of the MIDI standard worth mentioning. The Note On/Note Off pair 9n/8n is the only pair of MIDI messages where on and off are done with two different status messages. MIDIO128 makes the assumption that MIDI Inputs for on/off control can be configured with just the first two bytes of the MIDI message. The third byte of the message is handled algorithmically. Thus, MIDIO128 does not provide any way to explicitly configure a DOUT pin as being controlled by 9n for note on and 8n for note off.

LyleHaze: Are you saying that values < 64 are OFF is how things should work according to the MIDI Spec, which I agree with, or how MIDIO128 does work now, which is not what I see by inspecting the code but I could be wrong?

I'm surprised that the absence of NOTE OFF in the MIDI IN entries doesn't cause more questions. Maybe the MIDI IN isn't used so much. Or maybe I just lead a sheltered existence. ;) I agree with you Bassman, a bit more in the comments would seem like a good idea. Perhaps like this: # Supported MIDI events (. stands for hex digit, vv stands for 00 or 7F) # 9. .. (Note On) Example: 90 30 (MIDIO128 receives 90 30 vv) # A. .. (Poly Aftertouch) Example: A0 30 (MIDIO128 receives A0 30 vv) # B. .. (Controller) Example: B0 07 (MIDIO128 receives B0 07 vv) # C. .. (Program Change) Example: C0 30 (MIDIbox receives C0 30) # D. .. (Channel Aftertouch) Example: D0 30 (MIDIbox receives D0 30) # E. .. (Pitch Bender) Example: E0 7F (MIDIbox receives E0 7F vv) # # - 8. .. (Note Off) is translated to 9. .. 00 by the application # Example: 90 30 (MIDIO128 receives 80 30 vv, DOUT pin is turned off) # - On 2-byte events (C. and D.), the output pins just toggle (0->1 or 1->0) It seems that for 3-byte events--9 Note On/Off, A Poly Aftertouch, B Controller, and E Pitch Bender--vv == 0 turns the output off (high) and vv > 0 turns the output on (low). That should be put in the comments as well. (I think the MIDI specs say that vv < 64 is off and vv >= 64 is on, but vv > 0 for on probably makes more sense for typical MidiBox uses as a Note On of any positive velocity should turn on the output.) While we are at it, should the comment block explaining the DOUT section be moved down to be just above [MIDI_OUT]?

Thanks for posting warnings to this subtle trap in preparing .ini files Bassman. I only looked at MIDIIO128 but I assume the same considerations apply to .ini files for any of the official MidiBox applications that process Note messages from MIDI In, and should apply to all such applications. How about this for the parenthetical on NOTE OFF: NOTE OFF (NOTE ON with velocity 0 required for input configuration, preferred for output)

This is a most enlightening discussion! I've looked at the code for MIDIIO128. It converts a MIDI In Note Off message to a Note On with velocity 0: MIDIO_MIDI_Scan ;; if note Off event has been received, convert it to Note On with velocity == 0 movf MIOS_PARAMETER1, W andlw 0xf0 movwf TMP2 xorlw 0x80 bnz MIDIO_MIDI_Scan_NoNoteOff MIDIO_MIDI_Scan_NoteOff movlw 0x90 iorwf MIOS_PARAMETER1, F clrf MIOS_PARAMETER3 MIDIO_MIDI_Scan_NoNoteOff Therefore it should be pointed out that in configuring the Input portion of the MIDIIO128 configuration table, NOTE OFF (0x8n) should not be used because any NOTE OFF that is received will be converted to NOTE ON with velocity 0. A NOTE OFF in the Input section of the configuration table will never be selected by MIDI Input. You can use NOTE OFF in the Output portion of the MIDIIO128 configuration table and whatever you use will appear unaltered on the MidiBox MIDI Out Port. However, it is probably better to use NOTE ON with velocity 0 rather than NOTE OFF for consistency with the Input section and for greater efficiency if MIOS were to support running status for MIDI Out in the future. (MIOS does handle running status in the MIDI In.) Hope I got all that right.

Maybe better to say "(many devices use NOTE ON with velocity = 0 instead of NOTE OFF)"? I think this may point out a small issue in MIDIboxes that receive and respond to MIDI In. Do they understand that 8X NN VV and 9X NN 00 both do the same thing? I've never used the MIDI In on a MIDIbox for anything so I just don't know. Does MIOS translate one of those to the other? ??? For that matter, does MIOS handle running status for MIDI In or create running status on MIDI Out? I'm guessing yes, at least for handling running status on MIDI In. (Yes I know I'm being lazy and I could go find the answers. But since I don't care about the answers at the moment let's just say I'm asking for the benefit of someone who might not have thought of the questions. If someone knows the answers off-hand that is great but otherwise just leave it for someone who needs this information to go find it.)

Nice job Bassman! That should be added to the Wiki.