On 21/02/2025 11:10, Valentin Petzel wrote:
Hello all,Hello, Use \balloonGrobText before a note or -\balloonText after a note within chords. Here you use the latter but not within a chord. You could write <c-\balloonText #'(-2 . -2) \markup {\bold "crotchet in original"}>4 Or \balloonGrobText #'NoteHead #'(-2 . -2) \markup {\bold "crotchet in original"} c4 Kind regards, XavierI would argue that this is nevertheless a bug. Essentially no pure Lilypond input should produce cryptic error messages like this. The reason for this problem is that the ballon engraver expects the corresponding evens to have a `symbol` property, used for filtering the acknowledged grobs it should apply to. This is why `\balloonGrobText` works because this one requires you to set the symbol property by an argument. Now, \balloonText does not do this. But articulations in chords do behave quite differently to articulations outside. Articulations outside (both single notes and chords) are reported by the music iterators and are thus seen by the engravers. Articulations of note events within chords are not reported, and they need to be handled by the engravers themselves. This is by the the reason why fingerings outside of chords are handled by the Fingering_engraver, and thus cannot use all of the alignment options, while fingerings in chords are handled by the New_fingering_engraver. Now, the engraver for the balloon Texts assumes that it is used within a chord, and then the grob it applies to is clear, as the event needs to be extracted from the grob in the first place. But if it is outside of a chord things look different. But this means that the engraver handles this grob the normal way, and when trying to evaluate `ly_symbol2string (get_property (ev, "symbol"))` this fails, as that property is not set. Now, solution for this could be: * Check if event property `symbol` is an actual symbol, else issue a reasonable warning * Set a reasonable value for symbol (e.g. as the post-event will only really be useful to note and chord events set the default to NoteColumn) Of course the first point will be reasonable in any case. That being said, I don’t really like the implementation of this engraver. It essentially has to check every grob if it has articulations, for each articulation check if it is a `annotate-output-event`, and then compare the grob to all `annotate-output-event`s that the engraver has listened to. Cheers, Valentin Cheers, Valentin
I quite agree that the implementation is clunky and the usage awkward. My problem however, was just to understand the docs, and I hope that Xavier's recent PR improves that.
How to change the underlying code I shall leave to the experts.
