A quote from discord: "apparently alpha-zero has been replicated in open source as leela-zero, and then leela-zero got a bunch of improvements so it's far ahead of alpha-zero. but leela-zero was barely mentioned at all in the paper; it was only dismissed in the introduction and not compared in the benchmarks. in the stockfish discord they are saying that leela zero can already do everything in this paper including using the transformer architecture."
There are a few misunderstandings here. Rational Bézier curves are incidental in this article, and the conclusion is not that they are correct. They were just a convenient curve I used to express the main message of local control, and the article endorses looking for other curves that fit the properties.
The parameter count has not gone up; it's equal to or less than usual Bézier control handles, because I forced the parameters to take specific values.
The part that is "new" about the Béziers is the new formula that selects one specific Bézier out of all the possible choices. I think this linguistic accusation is silly; for example, if someone discovers a new rock, it would be fair to call it a "new rock" even though rocks have been discovered thousands of years ago.
These curves are also unrelated to the file format; the curves are designed to fit how the user thinks about curves rather than be computer-efficient. For the tooling point, I think you are agreeing with me while arguing; I agree that there's no reason the curve should match what is used in the final product, and some of the other curve choices I considered require a complex conversion step.
I have used this in some commercial software before (maybe Illustrator?); my experience was not positive. When you move a node, some not-so-close curves start wiggling, and you think, "I already set that part correctly, stop moving please". It behaves very poorly around rounded corners. Adding points causes the curves to shift, usually not how you want, and then you try to add more points, which causes more shifts, etc. Arc length-based interpolation might do better in this respect, as opposed to the (# of points)-based interpolation which I expect it used.
The alternative, which obeys similar principles, is the Pencil tool. This simply spams out a ton of points to match what you draw. https://news.ycombinator.com/item?id=37460009 mentions that these points can be capably reduced, which could serve your purpose.
The ideal dimensionality of the parameter space depends on the jaggedness of the curve. Derivatives are useful when they stay constant over a stretch of time; when derivatives vary too much, it becomes more efficient to use more points of lower degree. This is the same calculation in other domains of approximation: numerical integration, DiffEq, and Taylor series.
For example, to draw rough surfaces, point-to-point lines are the most efficient way, with a ton of points. For industrial geometric shapes, lines and ellipses become efficient. As the smoothness of the curve goes up, more derivatives become valid. But sometimes those higher derivatives are not useful.
This is why the parent comment likes the Pencil tool; it's optimal for high variation, because it is a local (smoothed) control of position, the zeroth derivative. The cost is some loss of smoothness, which likely doesn't matter for her domain, since her hands move smoothly enough.
I think the Pen tool would be a more competitive alternative with a better control scheme. For example, a Pen tool with local control would unify the Pencil and Pen: letting you draw jagged curves by holding your mouse down, and letting you draw straight lines and smooth curves by clicking. There would be no interruption of flow, as you can use either method freely to continue a curve. They should inherently be the same tool anyway, just with different numbers of derivatives.
It's a UI problem, not a mathematical problem. No set of curves can represent everything exactly, but they all can get close. The goal is just to make it easy to get close.
The computer can produce a near-perfect circle with Béziers for each 1/4 arc, and near-perfect circles are usually good enough. It's just inconvenient. It's also hard to manipulate the generated circle; the user might have a clear image of his head of the changed circle he wants, but pushing the control points to get there is not easy.
The mathematical "axioms" in the article are only attempting to provide a clean interface, so that the user can easily translate what is in his head to what the program creates. The circle axiom says, "The user often wants a circle, and also expects a circle, so let's produce the expected circle." There's no other mathematical purity involved.
The source code is visible with Ctrl+U, I didn't minimize anything. The g9 use is pretty neat. It definitely deserves the shout-out I gave it.
I just now uploaded a worse C++ desktop version with saving and loading: https://github.com/ad8e/local-curves This desktop version is 5 years old. I think the web version is better. This github repo is only interesting if you want to copy code from it; it's not practical as a drawing tool.
It's not as easy to visualize the tangent magnitude as you are suggesting, because the time parametrization makes the calculation fail - the curve doesn't travel forward at a constant rate. This is best seen with the second example: If the left handle is fully extended and the right handle is 0, the Bézier curve looks almost exactly the same as when the handles are reversed. Here's a picture: https://i.imgur.com/WkanN1G.png
The handle varies from 0 to full-strength, but the magnitude of the tangent vector stays constant. This means the handle doesn't decide the magnitude. Tracing the path in your head to visualize the changing tangent vectors would mean visualizing a competition between t^2, (1-t)^2t, and (1-t)^3, which I find difficult, even with some calculus knowledge.
Hex keyboard, purple keys under thumbs. Extra set of temporary purple (blue) keys 1/2-1/7x, not ratios, applying to one copy only. Two copies of the green keys, one for each hand. Added numbers are 36, 40, 48; unsure about 45. 7, 14, 15, and 30 probably moved. The organized core should be continued as much as possible; I share the sentiment that ease of learning is important. The physical buttons should make fat-fingering convenient, because that's useful for fingering (and for playing lots of extra notes).
The musician probably wants his feet for other things like sustain pedal and effect pedals. I won't be too greedy :)
Though, one possible use of foot pedals is to select the instrument timbre. Since with this layout, you can take the role of two musicians, playing two different timbres, and you might as well have the flexibility to change one instrument out while the other is playing. All your fingers are occupied so it'd be hard to ask them to press extra buttons.
It's possible to generate 12 ET too, by rounding all the keys and harmony changes. Just as 12 ET is a good approximation to Just Intonation, Just Intonation is also a good approximation to 12 ET. The tones lose some accuracy but gain compatibility with MIDI interfaces.
However, it would be hard for me to implement this feature, since I have no midi devices, no midi experience, and my browser (Firefox) also doesn't support WebMIDI.
I'm thinking about implementing record-and-replay, since the playback and storage-format are already done, but midi will likely be deprioritized unless there is significant interest.
In the original design, temporary harmony changes (hold-and-release) was the feature of the thumb keys, but there are no thumb keys here, huh.
It's necessary to have stateful harmonic changes, to be able to transition more than a little at a time. But I will add your option too, since it's also useful. I'll need to think about the interface a little bit, since I would either have to add ` or Shift to the keyboard, which will widen it a bit.
When you press these new temporary keys (after they're done), I'll make them change the green numbers. That is hard to do with the permanent purple keys, since they need to keep a base state.
State tracking is up. Fundamental = product of (prime)^(number of squares in the row), where the blue squares are 2, green 3, yellow 5, red 7. Let me know if this interface can be improved, such as by bolder colors or better explanations.
I didn't find a good way to implement absolute frequency without the rest of the visualization too, since it has to store and show "what were the last notes I just played", so the user can compare their frequencies to the current note options. So I don't have an idea for an easy-to-implement design here.
There's a desktop version which I unfortunately don't have the time to get in release state, but I'll release the source code for everything eventually (maybe months later).
