[prev in list] [next in list] [prev in thread] [next in thread]
List: lilypond-user
Subject: Re: Multi-measure rests and mark collisions ...
From: Anthonys Lists <antlists () youngman ! org ! uk>
Date: 2016-04-28 12:56:03
Message-ID: 57220863.7030006 () youngman ! org ! uk
[Download RAW message or body]
On 27/04/2016 01:04, Carl Sorensen wrote:
> On 4/26/16 3:56 PM, "Thomas Morley" <thomasmorley65@gmail.com> wrote:
>
>> 2016-04-26 2:21 GMT+02:00 Wols Lists <antlists@youngman.org.uk>:
>>> On 25/04/16 05:31, David Wright wrote:
>>>> (I still don't know what you're trying to accomplish
>>>> [...])
The problem here is the thread has drifted quite a lot. Sorry, David, my
previous email was a bit sarky, for which I apologise, but as I said in
my original email, this is my eternal bugbear, and you touched a nerve
... Incidentally, I didn't notice this earlier, but the house style I'm
copying DOES put the tempo above the tune name ... :-)
>>> Copy "House Style", maybe?
>>> And the whole point of this entire thread has been about
>>> SAVING VERTICAL SPACE - it's just plain butt-ugly for markup to stack
>>> vertically when a slight shift sideways could save lines - plus there's
>>> the high price I put on page turns that could be saved by reclaiming
>>> that wasted space.
>>
>>
>> Anyway, you seem to want multiple texts applied to a the same BarLine.
>> These texts shouldn't be stacked vertically but horizontally, right?
> I think that the desired functionality is to allow markups to be loosely
> tied to notes, so that if possible, they can shift horizontally some
> amount instead of shifting vertically to avoid collisions.
Yup. Because actually, a lot of markup doesn't actually belong to a
*note*. It belongs to a *phrase*. Which leads to the desire that, not
only should markup shift right or left to avoid a collision, it should
be able to push *music* out of the way. For example, I have a bit of
code similar to the following ...
R1 | \mark \default \tempo "Scherzando" R1*8 | \mark \default
At present, the scherzando sits above both rehearsal marks. And if I had
another tempo at the second mark, I'd have colliding tempi which doesn't
make musical sense :-) If only the scherzando could say "I apply to the
next 8 bars. The 9th bar must come after I end".
>
> That is, there could potentially be a shift in both X and Y to avoid
> collisions, and the shift with the least badness is the one that is chosen
> -- perhaps it's one line up in Y and two lines left in X, or something
> similar.
>
> If we had some facility for doing such a movement, then it would be
> relatively straightforward to assign penalties for taking up more vertical
> space, along with penalties for moving horizontally away from the desired
> home point. And we'd choose the layout with the lowest penalty.
>
> But right now, as far as I know, we have no such facility. I believe that
> right now, we horizontally space the music elements to avoid collisions,
> and then we vertically shift the outside-staff grobs to avoid collisions,
> and then we space the skylined staves to achieve the desired spacing. And
> there's nothing in this algorithm that lets us simultaneously vertically
> AND horizontally shift the outside-staff grobs.
>
> Such a feature would be cool to add. But it's not trivial in any sense of
> the word, given the current LilyPond spacing architecture, as I understand
> it.
>
>
That's what I understood, too. Because the outside-staff grobs need to
make the music elements wider if appropriate, and coding that sort of
feedback loop is probably a nightmare! In fact, coding it AT ALL seems
to be a nightmare with the current state of lilypond. You need some way
of allocating a minumum width to a random fragment of music (like above
- I need those 8 bars to take a minumum width, but while the current
part is all rests, another part may be all notes, so I can't even say
"make this rest that wide" because next time round it might not be a rest!
And apologies if I am grumpy about this topic, but as I said earlier in
the thread, it seems that every time I work around one problem, a
different one replaces it - that's why the original post just asked "any
pointers?".
I always used to deal with the multiple markups problem by doing
"s4\markup s2.", except that this time round I noticed the problem with
it breaking up multi-measure-rests. So I (re)found the trick of
"<>\markup", except that moved the markup to the left and exacerbated
the collision problem.
Now I've been given the trick of "\markup " text" " (ie leading
spaces) but that seems temperamental - with pretty much identical code I
have two markups where, in the first instance, the rehearsal mark has
fallen through the blank space to rest on the stave, as required. But
the second instance - near as dammit identical as far as I can see - the
rehearsal mark has only fallen to the horizontal centre line of the
markup, despite there being nothing underneath it preventing it falling
to the stave.
It's just so ******** frustrating :-(
Cheers,
Wol
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic