Re: Multi-measure rests and mark collisions ...

[Anthonys Lists]

On 27/04/2016 01:04, Carl Sorensen wrote:
> On 4/26/16 3:56 PM, "Thomas Morley" <address@hidden> wrote:
>
> > 2016-04-26 2:21 GMT+02:00 Wols Lists <address@hidden>:
> > > 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