Skip to content
This repository has been archived by the owner on Sep 6, 2023. It is now read-only.

Rendering barline types #11

Open
raffazizzi opened this issue Mar 1, 2014 · 4 comments
Open

Rendering barline types #11

raffazizzi opened this issue Mar 1, 2014 · 4 comments

Comments

@raffazizzi
Copy link

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).

@aerhard
Copy link

aerhard commented Mar 2, 2014

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.

@zolaemil
Copy link

zolaemil commented Mar 2, 2014

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.

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 ?

@zolaemil
Copy link

zolaemil commented Mar 2, 2014

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 :)

@aerhard
Copy link

aerhard commented Mar 3, 2014

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.
Making the left VexFlow barline invisible by default fits, in my opinion, the way the attributes are usually meant to be set. In VexFlow, the apperance of the very first line in a staff system can be controlled by parameters of the first measure, but I'm asking myself: Shouldn't this line better be totally independent of the measure's @left in MEI? Is that a bar line at all? The repetition bar lines, at least, don't render at the very left, but right to the clef etc. If it's not a bar line, it should only be controlled by staffGrp. Your proposal to hide the left VexFlow line by default would fit this very well, I think. There would only remain the problem that there will be no lines if there is only a @symbol="brace/bracket". I see two options, maybe others come to your mind: 1) have a line by default, render a line+bracket when the user writes 'bracket' (this could be controlled by a program option), render nothing if there's @symbol="none"; 2) require the user to specify both by writing <staffGrp symbol="brace"><staffGrp symbol="line"></staffGrp></staffGrp>
Nr. 2 would allow for more options (for example, the rendition of a brace without a line), but I don't know if it would be an uncommon way of encoding.

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

No branches or pull requests

3 participants