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.

Hi Thorsten, I've been doing PICs for a while but MIOS is the first time I've done 18F. This is actually my second MIOS project, the first had a couple buttons and encoders, but I didn't have to write anything for that, I just took a sample app and slashed and burned and changed a few values in some tables and it worked! When I first started working with this a few months ago I ordered a bunch of core modules from Smash, I have them all stuffed and ready to go, so when the urge hits I can program one and have it working in a short period of time. At one time this weekend I had three core modules strung together with midi cables, I'd turn an encoder and watch the flurry of activity and see the end results in midi-ox. This program on the fly through midi-ox is Soooo much better than any other environment I've worked with. It sure beats the days with EPROM PICs, take the chip out, stick it in the eraser for a half hour, put it in the programmer, program it, then back in the board. UGH! John S.

Today I finished what is probably the simplest MIOS based MIDIBox ever. I have a big electronic organ which every once in a while gets stuck (once or twice a year). It has a complex series of time delayed relays to turn on the power amps and aux devices (so the breaker won't blow when it all starts up at the same time), well this takes a long time to turn off and turn on, so I decided to make a midibox with one button that put out a reset message when the button was pushed. Since I'm learning MIOS I decided to start from the J5_DIN example, it turns out you can't just change the table, because the reset message is just one byte, the J5_DIN wasn't designed for that. So I got to modify it a bit (learning 18F instruction set as well). So now I have a core module with one button connected and one 5pin DIN and thats it! John S.

It turned out I wasn't putting in the processor specific ID into the syx file. Since these are going to be lighting controllers mounted in walls and ceilings etc, I had separate IDs for each processor. Being able to program a specific processor in place by sending a midi stream into the network from one location was one of the main reasons I chose midibox for this system. Once I got the right ID into the MIOS file it loaded fine, and I've assembled and loaded two different apps this morning, that do exactly what they were supposed to do! Thats somewhat of an unusual experience, write the code, assemble it, load it and turn the knobs and push the buttons and the right stuff happens!! Way cool! Now all I have to do is get the DMX converter working. I'm modifying the midi-merger for that. John S.

I found the problem, it was a solder bridge where the jumper to J10 is real close to the thin wire from TX, shorting pin 25 with pin 29. With that cleared out I get nice full swing pulses, the PC can read the sysex commands. Unfortunately MIOS still doesn't load, the data pulses are showing up at RD, but I only ever get the original sysex message out of it. After each buffer I get a whole bunch of sysex messages, all the same as the original. After the download I keep on getting the message every 2 seconds or so. I haven't tried any of the misi-ox settings yet, I'llgive that a try later on tonight. John S.

I just put together a core module, checked out voltages, it looks fine. Put in the 18F452 I got from Smash already loaded with the boot loader. When I setup midi-ox and turn on the core I don't get any messages. I tried a loopback on the PC- its working fine. So I brought out the scope and looked at what was going on. The oscillator is working fine, I get pulses out from the TX pin on the chip but they only go from ground to 1v. The VDD on the chip is 4.95V. In order to find out what was going on I disconnected it from the midi connections and just soldered various resistors across the midi out pins, making sure total current was never more than 10mA. What I found out was that the output pin high voltage was always 1v, and the low value was always essentially 0v, no matter what the resistor from 5V to the TX pin. This doesn't sound like a normal output, either open collector or totem pole. It looks like there is a 1V zener across the output, but that doesn't make sense. I tried three different processors and two of them gave this response, the other was different. When power was first applied it would go to 1V, then go to 5v for short time, then go back down to 1v and stay there, no pulses like the output from a UART like the other processors. But the output DID go to 5V for a brief period, which sounds like it IS something under program control. This is very confusing, I don't see a software setable 1v output clamp listed in the datasheet . Anybody have any clue whats going on? Thanks, John S.

Thorsten, thanks, thats the info I was looking for. I'm programming my first core module today, we'll see if all this works or not! John S.

Which port does MIOS use to look at DIN modules? I want to use both encoders and buttons on one board. The core module description says bot J6 and J9 are used, with J6 for encoders and J9 for buttons. But several of the MIOS examples use one SR for both, so they have to be using the same port on the core module. I looked around the MIOS files and didn't see anything that specifies which port to use for DIN, so either I missed it (quite probable) or the port is fixed, if so which one? Thanks, John S.

I've been looking into this for a while. It started out looking into MIDI over powerline (you plug the box iin and the data goes into the wiring). I haven't quite founf the best way to do this yet, the competing technologies are either too slow or too complicated. On the wireless front, the Linx modules seem like a great idea, the are not too expensive and are incredibly easy to interface to MBHP, BUT they have one major drawback for MIDI, no error correction at all. This is very bad when using state change protocol such as MIDI over a noisy channel such as radio. One little burst of noise and the last note you played doesn't go off, or the program change doesn't happen, or even worse goes to something compeltely wrong. Bluetooth on the other hand has a much higher data rate built in error correction, can talk the to the I2C bus of the PIC, BUT the prorocol is very complicted. Since all types of devices can use the same bluetooth spectrum they have come up with different device types and protocols. For example you don't want a printer and cell phone headset talking to each other. What would probably have to happen is a MIDI protocol and device type would have to be designed and ratified by the Bluetooth community. There are some "unspecified" connection types that might be used, but this is dangerous because you never know what might be using that as well which could cause collisions with the midi devices. What would be the quickest is the "cable eliminator" type connection (they have them for serial ports, parallel ports, USB ports etc). You have to have two boxes that will talk to each other and ignore all other bluetooth trafic or other boxes of the same type. You could build midi links out of these, but you cannot have midi bluetooth built into the keyboard, computer, sound module, controler etc and have them talk to each other. THAT takes the official midi protocol and device type. The major issue here is that bluetooth is trying to be a general purpose network, not just a cable eliminator. This is the same problem I had with the powerline systems, the one with the error correction and high bandwidth needed complicated software to make it work. So who wants to draft the official MIDI bluetooth standard ? John S.

This looks like a slide switch with round handle. Mouser has several of them: 10SL005 10SL009 10SL001 10SL008 Most slide switches have square handles, Mouser has MANY of those to choose from. My guess is that the one in the picture is the first one in the list above. John S.

Thanks for that detailed reply. It looks like my best bet here is to start from the midimerger, rip out everything except the software midi in and add the DMX out code. I'll probably use the existing core module for the processor and add a small separate module for differential line drive which can also be used as a long distance midi driver. Yes the DMX out function takes RAM since DMX is constantly outputting the state (not just the state changes as in midi), but you don't have to implement all 512 channels, you can only do 16 or 64 or however many you want. Standard MIOS and MBHP will handle all the rest of the system nicely. John S.