That all makes sense, so I can see why the facility didn't get merged. And as
I observed, for most text styles, it actually is pretty simple to apply a
custom style after the fact or use the text palette to enter text with a custom
style already applied. Lyrics really are the only case where I see this as a
serious issue.
In the particular use case i am concerned with - wanting voice 1 lyrics above
the staff where they differ from voice 2 - I think the most desirable workflow
would be one in which you could be typing lyrics, hit a button and be flipped
above the staff, then continue typing lyrics and have lyrics continue to be
placed above the staff. This really suggests a somewhat different design than
the more general one you had anyhow, although a more lyric-specific one could
probanly be built on top of yours).
So I wonder if the following wouldn't be usable and less invasive:
1) Change behavior when in edit mode so that as new syllables are created by
space/hyphen/underscore, they inherit the Y offset of the previous syllable.
Exiting lyric edit mode would reset this, so you could easily return to the
usual lyric position by exiting and re-entering lyric edit mode.
2) Add a command while in lyric edit mode to flip the current syllable above
the staff - to a position set in a general style parameter, perhaps. Or even
just to move the current syllable up or down in 1sp increments (much as you can
already do while not in edit mode). This would just apply a Y offset normally
- no text style changes required.
On the surface, this seems simple enough. What I don't know is how it might
mess with layout in terms of the lyric margins, the extra space allocated
between staves, etc.
—
Marc Sabatella
On Thu, Dec 26, 2013 at 4:15 AM, Maurizio M. Gavioli <[email protected]>
wrote:
> Marc Sabatella wrote
>> Sorry to keep harping on this, but I want to ask again if any thought has
>> been given to above/below text settings. I might assume the lack of
>> discussion does mean we've given up on this for now, but since the code
>> *does* already exist, and no one has specifically said it's definitely
>> been decided not to roll it in, I guess I still have hope.
> The main concern which has been raised about this PR is that, once
> implemented, it turned out to be rather invasive (39 files modified);
> whether it was *too* invasive is hard for me to tell, but I remember
> /lasconic/ telling on IRC that it looked rather scaring.
> Another concern I had (as being probably the only one who could test the
> feature rather extensively) is that, once merged, it would be rather hard to
> come back, should we change our mind. As the yOffset parameter (both in
> element data and in style parameters) should be split into new parameters
> yOffsetAbove and yOffsetBelow:
> a) scores saved with the feature enabled would not be readable without it
> AND
> b) even more important, *workspaces* saved with this feature enabled would
> not be readable without it
> a) can probably approached in some way or left on the account of unstable
> version vagaries; but b) would cause the program to crash at startup!
>> I've been exploring the text style facility of late. I am finding that
>> the ability to define and apply custom styles [...] So while I'd still
>> rather have native support, 2.0 does already provide a reasonably usable
>> alternative for many use cases.
>>
>> However, lyrics are still the sore point to me, because one tends to
>> generate so many of them and it's extremely cumbersome to select all the
>> ones you want flipped above the staff, especially if you've already
>> entered the lyrics you want to remain below. Plus the "lyric upper
>> margin" is still applied despite being meaningless for above staff lyrics.
>> So the otherwise reasonably usable alternative of defining custom text
>> styles isn't nearly as good for lyrics as for other text elements. And
>> the use case of wanting a SATB arrangement in closed score with alto &
>> bass lyrics below the staves, soprano and tenor above is pretty common.
>>
>> If there is any way to improve this situation for 2.0, I really think it
>> worthwhile.
> I see at least two possibilities:
> 1) Re-implement the above/below setting for lyrics alone; it should cover
> most of (probably all) the details already discussed: default above or below
> position, default Y offset if above, default Y value if below; for lyrics,
> the code should use the y offset as a distance from bottom of *lyrics* to
> top of *staff* when above and from bottom of *staff* to top of *lyrics* when
> below.
> A possibly cumbersome detail is that, if implemented for lyrics alone, the
> new parameters could not go in the "Text Style" dlg box, as this dlg box
> applies the same parameters to all the textual styles; they should go in the
> "General styles" section.
> 2) Re-evaluate the old branch (still available on-line here
> <http://github.com/mgavioli/MuseScore/compare/Placement_above_below_staff>
> ) and check again if it would be worth implementing, maybe applying the
> concept to less element types than it was originally the case.
> Thanks,
> Maurizio
> --
> View this message in context:
> http://dev-list.musescore.org/Elements-below-and-above-the-staff-tp7577993p7578555.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Mscore-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
