How much memory do you need?
Could you use I2C EEPROMs instead of RAM?
Good questions.
There will be eleven solenoid "fingers" on the RCD-1. The reason for that is there will be one per hole for five of the fingers, and two per hole for the other six fingers in order to accommodate the latter three holes' need to be half-holed (I'll post a concept illustration in the near future for how the half-holing business will work on RCD-1). So getting to your first question, it will be possible to represent the fingering of a note to RCD-1 at any given moment with an 11-bit number. I'm guessing if I'm doing that on an 8-bit PIC I'll have to use two bytes (16 bits) to get all the fingerings in. I think I might use the leftover 5-bits for details like tonguing* (e.g. 1 = tongue, 0 = don't tongue) or an indication that the tune is over and to shut down the robot.
When playing the recorder, regulating the amount of airflow at any given time is important in fine tuning each note's pitch, so each note packet will also need at least an 8-bit representation of how hard the lungs should be blowing. The lungs on the first RCD-1 will be a modified camping mattress air pump, but I might use some custom bellows further down the line (air pumps can be noisy, even when run at low speeds).
Now here's the tricky part: rhythm. MIDI has an efficient method of dealing with rhythm by expressing durations as variable length quantities. But where the PIC's concerned (and if I'm using program memory to store this info), I think some concessions will have to made (in the music) to accommodate what the PIC can do (by itself - I'll get to the RAM-EEPROM thing in a minute). The plan is to use a 16F88 for the first prototype, and before the pundits chime in to suggest a better PIC (which I'm sure there probably is) bear in mind that I'm brand new to the world of mcus (hence my decision to go with a popular model). More than anything else involved in the project, the RCD-1 is an excuse for me to develop my own understanding of mcus. Anyway, back to rhythm. I still have three bits left from the fingering values I mentioned earlier, so what I might do is use those to call one of eight durations between a whole note and a sixteenth note long**, each duration being set as its own subroutine in assembly.
So that gets me to a minimum of 3 bytes per note to get the RCD-1 to play at something close to the same level of a first-year recorder student. You've probably caught on to where all this is heading: the entire length of any tune programmed into the PIC will be dictated by the programming space available, the minimum 3 bytes per note requirement, and how efficiently I can coordinate/process each 3 byte packet in the PIC. It should be enough space, like I said, for RCD-1 to play a tune at the level of a first-year student, but obviously further down the road I'd like to be able to expand what the RCD-1 can do.
Getting back to MIDI, in terms of playing the recorder the information in a MIDI file will quite likely be adequate to program a recorder robot to play at the equivalent of a very accomplished performer. That's because of two things: 1) the recorder, relative to other wind instruments, is more simplistic; 2) due to the nature of the recorder, the information for the technique it requires lends itself well to the way a MIDI file is designed. To compare, the same can't be said of a trombone robot, where the variables (i.e. to accommodate such techniques as a slide glissando or the increased options for articulation) are not readily manipulated in present music notation programs (although MIDI would be able to accommodate these things if composition software had a reason to exploit them, but that's another story). Back to the RCD-1: if future versions of the recorder robot are to be able to accommodate the information (or equivalent) in a MIDI file, based on a generous estimate of what I've seen in MIDI we're looking at about 10 bytes per note. Again, how much memory you have dictates how long a tune can be, but presuming that a long tune is 500 measures of four beats each at a rhythmic density of 1/32 notes, multiplied by 10 bytes per note, that's about 160KB. Admittedly, I'm being very generous here, but I think it's close to what to plan for.
Do you have any part suggestions for the EEPROMs? I've seen them here and there, but I still need to learn more about how they and I2C work. Any tutorial or supplier links would be appreciated!
*Tonguing means articulating the note on a wind instrument. So this bit will tell RCD-1 whether to play the note with a "Tu" sound, or whether to play the note without articulating (which is called
slurring). The tongue on RCD-1 will probably be another solenoid that will close a valve that momentarily interupts the airflow to the recorder.
**In music, a whole note gets four pulses (or beats) and a sixteenth note get one quarter of a beat. For the robot, the tempo will be a constant for each program/tune, with the smallest pulse/increment being a sixteenth note.
