1. Actually, what I was thinking of getting, and paying for, to make learning easier, was this suite http://shop.borland.com/Product/0%2C...0110%2C00.html

And I would start learning with this program in the suite http://www.borland.com/borlandcpp/tu...te/turbo3.html

which they say is "the fast path to learning C."

I do think that a tutorial in a package with the compilers and programming tools would make learning easier and faster; I wouldn't have to hunt around all over the web for often incomprehensible tutorials full of typographical errors, or news server messages filled with hacker-talk consisting of cryptic slang jargon comprehensible only to other experienced programmers who speak only computer languages and not any of the normal spoken languages of the masses.

But since I don't know if I will be able to earn money as a programmer, it is hard to justify the outlay of \$70, just for a "pastime" which I seem to like.

2. This can only be understood by a musician.
(though they could do this with a bunch of pages in Excel. ) or some other little utility that saves them from having to do repetitious key-ins on a calculator.
I have no idea how to test if your piano is equal tempered with Exel. Can you explain it more exactly?

klausi

3. Briefly:

You use a spread sheet or program to create a table of fundamental frequencies, and tables of frequency-differences between the coincident partials (coincident harmonics) of musical intervals. Then you play the intervals and listen for frequency differences that match your calculated differences, and also take into account inharmonicity (partials of a tone that aren't exact integer multiples of the fundamentals), and adjust the pitch of one tone or both, so that the actual differences are closer to the calculated differences.

Equal temperament is defined by the 12th root of 2. That is, 2^(1/12).

Multiply 440 (freq in hz of A49) by that to get A#50 (pronounced a-sharp-50) (though you might want to use 438 hz or other "standard" to start from). Divide 440 by that to get G#48. Assign all 88 pitches to an 88-element "array" that indicates the fundamental frequency of each of the 88 "notes" on the piano, relative to the pitch of A49. Pitches really, not notes.

That's page one.

Then make a page for each interval you want to describe. Calculate the harmonics from the fundamentals, and locate coincident harmonics, for the 2 notes in the interval. Since you tune to equal temprament instead of just intonation, the coincident partials will be a slightly different frequency (they won't be exactly coincident), instead of being the same frequency. Find the direction of the difference (expanded interval or contracted interval), and write each difference out, print each out, tabularize the information about the intervals and the coincident-partial difference frequencies (commonly called "beat rates"). You listen to the actual interval on the piano, and determine if the beat rates are too fast or too slow, or just about right, and adjust them if necessary.

There a just lots and lots of intervals you can tabularize, and listen to, so any program you write, or spread-sheet you create, is simply to save you the work of doing hundreds or thousands of calculations on a calculator.

4. I've wrote a program in Atari BASIC to do the above, many years ago. Later I discovered it could probably be more easily done with a spread sheet, and maybe a few simple macros, but I never completed my Lotus 1-2-3 spreadsheet to do it. The printouts from the Atari program were adequate. I just saved the printouts and referred to them when tuning a piano.

5. I could write a complete, easier to understand explanation of how to tune a piano, including calculating the beat-rates of intervals, klausi, but it would take several pages of writing. What I wrote above will inform someone who already knows how to calculate the beat rates, that I also know how -- but it isn't really educational; I don't think it will really be too helpful to someone who doesn't know how and wants to learn; they might be able to learn from it, but I think it would be a lot easier if i explained things in a more leisurly fashion.

The same thing with me learning C. I could try and learn from news groups and scattered tutorials, but I think it would be easier to get the Borland Turbo C/C++ Suite I mentioned before. There doesn't seem to be such a choice in re to learning win32 assembly language though. I think i will have to learn that from message boards, news groups, and web tutorials.

6. Thank you!
IŽll try to understand it.
I asked because I play the piano.
Maybe I can use your explaination.

klausi

7. I'd suggest starting by creating a program or spreadsheet that calculates the equally tempered fundamental freq of all 88 pitches (most pianos have 88 keys and 88 pitches). Hint: to avoid accumulating errors in less signficant digits, calculate each pitch relative to A 440 -- the conventional "standard" of musical pitch.

Beyond that, I suspect that everyone else here but those who tune or play piano, might probably prefer it if this conversation was continued at piano-tuning message board!!

http://www.psc.edu/general/software/...ieee/ieee.html

9. Salem writes
-------------------------
-----------------------

Well, that describes how 32 bits are used to store variables with the min and max values (the range) specified -- but why would anyone want to store variables this way (other than, of course, because whoever designed and built their computer didn't give them any choice)? And of course there is no explanation of how this storage method results in 6 or 7 significant digits or whatever it is. I'm just too worn out right now to try and work out a proof of how the method allows for the number of significant digits it allows for!

10. > but why would anyone want to store variables this way
It's a compromise between extending the range of numbers available, and the resulting loss of accuracy in the least significant bits, without resorting to extremely memory intensive solutions which store all the bits required.

> And of course there is no explanation of how this storage
> method results in 6 or 7 significant digits or whatever it is
To represent any number (n) in binary, you need log2(n) bits to do it.

To represent a single decimal digit (10 values), you need
log2(10) = 3.322 bits (approximately)

So, if you divide the 23 bits in a floating point mantissa, by that value, you get something like 6.9 decimal digits

Or look at it this way - 23 bits in hex is 0x7FFFFF, which is 8388607 decimal. It can store all 6 digit decimal numbers, but it stops short of 10000000, so it can only store most 7 digit decimal numbers.

11. Ah! Thanks Salem.

That was less complicated than I was worried that it might be!