The thing that led me to stop contributing was ultimately seeing the progress that was being made toward automated music transcription. I saw this technology as something that would make the process a whole lot faster once it was good enough, and so it wasn't a wise time investment to keep writing out those intricate files by hand, but it also wasn't yet the right time for me to start using that transcription software, either.

At the time, the software that caught my attention was mainly the kind that helps users turn a scan of sheet music into something that could be transformed (with a text editor and some scripts) into a LilyPond source file with far less work than actually typing out all of the LilyPond input yourself.

I can envision software that does this, but it seems like a big project with very uncertain adoption outcomes.

Edit: I think software like this probably already exists, essentially, and definitely if you consider running one of the LilyPond command line conversion tools an acceptable step. The system's main differentiators would be being web-based (which isn't that uncommon anymore for music engraving software), and targeting LilyPond as the best-supported output.

Short of a genuinely complicated ML system which having been fed a bunch of (say) Jazz Pianists midi data for chord patterns etc, I think you could probably do it with some kind of weighted (let's say by the user) Markov chain/state machine with some kind of graph for which chord voicing should be used relative to those around it: e.g. "This Dm7 has a F in it, the next chord is a Cmaj7#11 so move the F up a semitone[Within the same octave]"

The above system should be able to come up with coherent movement of voicings (and fingers...) although I can't imagien that it would sound very human.

This sounds like a really interesting problem. What kind of transformation is taking place during compilation, datatype wise, like are you rendering audio serverside?

I wonder for a classroom setting, if many people compile similar scores, if there's any opportunity to say "the first half of all these scores are the same, compile it once and concatenate it with the unique pieces"...caching composition...I'm sure I'll play with it someday.

If you have considered using a queue, what were your reasoning to prefer lambdas?

To parse LilyPond you would first need to write a Scheme interpreter. Once you finally get a tree for the sheet music, rendering in a way that is correct, beautiful, and easy to read is no small task either. Sheet music rendering is full of so much nuance [1], and it's really hard to get it right. It took brilliant people many years to get LilyPond to the state it's in today. I picked LilyPond because it's powerful and beautiful. Don't get me wrong, VexFlow and abcjs are impressive projects, but LilyPond has a head start.

I think one day, you'll be able to use emscripten or similar to run LilyPond in the browser. We are not there yet.

[1] See, for example, https://www.amazon.com/Behind-Bars-Definitive-Guide-Notation...

Very neat indeed! Similar tools have done a lot to make TeX more accessible, so it makes sense that this also benefits lilypond.

I've started work on a project of my own that will do online rendering of lilypond (rather different design objectives from yours, though). I've been worrying a bit about resource consumption of frequent renders, and your application is occupying a rather extreme point there. Do you have any data about this already?

That's super motivating, thanks for taking the time to comment!