Generate names procedurally

[BridgeTheMasterBuilder]

Hi, I apologize if this is an ignorant question as I know nothing of Ekmelily and my knowledge of Lilypond scripting is very basic, but isn't it possible to generate the names on demand? You mentioned that 17-limit is the max due to slow parsing of the tuning file, presumably due to a combinatorical explosion in the possible names, but isn't it possible to instead write some Scheme that will take a string representing the interval name, decompose it and then map it to a code point?

[levinericzimmermann]

Hi @BridgeTheMasterBuilder ,

thanks for your message and sorry for the delay!

isn't it possible to generate the names on demand?

Yes I fully understand your point. It would be much more elegant if the names could be ad-hoc generated instead of being explicitly declared in 40k lines of a configuration file. Also we could indeed support all prime number exponent combinations that can be represented with the HEJI-Notation with a functional approach. The reason why it is like this is mostly due to the API of Ekmelily. Maybe this API could be changed, but I'm not sure if it's possible to program in Lilypond an ad-hoc parser of pitch names. If I understand ekmel-main.ily correctly (by looking at it for 2 minutes and not studying it in depth), ekm:set-notation (what seems to set the pitch names in Lilypond) is explicitly called only once at program start. Nevertheless I know too little of Lilypond to understand if this is a limitation within Lilypond or in Ekmelily.

Anyway, nowadays if I would create it again, I would perhaps rather define a Lilypond markup function, which would receive the respective prime-number combination as an argument, similarly how it is done here. Perhaps I wouldn't define functions for each accidental, but a general function that receives an argument, so that we would write something like:

\new Voice {
    c4
    e2 \heji #'(5 . 1)
}

But this would most likely only change the visual rendering of the pitch, while the Ekmelily-based approach also makes the MIDI rendering microtonal (at least I couldn't find a Lilypond function which sets an ad-hoc pitch bend to support microtonal MIDI renderings with the music functions approach). Personally I don't use MIDI rendering of Lilypond anyway, why I wouldn't mind this limitation. But because, also personally, the current implementation of Ekme-heji works fine for my work, I don't have a strong reason to distribute my time on re-working this tool. As the ad-hoc approach most likely wouldn't be solvable based on Ekmelily, the re-written version would indeed no longer be ekme-heji.ily, but maybe more general lilypond-heji, therefore this issue can be closed on this specific repo.

Best, Levin

[BridgeTheMasterBuilder]

@levinericzimmermann

Hi Levin, thanks very much for your response.

I closed this issue after taking a closer look at this project and Ekmelily and reaching the conclusion that what I was asking about was essentially incompatible with the way it was designed. I appreciate you taking the time to write a detailed response though.

Perhaps I wouldn't define functions for each accidental, but a general function that receives an argument, so that we would write something like: [...]

This seems like a reasonable interface!

But because, also personally, the current implementation of Ekme-heji works fine for my work, I don't have a strong reason to distribute my time on re-working this tool.

Understandable. To be honest, 17-limit is enough for me personally too, but, I want to use Lilypond to procedurally generate charts which go up to 31-limit so I'm looking for something that can help me do that, without luck so far. The repository you linked (which I wasn't aware of, thanks!) seems to go only up to 23 according to the manual (OTOH, it has definitions for up to 47-limit in markup-functions.ily so maybe not, I'll try it out).

Maybe if I find the time I will experiment with a modular markup-based solution but it's a bit daunting to have to dive into the Lilypond architecture.

EDIT: Actually, the repo you linked will probably work just fine for my use case! I can just build on top of what the author has done here and make a nicer interface, so I won't need to go down any rabbit holes. Thanks again for sharing that.

[levinericzimmermann]

Hey @BridgeTheMasterBuilder,

thanks for your feedback and you are welcome!

I'm glad to hear abjad-ext-microtones works for you and you can build your own version starting from this! Good luck with creating your tool.

Best, Levin