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

[David Wright]

On Thu 28 Apr 2016 at 13:56:03 (+0100), Anthonys Lists wrote:
> 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
> ... :-)

Very odd. The attached shows what I would want.

The dynamic is closest because it applies directly to me as the
singer. The tempo comes next; it applies indirectly to me. I need
warning of a change, but watching the conductor would be sufficient
instead. In this particular case, the swing directive is also vital.
The tune's information is given furthest away because it's not needed
in performance. It could equally well be summarised on a contents page.
Not shown here is some legal bumf at the foot of each page where a new
tune happens to start (song copyright, arrangement copyright, rights
administration and licencing).

> >>>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 ...

Perhaps the so-called spanners might help you here. You can even have
dashed lines to show the extent of their significance. They're really
set up for cresc etc, but can be customised.

> 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.

Have you tried spreading the music to take up more room? I'm not going
to bother to come up with an example as you usually just find
something else to criticise about it. Searching on the term
"newSpacingSection" should give you the idea. It changes the natural
spacing of the notes so that the stretching effect becomes unnoticeable.

> >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.

There's an implied ordering of outside-staff objects which is detailed
under "Vertical collision avoidance". The rules look quite complex.
Have you read and understood them? Once again, you complain about what
LP does but present no code yourself. (I'm not posting any more
examples in this thread.)

I've had problems in this area which I've eventually (had) solved, and
I keep pointers to my code so I can find and copy it easily.

> It's just so ******** frustrating :-(

Cheers,
David.

mark.png
Description: PNG image