I understand the need. But whatever would happen, I would love if it would
happen after 2.0.
lasconic
2013/12/26 Marc Sabatella <[email protected]>
> 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
>
>
------------------------------------------------------------------------------
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
