jimhenry

You should post this question in MIOS Programming. I think that area gets more traffic, especially by people who might have a good answer for you.

Some of that clunky outdated electromechanical hardware you find in organ consoles actually works quite well. I'd test the switches you have before you consider replacements. I've seen "switches" that were nothing more than a metal plate that got shoved into a pair of spring wire contacts which still worked perfectly after 80 years of hard service. Don't sell the organ builders of the past short just because they didn't have all the modern electronic stuff to work with. You'll find it hard to beat what they accomplished.

There shouldn't be any MIOS coding involved.

Yes, the MIDIO128 project with a CORE and a DIN will handle conversion of a switch closure into MIDI. Quite easy once you get your head around how MIDI Box works. Once you have working boards it will probably become clear. Your big job is to figure out how to get reliable switch closurs from your manual typewriter. You might look at the possibility of having a metal part on the key assembly short out a pair of phosphor bronze wire contacts. Pipe organ keys generally work that way.

As best I understand what you propose it seems workable. As to conventional organs, the foot control (swell pedal) is most logically Control Change 0B expression as you propose. In a real organ this controls shutters in front of the pipes to control volume. The control of the relative volume of ranks would fall into the realm of voicing, something that is not under the control of the organist during performance of course. I would say you can handle voicing in any way that seems reasonable as that does not have to be something that can be used while performing and thus does not need to conform to what is conventional. One thing you may wish to consider is that larger organs are typically spread out into more than one chamber, each with its own swell shades and a separate swell shoe on the console. If there are 3 or more swell shoes, there is typically a master swell shoe to the right of the chamber shoes and to the left of the crescendo pedal. Users of the Miditzer felt it was important to preserve the facility of multiple swell shoes. I'd suggest limiting yourself to two swell shoes if you go this route as the larger arrangements are going to escalate the console construction costs rapidly and aren't all that useful.

157Kb to California. Looks good!

The 18F4550 is now available for purchase. Just under US $10 in small quantities.

For your first MIDI Box project you should definitely include the LCD.

My wife is not French but she has taken a substantial amount of French in college. She suggests: Pris d'expédier: N'importe quel kits ou plus de 8 pièces de PCBs = $ PCBs seul, 8 pièces ou moins de 8 pièces de PCBs = $ Price of shipping: Any number of kits or more than 8 pieces of PCBs = $ PCBs only, 8 pieces or less than 8 pieces of PCBs = $

It sounds like you are very much on the right track. I don't think it will be so hard to add the necessary programming to get keyboard velocity. Good luck!

This site will probably tell anyone more than they ever wanted to know about designing power supplies: http://www.national.com/appinfo/power/

The WIKI seems hard to find. I only find one inconspicuous link on Thorsten's page. Whoever administers the forum needs to add a prominent link with explanation. I say let them be presented in whatever way the name can. Graphics and complex documents need to be hosted somewhere and pointed to from the WIKI. A common repository would be good as things have a way of disappearing when they are scattered around the web. How can we create a depository for files related to the MIDIbox?

Before we launch off into writing there are some other important issues to be decided. Who is this document aimed at? What do we assume they know? Where will this documentation be posted? What is the structure of the document? Using the power supply as an example. There is quite a bit of information in the description of J1 and J2 here: http://www.ucapps.de/mbhp_core.html What more is needed? And why? No one should be redesigning the power supply as part of a MIDI Box project. Designing power supplies is a major topic all by itself. Anyone designing electronic hardware should know how to design at least a simple power supply but I am sure that topic has been done very well many other places. Is this going into the Wiki documentation? If so, maybe this section needs to be nothing more than pointers glued together with a few sentences. Overall, it wouldn't be unreasonable to start with an outline of everything to be covered and a statement of who the document is written for. Does anyone beside me think that a redesign of the web page at http://midibox.org/ could go a long way in improving the perception of the amount of information that is available and make finding it easier? This project needs an editor. Who wants to take on that role? Those tossing their hat into the ring should write a statement giving their qualifications. There is no one to make official appointments around here. The editor is just going to emerge as the person who can get the job done. Convincing people to make the contributions needed will be important and convincing people you can do the job is one way to encourage contributions. Another is to write some significant first piece. A good outline should be useful in that regard.

Thorsten seems like the kind of gentleman who will make a new section if you need a new section to properly develop an idea you have. Thorsten is completely selfless. He welcomes contributions of all sorts to the MIDI Box project. He does not hold himself out to be the master overlord of what the direction of the project should be. Good luck with your project!

There are 10 kinds of people in the world, those who understand binary and those who don't. More on topic: There are 2 kinds of people in the world, those who can write documentation and don't need it, and those who need documentation and can't write it. Actually there is a third kind, people who need documentation but won't read what's there. That last group does a lot to discourage the first group. There are very few people who enjoy writing documentation. When I managed software development groups, even getting people who were being paid for what they did to write documentation was the hardest thing. Can't say I blamed them, writing good documentation is a very difficult thing to do and not all that satisfying. When you are done all you have is a document that tells you stuff you already knew. When you tackle an engineering project you wind up with something you can use that didn't exist before. So don't hold your breath or delay your MIDI Box project waiting for documentation. Ask your hundreds of questions and write a document based on the answers you get and what you learn as you work on your project. When you are done you'll have a useful device and a useful document that you give back to the MIDI Box community. The idea that makes a project like this work is that everyone does the things that they enjoy doing and shares their work with the community. So if you enjoy documentation, that can be your contribution to this engineering potluck called the MIDI Box.

I think improved documentation is one of the most frequent requests and something that almost everyone could benefit from. As I am sure you realize it will be a HUGE undertaking. I wrote a very modest explanation of how to make a cable for the LCD and it took far longer than actually making a cable. My suggestion would be to define some small finite documentation task that can be the cornerstone for your overall vision. The experience of doing that will probably give you a much better idea of how to tackle the balance of the project. Have you looked at the WIKI documentation? Perhaps giving that some direction as an editor would leverage your contributions and be a way to encourage more contributions from the community. There really is a lot of documentation for the MIDI Box although possibly not everything you have in mind. It is just hard to find and not particularly coordinated. An editor who can organize what has already been done, rewrite as necessary for continuity, identify gaps, and locate a volunteer to write material to fill those gaps could probably accomplish quite a lot in a reasonable length of time.

:-[ Head banging in stereo. :-[

You could use 330 ohm current limits on all the LEDs to bring the current down to 15 mA (5/330) from 23 mA (5/220). Then you can run 1 or 2 LEDs from a single output and all the intensities will be the same but lower. Try the LEDs with 330 ohm current limits on a breadboard before you commit to this approach but usually LEDs are acceptably bright over a range of currents.

Check-out the Midification area for much more discussion of Midifying organ consoles. I think you need a lot more than 96 digital inputs. Each keyboard is 61 inputs. Or are you just Midifying stops and pistons? The switch matrix project might be of interest but it is still very much in development.

People seem to LOVE their Hakko Desoldering Guns. This is a gun with built in vacuum pump, not a unit with outboard vacuum. They are pricey at about $160.00 US but they are supposed to be worth it if you do a lot of desoldering.

This discussion is getting interesting. Are things to the point where an SMD version of the core module and other "mature" modules could be designed? Would Mike and Smash be willing to take on making fully assembled and tested modules available? Is this a positive direction for the MIDI Box? I suggest SMD because it might make more room available for connectors and I think it is less costly to have assembled than DIP. Perhaps this would be less work for Mike and Smash because they would gradually get out of the kit business which has to be a headache. Perhaps this would be less work for the MIDI Box community because we wouldn't have to try and remotely diagnose assembly errors. The DIY part would be selecting and interconnecting modules, loading, configuring, and possibly modifying firmware, and designing and connecting the user interface. Maybe that is the most important part of the DIY experience?

No, that's the second version. Normally there is a scan of DIN and DOUT every millisecond. The first example used the standard scans and on the first millisecond you set the DOUT and on the next millisecond you read the DIN and set the next DOUT. If you are using 8 DOUTs latency can get up to about 8 milliseconds. When you go beyond 8 DOUTs, latency for keyboard input could get to be a problem, especially since the latency will be variable. Even good players would sound like me. ;)

Bravo SmashTV! You have an excellent grasp of copyright law as it applies to open source type projects. That is something a lot of people, such as SMGaudio, have real trouble understanding. You are also right on the money as to why it is not good for the MIDIbox community to have our projects available commercially. As simple as Thorsten's brilliant design has made these projects, they are still not for beginners. The ideal MIDIbox user would be skilled in microcontroller design, electronic assembly, programming, and MIDI. I'm sure almost all of us need help with at least one of those areas and that's what the MIDIbox community provides. If people with none of those skills were to start populating the community, those with skills to contribute would quickly be sucked dry by those with nothing to contribute. A commercial project operates on a different model. Users contribute money and the supplier pays people to provide what the users need. If the supplier provides something that enough people will pay enough money for so the the supplier can produce and support the product, the supplier succeeds in business. If not, they fail and disappear. A DIY open source project has a more complex balance. The users are also the suppliers. There needs to be enough contribution from all users so that the supplying users continue to contribute. Introducing users who paid a commercial entity to provide something aren't as likely to contribute to the DIY community and are much more likely to consume resources. They are mostly deadbeat customers for the DIY project. Those that can't build a MIDIbox for themselves should be paying a supplier that provides support for the product. Someone who is lifting a DIY design probably can't do that.

Sorry about the confusion. You probably don't need rock bottom latency. I am thinking of Thorsten's ultrafast switch matrix software that I am (should be) working on. It does things in a special way and I think it is incompatible with using the balance of the DOUT for other things. Thorsten's first switch matrix example used the normal DOUT routines and what is not needed for the matrix is available to do other things.

You should be able to do everything you want with one core if you can do the MIOS programming required to modify existing projects. You could use a switch matrix style input for your buttons. That will tie up both DIN and DOUT but it doesn't seem you need DOUT. You will need to be able to do some MIOS programming to take chunks of the Switch Matrix project and graft it into the MB64 project. The same is true, but probably to a lesser extent, of grafting MIDIO128 into MB64 to increase the number of DINs to 128. In summary, MIDIO128 is probably the easier way to get 128 inputs with one core. Switch Matrix will give you 128 or more inputs with less hardware and fewer wires but with more of a programming challenge. Look in the Midification forum for more information on Switch Matrix if you are interested.