jimhenry

Did a site to host new applications ever get set up? I should be ready to put up something for the Switch Matrix project pretty soon. This is a project that uses DIN and DOUT together to read massive numbers of switch inputs. It is useful for adding MIDI Out to organ consoles which often have several hundred switches.

Did a site to host new applications ever get set up? I should be ready to put up something for the Switch Matrix project pretty soon. This is a project that uses DIN and DOUT together to read massive numbers of switch inputs. It is useful for adding MIDI Out to organ consoles which often have several hundred switches.

Moebius understood what you wanted to do correctly and I did not. No, LTC will not do what you want. LTC is only a level shifter for the MIDIbox Core module. If you wanted to replace your Atmel based MIDI to relay interface with a MIDIbox MIDIO128 project it could be adapted to receive MIDI messages by RS232 using LTC. You would have 4 small PCBs plus your laptop to run the organ. Good luck with whatever approach you use for your project!

Moebius understood what you wanted to do correctly and I did not. No, LTC will not do what you want. LTC is only a level shifter for the MIDIbox Core module. If you wanted to replace your Atmel based MIDI to relay interface with a MIDIbox MIDIO128 project it could be adapted to receive MIDI messages by RS232 using LTC. You would have 4 small PCBs plus your laptop to run the organ. Good luck with whatever approach you use for your project!

It has already been said but just in case this makes it easier for someone to understand the point, shielded cables should only have the shield connected at one end. The idea of a shield is to provide a grounded enclosure for the wires inside but it should not conduct ground from one device to another. Each device connected by the shielded cable should have its own single connection to ground. Ground in each device could be at a different potential. So the wires will be inside the ground potential of one device with the shield extending the case of one of the devices and then inside the ground potential of the other device. You don't want to try to bring the two devices to the same potential by connecting their grounds, that will create a ground loop. The wires themselves have to have a circuit that can deal with the possible lack of a common ground reference. A MIDI out is two wires. They go to an optocoupler where an LED is powered by those two wires only without any reference to the device the LED is in. Thus connected MIDI devices are completely isolated from each other as long as the shield is connected on only one end. The two devices could be at quite different ground potentials, meaning metal cases could be at those potentials, and everything will work fine. But if you touch both cases at the same time YOU become the ground loop! :o Proper mains wiring is designed to keep all the ground potentials of properly constructed mains connected devices close to the same value. It is hard to do. It is much easier to use an approved wall power supply and leave the job of safely getting off the mains to that device.

Are you sure Moebius? What I think Edwardus is hoping to do is put a MIDI to serial driver on the laptop and use the LTC board to build a MIDIbox that receives the non-standard serial input. The MIDIbox itself might be a MIDIO128 to control the valves on a monkey organ. The LTC saves a box on the laptop to create standard MIDI signaling just to talk to the MIDIbox. As I understand it a minor modification would be needed in the MIDIO128 software to change the communication rate. With that and the LTC board it seems like the link between the laptop and the MIDIbox can be a serial cable. I don't think Edwardus needs a standard MIDI signal.

Are you sure Moebius? What I think Edwardus is hoping to do is put a MIDI to serial driver on the laptop and use the LTC board to build a MIDIbox that receives the non-standard serial input. The MIDIbox itself might be a MIDIO128 to control the valves on a monkey organ. The LTC saves a box on the laptop to create standard MIDI signaling just to talk to the MIDIbox. As I understand it a minor modification would be needed in the MIDIO128 software to change the communication rate. With that and the LTC board it seems like the link between the laptop and the MIDIbox can be a serial cable. I don't think Edwardus needs a standard MIDI signal.

Hard to imagine. Thorsten measured the switch matrix at about 80 microseconds for 64 notes input. Partswise you should be able to do a switchmatrix on the Trio with a core, 3 input registers and two output registers. The PCBs are more expensive than the parts on the shift registers. The necessary diodes are about $4 in the US. Of course you can't value your time at anything or the costs go through the roof. ;D But I look forward to hearing what you are thinking!

As it seems that the 16F version of MIDIO128 used the second byte as the data for Program Change and given that the only two of us who have commented find that more logical, I am going to do it that way in Switch Matrix. At such time as Thorsten is able to consider the matter, I am going to say the recommendation is to change the 18F version of MIDIO128 so that the second byte is used as the data for Program Change. Â In the meantime, the code is easily modified to do this for anyone starting a new project as Per explained above.

I have spent some time studying MIDIO128 and I have not been able to identify what stops MIDI messages from being sent at power up. The flow of control is bouncing in and out of MIOS in what seems to be the relevant area. I don't understand MIOS well enough to pinpoint what is needed to allow the MIDI messages to be sent at power up so that the initial state of the inputs is known. I will keep this issue in mind and if I see the solution as I am working on the Switch Matrix, which uses a lot of the code from MIDIO128, I will take the appropriate action.

I also have a Rodgers Trio 322. My original plan was to MIDIfy the Rodgers but then I came into two Wurlitzer consoles. My Rodgers has had ongoing contact problems and I can't even begin to contemplate MIDIfication of the Rodgers until those are resolved. What I had planned on for the Rodgers was to tie the Vcc of the 5 volt MIDI logic to the positive keying voltage. I would use a negative 5 volt regulator to create the ground for the MIDI logic. This would allow the keying voltage to pullup the logic input to positive. I forget what the plan was as far as pulling down. None of this has been tried. Before you do anything else, you need to build a small test circuit and verify that you can get logic out without disturbing the Rodgers keying circuit. As I recall there are two or three different circuit configurations used. Probably different between the Solo voices and the Tibias. There may also be something different on the Pedal keying. I never got to the point of considering the Stop circuits. I do recall reading something recently that mentioned that Rodgers MIDIfication tends to affect the sound of the orginal tone generators. You need to be very careful that you sense the inputs without disturbing the orginal tone generators. Now that I have gotten involved with the MIDIbox, I think my first choice for the input logic would be the 74165 shift register of the DI board. If the above scheme will allow you to connect the inputs of the '165 to the Rodgers, then MIDIbox will give you what you need to turn those inputs into MIDI messages. I haven't gotten to the point of expanding the switch matrix beyond the 64 inputs that Thorsten did as a demo of the concept, but Thorsten thinks it could be expanded to 1,024 inputs. If MIDIbox can handle that many inputs for switch matrix, then it probably can handle more than 128 inputs via a straight shift register chain. But it probably is less work to just use 2 or 3 MIDIO128s chained together if you don't mind a little bit more hardware since you won't need to do any programming.

Hard to say if that is a bug or a feature. I found it confusing at first too. But now there are people who have built tables that put the second byte of two byte messages in the third position. Do we change the way it works or just document very clearly how it works now? I think the comments in the sysex.ini files are out of date. It looks like a first byte of FF is used to trigger a Meta Event now. The @OnOnly Behavior is now used to set a switch that only sends a message when set On. In the following example pin 1 works as desired. Pin 2 send a Meta Message as indicated by the LCD display. [MIDI_OUT] ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = C0 00 01 C0 00 02 @OnOnly 2 = C0 00 03 FF 00 04 @OnOff Can someone (TK) confirm that the comments need to be updated? Then Per or I can do that and post the updates for approval.

DOUT is a long serial shift register. Multiple modules just extend the register. All the output comes from one pin on the PIC. I think Thorsten loads a single low going bit in the shift register and then just shifts it one position to scan successive columns in his second example which is the really fast scan and which I am working from. That would mess up the DOUT for any other use. I think his first example used logic that was closer to the MIDIO128 where the whole DOUT was sent every millisecond. That should allow a mix of switch matrix and unrelated outputs. But it would take up to 16 milliseconds to capture an input change if you used 16 columns. That's too long. If one is clever enough there is probably a way to get fast scanning and unrelated outputs. I'm not the one, at least not now. Seems that you have plenty to do without changing to the switch matrix. True, but I don't think anything in MIDIbox can handle that yet. I think you have a significant new feature that you will have to add. Perhaps you can do something where you couple by setting a flag that causes the button presses to be replicated appropriately after the scan of the DIN and before the search for changes. I was going to say after the search for changes but you should allow for the possibility of a coupler being added or removed without any other change.

Since I have apparently volunteered to make this minor enhancement to MIDIO128 ;D should it send just the messages for the switches that are on or a message for every switch based on whether it is on or off? Is there someone who wants to test this in a real setting when it's ready to leave the bench?

True. But you still need one diode per switch. The main thing is to figure out what is the best place to put them to minimize the effort of making the connections. See my comments in that thread. Maybe you are trying to solve the wrong problem with the buttons.

Robin, I took at look at what you are trying to do to see how it would affect the use of switch matrix. Do you want to turn LEDs on and off using DOUT? If so you should stick with MIDIO128 because Switch Matrix uses the DOUT in a way that may make it an input only device. I don't really grasp why you are dealing with the buttons the way you are. What are you planning to use for sound modules? Do they really respond to SysEx rather than ProgramChange to change instruments? You include some functions like couplers that would be handled by a relay in a pipe organ. Once you start doing things like having the MIDIbox produce multiple Note Messages from a single key, you are starting to make an organ relay with the MIDIbox. Are you trying to avoid using a PC? A PC costs about the same as a hardware sound module but can be more flexible. Virtual organ programs in the PC can provide the relay function. Does the budget preclude using a commercial product such as Opus Two? A real organ relay will give you much more flexibility than your proposal appears to offer.

That's what I understand Per S to be saying is the case with MIDIO128 as it is today. The initialization of stops is an even more important reason to change the behavior of MIDIO128 than the swell contacts. For mechanical reasons, swell pedals control swell shades in front of a pipe chamber. In a classical organ each manual is usually associated with a division, which is some subset of the pipes. Having one complete division under expression and placing it on the Swell manual is a common traditional arrangement. Theatre organs did away with the concept of divisions--one of the major points of contention between strict classicists and the TO people. Any rank might be controlled by any manual at a variety of pitches. TOs have only a small fraction of the number of pipes as in a classical organ with a comparable number of stops. Of course, the swell shoes on a TO are completely unrelated to the manuals. Now back to your question. The inputs to a virtual organ do not simply pass through to the output. The virtual organ program has to generate new outputs based on the inputs. Whatever ranks are supposed to be under expression may be played using several MIDI channels. The virtual organ program will translate the swell input into expression messages for the channels that need to be controlled by the swell input. The swell input doesn't go to the sound card at all. It is done in the same format as if was going to the sound card to maintain some sanity, but it is really just input to the virtual organ program.

The .jpg file has to hosted somewhere on the net. You paste the URL between tags.

Yes, it looks like a good fit to me. On an oscilloscope, yes. In what you hear, no. The benefit of the switch matrix is that you only need 1 CORE, 1 DIN, 1 DOUT, and 1 LCD. It will probably be easier to maintain. Figure no cost advantage because you already have the hardware either way, but with switch matrix you have spares. You'll have to decide if you want to redo the one keyboard or press forward with the original plan. Either should work quite well. If you want to change to a switch matrix let me know and I'll sketch a proposal for the wiring for your consideration. If I understand what you are thinking, no you can't put the diodes on the DOUT board. You need one diode per switch contact in the circuit that connects a DOUT line to a DIN line through the switch. The picture of the bottom of the keyboard that Thorsten connected shown in the Diode Matrix Input topic shows this pretty clearly: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=midification;action=display;num=1088098331

But this is an open source project so you don't have to live with shortcomings! ;D I'll try to look at what it takes to send messages for the initial state in MIDIO128 this weekend if Thorsten hasn't already answered.

Hi Robin. The Switch Matrix should be perfect for your keyboards. I plan to expand Thorsten's example to a 16x32 design to handle my console. Perhaps a 16x16 would be good for you. You would connect each buss to a DOUT pin. You could bring the key contacts in to the DIN pins in groups of 5. The advantage of putting the diodes at the keyboard end is that you reduce the number of wires that you need between the keyboards and the MIDIbox. If the keys are already cabled, or if there just is no place to put the diodes, you can make a simple diode array to terminate the contact. Here is one of 4 boards I will use in my console: I already have enhanced the example prepared by Thorsten, in which he did all the hard bits, so that the outputs are set by a table and to provide a display that shows what switch was last closed and what message that sent. For now the table is assembled in rather than being done with a seperately loaded table as in MIDIO128. If you are ready to start wiring up your keyboards, I'd be happy to work with you to size the switch matrix for your requirements. How many keyboards are you connecting? All based on 12 key busses? Any other inputs?

My comments were directed entirely toward real ;) swell shoes that have discrete switch contacts rather than potentiometers. I'm sure that AIN will work fine too but I don't see much point in trying to convert the digital (switch) inputs to analog (resistor) inputs and back into digital (MIDI) outputs. By keeping everything digital we can control exactly what message is sent for every step on the swell shoe and that might be important if there are only a small number of steps. I am only really familiar with Switch Matrix, which I realize you aren't using because it isn't even released yet. I would have expected MIDIO128 to send messages for all the switches that are closed when it starts up. It also seems reasonable that it should send a message based on the value of the analog inputs when it starts up. If MIDIO128 doesn't do that, it probably could be made to do so fairly easily. You also need this so that any stops that are on initially send messages. MIDIO128 is a program so whatever order it reads things in, it's going to stay that way unless the program is changed. I would imagine that pins are read in the order of the pins on the shift registers and that the pin closest to the core gets read first. A quick test will confirm this. So yes, it should be possible to wire things so you get the quick ramp up at startup. You send the closed setting during initialization (this will require a code change in MIDIO128 ) in case there are no contacts closed. (Hmmm. If you don't want to change the MIDIO128 code you can just hardwire one pin to ground and use that to send the initial close message.) I think the initial ramp up to even full open will happen as fast as the MIDI messages can be sent. It will happen in much less than 1 second. If you jump on the keys that fast you are going to have bigger problems than a fast change in expression. The grounding of the contacts is the usual way of reading switch closures with digital logic so that will be fine. The crescendo pedal can work the same way as far as sending messages. The problem is what messages does it send? Ideally it would send the same messages as the stops that are being added or taken off. But there are a couple of problems with that. MIDIO128 only sends one MIDI message per switch change. You may add several stops in one step. You'll probably change organs from time to time and each will have its own arrangement for the crescendo. It's hardly ever changed but usually the crescendo is settable. Having to reload the message table might or might not be viewed as acceptable for changing the crescendo pedal. If you can live with one stop per step of the crescendo pedal and with an occasional SysEx to reload the message table, then the crescendo is pretty easy. Otherwise you may want to send some arbitrary message that just indicates crescendo position and let something on the PC turn that into whatever is needed.

I am not sure what you mean by "the expression pedal." Traditionally organs have one or more swell pedals that control the swell shades in front of a pipe chamber and possibly a crescendo pedal to the right of the swell pedals and set slightly higher. The crescendo pedal adds stops to the registration. I'll address the swell pedal. If this doesn't answer the question for "the expression pedal" let me know. For the sake of discussion let's assume your swell pedal has 12 contacts numbered 1 to 12, 1 being almost closed and 12 full open. You will connect each contact to a MIDIO128 input (or a Switched Matrix input). The table entry for those contacts should be setup to produce a Control Change 11 (Expression message) of something like 0xB0 0x0B (n*10)+7 for on and 0xB0 0x0B ((n-1)*10)+7) for off where n is the contact number. As you open the swell from full closed it will send expression values of 17, 27, ... 127 and as you close from full open it will send 117, ... 17, 7. You should send 0xB0 0x0B 0x07 to set the swell shades to fully closed, 7, when you power up the console which should occur after the virtual organ is up. Be sure you setup the inputs so 1 is read before 2 etc. You want the system to send the Control Changes in order so that on initial power up the whole system will get to the initial position of the swell pedal no matter where it is. Thereafter changes to the swell pedal will send the appropriate Control Change as the swell pedal is opened and closed. I can tell you that the expression values given above won't work right for the Miditzer as it currently stands. I can figure out the values you need; I'm just warning you it isn't the ones I gave. Hopefully that situation will be improved in the Miditzer. You need to check on other virtual organs you might use to see if there are any particular requirements on the expression values that they need. It really isn't onerous to replace the table in MIDIO128 if you need to change what the swell pedal does as you change virtual organs. If it turns out that some "inertia" is needed as the swell changes, it wouldn't be too hard to add programming to send the expression changes in smaller steps over some period of time. If we wanted the virtual swell shades to take 250 mSec to open, we could send a Control Change every 25 mSecs to increase the expression value by 1 unit to effect a 1 swell step change. A larger change in swell steps could either send larger changes or send the changes more frequently.

It's a chicken and egg problem. If someone has a product that will use these things in quantity, they'll be able to get a quote for that quantity and hopefully everything will fall in place. Even at $2 each they add $122 to $176 dollars in parts alone to the cost of the keyboard. I don't think a keyboard product will be the place these are used in volume. They need to be pretty closely matched to be useful on a keyboard. Do you really need pressure sensitivity or would a simple on/off that requires extra pressure at the bottom of the key travel be adequate? Theatre organs have this and it is called second touch. Picking up an Ensoniq VFX on eBay is one reasonable way to get polyphonic aftertouch.

I really must learn to slow down and read the comments. :-[ Yes, of course putting the display code in USER_Timer is a bad idea. Thank you for saying it so nicely. I have now organized things so that USER_Timer sets a flag to hold off a display update for 256 mSec after the previous update.