Part 17: Assignment #6: Rubbish Audio Thing
Rubbish Audio ThingBefore I say anything else, you should probably look at the spec. And the ad.
So. That's the HARMONIC MAXIMIZATION ALGORITHM. Let me be perfectly clear, based on this formula, what this thing does. It doesnt care about the actual frequency (pitch) of the sound at all. It does only one thing:
If the sound is soft, or not too loud, it does almost nothing. But if the sound is sufficiently loud, the device makes it louder. The only difference is the increased contrast between softer sounds, and louder sounds. That is literally it. The device doesnt do anything else.
(To be fair, though, the promoters are at least using the word 'maximization' correctly.)
Anyway, let's get to work. The first half of Carl's favor is him not having anything to do with the construction of this.
[ ~ ]
There was a grand total of one design issue with the device: all three inputs/outputs are simple I/O and there's only two simple I/O pins on a MC. This is fixable, though - since the maximize button is an on-off switch, an output expander can work as a handy simple-to-XBus converter. Aside from that, it's just a matter of turning the HARMONIC MAXIMIZATION ALGORITHM into code.
[ ~ ~ ]
Bonus: After the Baron incident (thanks @whitehelm 😅), I've decided to challenge myself and make optimized versions of my designs if I have a bit of spare time. In this case, I decided to try to write a version of the MC with as few lines of code as possible.
The revised version has the same wiring as the original, but two changes to the code:
(1) In the first version, the MC would move the audio sample to audio-out with a stop at acc if maximize was on, but move it directly out if maximize was off. This took 3 lines for the two different versions of the 'move' code.
This version always moves the sample into acc first, using only the same two lines of code to move it around.
(2) I did a bit of algebra on the HARMONIC MAXIMIZATION ALGORITHM.
(audio_in - 50) x 4 + 50 = audio_in x 4 - 50 x 4 + 50 = audio_in x 4 - 200 + 50 = audio_in x 4 - 150.
It's the same formula, but it only uses two math instructions instead of three.
That's as optimized (for lines of code) as you can get, I think. It turns out, by the way, that the revised version is slightly more power-efficient on average than the original, probably because of (2).
Time to send the design off.
...
I felt sorry for Joe when he got the Solitaire game taken off his work tablet.
I don't feel as sorry about what happened to his speakers, for some reason.