John_Swenson

I've been reading over the example C programms to get a feel for it and came across this line in the clockbox: unsigned char mclock_ctr_measures; // counts the measures (up to 65535) This doesn't make sense to me, a char is usually an 8 bit quantity and I don't see how you get 65535 out of an unsigned char. Should this be an unsigned int or is there a separate variable that is the "upper byte" or some such? John S.

I'm building some simple boxes with just a few buttons. In the past I did this using the J5 DIN routines written in ASM. I don't see equivalents in the C wrapper. I want to do these projects with C, so I need some way of getting the J5 functionality in C. I presume I could either rewrite the ASM routines in C, or leave them in ASM and link them in with the C main program, but then I would need a J5 wrapper, correct? Given that one of the functions is an ISR, that might be a little tough to write in C. Any hints on the best way to do this? Thanks, John S.

Thanks, but it looks like I'm going to have to program this one, I just found out the message has to be different each time its sent and there is a checksum that has to be computed. I guess its time to try out the C interface! John S.

Its been a while since I've been in midibox land, so I don't remember the answer to this. I have a hard disk recorder I want to run remotely, the functions I want to control use SysEx messages. So what I want to build is a little box with 4 buttons that I can program to output SysEx messages. Can I do this with one of the canned applications? (Midibox64 etc) I could write a custom MIOS program to easily do this, but if the functionality already exists why reinvent the wheel. Thanks, John S.

Jim: the simple table is fine as long as there is enough memory to support it and the software can read it. I was just woried that with the current scheme the table was going to get rather large. On the stop configuration stuff let me rephrase it in my own words so I make sure I understand what you are talking about. It sounds like you are trying to make a configurable note "router". The end result is that a note on event comes in on say channel 5 and goes out on say channel 9 transposed up an octave. It might also go out channel 7 as well but not transposed this time. You could also have an event coming in on channel 4 also go to channel 9 but in this case it also goes to channel 6. All this gets configured by midi controller events that specify that routings get added or deleted from a certain input channel. Controller messages are used to specify channel and transposition. Ok this makes sense, but what specifies the stops that are present on each channel (unless you are only going to have 16 stops total)? Do you use a program change in addition to the controller specified above? Or does the program change from the stop switch cause a midi mapping then program change for the new channel? John S.

ooops, that was supposed to read," all the stuff for the LCD is NOT needed..." John S. (the guys whoose brain outstrips his fingers all the time)

Hi Jean, I've looked very closely at the code for the midibox midi-merger and came to the conclusion that it would be very difficult to convert to multiple midi input. The current version uses the built in UART and a software UART, it implements the functions of the UART entirely in code. Part of the code is using a timer to sample the waveforms at certain points. Since all the midi streams are asynchronous to each othyer they they all need different timings which would entail a major rewrite of the code to handle multiple ones from 1 timer. Anyway I looked at the problem and gave up and just built three midi mergers and cascaded them. The three midimergers cost WAY less than one commercial 2-1 midi merger. For this application the midibox core module only needs some of its parts, plus some extras. All the stuff for the LCD is needed as well as some of the connector pins for AIN, DIN DOUT etc. The standard core module only has one optocoupler, but with the merger of course you need 2, so I had to add a separate little board with the extra couplers. In the cascaded connection (2 2-1 feeding a third 2-1 giving 4-1) you don't need the optocoupler on the secend level merger, you can feed cmos level directly into cmos level. Since you are already dealing with 877s it sounds like you have the environment setup to program them, the midimerger also uses the 16f877. If you decide to try the multiple midi merger let me know and I can give some more details if the above description is too vague. John S.

Thorsten: WOW you are incredible!! I spent the weekend with my sister, her husband and my Dad, driving around to all the old places where he grew up, went to school etc. I get back and you've already got it done! Jim, tomorrow I'll take a stab at modifying Thorsten's driver for different size matrices. As to what to do with the buttons I had a few thoughts on that. The current table would get too big with a really large matrix so I was thinking about a two stage table. The first level table is indexed by the button number right shifted 3 bits. The 3 LSBs of the button number would be added to the value in the table. This would handle the "note on" type function where a bunch of buttons get the same midi function just differing by some value related to the button number. IF the seond value has the MSB set (which should not happen in a regular midi message) it means the entry is really a pointer into the second table. Again the 3 LSBs are added to the value in the first table (probably the 3rd byte or the bottom 7 bits of the second byte) and used as an index into the second table. THIS table contains individual middi messages for each button put in this table. So for a 16x64 (or other large table) we have 128 first table entries which cover MOST of the note on type messages, but for those that need to have independant middi message you have 128 entries in the second table for stop changes, "pistons", crescendo sets, whatever. Make any sense? BTW my arms are quite sore after spending a couple hours with a file enlarging the holes on my front panel so the switches would fit, but itall done now. John S.

Hi Jim, I think I'll go into detail on how all this works in MIOS so we can all be clear about whats going on so we can make good decissions. I've been pouring over the MIOS V1.7 source today so I think I REALLY understand how the SRIO is currently implemented and how Thorsten's current SM driver works. In hardware you have chains of 8 bit shift registers. There are seperate DIN and DOUT chains which are clocked by a shift and latch clock (the same clocks used for both chains). For DIN the latch clock takes the parallel 8 bit data and latches it into the shift register to be clocked out later. For DOUT it takes the current value of the shift register and latches it onto the parallel data out pins. On the core module side you have 2 five pin connectors, each connector has +5V, gnd, shift clock, latch clock and data bit. In software mios has a timer that causes an interrupt every 1 millisecond. The ISR for this latches the DIN chain, reads the DIN pin (which is pointing at bit 7 of register 0) stores it, writes the DOUT pin, sends out a shift clock pulse, and repeats until it has gone through all bits of all the shift registers. It then sends out a latch clock pulse to latch out the DOUT values. This is all done in software durring an ISR, so latency is very important, which is why I presume Thorsten limits the number of shift registers (DIN or OUT) to 16. So given the way this works, for a diode matrix you can enable a column (0 on that column, 1 on all others) with the DOUT boards and read the row from the previous column every ms. The read the previous is because the SR driver reads the DIN bit before it writes the DOUT bit. So for a 8x8 matrix it takes 8ms to cover the whole matrix. A 8x16 still takes 8ms. A 8x64 also takes 8ms. The latency is determined by the number of DOUT bits used, its independant of the number of DIN bits since all (up to 128) DIN bits are read every ms. So for your situation you could have a 8x64 arrangement with 1 DOUT and 2 DIN boards and have 8ms latency on the matrix. You could even do 8 x 128 if you needed that many inputs but of course that takes more DIN boards. Thorsten mentioned the possibility of writing a special SR driver that would do more than one pass on the SR chains every ms. This is how you would get the latency lower than the 8 ms. Since the core isn't going to be doing much of anything else this is probably all right. You still want to have SOME processor bandwidth left for writing out midi messages! I hope that clears things up a bit. BTW I have a pile of core and DIN/DOUT boards sitting around right now so I might try writing a 8x64 driver and trying it out. Its going to be a little while before my current project gets done, I got my front panels back and the switches don't fit so its not going together this weekend. John S.

Hi Jim H, yes you COULD do a 16 x 64 (or 8 x 64) using 1 DOUT and 2 DINs, but then you loose one of the big advantages of the diode matrix approach: small amount of wiring to each keyboard. You would still have to bring all 64 wires out of each and combine them together into the DIN boards. Thats why I really like using the 8x8, it only takes 16 wires to each manual. For your arrangement you could either put the diodes at the keys, then connect to the wires and connect each set in parallel at the DINs, or you could run the wires directly from the key contacts to a big diode board that goes to the DINs. I agree with Thorsten that trying to make a unified configurable code would be a mess, his approach of having several configurations would be the way to go. One advantage to the 16x64 approach is that the latency is still fairly low at around 16ms. With a 32x32 you are getting to 32ms which might wind up being noticable. Thorsten mentioned he could do the drivers, but I could do them as well and let Thorsten focus on the really important stuff, making MIOS the most flexible PIC environment in the world. John S.

Jim C, the reed switches are very fast, even the release is less than a millisecond (at least for the small ones you would use on on a keyboard, some of the BIG ones are slow). The only real problem as far as playing goes is that the on and off points on the key travel are at slightly different points. The switch closes when the magnetic field reaches a certain field strength, it releases at a slightly less field. There are a very few organists that don't like this (they are usually those that only like playing trackers!) Many years ago I was thinking of putting a magnet on a small post sticking down from the key with a coil around it. A computer would then send exactly the right pulse through the coil to give you any "feel" you wanted. You could have tracker feel, harpsichord feel even tubular pneumatic feel! But I have never gotten around to building this, one of the big problems was magnet strength, but with modern rare earth magnets its should be easy. The coil is also a very good velocity sensor if you wanted to implement something based on velocity. Speaking of trackers one of my goals is to sometime in my life build a pure tracker out of modern hi tech materials such as frictionless flex bearings, high strentgh fibers that have almost no stretch due to load or humidity or temperature. You should be able to build a large tracker that once adjusted STAYS adjusted no matter what the temperature or season. Some of these fibers in a teflon tube have very low friction so you could even make a moveable tracker console!! John S.

Hi John C, to see how the wiring is done, go to the MIOS download page and look for the sm_example_v1 sections, there is a picture of the wiring. For an 8x8 you have 16 wires running the length of the keyboard, 8 to a DOUT and 8 to a DIN. One side of each key is connected to one of the DOUT wires, a diode is connected to the other side of the key which then goes to then goes to one of the DIN wires. You are quite correct that you need to get to both sides of the contact, the common "bus" arrangement is tough for that, particularly if you are trying to preserve the original functionality. I've done it by either adding aditional contacts (I'll explain my favorite later) or modifying the "bus" if you do't need the original functionality. If the common contact is continuously supported (such as a bar on a wood support, just cut it apart at each key! One I did by putting some tape over the original bar and gluing a new wire over it at each loacation, it was actually quite easy. For adding extra conacts I usually like to use "non contact" contacts. I've done both optical and magnetic. For the magnetic I use a reed switch (magnetic switch enclosed in a glass envelope), you can get these quite cheap from mouser or digikey. I then bought a roll of magnetic strip material and cut off little pieces and glued them to the end of each key. The reed switches, diodes and 16 wires I put on a board that runs along behind the keyboard with each switch oriented vertically. When the key is pressed the magnet raises up and turns on the switch, no physical contact happens. I've also done this optically in two different ways. There are reflective sensors, that send out a light beam and have a detector right next to it. You glue a piece of white paper (carboard, plastic, whatever) on the back of the key and place the sensor so that when the key is depressed the reflector sends the light back into the sensor. The problem with this is that it can be sensitive to external light. Ie it works fine when the over is on but when you open things up and aim bright lights at it for trouble shooting, it doesn't work! The other is the interrupting beam approach. In this one the sensor has a slot with a source and detector on opposite sides of the slot. You glue something on the key which will slide through the slot and block (or unblock) the beam as the key is depressed. I used some plastic strips from the hobby shop and glued them to the end of the keys. Because the detector is much more enclosed than in the previous version it doesn't get mucked up by ambient light. The magnetic approach is the cheapest. I did a 3 manual + pedalboard for less than $100. The optics cost more. Have fun! John S.

Hello all, I'm new to this thread but not to midibox or organ conversions. I'd like to offer my help and experience in these matters if any of you need a little help with this. I'm well versed in MIOS programming if anyone needs some custom programming for any of this, or help in doing your own. I'm also fairly well versed in the amplifier/speaker area for electronic organs if anyone is interested in that. One interesting things I noticed from reading this thread is that no one seems to be using the diode matrix approach for inputting keyboards etc. I've used diode matrix techniques on all my organs and find it much easier than the direct in approach. With the matrix approach you can get up to 1024 inputs with 1 core, 1 DOUT and 1 DIN. Thorsten has a code sample on the MIOS download page on how to do this in MIOS, but it would need an app written around it (very easy to do). TK's code is for a 8x8 matrix which gives you 64 inputs, which is perfect for organ use. You can get 4 of the 8x8s with the 1 core, 1 DIN and 1 DOUT. A big advantage here is that you have 1 16 conductor cable going to each keyboard, it cuts down immensely on the cabling. John S. (Hmmm, that makes John C, John H and now John S on this thread!)

Having just spent the weekend building 4 DOUT boards and 2 DIN boards I'm greatly in favor of converting the current board design into using resistor packs rather than individual resistors. I know the parts are probably a little more expensive and somewhat harder to get, but putting in what seemed to be thousands of resistors was not fun! (not to mention blistering) Any thoughts on this from others? Thanks for considering it, John S.

As far as the MTC and other midibox functions go, with a MIOS bassed system this should be easy. I don't know about the older non MIOS systems though. John S.