Quote:
Originally Posted by twobob
For my part I would like to see it documented to indicate why you used certain values or number types to constrain number ranges.
I did that in a "Theory of Operation" in some of my posts where they "funny business" was what I was trying to teach.
|
In this case, the "funny number stuff" is just there to synthesize some interesting noise.
If this had been a "musical synthesis" demo, I would have tried to show what was going on in the "magic formulas". This is so simple I did not think that necessary, but because you are "into" music, I will do that now
... Done! I added a "Theory of Operation" section for the tiny sound synthesis formula to the Top Post.
Regarding internal documentation, I use a little inline commenting where needed, and I document the important variables that you may want to change with inline comments where they are defined. But stuff that is "just there" to be used and not changed, I like to "black box" so it does not distract from the "important" stuff.
Feel free to create fully comment hybrid-style source code that has more documentation if you want, but I would rather move on to the next incremental step in my evolution of native mode sound software for the eink kindles. I got a lot of professional criticism by colleagues over the years for "too many comments" in my code, so now I try to make my code small, simple, and self-evident, so it only needs minimal comments to guide you through it (with the help of RTFM on the "standard" function call parameters and data structures).