one of my favourite programs for the HP-34C is the "Calculator Program For Musical Notes", originally written for the HP-29C by J.M. Bowsher, published in the "Journal of The Audio Engineering Society", 1980 June, Volume 28, Number 6, Page 437.
the program lets you convert tonal frequencies into their corresponding musical notation and vice versa, by simply entering either the frequency in Hz or a musical notation in the form of an integer number that represents the notation in the following way:
Code:
C 0
C# 1
D 2
D# 3
E 4
F 5
F# 6
G 7
Ab 8
A 9
Bb 10
B 11
so that for example 440 Hz gets converted to 9.400, which is exactly the 4th octave of A. in the same way, slightly "off" tones like 441 Hz are converted to 9.404, which is again the 4th octave of A, but high by 4c (or "cents").
this is the transcript of Bowsher's program for the HP-34C:
Code:
001 LBL 0
002 R/S
003 LBL A
004 1
005 5
006 .
007 8
008 8
009 6
010 0
011 9
012 9
013 5
014 8
015 STO 8
016 X<>Y
017 EEX
018 1
019 5
020 CHS
021 +
022 STO 1
023 ABS
024 STO 2
025 1
026 6
027 2
028 6
029 4
030 X<>Y
031 X>Y
032 GTO 9
033 1
034 1
035 .
036 9
037 4
038 9
039 5
040 X<>Y
041 X>Y
042 GTO 1
043 FIX 1
044 INT
045 EEX
046 2
047 *
048 STO 0
049 RCL 2
050 FRAC
051 EEX
052 1
053 *
054 ENTER
055 INT
056 1
057 2
058 0
059 0
060 *
061 STO+ 0
062 X<>Y
063 FRAC
064 EEX
065 2
066 *
067 5
068 0
069 STO+ 0
070 X<>Y
071 X>Y
072 GTO 9
073 RCL 1
074 RCL 2
075 /
076 *
077 STO+ 0
078 RCL 0
079 1
080 2
081 0
082 0
083 /
084 2
085 LN
086 *
087 e^x
088 RCL 8
089 *
090 GTO 0
091 LBL 1
092 FIX 3
093 RCL 1
094 RCL 8
095 /
096 LN
097 X<0
098 GTO 9
099 2
100 LN
101 /
102 ENTER
103 INT
104 1
105 0
106 /
107 STO 0
108 X<>Y
109 FRAC
110 1
111 2
112 *
113 ENTER
114 INT
115 STO+ 0
116 X<>Y
117 FRAC
118 EEX
119 2
120 *
121 5
122 0
123 -
124 EEX
125 3
126 /
127 ENTER
128 ABS
129 STO+ 0
130 /
131 RCL 0
132 5
133 EEX
134 CHS
135 4
136 X>Y
137 GTO 2
138 RDN
139 *
140 GTO 0
141 LBL 2
142 CLX
enjoy!
(02-09-2019 12:11 PM)Hans Brueggemann Wrote: [ -> ]the program lets you convert tonal frequencies into their corresponding musical notation and vice versa, by simply entering either the frequency in Hz or a musical notation in the form of an integer number that represents the notation in the following way:
Fine. But how does it work? There are no instructions. How does the program determine which way the conversion between tone and frequency is done?
Could you please explain how the program is supposed to be used, and maybe you can also give some examples.
I also wonder what all the constants in the program are for. Can you say a bit about the way the program works? I have tried a similar conversion in Excel, and here only a single reference frequency is required.
Dieter
(02-10-2019 01:26 PM)Dieter Wrote: [ -> ]Fine. But how does it work? There are no instructions. How does the program determine which way the conversion between tone and frequency is done?
Input smaller than 11.9495 is considered a musical notation.
A frequency higher than 16264 is considered invalid.
Quote:Could you please explain how the program is supposed to be used, and maybe you can also give some examples.
Examples:
441 A
9.404
R/S
441.0
Quote:I also wonder what all the constants in the program are for.
\(15.88609958 = \frac{440}{2^\frac{115}{24}}\)
Quote:Can you say a bit about the way the program works?
These two programs for the
HP-42S may miss the fancy output but are probably easier to follow.
Frequency → Note
Code:
00 { 30-Byte Prgm }
01▸LBL "F→N"
02 440
03 ÷
04 LN
05 2
06 LN
07 ÷
08 4.75
09 +
10 IP
11 LASTX
12 FP
13 12
14 ×
15 END
Examples:
450
XEQ "F→N"
y: 4.00
x: 9.39
A
4 + 39¢
4698.63
XEQ "F→N"
y: 8.00
x: 2.00
D
8
Note → Frequency
Code:
00 { 27-Byte Prgm }
01▸LBL "N→F"
02 12
03 ÷
04 +
05 4.75
06 -
07 2
08 X<>Y
09 Y↑X
10 440
11 ×
12 END
Example:
G
6
6
ENTER
7
XEQ "N→F"
x: 1567.98
Cheers
Thomas
(02-10-2019 03:28 PM)Thomas Klemm Wrote: [ -> ]Input smaller than 11.9495 is considered a musical notation.
A frequency higher than 16264 is considered invalid.
OK, but the 34C has two label keys A and B so that this kind of trick is not required.
(02-10-2019 03:28 PM)Thomas Klemm Wrote: [ -> ]\(15.88609958 = \frac{440}{2^\frac{115}{24}}\)
I now have a program for the HP67 that is based on a slightly different constant and returns the output in the same way as the original program. Both conversions fit into not much more than 67 steps.
450 [A] => 9,439
4698,63 [A] => 2,800
7,6 [B] => 1568,0
Changing the input/output the way you did allows even more compact code, as you have shown. I think it even makes more sense to have the octave and then the tone plus cents. So instead of 9,439 I think that 4 and 9,39 are more intuitive.
Edit:
Here is an HP-34C version of your program. Since there is no two-line display the octave is displayed with "PAUSE". In either case the octave is returned/entered in Y and the note in X.
Code:
001 LBL A
002 FIX 0
003 4
004 4
005 0
006 /
007 LN
008 2
009 LN
010 /
011 4
012 .
013 7
014 5
015 +
016 INT
017 PAUSE
018 LastX
019 FRAC
020 1
021 2
022 *
023 FIX 2
024 RTN
025 LBL B
026 FIX 1
027 1
028 2
029 /
030 +
031 4
032 .
033 7
034 5
035 -
036 2
037 X<>Y
038 Y^X
039 4
040 4
041 0
042 *
043 RTN
450 [A] => "4" 9,39
6 [ENTER] 7 [B] => 1568,0
Dieter
We could also use
55 with
1.75 instead of
440 with
4.75.
Which makes it a bit shorter.
Or then only use:
\(16.3515978313=\frac{440}{2^{4.75}}\)
Similar to the original program.
I must admit that I still don't really understand why it shifts by an additional 50¢.
Interestingly a search for just
15.88609958 using Google brings up a link to
JAES Volume 28 Issue 6; June 1980.
This is in accordance with:
(02-09-2019 12:11 PM)Hans Brueggemann Wrote: [ -> ]published in the "Journal of The Audio Engineering Society", 1980 June, Volume 28, Number 6, Page 437.
But unfortunately that paper is hidden behind a paywall:
Quote:This paper costs $33 for non-members and is free for AES members and E-Library subscribers.
Cheers
Thomas
(02-10-2019 06:15 PM)Thomas Klemm Wrote: [ -> ]We could also use 55 with 1.75 instead of 440 with 4.75.
Which makes it a bit shorter.
Or then only use:
\(16.3515978313=\frac{440}{2^{4.75}}\)
Similar to the original program.
That's what I used for the mentioned HP67 program: 55/4 · √√2.
(02-10-2019 06:15 PM)Thomas Klemm Wrote: [ -> ]I must admit that I still don't really understand why it shifts by an additional 50¢.
Take a look at line 67 and 121 ff. respectively of the original program. This seems to add or subtract 50 cents.
Other calculations still remain unclear to me. For instance line 017 ff. Here a tiny value of 1E–15 is added. ?!? Then both the sum and its absolute value are stored separately. Can this be negative at all? Later both (073 ff.) values are divided, so this returns the sign of that number. And there is a second occurence of a sign calculation starting at line 127. What is the purpose of that? I also wonder why line 084 ff. calculate e
x · ln 2 instead of a simple 2
x. Maybe Hans can shed some light on this.
Dieter
(02-11-2019 07:49 PM)Dieter Wrote: [ -> ]That's what I used for the mentioned HP67 program: 55/4 · √√2.
With the
HP-42S using this expression is one byte smaller:
\(\frac{55}{\sqrt{\sqrt{128}}}\)
Code:
00 { 12-Byte Prgm }
01 55
02 ×
03 4
04 ÷
05 2
06 SQRT
07 SQRT
08 ×
09 END
Code:
00 { 11-Byte Prgm }
01 55
02 ×
03 128
04 SQRT
05 SQRT
06 ÷
07 END
This leads to the following programs:
Code:
00 { 30-Byte Prgm }
01▸LBL "F→N"
02 55
03 ÷
04 128
05 SQRT
06 SQRT
07 ×
08 LN
09 2
10 LN
11 ÷
12 IP
13 LASTX
14 FP
15 12
16 ×
17 END
Code:
00 { 27-Byte Prgm }
01▸LBL "N→F"
02 12
03 ÷
04 +
05 2
06 X<>Y
07 Y↑X
08 55
09 ×
10 128
11 SQRT
12 SQRT
13 ÷
14 END
Or then you simply store that value in a register:
55
ENTER
128
SQRT
SQRT
÷
STO 00
16.3515978313
And end up with:
Code:
00 { 22-Byte Prgm }
01▸LBL "F→N"
02 RCL÷ 00
03 LN
04 2
05 LN
06 ÷
07 IP
08 LASTX
09 FP
10 12
11 ×
12 END
Code:
00 { 19-Byte Prgm }
01▸LBL "N→F"
02 12
03 ÷
04 +
05 2
06 X<>Y
07 Y↑X
08 RCL× 00
09 END
Quote:Take a look at line 67 and 121 ff. respectively of the original program. This seems to add or subtract 50 cents.
This led me to the definition of the constant
15.88609958 in the first place.
Still I don't grok the benefit of doing it.
Quote:Maybe Hans can shed some light on this.
1+
Cheers
Thomas
If we don't care about using registers we can use the exponential regression model with:
EXPF
CLΣ
55
ENTER
1.75
Σ+
440
ENTER
4.75
Σ+
And then let the forecast functions do the heavy lifting:
Code:
00 { 16-Byte Prgm }
01▸LBL "F→N"
02 FCSTX
03 IP
04 LASTX
05 FP
06 12
07 ×
08 END
Code:
00 { 14-Byte Prgm }
01▸LBL "N→F"
02 12
03 ÷
04 +
05 FCSTY
06 END
Cheers
Thomas
(02-11-2019 10:26 PM)Thomas Klemm Wrote: [ -> ]Still I don't grok the benefit of doing it.
For those of you who want to give the
HP-29C a try here's the original program:
Data
Code:
00: 1200
01: 1731.234049
02: 15.88609958
03: 50
04: 100
05: 11.9495
06: 16264
07: 10
08: 0.0005
09: 1e-15
Program
Code:
01: 15 13 00 : LBL 0
02: 74 : R/S
03: 24 09 : RCL 9
04: 51 : +
05: 23 .1 : STO .1
06: 15 64 : ABS
07: 23 .2 : STO .2
08: 24 06 : RCL 6
09: 21 : x<>y
10: 14 51 : x>y
11: 13 22 : GTO i
12: 24 05 : RCL 5
13: 21 : x<>y
14: 14 51 : x>y
15: 13 01 : GTO 1
16: 14 11 01 : FIX 1
17: 14 62 : INT
18: 24 04 : RCL 4
19: 61 : ×
20: 23 .0 : STO .0
21: 24 .2 : RCL .2
22: 15 62 : FRAC
23: 24 07 : RCL 7
24: 61 : ×
25: 31 : ENTER
26: 14 62 : INT
27: 24 00 : RCL 0
28: 61 : ×
29: 23 51 .0 : STO + .0
30: 21 : x<>y
31: 15 62 : FRAC
32: 24 04 : RCL 4
33: 61 : ×
34: 24 03 : RCL 3
35: 23 51 .0 : STO + .0
36: 21 : x<>y
37: 14 51 : x>y
38: 13 22 : GTO i
39: 24 .1 : RCL .1
40: 24 .2 : RCL .2
41: 71 : ÷
42: 61 : ×
43: 23 51 .0 : STO + .0
44: 24 .0 : RCL .0
45: 24 01 : RCL 1
46: 71 : ÷
47: 15 42 : eˣ
48: 24 02 : RCL 2
49: 61 : ×
50: 13 00 : GTO 0
51: 15 13 01 : LBL 1
52: 14 11 03 : FIX 3
53: 24 .1 : RCL .1
54: 24 02 : RCL 2
55: 71 : ÷
56: 14 42 : LN
57: 15 41 : x<0
58: 13 22 : GTO i
59: 24 01 : RCL 1
60: 61 : ×
61: 24 00 : RCL 0
62: 71 : ÷
63: 31 : ENTER
64: 14 62 : INT
65: 24 07 : RCL 7
66: 71 : ÷
67: 23 .0 : STO .0
68: 21 : x<>y
69: 15 62 : FRAC
70: 24 00 : RCL 0
71: 61 : ×
72: 24 04 : RCL 4
73: 71 : ÷
74: 31 : ENTER
75: 14 62 : INT
76: 23 51 .0 : STO + .0
77: 21 : x<>y
78: 15 62 : FRAC
79: 24 04 : RCL 4
80: 61 : ×
81: 24 03 : RCL 3
82: 41 : –
83: 33 : EEX
84: 03 : 3
85: 71 : ÷
86: 31 : ENTER
87: 15 64 : ABS
88: 23 51 .0 : STO + .0
89: 71 : ÷
90: 24 .0 : RCL .0
91: 24 08 : RCL 8
92: 14 51 : x>y
93: 13 02 : GTO 2
94: 22 : R↓
95: 61 : ×
96: 13 00 : GTO 0
97: 15 13 02 : LBL 2
98: 34 : CLx
Examples
Code:
440 9.400 (A4 exactly)
441 9.404 (A4 + 4 ¢)
439 – 9.404 (A4 – 4 ¢)
123 –11.207 (B2 – 7 ¢)
50 7.135 (G1 + 35 ¢)
60 –11.149 (B1 – 49 ¢)
0.400 (C4 exactly) 261.6
10.400 (Bb4 exactly) 466.2
–4.321 (E3 – 21 ¢) 162.8
4.321 (E3 + 21 ¢) 166.8
14.0 (?) Error
0.451 (C4 + 51 ¢) Error
Thanks to the examples I understand now that the difference in cents to a pure note must be between
–50¢ and
50¢.
A negative value is indicated by a negative sign.
Though I can see that this is a reasonable convention I'm still not convinced to enter the data in this peculiar way.
Furthermore I get
-9.400 for the
440Hz of the first example.
Quote:We are left with the problem of displaying the number of cents by which the note is sharper or flatter than the nominal note of the scale. It would be most elegant to use the exponential part of the display to carry this information. The author has studied this problem but has concluded, regretfully, that this is impossible to execute on a reasonably simple calculator, as a great number of steps are required to handle the computations. Thus we are forced to use the next two digits of the display to handle the number of cents.
The real problem is to distinguish for instance
B0 + 23¢ from
C#1 + 24¢.
Both entries
11.0e23 and
1.1e24 lead to the same number:
1.1 24
Cheers
Thomas