If anything, it had been quite customary to supply references for some important facts. Thus letting readers to explore further and interpret the facts.

With AI in the mix the references become even more important, in the view of hallucinations and fact poisoning.

Otherwise, it's a forum. Voting, flagging, ignoring are the usual tools.

I wonder what is author's view about user's reasons to choose a C API?

What I mean is users may want exactly the same freedom and immediacy of C that the author embraces. However, the very approach to encapsulation by hiding the layout of the memory, the use of accessor functions limits the user's freedom and robs them of performance too.

In my view, the choice of using C in projects comes with certain responsibilities and expectations from the user. Thus higher degree of trust to the API user is due.

Well, apparently [0], in a 1947 document "Planning and Coding Problems for an Electronic Computing Instrument, Part 1" by H. Goldstine and J. von Neumann it is stated:

    "We call the coded sequence of a problem a routine"

I always thought that the functions did not need a call keyword, as they normally would return a value, so that functions would appear in an assignment. So one just uses the function.

What needed a CALL was a subroutine, which effectively was a named address/label.

Indeed it would be just as possible to GOTO the address/label and then GOTO back. CALL keyword made the whole transaction more comprehensive.

So in a sense it was similar to calling up someplace using the address number. Often times this would change some shared state so that the caller would then proceed after the call. Think of it as if a 'boss' first calls Sam to calculate the figures, then calls Bill to nicely print the TPS report.

Eventually everything became a function and subroutines were associated with spaghetti...

Now, why is that it's called routine (aka program) and subroutine?

Say, if I wanted to see immediate effects of changing an incidence angle, could I just "scroll" the incidence parameter?

I like the idea. Happy New Year!

Such a wise way to both elicit ideas and encourage introspection. Very inspiring!

That's why this advice is common. It's important to be clear about the reasons for reaching out.

The original Nokia 5110 obviously lived long, probably still is there in author's drawer in some disassembled state.

Indeed, the announced Part 2 has not been linked so far...

However, the internal capacity is fairly limited and there's some tolerable yet a delay after the recording to save the buffer on the flash.

I don't think there's a ready way to copy such internal recording from the piano onto some external medium.

This device may be a nice 'upgrade' for such digital pianos. It'd be nice if the recordings can also be played for a selected hand, so that it could be used in learning.

It helps also to develop some sort of notation for yourself. This way you can track and repeat your moves.

Solving by layers is kinda logical. So solving one side (first layer) is not hard. Then some experimentation with rotation sequences which temporarily break the solved layer/face and then re-assemble it will lead to discovery of moves to swap the edges into the second layer.

The hardest then is to solve the third layer. Again, the notation and observations help charting your way through.

A curious discovery may be about some repeated pattern of moves which may be totally shuffling the cube yet, if continuing it, eventually returns the position to the beginning state. It's kind of a "period".

Have fun.

Lots of interactive ideas could be easily implemented with already available assets (sprites, backgrounds, sounds), customized too. It's more tooled for platformers. There are many nice tutorials (loadable projects). Tons of books (we used 'Super skills. How to code').

The other day this 8yo even had to face first ever concurrency bug - the race condition. Alas there are no ready mutexes as such in Scratch, but we found a way to synchronize the execution.

At times I did feel that it'd be faster to just type the code, but the kid actually felt more in control doing all the needed coding with touch/mouse.

Also the projects/games are shareable, so friends can load that too.

I do question the need for the verbosity of their own.

As a constructive advice, I do believe that a visual representation of the subject serves better not only to this context but also to the target audience.

As a side-note, I have a member of such audience still enjoying the summer break ... the wall of the OP text proved impenetrable, despite the initial interest.

https://en.m.wikipedia.org/wiki/Syndactyly