progress: I have successfully implemented the concept of 'parts' and 'layout' as separate concerns, with default behaviors for each (In other words, if you just have a chunk of , it will be rendered as a \staff within a \score)

It's about to get tricky as I try to figure out where it makes the most sense to specify certain attributes, and reminding myself not to try and get *too* clever; like, if you're doing stuff with key and time signature changes and multiple parts, it's still going to be on you to handle the key/time changes in each part

I've come up with a better name for , but I'm keeping it under wraps until I actually claim the npm namespace, and I'm not ready to publish a package yet.

Currently working on tablature concerns, and figuring out how best to support the concept of "Given this one input document, I want to generate these multiple output documents"

Show thread

It's official: is now called and a very, very early/rough version is available as a Node package; install with

npm install -g nepenthe

or

yarn global add nepenthe

and 💥 you should be able to run the `nepenthe` command from your terminal.

Parts/Layouts are poorly documented because I've realized that declaring layouts in the YAML front-matter doesn't quite cut it; They really want to be document tags, which means back to the handlebars drawing board. But the example in my last post is pretty representative.

Show thread

Inflection point: I want to implement new {{layout}} and {{staff}} tags to replace the current describe-layouts-in-the-frontmatter pattern, and I feel like I should *probably* do a scorched-earth rewrite of all the various under-the-hood handlebars stuff I've already done, because it's already a bit of a mess in that "I was both learning how to speak handlebars *and* making it up as I went" way.

And then as I review the Lilypond docs for \book and \bookpart I'm wondering if I need to rethink my overall approach slightly to be able to support those idioms, which would also mean optionally supporting multiple \header elements, and that feels like it's getting into "is this actually easier/more convenient than pure Lilypond" territory.

Conceptually, I think it makes sense to enforce a "single file = single score" structure; each file can contain:

* Header info (YAML front-matter)
* Parts (the actual Lilypond markup for one or more instruments or voices)
* Layouts (one or more groupings of available parts using different kinds of staves)

...and if/when I get around to implementing \book / \bookpart support, that can be done with additional tags that include individual score files; that way it would also be possible to assemble multiple book files that combine different layouts from each score. (Book of standard notation, book of tab, book with music transposed to Bb, etc)

Show thread

...I took the time to write a document spec *before* I attempt to implement a parser for it and that's good, but it also derailed me because writing specs is not the fun part of hacking on personal projects.

I am starting somewhat from scratch on a new branch using , which is also slow going because it's unfamiliar (and I'm still not super-familiar with node in general) but hopefully the rewrite will go quickly enough once I find a foothold.

Show thread

I really do seem to have a talent for finding my way straight to use cases that libraries really weren't intended for; in this case I'm trying to use with custom helpers to implement my own simple/lightweight document format, and that gets me about 90% of the way there, but the way I'm using custom helpers and partials, I'm realizing there no way to access the root context without explicitly passing it to my under-the-hood helpers and/or partials in the source document.

Which makes sense when considering handlebars from the perspective of a developer tool where you're going to dial in your templates and forget about them... but doesn't make sense when trying to provide a simple document format for myself and others.

I think I've got a workaround though.

Show thread

progress: I think I've got a handle on the rewrite, and now it's a matter of adding support for various tag attributes, etc, and then mundane build/packaging concerns.

This is what a Nepenthe document looks like now. Explicit `score` and `staff` tags make it a bit more verbose than the first iteration, but having worked on some OG last night I think this is still going to be a more pleasurable way of dealing with wrangling chunks of Lilypond into scores.

All of this work is ongoing on the `dev-typescript` branch of the repository at github.com/tinpan-io/nepenthe/ (Very much an unstable WIP at the moment.)

Show thread

I've been nudging forward inch by inch, trying to organize things in a sane fashion and rewrite brute-force code into something a little more flexible (where needed) and better-commented.

Current status: tantalizingly close to having a functional terminal command.

Show thread
Follow

Looked at again this morning g for the first time in a while and was surprised to find it in better shape than I thought. Now immersing myself in typescript matters so I can write some tests, etc.

Sign in to participate in the conversation
Banjotown

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!