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!
library (Score:1)
that's the kind of unnecessary complexity
Which is why you wrap string operations in a library. In C++'s case, this library is called STL.
wow! (Score:2)
how many 'strings' do you have? where did you get the parts? heck i'm not even sure what a PIC micro-controller is
PIC µcontrollers... (Score:2)
Not so long before, I had chosen a PIC for a project of mine (controlling a small DC motor wrt a couple inputs, both A&D), and I was actually a bit surprised to see some in a production environment. Although the Microchip site doesn't hint to only "tinkerers"...
Oh, another use: it seems there's a lot of satellite boxen which use a certain PIC (I think it's a PIC16F84) for authentication (either in the box, or on a ???-card). I found quite some software programmers for that chip, but only 2 for the PIC16C71 that I chose.
Re:PIC µcontrollers... (Score:2)
AFAIK, the satellite boxen don't necessarily use a PIC for authentication -- they would probably use a more cryprographically secure/hacker-proof device. It's been the cloners that use PIC chips because they are versatile and cheap enough to get the job done.
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].
I wish I had this two years ago- (Score:1)
I was doing an independent study with two other guys from my digital electronics class, on programming microcontrollers. Our teacher for DigElec did mostly thin-film and semiconductor physics, and encouraged us to find out- and I quote- "how hard it would be to teach physics students how write a program for all those PIC 16c55x's I have lying around." I was a sophomore math/cs student, John was English/Geography , and Will was Physics/Math. It was one of the coolest classes I ever had.
If nothing else, there's something magical about programming in assembly for a chip, with nothing more than the giant language reference manuals and whatever we could scrounge on the web. That, and you have to put the PIC under UV light for a few hours if you make a mistake. I love the microcontrollers- I just wish we'd gotten our idiot tic-tac-toe playing system to work!
What an innovative idea....but (Score:1)
Re:What an innovative idea....but (Score:2)
The interesting thing, Jarre's lasers went off into the clouds, but he did seem to be wearing a particular glove with a wire hanging from the wrist. I'm not sure what kind of sensors he was using. The harp on Beyond 2000 was a closed system and thus could detect if the beam had been broken or not, and if so, where. Once again, Jarre's system would have had to identify that his hand was interrupting a beam, and which beam it was, without having a second fixed endpoint for the laser beams.
I never did work out exactly how he managed to use it as a trigger. (and half debated that it was just a stage effect and another keyboardist on the stage was really covering his parts...)
Aww c'mon (Score:1)
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/
Re:Jarre had this... (Score:1)
If you put two lasers and sensors almost together (with maybe 1mm distance), then you could determine how fast the player's hand plucks the string. You can then use this data to modify amplitute.
Re:Jarre had this... (Score:1)
Interesting, but is it useful? (Score:1)
---------
[1] I couldn't find the name of the object that you pass on the string in order to produce sounds. I wonder - nobody sells those?
Re:Interesting, but is it useful? (Score:2)
> [1] I couldn't find the name of the object that you pass on the string in order to produce sounds
Bow. (Same word as the thing used for shooting arrows (tir à l'arc in French, if that's where you got arc) (I mean it's the same word in English, I don't actually know if the French for the instrument bow is the same as for an archery bow)).
And yes, I imagine a bowed instrument with virtual strings would be _really_ hard to play even if you could see the strings.
Haiku. (Score:2)
has no strings for you to pluck:
how incredibly Zen.
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!
PICs are cheap enough you might consider kludging (Score:2)
Finally, using one cheap speaker for each string could give you a greater tone range - use cheaper, smaller speakers for the higher registers, and some "more expensive" (maybe $5) ones to get a more satisfying bass on your lower strings.
As I've said, I realize this is not elegant, but it will be quicker and easier to build and debug than a "one-PIC-to-bind-them" approach. Important, since you've got maybe a month until graduation.
Paul McAvinney's Video Harp (Score:1)
http://web.media.mit.edu/~joep/SpectrumWeb/Spec
from the above site:
"Other noncontact optical tracking devices have been built, such as the "Videoharp", introduced in 1990 by Dean Rubine and Paul McAvinney at Carnegie-Mellon. This is a flat, hollow, rectangular frame, which senses the presence and position of fingers inside the frame boundary as they block the backlighting emanating from the frame edges, thereby casting a corresponding shadow onto a linear photosensor array. Appropriate MIDI events are generated as fingers are introduced and moved about the sensitive volume inside the frame, allowing many interesting mappings"
Also check out http://www.ircam.fr/equipes/analyse-synthese/wand
for trends of gestural control in music
Frankly, I would like to see more alternate music controllers built and supported by manufacturers. This is a potential gold mine if done well, not to mention the benefit to those who want alternatives to traditional musical instruments - whether electronic, or acoustic.
PICs and other microcontrollers (Score:2)
They just aren't as visible to the end-user - I think I saw once that Intel makes as much money from their microcontrollers as from big CPUs - They only cost $2-$10 apiece, but are sold in INCREDIBLE volume. Microcontrollers are EVERYWHERE, and the ability to program them is a useful and fun skill. It's amazing what you can do with 1k of flash and 128 bytes of RAM. (I've seen Tetris in 16k flash/2 or 4k RAM). Heck, one of the most popular AVRs is the AT90S1200 - which has NO RAM - just flash and 32 registers.
You might want to check out Atmel AVR chips - They tend to be MUCH more powerful than PICs of the same price. The subject of which is easier to program is much more of a debate, but with C compilers like CodeVision AVR (or GNU GCC), AVR programming is EASY.
http://instruct1.cit.cornell.edu/courses/ee476/ - LOTS of neat AVR-based projects there. Once I get around to tweaking our webpages, you'll see my group's project there.