Building String Instruments with No Strings?

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!

Comments

Plenty of people are using PICs

[Matt_Bennett]

Plenty of people are using PICs, even putting them in new designs (like me- I use them both for play and professionally)- not everything needs the power of a 32 or 64 bit OS. You can get a 12C508 (an 8 pin microcontroller with 0.5K of program space) in quantity for about $0.50USD each! You can make something with a PIC that is extremely reliable- which is exactly what an embedded system is- it's not about being a computer, it's about doing some function. A PIC is maybe a *bit* low powered for doing heavy duty MIDI, since you don't have a lot of time between bits, but people have done it.- check out this site for a bunch of MIDI/PIC related resources.

For general PIC support, there are a couple active mailing lists, the big one is the piclist, and there is a website 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. Of course, you can always go to the manufacturer.

That's a little vague, isn't it?

[bedessen]

Well, first let's assume that this is not another of those "Dear Slashdot: Will You Please Do My Homework For Me?" submissions. I realize you were trying to be brief and concise, but in order to proceed with this design you will have to nail down some details first.

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 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