Debian unstable user here (and also Gentoo on a different PC) - I've removed PulseAudio for a couple of months now, and everything works nicely (including a Bluetooth headset and HDMI audio out) with PipeWire and WirePlumber - the only hiccup was an old manual configuration I had for ALSA to use PulseAudio as default audio sink, which needed to be removed.
According to Wikipedia, "first century AD is the most probable guess" for the stele's age. By that time, pronunciation was probably nearer to the modern language than to Ancient Greek, although, of course, not exactly the same: https://en.wikipedia.org/wiki/Koine_Greek_phonology#Popular_...
Even Modern Greek, despite the homogenization effect of modern communications, still has local dialects which sound very different from one another and aren't easily intelligible to speakers of the standard dialect.
The shift in pronunciation wasn’t a simple and straightforward process. If you’re trying to argue that the reconstruction is faulty on the basis that the shift was >50% complete, I’d respond that nothing like that level of precision is possible. Moreover, I’d expect funerary songs to be a bit conservative in their pronunciation.
I was a heavy It's All Text! user, too, and fortunately, an alternative exists, implemented just as you describe. See: https://github.com/jlebon/textern
Not the OP, but LilyPond is a TeX-like music editor. Sibelius is a WYSIWYG editor. One might expect the author of TeX to prefer a similar approach to typesetting music. Like the OP, though, I don't find it surprising. Writing in your native language is relatively easy. Writing music is a lot harder, especially for an amateur (like me). Using the most intuitive software available is probably a good idea.
LilyPond is a pain to write in by hand. When looking at the text, it's difficult to see the cleffs side-by-side. I think most people who use LilyPond use one of the GUI editors.
LilyPond text format is best seen as an open file-format in ascii, primarily for machine consumption, not human.
That's not my experience. I did quite a bit of engraving using LilyPond as part of my music publishing company (a catalog of around 100 organ, choral, and/or instrumental works, many of them quite complex). I always entered the notation by hand, using the Frescobaldi editor to give easier previewing and various shortcuts.
I'm an organist myself, and entering music that way became extremely fluid—to the point that I felt like I was "playing" the music as I typed. For complex three-stave music, I got up to a pace of a couple of pages per hour. Polyphonic music with well-written voice-leading (i.e. independent voices, rather than big chunks of notes) was especially pleasant to engrave in this way.
I’m not remotely proficient in music engraving, but I found it pretty straight forward to type a few pages of music into Lilypond format a few years ago, just using a regular plain text editor.
Comparable to writing (La)TeX for mathematics I’d say.
I don't have any samples handy, but here are some pointers:
1. Before starting, number the measures on the original score. I write the number every fifth measure.
2. Before engraving any actual notes, I'll make a voice that is entirely "skips", plus time signatures, key changes, barlines, etc. I include this voice on each stave.
3. I always try to deconstruct the piece into individual voices. Of course, this is straightforward for many pieces (choral and instrumental especially), but every piece with good voice-leading can be broken up like this. My music theory background (I was a Music & Comp-Sci double-major in college), along with my experience as a chorister and organist, helps me a lot with this.
4. Engrave one voice at a time. For some pieces, this means that I'm engraving half of a stave's notes (or less) in each pass.
5. In most cases, I put a single measure on each line. I make sure to use bar-checks whenever possible (once in a while they won't work, if I'm doing something weird that confuses LilyPond). Every fifth measure, I add a comment with the measure number (to match up with the numbers I've written on the physical score).
6. I use LilyPond's various built-in checks (bar number checks, octave checks...) liberally. They're very similar to unit tests, in that they allow for much easier "refactoring" down the line.
7. The right environment helps a lot. When I was doing tons of engraving, I had a document holder with a movable marker to help me keep my place. I rotated one of my monitors to portrait to show a full page; I'd keep the markup on the other monitor, and had a keyboard shortcut set up to easily run LilyPond as needed. I'd often run it after making just a change or too.
8. LilyPond's layout engine is astonishingly good, but I'd still have to make tweaks to the final output in some cases. I had a macro set up so that I could do a quick /moveGrob to tweak the extra-offset property of a grob to move it without changing the behavior of the layout engine.
Well, it looks like a nice book and you can read it online or download it (there's a link at the top). The "Brainfilling" title is probably a pun to make the title more interesting.
Maybe a bit off-topic, but the Grand Comics Database (http://www.comics.org) is an fan non-profit effort to index all comic books worldwide. We don't have an API, although we'd like to - it's mostly that we have no clear requirements yet, and since all data is available as a DB dump under CC-BY, there's not much push for one.
The project is now in its 20th year and this shows in that the database schema isn't as canonicalized as could be (for example, creator credits and character fields are just text fields and not DB references. Yet slowly but surely improvements are being made, faster in the last couple of years.
We could use some help if anybody is interested - our code is GPL (https://github.com/GrandComicsDatabase/gcd-django) and since the dev team is limited and everything happens on our free time, all kinds of help are appreciated.
I haven't tested Jack compatibility yet.