[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [musicxml2ly] unwanted staves and voices [was: missing <voice>-eleme
From: |
pls |
Subject: |
Re: [musicxml2ly] unwanted staves and voices [was: missing <voice>-element in chorded note leads to unwanted additional staff] |
Date: |
Sun, 30 Sep 2012 17:04:08 +0200 |
My test files obviously got lost. :(
Am 29.09.2012 um 14:24 schrieb pls:
> Sorry, this is killing me. :(
> Am 29.09.2012 um 13:19 schrieb pls:
>
>>
>> Am 28.09.2012 um 12:09 schrieb pls:
>>
>>> A <note>-element containing a <chord/>- and a <staff>-element but no
>>> <voice>-element causes an additional empty staff above the defined one.
>>>
>>> Tiny example:
>>> <missing_voice-element_in_a_chorded_note_leads_to_empty_second_staff.xml>
>>>
>>> (unwanted) result:
>>> <missing_voice-element_in_a_chorded_note_leads_to_empty_second_staff.png>
>>>
>>> The wrong MusicXML-markup was caused by Sibelius 7.0.0.
>>>
>>> In this case musicxml2ly puts the chorded note without a <voice>-element in
>>> an own voice (PartPOneVoiceNone) instead of placing the notes in a chord
>>> construct (< a' c''>1) in the same voice. She also surrounds the \context
>>> Staff block by an additional \new Staff block which causes the additional
>>> staff.
>>
>>>
>>> musicxml2ly should be taught to be tolerant and automatically assign notes
>>> containing <chord/>-elements to the voice of the first note of the chord.
>>> (This first note does not contain a <chord/>-element.)
>>
>>
>> Hm, the above obviously seems to tell only half the story: Without a
>> <staff>-element the .xml-file does NOT cause an additional empty staff above
>> the normal one even though two voices are exported and the \context Staff
>> block is surrounded by a \new Staff block. So this means that I have to
>> correct myself. There are two issues involved here:
>>
>> 1) if an .xml file contains only <staff> elements with value "1" (i.e.
>> <staff>1</staff>) musicxml2ly erroneously thinks that there are several
>> staves.
>
> This bug is even more complicated and it seems to interact with the issue
> described below:
>
> if an .xml file contains only <staff> elements with value "1" (i.e.
> <staff>1</staff>) AND no <voice> element in a chorded note musicxml2ly
> erroneously thinks that there are several staves. (I haven't tested what
> happens when there are several <staff> elements with different values in an
> .xml fle.
>
> Test file:
https://www.dropbox.com/s/l9mt7iqd38lqqng/unwanted_staves.xml
>> The result is:
>
>>
>> \new Staff <<
>> \context Staff ="1" <<
>> \context Voice = "PartPOneVoiceOne" { \voiceOne
>> \PartPOneVoiceOne }
>> \context Voice = "PartPOneVoiceNone" { \voiceTwo
>> \PartPOneVoiceNone }
>>>>
>>>>
>>
>> This leads to a second unwanted empty staff.
>>
>> Without any <staff> element in the .xml file the result is:
>>
>> \new Staff <<
>> \context Staff <<
>> \context Voice = "PartPOneVoiceOne" { \voiceOne
>> \PartPOneVoiceOne }
>> \context Voice = "PartPOneVoiceNone" { \voiceTwo
>> \PartPOneVoiceNone }
>>>>
>>>>
>>
>> and there is NO unwanted additional staff!
>>
>> In this case musicxml2ly should be taught to ignore the element value if
>> there is only one staff.
>>
>> 2) if a <note> element contains a <chord/> element but no <voice> element
>> musicxml2ly puts the chorded note without a <voice>-element in an own voice
>> (PartPOneVoiceNone) instead of placing the notes in a chord construct (< a'
>> c''>1) in the same voice.
>>
>> In this case musicxml2ly should be taught to be tolerant and automatically
>> assign notes containing <chord/>-elements to the voice of the first note of
>> the chord. (In MusicXML the first note of a chord does not contain a
>> <chord/>-element.)
> Test file:
https://www.dropbox.com/s/8bep4ly69xfwfmt/unwanted_voices.xml
>
>
>>
>> hth
>> patrick
>>
>>
>> _______________________________________________
>> bug-lilypond mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> _______________________________________________
> bug-lilypond mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-lilypond