Re: MusicXML 3.1 - ready for release?

Thank you, I now understand your problem. I can only speak to the software
which I developed. In that software, MusicXML import converts the file into
the internal representation used by the software. Any information that is
not supported by that software is ignored. MusicXML export then takes
whatever information is stored in the internal representation and converted
to MusicXML. You are correct in that your missing data is lost during the
import process. I believe other notation software also works this way.

I do not believe it is part of the MusicXML standard to specify that a
MusicXML client must maintain an internal state that would preserve the
imported MusicXML. MusicXML is (primarily) a transport mechanism; it allows
files to be exchanged between different pieces of software. MusicXML does
not specify whether a MusicXML client uses MusicXML beyond import/export.

I don't know how Finale handles time-only in verses, but you may want to
file a bug/feature request with them to address the issue. I personally do
not believe that this is a limitation of MusicXML, but rather a limitation
of the MusicXML clients.

On Thu, Aug 31, 2017 at 4:05 PM, mogens@lundholm.org <mogens@lundholm.org>
wrote:

> About notation programs preserving the MusicXML code (Answer to Jeremy
> Sawruk's question):
>
> I did Test-1.xml that has a note D, lowered a little bit:
>
>       <note default-x="159">
>         <pitch>
>           <step>D</step>
>           <alter>-0.23</alter>
>           <octave>4</octave>
>         </pitch>
>         <duration>1</duration>
>         <voice>1</voice>
>         <type>eighth</type>
>         <accidental>flat-1</accidental>
>         <stem default-y="-3">up</stem>
>         <beam number="1">continue</beam>
>       </note>
> I imported Test-1.xml into Finale and saved it as Test-2.xml. Now the
> alter-value disappeared and the accidental changed to "natural". I also
> imported Test-1.xml to MuseScore and saved this as Test-3.xml. And both
> alter- and accidental-definition disappear.
> But I am not only thinking of single elements - also the whole structure
> is changed. If you compare Test-2.xml and
> Test-3 (Finale and Musescore) you see a lot of differences. Even when you
> save from MusesScore some formatting
> is lost (again and again).
> The reason is of cause that notation programs have their own formats and
> internal structure. And this internal structure is not linked to the
> MusicXML code.
>
> Hope this explains what I mean.
>
> For my part, I want to add lyric text,  that appears like writers use to
> write it: A repeated text (e.g. a refrain that is the same
> in all verses) is only written once. To the text I therefore add the
> "time-only" attribute e.g. with a value "1, 2, 3, 4" - for all verses.
> But I use a notation program to write the music score. I can add this
> manually into the MusicXML-file, but if it disappears after every change
> done with the notation program?
>
> Still the saved files are MusicXML. I just hope that notation programs in
> the future will provide means to write the lyrics using "time-only".
>
> PS: I could be wrong with these two examples - but the general problem
> exists.
>
>
> On 2017-08-31 20:18, Jeremy Sawruk wrote:
>
> I'm sorry, but I personally am not clear on what MusicXML data is not
> being preserved. Could you please provide an example file?
>
> On Thu, Aug 31, 2017 at 2:02 PM, mogens@lundholm.org <mogens@lundholm.org>
> wrote:
>
>> I am sorry but I just didn't reach what I wanted to do with the testing
>> of MusicXML 3.1. But I am working on it.
>>
>> Using Finale to make new MusicXML-3.1-files seems to bring a common
>> problem up again: Finale (and all other programs) does not preserve the
>> MusicXML-data. In my case it concerns the time-only attribute for lyrics.
>>
>> To claim that notation programs should preserve MusicXML is not realistic
>> and maybe not even desirably. But this means that some the improvements in
>> 3.1 may never be implemented.
>>
>> My job now is to identify changes, that affects playing. Among these I
>> shall identify those, that can be implemented in MIDI. But I do not believe
>> this may cause new issues.
>>
>> I think that MusicXML 3.1 could be finalised, but hope there will come a
>> MusicXML version 3.1.1 - if issues appear. It should not end up like MIDI -
>> where they forgot a clef-definition and now, thirty years later, there is
>> still no clef-definition. (as stated in the book "Beyond MIDI")
>>
>> So go ahead with 3.1.
>>
>> Regards
>> Mogens
>>
>> PS: I am not using code generation from the XSD yet. Look forward to have
>> "fun" with grace-cue-notes.
>>
>> On 23 Aug 2017, at 16:11, Michael Good <mgood@makemusic.com> wrote:
>>
>>
>
>