-
Notifications
You must be signed in to change notification settings - Fork 35
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
api: support transpose element #115
Comments
That feature has not been added to the
This requires using the 'private' includes, e.g. I will add this feature to |
I will have a go at seeing if I can add it to |
I started looking at this and wrote the following thinking that transposition would be an attribute of a A new struct, e.g. mx/Sourcecode/include/mx/api/PartData.h Line 96 in 03a9b32
An optional instance of that struct added to There's a macro pattern to remember: https://github.com/webern/mx/blob/03a9b3254b853c04fb069cacc79281800215a0d4/Sourcecode/include/mx/api/PartData.h#L169..L210 During 'serialization', functionality has to be added to
During
However, not as simple as thatYour original statement says that transposition exists in the attributes of the first measure. Uh oh, this is more complicated. If Anyway, if we stick with the idea of placing the transposition in the part, such that one can only specify the transposition once, at the beginning, then we could still create the struct and add it to There are precedents for this, anyway it will be these files:
Unfortunately much of the code in TestingIf we go with putting this in |
My only experience of musicxml is as something that can be read and written by musescore (i.e., I am definitely no expert on the intricacies of musicxml!). In musescore, each staff is a part in partwise musicxml and has an associated instrument, e.g., Flute, Clarinet, Trumpet, etc. Part of the details of each instrument includes its transposition. When the score is exported to musicxml, some of the instrument information ends up in the I don't know if there is any other valid use case where there could be a
which makes it sound like it is envisaged to be used as part of the description of the instrument that should be the same for the entire part. In a saner world, maybe But, to counter that view, the description of the The question is, do you want I would argue not to. As it is, Rather than create a new struct The situation seems similar to |
I agree, if someone needs to change transposition later in a piece, then a different feature could be added for that more advanced use-case. The example you provided <transpose>
<diatonic>-1</diatonic>
<chromatic>-2</chromatic>
</transpose> Does seem non-ambiguous, but I'm thinking there are probably some ambiguous cases where the ability to set both |
My problem is I don't know much musical theory and assume all one needs to know about music is that frequency is proportional to 2**(n/12)! The purpose of I gather the So, if we associate
|
I think I've changed my mind. Mostly because of this quote from wikipedia
This makes sense with the way musicxml places |
Yeah that's fine. I think it's disappointing for the user to have to interact with transposition in that way (when the most common use-case is to set it once at the beginning of the piece when setting the instrument), but your approach will work and will support additional use cases. |
I've started working on this. Let me know if you want me to get it done or if you want to collaborate in some way... |
Is there a way to specify a transposing instrument in the mx::api? Maybe its just me but I can't see how to do it.
For example, exporting a musicxml score for a B♭ Clarinet from musescore results in a element in the attributes of the first measure
How do I achieve that in mx::api?
The text was updated successfully, but these errors were encountered: