Other than Yang Song, who were Caltech's AI faculty hires with issues?
932 karma · joined February 18, 2021
Teknium: Okay and Ive had 4 high-ish level sources tell me they dont plan to release it ever though
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.
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.
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.
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.
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.
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.
Windows: https://github.com/randyrants/sharpkeys
Ubuntu Linux (don't know about other Linuxes): /usr/share/X11/xkb/symbols/pc
key <CAPS> { [ Caps_Lock ] }; key <CAPS> { [ Control_L ] };
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.
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.
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.
(nothing there now!)
The three necessary primes to represent on the organized lattice are 2, 3, and 5. Given a key like 16, each of these primes should be represented in its adjacent buttons, hopefully in an axis-like manner, because these are the consonant notes to it. Left of 16 is 5/4, right is 3/4, and up-down is 2 and 1/2. But why this way?
Consonant pitches stay within a range - so large leaps in pitch are the least common. That means next to any number, the adjacent keys must have close by numbers. That's why the three primes 2, 3, 5, are converted to 2, 3/4, 5/4 - because these are the closest numbers to 1, after multiplying by a power of 2.
Your hand has a harder time reaching vertically than horizontally. 2 is the largest of these three numbers, which is why 2x is on one of the 4 vertical directions, and 3/4 and 5/4 are on the horizontal directions. Furthermore, it means that 2x must be on the 5/4 side, not the 3/4 side - because this keeps pitch distances the smallest.
There's only one remaining decision - why right to left? Your hand has an easier time turning inward than outward. And, whichever way it turns, the horizontal notes should have pitches as close as possible. Thus, 5/4 must be to the left direction.
Luckily, divisors don't exist, so the fact that the 3/4 axis and 5/4 axis are on the same line - rather than 3/4 turning to 4/3 on the opposite side - is perfectly fine.
So thanks to the above, the keyboard is forced to be this way, and every note is in its logical and rightful place, with no subjective choices. Except not, because there's not enough space. And because 7 and 15 can't be on the lattice, so they are just placed wherever there's room. 2 should really be below 1, and 3 should be where 2 is. 30 should be 40, etc. I tried to maintain the structure as much as possible but had to make things fit.
EDIT: thanks to your feedback, I added a textbox below the keyboard. It will show how to play things if you can write the ratios of the notes. This may be a helpful map for turning 12 ET into just intonation:
C 16/15 D9/8 6/5 E5/4 F4/3 7/5 G3/2 8/5 A5/3 16/9 B15/8 2
The first is, yes, some of the notes from Debussy are actually poorly playable on the piano. One is this: https://i.imgur.com/K0Wuu3Q.png. This is a visualization I built (and which can't be ported to web easily, so unfortunately it's just something I have for now). It's like a scrolling player piano with rising notes, and the numbers next to the bars are what the numerators are. Note there are two 7s in the middle, and pianos are not good at 7s. I've verified these numbers are correct manually, so it's supposed to sound like that and the piano has an inaccurate approximation. This corresponds to this location in the score: https://i.imgur.com/24XY8vR.png
The second is, I suspect there is a mistake near the end. This visualization overlaps the original with the twelve-tone version: https://i.imgur.com/tS7WzRg.png. Note how some of the bars are separated from each other. I'm currently in the process of checking these notes. My original 12ET -> Just Intonation conversion was automatic and I fixed up all the errors I could find, but I could have missed one. EDIT: yes, there was. I fixed it now.
The third doesn't happen in this example, but sometimes composers want to deliberately round, such as in the Circle of Fifths. That would create unpleasant commas. I'm kind of lucky that it didn't happen in the demo I chose. The Circle of Fifths is not actually an issue; first, you can't keep old notes persistent across the whole circle; they will interfere. And second, thanks to Diana Deutsch's experiments on pitch memory, we know that if there are more than 16 notes between the old and new note, you shouldn't be able to discern the comma. However, although the Circle is not a big deal, other rounding intervals can become an issue, like 63/64, where the composer would like the rounding to occur somewhere other than the exact pitch repeat. Listeners are effective at detecting when an exact pitch repeat is slightly inexact, while they have a harder time discerning slightly-off harmonies.
"It's the exact same implementation."
So although Google banned him for breaking the rules on banner placement, he was following Google's own instructions on where to place the banner.
Source: https://old.reddit.com/r/androiddev/comments/13lf6jb/open_so...