Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clearer identification of movements #42

Open
craigsapp opened this issue Nov 14, 2017 · 2 comments
Open

Clearer identification of movements #42

craigsapp opened this issue Nov 14, 2017 · 2 comments

Comments

@craigsapp
Copy link
Member

In the complete example data set:

https://github.com/music-encoding/sample-encodings/tree/master/MEI_3.0/Music/Complete_examples

Mutli-movement works are stored in a single file. However it is difficult to identity where and how many movements the encoding has. Sections are given as a flat list, regardless of whether or not the section is describing a movement or a section of a movement.

In Particular, the Teleman Concerto:

https://github.com/music-encoding/sample-encodings/blob/master/MEI_3.0/Music/Complete_examples/Telemann_Concert.mei

has 5 sections, but apparently 4 movements.

A similar thing happens in the Hummel trumpet concerto.

@pe-ro
Copy link
Contributor

pe-ro commented Jan 6, 2019

@craigsapp, this is due to the uncorrected output from the conversion from MusicXML, since it (MusicXML) has no way of indicating movement boundaries. I'll work on fixing this in the Telemann (already done in the Hummel), but I just wanted to let you know the genesis of the problem.

@pe-ro
Copy link
Contributor

pe-ro commented Jan 6, 2019

Looking more closely at the Telemann, the score is presented without breaks between the "movements" -- Each new movement begins on the same system as the previous one. Each movement (including the 1st) has a tempo indication that includes a number, but there's no system break between movements.

So, there's some "dissonance" (forgive the pun) between the "logic" of a multi-movement work and the visual display as a "sectional" composition. Giving precedence to one or the other creates a burden to encode the other. In its present form (using sections), the encoding doesn't capture the movement structure. But, using <mdiv> elements to emphasize the movements makes it impossible (given the current schema) to capture the visual presentation.

Therefore, I'm inclined to leave the encoding as it is until we can resolve this dichotomy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants