Quantcast

Some thoughts on linked staves

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Some thoughts on linked staves

Maurizio M. Gavioli
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, 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).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some thoughts on linked staves

Marc Sabatella
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 <[hidden email]> 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 &lt;=&gt; 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Loading...