Good points! I recall there are places where we do try to differentiate in this way, checking to see if a linked element is in the same score as the original before deciding what to do with it, but I am not sure it's really the same type of case you are describing. One reason I haven't tried to tackle the unlinking idea yet is that the semantics of how things work are pretty complex and delicate.
Maybe a way to better reprsent the sort of thing you are talking about is to have some sort of property describing the nature of the link between two staves - whether they should be the "full" link we expected for linked parts or the "partial" link we expect for linked staves. Not sure how that would actually work. On Tue, Sep 29, 2015 at 4:26 AM Maurizio M. Gavioli <miwa...@miwarre.org> wrote: > It occurred to me that some of the complexities we are regularly facing > with > linked staves may stem from the fact that the current concept of staff > linking gathers together two rather different types of links: > > 1) The *score part <=> separate part* link: the basic idea here is > that the two staves are the same representation of the same music and then > the separate part is a rather exact copy of the part as it appears in the > score and the majority of the details should be linked, with the possible > exception of the 'outermost' features having to do, for instance, with page > layout (scaling, line breaks, and so on). > > 2) The link between *two different staves in the same score*: the basic > idea > here is that the two staves are two different representations of the same > music and then, in principle, the majority of the details -- above the > 'innermost' ones, like note pitches -- should *not* (could not? might not?) > be linked. By far the most common case of this kind of link is the link > between staves of different types, and it is not possible to take for > granted that any or most aspects of one representation can be transferred > to > the other. > > An example occurred to me, while working on this PR > <https://github.com/musescore/MuseScore/pull/2235> , having to do with > beaming in historic tablatures. Beam mode is currently a linked feature and > in case 1) above (score part & separate part) this makes perfect sense; but > in case 2) above (two different staves linked together) it does not (or not > necessarily): beaming practices might be different in the two > representations (in fact they *are* different) and the beaming setting for > one might be inappropriate for the other. > > I have no ready-made answer or solution, not even a clear idea of all the > sides of the matters involved and I assume the border lines defining the > 'innermost' or 'outermost' features evoked above will anyway be a matter of > compromise. But I suspect this concept of staff linking deserves some more > thought and/or re-evaluation. > > Thanks, > > Maurizio > > Note: the idea floating around since a while of allowing linking / > unlinking > of individual elements would affect this point only marginally. To expand > on > the example given above about beaming, unlinking the beam mode of a single > chord (assuming this would ever be possible) would not be particularly > useful, as the point is that, by default, beaming mode should be linked for > all chords in case 1) but unlinked for all chords in case 2). > > > > -- > View this message in context: > http://dev-list.musescore.org/Some-thoughts-on-linked-staves-tp7579522.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mscore-developer mailing list > Mscore-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mscore-developer >
------------------------------------------------------------------------------
_______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
