[Question] Full measure 'info' and system break with every new <mDiv>?

[aerhard]

Converter.js contains the (Boolean) pendingSectionBreak object property; when it's true, full 'info' (key and clef signatures, meter) is added to the first measure of a new system, see https://github.com/TEI-Music-SIG/MEItoVexFlow/blob/master/src/Converter.js#L473-L478. This property is initially true and gets set to false every time full info is added to the first measure in a system. As a result, the first system in an MEI file has full info, all following systems don't. My question is: How should setting pendingSectionBreak true be triggered from the MEI code? Despite the name, I don't think <section> is suitable to do this automatically, as an MEI section doesn't necessarily indicate the change of a musical section in the sense of a musical movement. <mDiv> might be suitable; I think in many cases you would expect a new mDiv to start in a new system an have the full 'info'. To be on the safe side, you could trigger an mei2vf section break with every new mDiv by default, but add a general config option to turn this behavior on/off.

[aerhard]

From #52:

Yeah I changed it because it seems to be more consistent with out current approach to section in general. That is, section is the container of everything we render. I think this question therefore relates to the more general question of how to treat multiple sections and mdivs; you touch on this in #43

Ah, I see -- meilib.js as well as Converter.js don't refer to mDiv, but search directly for the section element. It looks to me that there would be some advantages in starting with mDiv; this should be easy to implement in Converter.js -- but would it cause problems in meilib.js or MeiView / would you prefer to skip mDiv for now / generally?

[zolaemil]

How would you render a multiple mdivs? Is there any VexFlow-related logic in there? If not, maybe Converter shouldn't deal with it. I'm just wondering myself.

[aerhard]

I was thinking of cases where you have parts of distinct musical pieces or movements on a single canvas, like at http://music-encoding.org/documentation/samples in the Vivaldi "Example of encoding multiple mdivs II". I have to admit I haven't been aware of the fact that rendering multiple mDivs implies dealing with multiple score elements. Do you think it would be better (instead of letting Converter.js handle multiple scores) to use a pre-processing step (address the converter separately for each mDiv/score, but render everything to the same canvas) should this feature be required? While there might not be too much difference with plain scores, the second option might be better suited to deal with multiple pieces each with its own set of variants. From my perspective, this could be something to concentrate on later. Regarding mdiv/section: Do you think it's plausible to associate the processing steps triggered by pendingSectionBreak with mDivs like in the Vivaldi example? Combined with option 2, this could mean there wouldn't be any changes necessary to the code.

[zolaemil]

I think at some point we will have to face scalability, especially in terms of canvas size. I have the suspicion that rendering several movements of a piece on a single canvas at one go will not be a real world scenario. Of course, a smaller fragment could still include the transition between movements, in which case an integrated mdiv handling could be a better solution... Or a middle layer that sits between our MeiDoc and the Converter.