On 6/14/19, 9:35 AM, "Florian" <florian.grun...@gmx.de> wrote:
Hi again,
Carl Sorensen-3 wrote
> I believe that this is less a bug in musicxml2ly and more a limitation of
> musicxm2ly. MusicXML and Lilypond have fundamentally different concepts
> of the structure of music. These differences lead to inability to exactly
> render the MusicXML in LilyPond for complicated structures.
Hmm - I'm not so deep into MusicXML and Lilypond - I would really appreciate
it if you could elaborate a bit more on that? It is always good to
understand the limitations :)
I don't know enough to do so.
Carl Sorensen-3 wrote
> In this case, the note of musicXML is correctly rendered -- that is, the
> note is put in the correct voice and the correct staff. However, the
> musicXML structure is different from the LilyPond structure, so there is
> not a one-to-one correspondence.
I see - since MusicXML does not have a kind of grouping per voice or staff
like Lilypond-> just a simple list of pitches (which can be assigned to any
voice and staff) it might be not so easy to (automatically) decide what to
do in musicxml2ly: like adding an { s1*2 } to keep the context alive or
adding some more \change Staff="2" or whatever…
But still - if this kind of limitation is known, does it mean that
musicxml2ly can’t provide a sane default if there’s any?
I can contribute a fix if there’s such a default and somebody explains it to
me…
I don't think it is as simple as having a sane default. I think it will mean
changing the way musicxml2ly makes its fundamental score layout. To solve this
particular problem as a special case we would need to somehow track which
contexts are missing content and then add spacer rests. This would require
parsing the whole lilypond music tree, I think, and is not really a simple
problem.
On the other hand, one could put a generic fix in place by finding the length
of the music (still not a trivial problem, I think) and then automatically
putting a spacer part of the same length in parallel with each of the staff
contexts (or maybe with each of the voice contexts instead). This would create
unnecessary elements in the .ly score, but would solve the problem.
IMO, the best solution is just to hand manipulate the .ly score to make it a
good score. But I wouldn't be opposed to you developing a solution to solve
the problem and avoid the hand manipulation.
Thanks,
Carl
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
