only open referenced parts with openAll from annotationView

[bwbohl]

No description provided.

[bwbohl]

@nikobeer could you please find some edition example that already supports this feature for code comparison?

[bwbohl]

might be connected to #271

[nikobeer]

Will have to look in the RWA- and/or OPERA-Edirom. November +…

[nikobeer]

Ok, found it in a working state with @bwbohl: OPERA vol. 4, all critical remarks that reference source WO. "OpenAll" will trigger a source window for each participant. When this participant is a measure in a part it will first trigger the "Parts Selection" and then navigate to the measure(s) in question.

We also found some commits that should be helpful. More (re)search needed the next days. Maybe start here: OPERA-Editions@d390fc5

[riedde]

Worked on this today. Even if I don't have a solution, I found out that one problem could be the grouping of measures that combines all measures (even if they are in different parts) into one setting (one source window). When I disable the grouping for measures in parts the right number of source windows appears, but no measures are shown inside them. I tried to fix this at getAnnotationOpenAllURI.xql and also at getParts.xql (idea: define a parameter for select/unselect parts). Both wasn't helpful in the end.

[nikobeer]

Discussed this with @riedde reviewing OPERA's solution.

Short: Problem remains with sources with parts, because it only works, when there are no multi measure rest measures involved or better: it could work when every logical measure would be present (by an ID) in every part of a/the source in question. As soon as we lose logical measures because of a multi measure rest, we could get lost in the source.

Long Version:

Edirom addresses measures in sources with parts either by:

1. a virtual measureID build from the parent mdivID + the number label of the measure in question (measure_parentMdivID_measureNo) + sometimes an optional parameter naming the parts that should be take in to account for building and displaying a reduced virtual score ("we came from an edirom concordance and tried configure and to display the source in its source window")
2. a single measureID from whose n- or label-attribute a measure number is retrieved while its part is evaluated by its parent part element ("we came from an edirom annotation participant and tried to display the participant in its own source window").

The problematic way is "2.", because it uses "1." to configure the source window:

1. measureID is retrieved from annot plist
2. measure is searched in source by id
3. measure part is evaluated (measure's parent part)
4. measure's parent mdivID is evaluated
5. measure number is read either from measure/@n or measure/@Label
6. virtual measureID for part sources is build adding the part parameter
7. virtual measureID is send to configure the source window

So far so good…

Now, when measure is within a range of a multi measure rest and we only have one measureID (which in this case represents multiple logical measures, ex. "35–40") we get lost. We have no chance to determine which actual measure number we should use to build step "5." to "7.".

Stop here! Think about a solution…

[riedde]

Something that came on my mind: when we have a multiMeasureRest with a count of 4 then we have one measure that represents 4 measures. For addressing the measure, e.g., in parts material we need the logical structure without loosing the information of the visual realization of the "measure" in the manifestation. What if just using measures and group them as an regularization?

<reg type="multiRest">
   <measure n="1"/>
   <measure n="2"/>
   <measure n="3"/>
   <measure n="4"/>
</reg>

See also the definition of <reg>: https://music-encoding.org/guidelines/dev/elements/reg.html

[riedde]

Ideas from todays meeting: <choice> with <abbr>/<expan> or <orig>/<reg>

• <abbr> or <orig> should be used for the original encoding (e.g. <multiRest>)
• <expan> or <reg> could be used for an other representation like only open referenced parts with openAll from annotationView #273 (comment)

[bwbohl]

<parts>
    <part>
        <section>
            <choice>
                <abbr>
                    <measure>
                        <staff>
                            <layer>
                                <multiRest />
                            </layer>
                        </staff>
                    </measure>
                </abbr>
                <expan>
                    <measure>
                        <staff>
                            <layer>
                                <mRest />
                            </layer>
                        </staff>
                    </measure>
                    <measure>
                        <staff>
                            <layer>
                                <mRest />
                            </layer>
                        </staff>
                    </measure>
                    <measure>
                        <staff>
                            <layer>
                                <mRest />
                            </layer>
                        </staff>
                    </measure>
                </expan>
            </choice>
        </section>
    </part>
</parts>

[bwbohl]

This might actually be connected to #271

[bwbohl]

@riedde & @nikobeer do you see a chance of getting a draft pull request done until November?

[riedde]

@bwbohl I am not sure. Maybe not by me.