-
Notifications
You must be signed in to change notification settings - Fork 9
Rendering barline types #11
Comments
I also think that it would not be the best practice to use the 'left' attribute whenever 'right' could be used as well. But it seems to me that there are cases where using 'left' is legitimate or even unavoidable. For example, look at one of the examples on the MEI website (MEI 2013): http://music-encoding.org/sampleCollection/encodings/multiple_sectionsI.xml / http://music-encoding.org/sampleCollection/encodings/multiple_sectionsI.pdf; the last measure in system 1 is encoded with right="dbl", the first measure of the second system with left="rptstart". If there is no other / better way of encoding this (it seems very plausible to me), I would maintain rendering support. |
You're right. Would it help if we defaulted to "null", instead of SINGLE in https://github.com/TEI-Music-SIG/MEItoVexFlow/blob/master/src/StaveConnector.js#L41 ? |
I think one could use to avoid using measure/@left, and we should maybe consider supporting this element eventually. I don't see a big problem with giving one side priority over the other one, but I think in your code, it's now visibility overriding non-visibility: since both start bar line and end default to SINGLE, in order to display no bar line, one has to specify @right="invis" and @left="invis" too in the following measure. I think we should default to NONE at one side, and SINGLE on the other side (probably @left -> NONE and @right -> SINGLE). If you consider my previous comment, having both measure/@left and staffGrp/@symbol default to void there will be no connectors at all by default; which is probably fine, but I am now thinking it may make sense to give the user the possibility to control default behaviour... possibly a bit wild idea :) |
I like the idea of giving control to the users by providing additional options (like default margins, annotation font type and size etc.). Just like in many jQuery plugins: the user can choose to pass options in an object, but he doesn't have to, since everything he doesn't declare will revert to hard coded default values. We only have to be careful not to put users up to displacing semantic information from the MEI files to the plugin config. |
aerhard said: "I also added support for different bar line types, based on Raffaele's experimental branch. There are still open questions: Right now, MEItoVexFlow detects them in extract_layers and passes them as function parameters to initialise_staff_n. Do you think this is a good solution or would you prefer to write it to the staff info array instead? I think, using the staff info array could address one issue: The staff lines are currently rendered in an additive manner: When you have 2 measures, the first with no bar line specified, the second with @left="invis", there will be a bar line in the middle, because the default right bar line will be shown; I would expect the measure line to be invisible, because @left="invis" should win over the default line. On the other hand, the usage of @left is not encouraged in the MEI guidelines. It could be OK to postpone addressing this issue. My main reason for handling @left is that i'd like to be able to have no line at all at the beginning of a system. I'm not too content with my solution, maybe you have a better idea. Right now, when you want a staff to have no line on the left, you have to both specify measure/@left="invis" and staffGrp/@symbol="none". Having to do two thing to get one result is not intuitive. The obvious reason for this is that the leftmost line is actually rendered twice: Once as a staff symbol, once as the default bar line of the first measure."
I would avoid dealing with @left='invis'. That attribute is too overloaded. We should look into a better encoding and support that (through our ODD, too).
The text was updated successfully, but these errors were encountered: