A MusicXml parser outputing separate streams of data for each tone generator

[bjkrug]

I’ve been working on my own MusicXml parser (https://github.com/bkrug/envelope-demo#readme). As stated in the Readme the parser supports:

• Storing a separate stream of data for each tone generator
• Repeats and volta brackets
• compressing rests to save space
• storing notes as 7-bit values instead of 10-bit values

 

An accompanying cartridge program plays the output, and also demonstrates

• adding envelopes to music
• auto-detection of a 60hz vs 50hz environment
• playing music at different tempos as specified in a song header

 

I'm not the first person to create a MusicXml parser for TI-99 development, but I think existing parsers are geared towards sound lists. The reason I prefer to have a separate stream of data for each generator, is because that way I can support, for example, a half note played simultaneously with two consecutive quarter notes.

 

My parser is shared as source code, because while another developer could use the compiled parser as is, it's also likely that one would want to add features I didn’t add. For example, the parser doesn't currently support dynamics. The existing repo has high test coverage, so you should be able to add functionality without breaking something you didn’t mean to.

MusicEffects.rpk musiceffectsC.bin MusicXmlParser.exe

Edited April 15, 2023 by bjkrug

[sometimes99er]

5 hours ago, bjkrug said:

I'm not the first person to create a MusicXml parser for TI-99 development, but I think existing parsers are geared towards sound lists. The reason I prefer to have a separate stream of data for each generator, is because that way I can support, for example, a half note played simultaneously with two consecutive quarter notes.

I think sound lists allow for that too (a half note played simultaneously with two consecutive quarter notes). 🙂
 

[bjkrug]

If the two quarter notes are the same tone, and there is no pause between notes, then the quarter notes blur together as a half note. In the above cartridge program, listen to "Turkey in Straw", and hear how different it sounds between envelopes A & B. Envelope A has no pause between notes, but envelope B does have pauses.

[SteveB]

Funny .. I picked up my MuseScore/4a code some weeks ago and started working on creating a XB256 soundlist. 

 

I am also thinking of implementing some kind of decay, as you are right, two subsequent quarters get "merged" to a half note at the moment ... Would sound better to have some attack and decay for sure, 

 

How do you deal with high <divisions> values in some MIDI files? This drove me mad at first ...

[bjkrug]

On the one hand, the files I've tested with so far haven't had a division higher than 24. So it's possible that the current code just isn't handling high division values well. That being said, after reading your comment, I wrote a unit test in which the divisions value is 120, and it passed.
 

Keep in mind that for the output assembly language file, a quarter note is always represented with a value of 24. If the <divisions> tag specifies 24,000, the parser (in C#) will divide quarter-note-durations by 1,000 using the below code. The variable lengthOfQuarter holds the value found in the <divisions> tag. This comes from NoteToGeneratorGrouper.GetNotesForOneToneGenerator().

Duration = (Duration)((double)Duration.N4 / lengthOfQuarter * duration)

 

One issue that could come up in the future is notes longer than a double whole note. The assembly language output represents durations as bytes. Since 24 represents a quarter note, we can represent a double whole note as 192. I haven't written anything to deal with non-rests that are longer than that. A bug would probably result from a song with a triple whole note or a set of tied notes of such a length.

 

Another problem is that I now see that the MusicXml format allows different musical-parts to have their own <divisions> tag. If we find a MusicXml file where different parts have different divisions values, then the current parser will incorrectly apply the first divisions value to all of the parts.