What's the purpose of clefs array in the beginning of the measures array?
#343
-
|
I'm having a hard time understanding the logic behind such structure. Can clef sign change in the middle of the score? If a clef sign can be only one at the beginning of the part and there can be only one clef sign for a part why it's not under |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 13 replies
-
|
Hello — please see the example document called "Clef changes": That Yes, it is indeed possible for the clef to change in the middle of a score, even in the middle of a measure. Our lives would be much easier if this weren't the case. We haven't yet specified how to encode clefs for multi-stave instruments, such as a piano grand staff. MusicXML does this via the "number" attribute on the clef object, and I imagine MNX will do something similar. (I'm going to convert this to a GitHub discussion thread, since it's more of a question as opposed to a specific to-do.) |
Beta Was this translation helpful? Give feedback.
-
|
I wish there was some kind of |
Beta Was this translation helpful? Give feedback.
-
|
I suspect you would quickly get caught up in the problems of averages and statistics. The most common, by far, is the ability to encode notes. That's not actually the problem. It's that individual scores sometimes require a very specific ability, and while those are the "long tail" of features, they're actually requirements for any given composer / repertoire / genre. I remember being at a conference where we discussed for at least a couple hours whether a slur should end ON the note, or AFTER a note, for a Chopin piece. The performers were adamant that it made a huge difference in how you perform the piece, so the ability to accurately position the ending of a slur was of vital importance to them. Would that feature make the cut? Probably not. 99% of music notation doesn't need that. But if you're doing a Chopin edition (aka "bog-standard romantic piano music") it can be very important. Similarly, I don't actually know of any "pure" music encoding format that would deal with those George Crumb (?) scores. You have to shift to a more graphical format for a dedicated piece of software, like MSCZ, Lilypond, or SCORE, to get the level of visual precision you need for those scores. MEI or MusicXML would both mess up the formatting, particularly if you tried to go from, say, MuseScore to Sibelius. It might be theoretically possible to do it in those formats, but you would have to study them for a very long time, and probably write your own dedicated exporter, to do it. If you want a simple notation format, I would look at **kern. The advantage is that the learning curve isn't quite as steep as MusicXML or MEI. Very simple pieces are very simple to encode, but you can also do some pretty complex things as well. |
Beta Was this translation helpful? Give feedback.
-
|
Bryan Ferneyhough. Second is Quartet -- 3?. First is Mnemosyne perhaps? I don't see a need for a system to absolutely be able to represent everything here but I like the pieces so it would be good to allow them. |
Beta Was this translation helpful? Give feedback.
-
|
I understand your point, but the question here is rather this: does MNX strives to be a guideline on how to encode musical sheets or a music exchange format? The latter suggests that you can export it in one piece of software and import it in another one and it should just work. But from my experience, most software programs were not able to fully read the musicXML file they produced, the imported exported file was different than the native format for any particular program. Not even mentioning trying to import exported file from/to another piece of software. I appreciate you suggesting other formats but they are not exchangeable, because no one is using them apart from the owner. Btw, I tried to export https://verovio.humdrum.org/ as a musicXML file and import it into GuitarPro, the beams were not properly encoded, the instrument played in GuitarPro was 4 guitars instead of piano, also the tempo is different, 100 bpm in guitarPro and a little more in this humdrum thingy. IMO, you can choose only 1: either support everything and it's not exchangeable, or support a subset with high chances it will be exchangeable due to simplicity and ease of enforcement of rules via some kind of schema. |
Beta Was this translation helpful? Give feedback.
-
|
When it comes to music exchange, there are many possible points of failure. If exporting from Software A to Software B in MusicXML, any or all of the following problems might happen:
In my view, MNX is primarily concerned with problem 4. We also think long and hard about how to avoid problems 2, 3, 7 and 8. Of course, we think about all of these problems, but some of them are inherently out of our control. The best we can do is to design a format that's unambiguous whenever possible, with documentation that's as clear as possible. |
Beta Was this translation helpful? Give feedback.
-
You are exactly right. The central issue, though, is whose simplicity are we going to agree on? Your simple requirements, and my simple requirements, and Myke's simple requirements, are not the same. We're going through this exact conversation over on the MEI github where we're trying to work out what constitutes "Basic" encoding. Is the ability to arbitrarily scale a staff a "basic" feature? Some would say so. What about the ability to give the staff lines a specific colour? Or to mark the staff lines visible or not? Or the ability to shift a rest up and down the staff on a given line? It's not like we (the designers of notation encoding formats) set out to purposefully create complex systems where enforcement of the rules is difficult. In fact, I would hazard a guess that the motive behind most new formats is to try and address this exact problem. My take on it is that, fundamentally, music notation is a picture that represents some system of sound making. We think music notation is like text, but it really isn't -- it's what you get when you try and draw sound. So a notation format is a bit like trying to invent a format that will accurately represent a visual phenomenon, and then we impose the requirements that it must represent everything from a Dutch Master to an Impressionist to a Jackson Pollack to a couple scribbles on the back of a napkin, and do that semantically (that is, encode the semantics of the contents of the painting, rather than simply the shapes and colours a la SVG). There is no way that can be done and keep precise fidelity with all. And not impose any mutually exclusive behaviours. **kern is exchangeable. music21 supports it. Verovio supports it. It's an "open" format, insofar that there's no proprietary motive behind it. It may not be exchangeable in the tools you want to use, but there are very significant bodies of encoded notation available in it. Sibelius, Finale, and MuseScore might be the household names, but there's really a lot of stuff happening outside of those tools. |
Beta Was this translation helpful? Give feedback.
Hello — please see the example document called "Clef changes":
https://w3c.github.io/mnx/docs/mnx-reference/examples/clef-changes/
That
"clefs"array is a list of clefs with their rhythmic positions — positioned clef objects.Yes, it is indeed possible for the clef to change in the middle of a score, even in the middle of a measure. Our lives would be much easier if this weren't the case.
We haven't yet specified how to encode clefs for multi-stave instruments, such as a piano grand staff. MusicXML does this via the "number" attribute on the clef object, and I imagine MNX will do something similar.
(I'm going to convert this to a GitHub discussion thread, since it's more of a question as …