Building String Instruments with No Strings? 42
sansglitch asks: "Well, as the end of the academic year rolls around, I come before the Slashdot community to ask for a little help on a research project thats hopefully going to allow me to leave my sleepy suburban high school with a bang. Inspired by a 6th grader's science textbook, I have undergone construction on a Laser Harp (that is, a harp of sorts in which I've replaced the strings w/ beams of light). For the brain of this small midi-producing gadget, I've opted for a PIC micro-controller. I was hoping that someone with experience in dealing with this kind of chip setup might help with the finer points of integrating it into this monster. Do people still code for PIC's these days?" Now that is actually a cool idea for a project. Good luck with it, sansglitch!
Think of it (Score:2, Informative)
Plenty of people are using PICs (Score:5, Informative)
For general PIC support, there are a couple active mailing lists, the big one is the piclist, and there is a website [piclist.com] that will give you plenty of (3rd party) info on the PIC and the mailing list. There is even some GNU/Linux work being done with Linux, try out Gnupic [gnupic.org]. Of course, you can always go to the manufacturer [microchip.com].
That's a little vague, isn't it? (Score:4, Informative)
For instance, how many strings? I would assume it's more than one octave and less than five or so. Also, how many polyphonics do you want to support? That is, how many strings can be "played" (i.e. beam interrupted) at once? You can make the hardware really simple if you only support one string at once. But it wouldn't be very useful. A design in which you support full polyphony, where any possible combination can be played, will be more complex but it will also be more realistic. The whole idea here is that you can vastly reduce the number of i/o lines required if you do some encoding or grouping of the strings, at the price of not allowing certain combinations of strings to be simultaneously addressed. If you want this instrument to be practical, you must think hard about the multiplexing (if you go this route.)
Another thing to decide early on is whether you want to deal with velocity data. A decent midi keyboard will sense how hard you press the keys, and include this data in the midi stream. It would be really neat to detect how fast your photodetectors are covered by the fingers (to simulate plucking the string violently vs. gently strumming it), but this would add greatly to complexity, so I suggest avoiding it.
Don't be afraid to use multiple PICs. If I were doing this design I would consider a two-tier design. Perhaps a three dollar 16F627 [microchip.com] for each octave, with one i/o line per string (this gets around the multiplex issue.) Unfortunately I don't think you will be able to use interrupt-on-change for every string, so these first tier chips would periodically scan their 12 strings for an event. You can do the debouncing in software, but it's probably easier to buffer the photodetectors with Schmitt triggers. Each of the first tier chips would talk to a central second tier chip which aggregates the events and encodes them as a midi stream. Those 16f627's have up to 15 i/o lines, so that leaves 3 for communication with the master. You could use something standard like I2C, or just invent your own protocol. You might be able to do something as simple as one data line and one handshake line (if you have a common clock for the whole unit) from each slave to the master. The idea here is that rather than a single chip constantly trying to keep track of the state of a number of strings, the master simply receives a few bits of data from one of the slaves whenever there's an event.
Anyway, those are my initial thoughts. The first thing you design should be the general architecture stuff, don't get bogged down in details. Have a general block-diagram sketch of the whole thing before you start building anything. Keep a notebook, and record all your design ideas, sketches, schematics, specs, etc. in one place. It will make your life much easier.
Brian
Re:Jarre had this... (Score:3, Informative)
Musically speaking, the instrument was very limited; it was the equivalent of your run-of-the-mill-Casio-cheapo no velocity, no aftertouch keyboard. Beam free or beam cut, that's it. Very easy to implement in MIDI. What would be *very* cool would be to use the vertical position of the hand (the height at which the beam is cut) to modify factors such as signal amplitude (volume/tremolo), slight pitch alterations (vibrato), wave shape, etc. A hell of a lot harder to implement, but very interesting.
For examples of the harp in action, see Jarre in Houston, mega-concert event recorded in 86, in which one of the Challenger astronauts, Ron McNair, was supposed to play sax from the shuttle. There is also a short documentary before the concert itself where Jarre talks about the harp. For audio examples, the album "Houston/Lyon: cities in concert" includes those parts.
More info on Jean-Michel Jarre at http://www.jarre.net/
rough sketch (Score:3, Informative)
Need:
lasers - grab a passle of pointers off ebay, watching for sneaky shipping/handling charges. Since you have to mount them, the short-profile "bullet" ones would be nicer than the longer ones. One pointer per string. If you have time, hack the power supply and switch so they all work together and don't eat 600 batteries.
laser detector - a phototransistor, although a photodiode would also work. Photoresistors might be a little slow, but could also work, maybe with a comparator to give it some snap. They also are at every Radio Shack, and their bigger target size may ease alignment.
If you want to do it another way, just have an high-mounted IR emitter that multiple high-looking IR detectors can see, then detect the shadow.
PIC or Basic Stamp - My preference (since I have the programmer already) would be to go with one of the new, larger PICs that has 28/40 pins and built in serial. 33 I/O lines is more than enough for a decent harp. Anything else (small PIC or Stamp) and you will need more external hardware to decode lines; you will have to bit-bang serial as well, potentially losing some notes. At $5 for the right chip, why suffer?
Detect change, spoot MIDI, repeat.
frame: stable alignment for lasers and detectors is key. If a laser turns off or gets misaligned, the detector thinks you are trying to play the note. Depending on the sound patch and your program, you may end up with either a stuck note or a missing note.
random thoughts: Work the one string method out (duh) before you commit it to solder. Use sockets. Have an all-notes-off button.
MIDI: Three bytes, 31250 baud; details everywhere. The velocity byte is going to be fixed unless you decide to do something clever with it; that may not be a problem if the patch/samples you are triggering are not that responsive to velocity. You could subtly vary the velocity plus or minus five or so just for kicks. With the built-in A/D you could read a volume pedal or pressure sensor easily. Note off messages are usually optional, but checking that the string has had some reset time (unshadowed) will have to be done.
Some pointers:
www.phanderson.com for cheap PICs/parts
www.melabs.com and www.basicmicro.com for PIC protoboards (and compilers). Melabs stuff rocks.
www.dontronics.com and john kerr on Ebay also have nice protos which I have used
Have fun!