Sebastian Menge <s.me...@gmx.de> writes: > I am not an expert in lilypond, but as a language it does not have the > proper semantics/structures to do that - it is not XML or Json or so. Other > Notation programs have internal data structures that make it easy to > implement that. > > So the editor has to overcome it. And the editor then needs hints, e.g. > line numbers or bar checks. > > I think there simply is no solution possible for this. > > Regards, Sebastian.
If by "no solution possible" you mean one that would automatically insert the desired bars given any valid lilypond input, I agree that would be difficult. But it's easy enough for a user to impose a more rigid structure on their own input files---which is what I and I think many people do---and then it's easy enough to parse, at least at the rather course level we're talking about here. -David > David Zelinsky <d...@dedekind.net> schrieb am Sa., 28. Sept. 2024, 18:24: > >> David Bellows <davebell...@gmail.com> writes: >> >> > This is a question that came up on Reddit the other day and I didn't >> > have an answer (it never happens to me). >> > >> > Say you are working on a score with multiple parts (like an orchestra) >> > and you need to insert some measures into all the parts somewhere in >> > the middle of the piece. Is there a way to organize things to minimize >> > the hassle? Having to go to each file for each part and insert the >> > measures would be a huge pain especially when compared to how >> > relatively easy this is for other notation programs (so I'm told). And >> > if you have to do this more than once then it's especially cumbersome. >> > >> > I know with some editors you can search and replace multiple files at >> > once but this feels like it would mess up any internal organization >> > with respect to bar numbers in the LilyPond file (in the comments). >> > >> > I understand that many people only use LilyPond for engraving so this >> > isn't a problem for them, but there are those of us who compose >> > directly in LilyPond and this could be a potential issue. >> > >> > I guess I'm wondering if there is a way of writing your LilyPond files >> > in such a way to make this easier than just manually going through >> > each part and changing them. >> >> As others have said, this is much easier if you write your parts with >> one bar per line, and also label them in some stereotypical way. (I use >> emacs, and I've modified lilypond mode to add a newline with a bar check >> and a commented bar number label when I type Control-Return.) Then it >> would be easy enough to make one file with the list of bars to be >> inserted for each instrument labeled with the filename for that >> instrument, and write a script to automatically insert them all. >> >> If I had to do this once, rather than fuss with writing and debugging a >> script I would probably do it manually in emacs, recording a keyboard >> macro while I do the first instrument, and then doing each of the rest >> by calling that macro with a single key stroke. >> >> As for messing up the bar numbering, this is a standard problem in >> musical theater, where bars are often added or removed during rehearsals >> or previews, and the standard solution is to label bars inserted after, >> say, bar 17 as 17a, 17b, etc. If you want the bars numbered accordingly >> in the output, I guess you could define a barNumberFormatter for this >> purpose. (I've never done that, so I'm not sure if that's the right >> solution. Maybe someone can suggest the right way. There is >> Score.alternativeNumberingStyle that can be set to >> #'numbers-with-letters, but that only applies to volta alternatives.) >> Then set Score.currentBarNumber to what it had been after the inserted >> passage. >> >> Alternatively, it would be easy to write a script that modifies all the >> commented bar numbers in a file (or section thereof) to make them >> consecutive. (My modified emacs lilypond mode has a function that does >> this.) >> >> Really, rather than being a drawback (as someone suggested), I feel it >> is a great advantage that Lilypond's plain text format allows one to use >> very general text processing tools. >> >> >> -- >> David Zelinsky >> >>