>My question is: Has anyone at Electrix read _The Mythical Man-Month_? Now we're getting VERY OT, but I doubt the problems with the Repeater have to do with the phenomena described in "The Mythical Man-Month," which mainly deals with the problem of scale and larger projects. I doubt that there are THAT many programmers working on the Repeater. It's not that large a program. There are parts that are very *difficult*, like the pitch/time shifting for example, but there just aren't that many parts you could divide the problem up into! I'd be surprised if there were more then half a dozen programmers involved in the Repeater. I wouldn't be surprised if the number was four and the technical lead (which is the correct number for that project -- one person doing the operating system, one person doing the pitch and time-shifting, one person doing the playback, and one person doing the time sequencing and synchronizing). No, I'm sure the problem is that they have built a complex system and there emergent phenomena of an undesirable nature (what we call "bugs"). <soapbox> Emergent phenomena are things that a whole system does that are not obvious from looking at the separate parts. They can be good or bad. Real instruments have both good and "bad" emergent phenomena. Things like "wolf tones" on a guitar or "throat notes" on a clarinet are "bad". Things like harmonics or overtones are good. Computer programs beyond a certain size have emergent phenomena that are almost always "bad" and even just bad like hang-ups, crashes or corruption. The reason is that the program world just doesn't force you to completely specify things in the same way the real world does. The programmers make mistakes which aren't immediately caught because there is no specification that completely proves the program correct. Real-time programming is worse. The programmers have a rough, informal model of what possible real-time events can occur and when. But it's kept in the back of their heads and not completely put on paper. Since the model is never formalized, you can't examine it to see if there are any assumptions about the state of the system that can't be justified. The solution is painful. Each section must be taken apart and completely specified. Any section that doesn't have a clear and unambiguous specification should be taken apart and refactored until it is. And the entire timeline of possible real-time events needs to be completely specified so you KNOW what events can occur, when. <brag> I know whereof I speak, because I have done just this to a real-time Java animation program over the last eight weeks. </brag> BUT I've been programming for a living since 1979 and it's only very recently I got completely rigorous. So I know very very well what it's like to have a completely mysterious bug that you are *never* able to fix... /t <http://ax.to/fortune>.........a new fortune every minute. <http://FortNY.com>..................Forteans of New York.