On 2014/09/08 23:28:31, dan_faithful.be wrote:
On Sep 8, 2014, at 03:54 , mailto:[email protected] wrote:
> Again: I would strongly suggest that you backpedal and consider the > question "what was my first approach which did not work, for > reasons?". > > And then we see what it would take to address the reasons.
How about placing the voices inside a VoiceGroup context, moving the Accidental_engraver there, and leaving the NullVoice outside, like in
my recent
partcombine experiments?
VoiceGroup would by default consist of nothing, accept any kind of
Voice, and be
accepted by any kind of Staff.
A solution that reorganizes the default voice hierarchy will cause interference with all user code fiddling with hierarchy. At the current point of time, such code has some place for cross-voice placements of items like stems, ties, or slurs. That kind of thing has its place in piano music. So touching the default hierarchy should be a last resort. One can use music functions for juggling with \accepts/\denies in local context modifications and thus change the hierarchy ad-hoc just at the place where an effect is desired. I am not sure I understand your proposal correctly, namely whether you are thinking of changing stuff like the \defaultchild of Staff. If you don't, all VoiceGroup staves would have to be instantiated manually. If you do, many things will change. The former could be used for providing music functions solving a particular problem. But it sounds like a solution that has quite a bit of potential of interfering with other solutions focused around similar problems. It would, of course, at least spare us the hackery in the internals of the grob implementation. But I think we can do better, see <URL:https://code.google.com/p/lilypond/issues/detail?id=4093#c6> https://codereview.appspot.com/117050043/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
