When tuning down those two strings, would the player need to "relearn" the positions of fingers on the strings when playing? Or would they play at the same positions and ignore the conflict in expected and actual sound?
The linkage between hand position and visual location on the staff is so hard to relearn for someone that only plays one instrument that the music is written so that notes to be played on the B string (the C tuned down) and the F# string (the G tuned down) are written with incorrect pitches.
That is, an actual D# played on the actual B string is written as an E on the staff.
It's weird to learn the Kodaly this way, but the piece is hard enough that, at least in my case, I basically have to memorize it to have a fighting chance. I still haven't performed it for a real concert after 20 years of thinking about doing so.
This also creates some ambiguities, since you can play many notes on either the F# string or the D string. But context is enough to tell what Kodaly meant.
Relatedly, the fifth Bach suite is also written for an alternate tuning ("scordatura"), with the same "wrong note" approach to notation (at least in modern editions). The A string is tuned down to a G, giving you beautifully transformed resonances for the key of C minor.
> This also creates some ambiguities, since you can play many notes on either the F# string or the D string. But context is enough to tell what Kodaly meant.
I found that sticking to the edited score's III/IV markings gets you in the right zone–there's enough other things to figure out haha.
The music is notated as if there had been no detuning so that you can use the natural finger positions. (For example, a note that is notated as a C would actually sound as a B.) The trade-off is that it makes some of the intervals look wrong, but you do get used to it.
Bach's 5th cello suite also uses this technique where the A string is tuned down to a G. (The technical term is "scordatura.")
Interesting! On the guitar when alternate tunings are used, the pitches are written as they sound.
I wonder if maybe the difference is due to the fact that alternate fingerings are very common for guitar (because of having more strings spaced closer together). So notating pitches assuming a specific fingering doesn't make sense.
Plus I don't think the mapping from the staff to muscle memory for guitar is nearly as strong because we have frets.
Do you happen to know how the Braille website's style is called? The high contrast, button shadows with big offsets. I've seen it in several places now and would like to use it myself
Succinct and rigorous. This article has a clear problem statement, explicitly calls out assumptions and expected properties, shows how to express them in TLA+/PlusCal, and even adds a sanity check by refining the mutex model. I wish I had seen this article when writing my BA thesis.
Can you elaborate on how you made the connection between the article and BEAM languages? I suppose you experienced a lot less friction when working with Erlang or similar, care to share your experience?
> He gives some examples of ways that programmers, even after being taught in intro classes not to use magic numbers, still litter their code with constants like 404. But I wish he’d tell Python programmers to stop designing APIs where you write string constants like “r--” and “bs” to denote that your scatterplot should use red dashes and blue squares.
Intriguing. I assume the author would prefer a stronger-typed alternative like explicit parameters and enums. Yet I wonder if having a small DSL-like syntax is actually the better for a scripting language. Most of these plots will be hacked together in a local notebook anyway.
What would be a better alternative to this terse DSL in such case?
This line style API was included MATLAB[0] (and perhaps designed elsewhere earlier) in the Olden Days where terseness was both more necessary (due to space and performance constraints) and more accepted. MATLAB development started in the 60s, though this DSL was likely added in the 80s.
Later, Python's matplotlib library started life as an emulator for MATLAB graphics in Python so naturally included the same plotting DSL.
Only later still did matplotlib morph into the defacto general Python plotting library. And then because plotting is so complex and matplotlib exposes so much control, most subsequent plotting libraries were based on matplotlib, opting to add value via high-level abstractions and better defaults, often exposing the underlying matplotlib objects to allow for fine-tweaking. And so the linestyle API leaks into those libraries too.
All of that to say, this DSL was likely invented by a scientist in a lab in 1981 and has survived through inertia and "jumping hosts" a couple times, rather than careful design.
I think the DSL is bad. And the matplotlib developers may agree, because while you can pass a combo like "ro--", you can also pass these parameters separately and more descriptively like
Is there another library besides matplotlib (and its derivatives) that use this "linespec" format? And doesn't matplotlib's API derive from Matlab?
What's worse, using a terse linespec syntax and being stuck in Matlab-world, or using a terse linespec syntax in Python, and at least possibly being exposed to relatively modern and maintainable software practices?
I suspect that the plot formatting syntax is very old. I remember doing stuff like that with SuperMongo (popular amongst astrophysics ca 2002), which predates e.g. MatPlotLib. It may be as old as computer controlled plotters themselves.
