Yes, of course it is :). But I think there are reasonable cases to do so. The issue here is of course stability: If we wanted to issue some code which is supposed to remain functional for years to come, this is ill suited, as it does not solely rely on the interface Lilypond provides. So if you were to extend Lilypond this way someone would need to maintain this against the current version of Lilypond.
But I think doing so is a very effective way of creating a proof of concept how internals could be handled differently. Because it is quite simple to create a Lilypond file that adapts some internals and tell people to try this rather than forking the codebase, adapting the scheme files and telling people to build Lilypond from that source. I think in this case the naming of midi files is something that might be something Lilypond should be able to handle (because naming the output files is not an unreasonable thing, and putting midi scores in singular books just to get this done seems like it is handled in the wrong place), and this code demonstrates how this could be done. And the abilty to quickly try out different such options is in my option very useful. Cheers, Valentin Am Freitag, 30. Juni 2023, 22:16:01 CEST schrieb Jean Abou Samra: > Le mardi 27 juin 2023 à 21:17 +0200, Valentin Petzel a écrit : > > Hello Knute, > > > > so you are using books to allow specification of the midi filename. This > > is > > probably a fine usecase, but it still seems like a bit of an abuse of the > > book mechanic to me. Rather I’d adapt the midi output name logic itself. > > > > This code adapts the internal function responsible for writing out the > > midi > > performances (scm/midi.scm:write-performances-midis) in such a way that > > #(set-current-module (resolve-module '(lily))) is true lock picking :-) I > mean, sometimes you really can't avoid monkeypatching internals, but I'd > reserve it for desperate cases.
signature.asc
Description: This is a digitally signed message part.
