Since an "arbitrary piano" is tuned by turning screws, like simpler string instruments, the only pitches that it cannot be tuned to are those that fall outside the range of each string. Departing from the usual inharmonically tempered 12-EDO tuning would just sound strange, possibly outside some piano tuner's professional comfort zone.
I'm starting to read the course at the beginning, and a depressing aversion to explaining why and not only what seems apparent, probably motivated by a desire for brevity and informality that also causes serious defects. For example:
- 1.3 grand staff: "Note that middle C is always clearly notated in either the upper or lower staff and never floats between the two staves." It doesn't tell that the choice of which staff the notes belong to indicates which hand should play them.
- 1.4 accidentals "... are characters that can be placed before notes to raise or lower them." Not to reuse staff locations to distinguish the notes one needs to use.
- 1.5 Enharmonic notes: "When two notes sound the same but are written as two different notes on the staff, the written notes are said to be enharmonic."
This is totally wrong, not merely maddening, but before discussing scales any decent explanation is impossible.
- 3.3 Scale Degree Names: in the middle of chapter 3 (minor scales) because there's no f** definition of what a scale is.
- 6.1 Introduction to Triads: "A triad consists of three notes stacked in consecutive thirds. A triad is also called a chord as well as a harmony. (Harmony also refers to chord progressions.)"
It's sad because many other places benefit from the concise and elegant treatment, for example:
- 5.5 Augmented and Diminished Intervals: "Augmented intervals are one half step larger than perfect or major intervals and diminished intervals are one half step smaller than perfect or minor intervals."
Behind the article's dichotomy of CTTI and RTTI there is the catalogue of concrete features (e.g. printf-like string formatting) and the respective algorithms with an exponential or linear cost in the number of types.
The choice between optimized but polymorphic and lean but indirect implementations and the choice to do the work statically at compile time, dynamically at run time, or never are more independent than the article suggests, and the constraints more complex. For example, the known types at compile time that need to be handled could be all important, or an infinite (sometimes merely impractically huge) superset of the types that are actually used for a certain input, or anything in between.
I definitely agree, but grandfathering in this specific exception suggests a definition variant: a salad can be mixed and shuffled (possibly from an ordered initial state), and in this case it remains a salad; it isn't damaged, and on the contrary it usually improves (typically by increasing the entropy of solid component positions and distributing liquid condiments more uniformly).
I think you've nailed it here. I had a really good wedge salad last night. The advantage of a wedge salad is that the blue cheese stays on top evenly distributed. On many salads it'd drop to the bottom and be less evenly distributed. The untossed salad is more evenly mixed than the tossed one, and both would be improved by more entropy.
Part of the appeal of the wedge salad is the crispiness of the lettuce. So if you improve it with more thorough mixing, you'd have to consume it immediately before the crisp is lost. I don't think this is incompatible, just a nuance.
This becomes more obvious with a layered salad -- layered salads seem designed to keep ingredients separate in the presentation container, but get mixed together in the transition to the plate or dipper.
Given that it is easy to feed FFMPEG arbitrary input to exploit any vulnerability, popular codecs are very likely to be already secure enough, while unpopular ones are far more dangerous and deserve more attention. It can be assumed that an attacker would target the worst, easiest to exploit codec they can find in the whole of FFMPEG.
It is usually possible to design a representation where cows and pigs are the same thing, either Animal class instances or equally unified other data structures, and their differences are data (e.g. weight, length, one of several colour patterns).
> start incorporating DUP and OVER and ROT and PICK and friends
If one understands adding and consuming values at the top of the stack, putting the stack in the state you want it is certainly a small logical step without new theoretical baggage.
Word definitions and the accompanying pointer tricks are more likely to be challenging.
The stack is functionally very simple, but keeping a mental model of what exactly is on it at each point in your code and how to transform it to perform the calculations you need can be tricky.
I certainly don't know "what my program does" if it's a game where, at every frame of the simulation, thousands of entities might or might not be created, deleted and recycled depending on player inputs.
Can you describe a superior replacement for generation counters?
If you don't know what your program does, DOD asserts that you are a bad programmer and you should first figure out what your program does before continuing.
Sounds like you're writing a game engine, not a game?
You don't seem to grasp that handling individual entity state has a cost that has to be minimized and amortized.
A generation counter offers a good deal in many common cases: for the fixed small cost of incrementing the generation counter when an entity ID is assigned a trivial test, also fixed cost, can disambiguate successively recycled entities that share the same number and tell which one is current.
This adds up to work proportional to the number of distinct entities plus, assuming obsolete references are eliminated, work proportional to the number of references to entities, which is clearly very good.
Do you recommend a different way to solve the same problem? There is at least one obvious one.
reply