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

[David Wright]

On Tue 26 Apr 2016 at 01:21:00 (+0100), Wols Lists wrote:
> On 25/04/16 05:31, David Wright wrote:
> > But I see you've now acknowledged (indirectly) that LP can set
> > multiple marks at the same point after stating that it can't.
> > Are there other things that LP can be persuaded to do itself that you
> > have closed your mind to?
> > 
> Except I *haven't* closed my mind. That's you putting words into my
> mouth.

The exact words were "The problem really is, all I want to do is stick
multiple marks on a barline (which doesn't work, lily doesn't do
multiple \mark's :-(," on Sat, 23 Apr 2016 11:25:05 +0100.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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"  wrote:
> >
> >>2016-04-26 2:21 GMT+02:00 Wols Lists :
> >>>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!
> 

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"  wrote:


2016-04-26 2:21 GMT+02:00 Wols Lists :

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

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

[Carl Sorensen]

On 4/26/16 3:56 PM, "Thomas Morley"  wrote:

>2016-04-26 2:21 GMT+02:00 Wols Lists :
>> On 25/04/16 05:31, David Wright wrote:
>>> (I still don't know what you're trying to accomplish
>>> [...])
>>>
>> 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.

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.

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Thomas Morley]

2016-04-26 2:21 GMT+02:00 Wols Lists :
> On 25/04/16 05:31, David Wright wrote:
>> (I still don't know what you're trying to accomplish
>> [...])
>>
> 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.

Pretty late to the party.

Though, I've to agree with David W.
At least for several mails with lines over lines of text it was _not_
clear to me what you want and I'm not sure I understand now.
As a non-native speaker I always think it may be due to language issues.
Though, the amount of code-lines is remarkable low in the whole thread...
And sometimes images indeed help, even if put together with some
graphic-program.

Anyway, you seem to want multiple texts applied to a the same BarLine.
These texts shouldn't be stacked vertically but horizontally, right?

In LSR and elsewhere some methods for multiple RehearsalMarks are
known, stacking vertically.

Should be possible to adapt it.

How should this texts be aligned over the BarLine?
More general, how should it look?

Maybe you told already, then I missed it.


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Wols Lists]

On 25/04/16 05:31, David Wright wrote:
> On Sun 24 Apr 2016 at 19:18:01 (+0100), Anthonys Lists wrote:
>> On 24/04/2016 03:13, David Wright wrote:

>>
>> Ah - does that mean the rehearsal mark would happily overwrite the
>> blank space at the start of the other markup string?
> 
> Typically, yes.

Ah good ...
> 
>> But as for "why would I want to do that" - to serve as an example
>> maybe. Let's change it then. Get rid of the tempo. The title would
>> still collide with the rehearsal mark, and it would still take three
>> lines - I wouldn't save a line. But shift the title a couple of mill
>> to the right, and it would drop down and save us a line. SAVING
>> VERTICAL SPACE is the point.
>>>

>>
>> Most people? Most people probably give up and go back to Sibelius,
>> or Finale, or whatever. My day job was programming, and I haven't
>> managed to get to grips with Scheme (it was FORTRAN/C, so Scheme is
>> a bit of a culture shock :-) because time to concentrate and learn
>> is a luxury :-(
> 
> Fair enough. I was making the point that LP sometimes looks like a
> programming language but isn't actually one.
> 
> But it never ceases to amaze me how, if you post a reasonably
> well-defined problem here, someone often posts a scheme solution.
> But you have to factorise your problem into chunks that people
> will feel inclined to tackle.

Well, I would like to tackle them myself. But, as I said, time to
concentrate is a luxury (I'm a carer, and dealing with someone with
memory problems can be very difficult :-(
> 
>>> Why not push the rehearsal mark left if you want loads of text to the right?
>>> I don't get the bit about notes in a MMR. Isn't that a contradiction?
>>
>> Not really. My modus operandi is
>>
>> voiceStaff = ...
>> voiceInstrument1 = ...
>> voiceInstrument2 = ...
>>
>> \score {
>>   <<
>> voiceStaff
>> voiceInstrument1
>>   >>
>> }
>> \score {
>>   <<
>> voiceStaff
>> voiceInstrument2
>>   >>
>> }
>>
>> The problem is that the contents of voiceInstrumentx has a *major*
>> influence on the way the contents of voiceStaff is displayed :-(
>> Instrument1 may have an MMR, Instrument2 may have notes, they affect
>> the bar spacing in different ways, and I may get markup collisions
>> in one part, and no collisions in the other. Basically, lily is
>> setting the notes, and then fitting the markup over the notes. There
>> are occasions when you want to set the markup and then fit the notes
>> under it.
> 
> Without wishing to imply that I could code it, that's why you might
> have fragments of markup suitable for notes, and others for MMRs,
> and then select between them to assemble each part.

In other words, put loads of \tags or instrument-specific stuff in
voiceStaff, which is supposed to be instrument-independent :-(
> 
> Why would you "go back to" Sibelius? Would that automate this?
> Even if you had to assemble the fragments manually for each part,
> that would be simpler, I'd have thought. You may or may not end up
> with a part like one of mine:
> texttenorsA = \lyricmode {
>   \Tteetuka \Tteetuka \Tteetuka \Tteetuka \Tteetuka \Tteetuka \Tteetuka 
> \Tteetuka
>   \barNumberCheck #17
>   \Tteetuka \Tteetuka \Ttravi \Ttravs \Ttravs \Ttravr \Ttravs \Ttravs
>   \Ttravz
>   \barNumberCheck #27
>   \Tzumpaka \Tzumpaka \Tzumpaka \Tzumpaka \Tzumpaka \Tzumpaka \Tzumpaka 
> \Tzumpaka \Tzumpakaz
>   Oo __ _ _
>   \barNumberCheck #35
>   \Tvumtb \Ttravs
> }
> where I'm selecting from a menu of lyrics fragments.
> 
?

And let's say the piece is SSAATTBB, could you combine that single
lyrics part with two different tenor melody parts, to give two different
part-sheets? Because THAT is the problem I would like to solve.

>>>
>>>
>> And you've given me a wonderful example of what I want :-) Let's say
>> a new tune starts at B, so I put a tune name there. You can't play
>> two tunes at once, can you? But you've got two tune names stacked
>> one above the other ... (Yes I know you can play two tunes at once,
>> but it's not normal :-) And you could get stacking tempi the same
>> way...
> 
> If the names of the tunes are so important (which is pretty
> unusual for a part), then why not place them underneath (like "halt!"
> in my example) so they don't interfere with the tempos.

Because I don't give a monkeys about interfering with tempi? Because I
*DO* give a massive monkeys about wasting vertical space, and moving the
tune-name underneath gains me nothing?

> If the names of the tunes are long, you're already going to have to
> deal with how they mesh with your linebreaks (which is tricky
> because you usually don't know where the latter will fall).
> 
> You could shrink the names of the tunes. You could print them in a
> heap at the foot of the page. You could leave them out of the parts,
> as is conventional. You could decide on your priorities.
> 
>> At the end of the day, the basic problem is that lily, by default,
>> stacks markup upwards. There is no way to tell it that markup should
>> 

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

[David Wright]

On Sun 24 Apr 2016 at 19:18:01 (+0100), Anthonys Lists wrote:
> On 24/04/2016 03:13, David Wright wrote:
> >On Sat 23 Apr 2016 at 11:25:05 (+0100), Wols Lists wrote:
> >>On 22/04/16 19:36, David Wright wrote:
> >>>On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:
> On 22/04/2016 14:31, Kieren MacMillan wrote:
> >David K wrote:
> >>>Hm?  How could you even have a compressed multi-measure rest when there
> >>>is anything like an "8-bar phrase" in parallel?
> >>>That sounds like a problem that cannot occur.
> >I assume Wol (like me) has the problem where the compressed rest happens 
> >in the part, not in the full score — but one wants not to have to use 
> >multiple \tag constructs just to handle this issue.
> Exactly... I write my music with "voiceStaff" to contain all the
> score-level stuff eg tempi, tune names, rehearsal marks etc, and
> "voiceInstrument" to contain the stuff that varies by instrument, eg
> notes, dynamics, anything else like that ...
> 
> In the case example, the phrase is eight bars long, commencing with
> a two-bar rest. For another instrument, it won't have a rest. And I
> don't want the output to change dramatically depending on what's in
> the part.
> 
> So of course, because voiceStaff is not meant to contain notes, it
> uses "s" all the time. And I very rarely produce scores, this case
> is absolutely typical for me in that we only have a bass-clef part,
> and because while some players in our section can read both, we have
> some players who can only read bass or treble clef so transposing is
> a regular requirement. So I'll have three parts to do, 1st, 2nd and
> bass.
> >>>I haven't followed all that. Is this the sort of thing you want?
> >>>
> >>Pretty much. In your example it's exactly okay - the "poco allegretto"
> >>is to the right of the rehearsal mark, so the four marks take three
> >>lines to display. (Note I tend to use box-barnumber, so my rehearsal
> >>marks can get quite wide :-)
> >>
> >>Now, imagine the "poco allegretto" and "This is the army mr jones" were
> >>the other way round - the "This" would collide with the rehearsal mark,
> >>and it would take four lines.
> >I'm not quite sure why you'd do that. The tempo is part of the
> >music. The tune titles that you want to include are not. But you can
> >add spaces to the beginnings of strings to avoid collisions.
> 
> Ah - does that mean the rehearsal mark would happily overwrite the
> blank space at the start of the other markup string?

Typically, yes.

> But as for "why would I want to do that" - to serve as an example
> maybe. Let's change it then. Get rid of the tempo. The title would
> still collide with the rehearsal mark, and it would still take three
> lines - I wouldn't save a line. But shift the title a couple of mill
> to the right, and it would drop down and save us a line. SAVING
> VERTICAL SPACE is the point.
> >
> >>I want some semi-automatic way so I can push the other markup to the
> >>right of the rehearsal mark and make sure I only use three lines. Oh -
> >>and if I use "extra-spacing-width" (which iirc works fine with
> >>multi-measure-rests), as soon as I have another part which actually has
> >>some notes in the first bar of the MMR, that first bar will be the same
> >>width as the markup so that then looks awful :-(
> >A lot in there. Your OP didn't have automation specified. Most people
> >drop into scheme for that, don't they?
> 
> Most people? Most people probably give up and go back to Sibelius,
> or Finale, or whatever. My day job was programming, and I haven't
> managed to get to grips with Scheme (it was FORTRAN/C, so Scheme is
> a bit of a culture shock :-) because time to concentrate and learn
> is a luxury :-(

Fair enough. I was making the point that LP sometimes looks like a
programming language but isn't actually one.

But it never ceases to amaze me how, if you post a reasonably
well-defined problem here, someone often posts a scheme solution.
But you have to factorise your problem into chunks that people
will feel inclined to tackle.

> >Why not push the rehearsal mark left if you want loads of text to the right?
> >I don't get the bit about notes in a MMR. Isn't that a contradiction?
> 
> Not really. My modus operandi is
> 
> voiceStaff = ...
> voiceInstrument1 = ...
> voiceInstrument2 = ...
> 
> \score {
>   <<
> voiceStaff
> voiceInstrument1
>   >>
> }
> \score {
>   <<
> voiceStaff
> voiceInstrument2
>   >>
> }
> 
> The problem is that the contents of voiceInstrumentx has a *major*
> influence on the way the contents of voiceStaff is displayed :-(
> Instrument1 may have an MMR, Instrument2 may have notes, they affect
> the bar spacing in different ways, and I may get markup collisions
> in one part, and no collisions in the other. Basically, lily is
> setting the notes, and then fitting the markup over the notes. There
> are occasions when you 

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

[Anthonys Lists]

On 24/04/2016 03:13, David Wright wrote:

On Sat 23 Apr 2016 at 11:25:05 (+0100), Wols Lists wrote:

On 22/04/16 19:36, David Wright wrote:

On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:

On 22/04/2016 14:31, Kieren MacMillan wrote:

David K wrote:

Hm?  How could you even have a compressed multi-measure rest when there
is anything like an "8-bar phrase" in parallel?
That sounds like a problem that cannot occur.

I assume Wol (like me) has the problem where the compressed rest happens in the 
part, not in the full score — but one wants not to have to use multiple \tag 
constructs just to handle this issue.

Exactly... I write my music with "voiceStaff" to contain all the
score-level stuff eg tempi, tune names, rehearsal marks etc, and
"voiceInstrument" to contain the stuff that varies by instrument, eg
notes, dynamics, anything else like that ...

In the case example, the phrase is eight bars long, commencing with
a two-bar rest. For another instrument, it won't have a rest. And I
don't want the output to change dramatically depending on what's in
the part.

So of course, because voiceStaff is not meant to contain notes, it
uses "s" all the time. And I very rarely produce scores, this case
is absolutely typical for me in that we only have a bass-clef part,
and because while some players in our section can read both, we have
some players who can only read bass or treble clef so transposing is
a regular requirement. So I'll have three parts to do, 1st, 2nd and
bass.

I haven't followed all that. Is this the sort of thing you want?


Pretty much. In your example it's exactly okay - the "poco allegretto"
is to the right of the rehearsal mark, so the four marks take three
lines to display. (Note I tend to use box-barnumber, so my rehearsal
marks can get quite wide :-)

Now, imagine the "poco allegretto" and "This is the army mr jones" were
the other way round - the "This" would collide with the rehearsal mark,
and it would take four lines.

I'm not quite sure why you'd do that. The tempo is part of the
music. The tune titles that you want to include are not. But you can
add spaces to the beginnings of strings to avoid collisions.


Ah - does that mean the rehearsal mark would happily overwrite the blank 
space at the start of the other markup string?


But as for "why would I want to do that" - to serve as an example maybe. 
Let's change it then. Get rid of the tempo. The title would still 
collide with the rehearsal mark, and it would still take three lines - I 
wouldn't save a line. But shift the title a couple of mill to the right, 
and it would drop down and save us a line. SAVING VERTICAL SPACE is the 
point.



I want some semi-automatic way so I can push the other markup to the
right of the rehearsal mark and make sure I only use three lines. Oh -
and if I use "extra-spacing-width" (which iirc works fine with
multi-measure-rests), as soon as I have another part which actually has
some notes in the first bar of the MMR, that first bar will be the same
width as the markup so that then looks awful :-(

A lot in there. Your OP didn't have automation specified. Most people
drop into scheme for that, don't they?


Most people? Most people probably give up and go back to Sibelius, or 
Finale, or whatever. My day job was programming, and I haven't managed 
to get to grips with Scheme (it was FORTRAN/C, so Scheme is a bit of a 
culture shock :-) because time to concentrate and learn is a luxury :-(



Why not push the rehearsal mark left if you want loads of text to the right?
I don't get the bit about notes in a MMR. Isn't that a contradiction?


Not really. My modus operandi is

voiceStaff = ...
voiceInstrument1 = ...
voiceInstrument2 = ...

\score {
  <<
voiceStaff
voiceInstrument1
  >>
}
\score {
  <<
voiceStaff
voiceInstrument2
  >>
}

The problem is that the contents of voiceInstrumentx has a *major* 
influence on the way the contents of voiceStaff is displayed :-( 
Instrument1 may have an MMR, Instrument2 may have notes, they affect the 
bar spacing in different ways, and I may get markup collisions in one 
part, and no collisions in the other. Basically, lily is setting the 
notes, and then fitting the markup over the notes. There are occasions 
when you want to set the markup and then fit the notes under it.





The problem really is, all I want to do is stick multiple marks on a
barline (which doesn't work, lily doesn't do multiple \mark's :-(, and I
want to be able to move those markups to the right so they don't collide
with the rehearsal mark. \tempo *partly* solves my problem.

Well, that's a relief. BTW you can have multiple marks. My example had
one \tempo and the rest were marks.


The trouble
is, all the tweaks I've come up with (like for example "s1 s1*11") all
have side effects that don't matter in certain cases, and matter
enormously in others.

I haven't yet seen an example of what you want, not anything that
you've produced in the dim and distant past that 

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

[David Wright]

On Sat 23 Apr 2016 at 11:25:05 (+0100), Wols Lists wrote:
> On 22/04/16 19:36, David Wright wrote:
> > On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:
> >> On 22/04/2016 14:31, Kieren MacMillan wrote:
> >>> David K wrote:
> > Hm?  How could you even have a compressed multi-measure rest when there
> > is anything like an "8-bar phrase" in parallel?
> > That sounds like a problem that cannot occur.
> >>> I assume Wol (like me) has the problem where the compressed rest happens 
> >>> in the part, not in the full score — but one wants not to have to use 
> >>> multiple \tag constructs just to handle this issue.
> >> Exactly... I write my music with "voiceStaff" to contain all the
> >> score-level stuff eg tempi, tune names, rehearsal marks etc, and
> >> "voiceInstrument" to contain the stuff that varies by instrument, eg
> >> notes, dynamics, anything else like that ...
> >>
> >> In the case example, the phrase is eight bars long, commencing with
> >> a two-bar rest. For another instrument, it won't have a rest. And I
> >> don't want the output to change dramatically depending on what's in
> >> the part.
> >>
> >> So of course, because voiceStaff is not meant to contain notes, it
> >> uses "s" all the time. And I very rarely produce scores, this case
> >> is absolutely typical for me in that we only have a bass-clef part,
> >> and because while some players in our section can read both, we have
> >> some players who can only read bass or treble clef so transposing is
> >> a regular requirement. So I'll have three parts to do, 1st, 2nd and
> >> bass.
> > 
> > I haven't followed all that. Is this the sort of thing you want?
> > 
> Pretty much. In your example it's exactly okay - the "poco allegretto"
> is to the right of the rehearsal mark, so the four marks take three
> lines to display. (Note I tend to use box-barnumber, so my rehearsal
> marks can get quite wide :-)
> 
> Now, imagine the "poco allegretto" and "This is the army mr jones" were
> the other way round - the "This" would collide with the rehearsal mark,
> and it would take four lines.

I'm not quite sure why you'd do that. The tempo is part of the
music. The tune titles that you want to include are not. But you can
add spaces to the beginnings of strings to avoid collisions.

> I want some semi-automatic way so I can push the other markup to the
> right of the rehearsal mark and make sure I only use three lines. Oh -
> and if I use "extra-spacing-width" (which iirc works fine with
> multi-measure-rests), as soon as I have another part which actually has
> some notes in the first bar of the MMR, that first bar will be the same
> width as the markup so that then looks awful :-(

A lot in there. Your OP didn't have automation specified. Most people
drop into scheme for that, don't they?
Why not push the rehearsal mark left if you want loads of text to the right?
I don't get the bit about notes in a MMR. Isn't that a contradiction?

> The problem really is, all I want to do is stick multiple marks on a
> barline (which doesn't work, lily doesn't do multiple \mark's :-(, and I
> want to be able to move those markups to the right so they don't collide
> with the rehearsal mark. \tempo *partly* solves my problem.

Well, that's a relief. BTW you can have multiple marks. My example had
one \tempo and the rest were marks.

> The trouble
> is, all the tweaks I've come up with (like for example "s1 s1*11") all
> have side effects that don't matter in certain cases, and matter
> enormously in others.

I haven't yet seen an example of what you want, not anything that
you've produced in the dim and distant past that you barely remember.

> As Kieren said, this stuff is generic across all parts, so he and I want
> to store it in a generic variable that then gets merged with the notes.
> But there doesn't appear to be a syntax that isn't crucially dependent
> on the notes being merged, other than filling the generic variable with
> a whole bunch of special-case formatting tags, which totally misses the
> point of having a generic variable :-( (plus I haven't used tags yet,
> another learning curve ...)

Again, isn't that why people use scheme. Then you can see if a given
moment has a note or not, and choose your markup appropriately.
LP never looks very automatic to me. It doesn't even have an "if"
construction to make a decision.

Anyway, I made mr jones into a nonsensical "\tempo". The rehearsal
letter now appears above it of course. I stuck a note in before the
MMR for some reason though nothing is anchored to it; everything but
mr jones is a \mark. I'm just doodling—not sure why I bothered.

Cheers,
David.


markswap.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Anthonys Lists]

On 23/04/2016 12:23, Kieren MacMillan wrote:

Hi Wol,


if I use "extra-spacing-width" (which iirc works fine with
multi-measure-rests), as soon as I have another part which actually has
some notes in the first bar of the MMR, that first bar will be the same
width as the markup so that then looks awful

\textLengthOff

?

Hope this helps,
Kieren.


BRILLIANT (but not the way you intended :-)

As far as I can tell, \textLengthOff is the default, but I looked it up 
in the manual, and found out how to attach a markup to a zero-length 
note! Just attach it to an empty chord!


So instead of doing "s4\markup s2. s1*7", I can simply do "<>\markup 
s1*8", and that stops my multi-measure-rests mucking up. (I think I'd 
found that before ages ago, but forgotten it ...)


I'll need to play a bit more, but that's another niggle fixed ... :-)

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Kieren MacMillan]

Hi Wol,

> if I use "extra-spacing-width" (which iirc works fine with
> multi-measure-rests), as soon as I have another part which actually has
> some notes in the first bar of the MMR, that first bar will be the same
> width as the markup so that then looks awful

\textLengthOff

?

Hope this helps,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Multi-measure rests and mark collisions

[Wols Lists]

On 23/04/16 01:52, Kieren MacMillan wrote:
> Hi David,
> 
>> It strikes me as conceptually problematic to try to put a fermata on a 
>> multi-measure rest.
>> Who does this, and what does it mean, musically?
>> In this example, you are actually placing a fermata on a single bar of rest.
>> In which case, this works fine:
>> { \compressFullBarRests f1->\fermata R1*3 r1\fermata }
> 
> Except r1\fermata and R1\fermataMarkup look and behave differently.
> And the difference gets even more obvious when you have a measure not in 4/4.
> =)
> 
And my mind is still stuck in the old days when neither of those worked,
but

\bar "||" \fermata

did :-) I think a load of my old code still has \markup #script.ufermata
or whatever it was all over the place trying to get them above notes ...

Cheers,
Wol


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Wols Lists]

On 22/04/16 19:36, David Wright wrote:
> On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:
>> On 22/04/2016 14:31, Kieren MacMillan wrote:
>>> David K wrote:
> Hm?  How could you even have a compressed multi-measure rest when there
> is anything like an "8-bar phrase" in parallel?
> That sounds like a problem that cannot occur.
>>> I assume Wol (like me) has the problem where the compressed rest happens in 
>>> the part, not in the full score — but one wants not to have to use multiple 
>>> \tag constructs just to handle this issue.
>> Exactly... I write my music with "voiceStaff" to contain all the
>> score-level stuff eg tempi, tune names, rehearsal marks etc, and
>> "voiceInstrument" to contain the stuff that varies by instrument, eg
>> notes, dynamics, anything else like that ...
>>
>> In the case example, the phrase is eight bars long, commencing with
>> a two-bar rest. For another instrument, it won't have a rest. And I
>> don't want the output to change dramatically depending on what's in
>> the part.
>>
>> So of course, because voiceStaff is not meant to contain notes, it
>> uses "s" all the time. And I very rarely produce scores, this case
>> is absolutely typical for me in that we only have a bass-clef part,
>> and because while some players in our section can read both, we have
>> some players who can only read bass or treble clef so transposing is
>> a regular requirement. So I'll have three parts to do, 1st, 2nd and
>> bass.
> 
> I haven't followed all that. Is this the sort of thing you want?
> 
Pretty much. In your example it's exactly okay - the "poco allegretto"
is to the right of the rehearsal mark, so the four marks take three
lines to display. (Note I tend to use box-barnumber, so my rehearsal
marks can get quite wide :-)

Now, imagine the "poco allegretto" and "This is the army mr jones" were
the other way round - the "This" would collide with the rehearsal mark,
and it would take four lines.

I want some semi-automatic way so I can push the other markup to the
right of the rehearsal mark and make sure I only use three lines. Oh -
and if I use "extra-spacing-width" (which iirc works fine with
multi-measure-rests), as soon as I have another part which actually has
some notes in the first bar of the MMR, that first bar will be the same
width as the markup so that then looks awful :-(

The problem really is, all I want to do is stick multiple marks on a
barline (which doesn't work, lily doesn't do multiple \mark's :-(, and I
want to be able to move those markups to the right so they don't collide
with the rehearsal mark. \tempo *partly* solves my problem. The trouble
is, all the tweaks I've come up with (like for example "s1 s1*11") all
have side effects that don't matter in certain cases, and matter
enormously in others.

As Kieren said, this stuff is generic across all parts, so he and I want
to store it in a generic variable that then gets merged with the notes.
But there doesn't appear to be a syntax that isn't crucially dependent
on the notes being merged, other than filling the generic variable with
a whole bunch of special-case formatting tags, which totally misses the
point of having a generic variable :-( (plus I haven't used tags yet,
another learning curve ...)

Cheers,
Wol


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Multi-measure rests and mark collisions

[Simon Albrecht]

On 23.04.2016 02:06, Flaming Hakama by Elaine wrote:
It strikes me as conceptually problematic to try to put a fermata on a 
multi-measure rest.

Who does this, and what does it mean, musically?


You must be kidding. While calling R1 a MultiMeasureRest may be slightly 
confusing in LilyPond terminology, honestly it’s not so difficult to 
grasp. And of course it’s totally standard notation to use R, not r, for 
full-bar rests.


Regards, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Multi-measure rests and mark collisions

[Kieren MacMillan]

Hi David,

> It strikes me as conceptually problematic to try to put a fermata on a 
> multi-measure rest.
> Who does this, and what does it mean, musically?
> In this example, you are actually placing a fermata on a single bar of rest.
> In which case, this works fine:
> { \compressFullBarRests f1->\fermata R1*3 r1\fermata }

Except r1\fermata and R1\fermataMarkup look and behave differently.
And the difference gets even more obvious when you have a measure not in 4/4.
=)

Hope that helps!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Multi-measure rests and mark collisions

[Flaming Hakama by Elaine]

> Try the following ...
>
> f1->\fermata R1*3 R1\fermata
>
> The first fermata prints fine. The second fermata prints
> "programming error: Object is not a markup." in the log and doesn't
> print.


It strikes me as conceptually problematic to try to put a fermata on a
multi-measure rest.
Who does this, and what does it mean, musically?

In this example, you are actually placing a fermata on a single bar of rest.
In which case, this works fine:

{ \compressFullBarRests f1->\fermata R1*3 r1\fermata }


As such, \fermataMarkup seems like a solution in search of a problem.

Unless I'm missing the reason why you would consider a single bar of rest
to be multiple bars of rest.


I think I must be missing more of the subtlety of this issue.

Since it hasn't been mentioned yet in this thread, you can also place text
at the start of a multi-measure rest using the empty chord structure:

{ \compressFullBarRests f1->\fermata R1*3 <>^\markup{ "hold me" } R1 }




David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Wright]

On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:
> On 22/04/2016 14:31, Kieren MacMillan wrote:
> >David K wrote:
> >>>Hm?  How could you even have a compressed multi-measure rest when there
> >>>is anything like an "8-bar phrase" in parallel?
> >>>That sounds like a problem that cannot occur.
> >I assume Wol (like me) has the problem where the compressed rest happens in 
> >the part, not in the full score — but one wants not to have to use multiple 
> >\tag constructs just to handle this issue.
> Exactly... I write my music with "voiceStaff" to contain all the
> score-level stuff eg tempi, tune names, rehearsal marks etc, and
> "voiceInstrument" to contain the stuff that varies by instrument, eg
> notes, dynamics, anything else like that ...
> 
> In the case example, the phrase is eight bars long, commencing with
> a two-bar rest. For another instrument, it won't have a rest. And I
> don't want the output to change dramatically depending on what's in
> the part.
> 
> So of course, because voiceStaff is not meant to contain notes, it
> uses "s" all the time. And I very rarely produce scores, this case
> is absolutely typical for me in that we only have a bass-clef part,
> and because while some players in our section can read both, we have
> some players who can only read bass or treble clef so transposing is
> a regular requirement. So I'll have three parts to do, 1st, 2nd and
> bass.

I haven't followed all that. Is this the sort of thing you want?

Cheers,
David.


marks.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Anthonys Lists]

On 22/04/2016 16:55, David Kastrup wrote:

>The first fermata prints fine. The second fermata prints "programming
>error: Object is not a markup." in the log and doesn't print. So
>that's another bug tracked down in my piece,

That's_explicitly_  what \fermataMarkup is for.  If people consulted the
manual before reporting known quirks...


Oops - I *used* to know the manuals very well - I proofread them from 
cover to cover back in Graham's day ...


I know a lot has changed since then - as I said \fermata didn't even 
work on notes back then - but there's a lot that's changed since then. 
Having a comprehensive out-of-date knowledge can bite you ... and I 
don't use lily enough to keep up with the changes.


That said, this *is* the user list, and sometimes RTFM is a good answer. 
Although I hate it when they don't tell you where in the FM to R. 
(That's not the case here, though, I ought to be able to find it very 
easily :-) Often it's not knowing WHAT to look for that's the problem, 
as in here I thought I knew about fermata ...




We'd probably have less inclination to address the quirks eventually.
As David Wright said, it seems MMRs are just one big quirk (as I'm 
finding out with this piece), so that's probably a big job to address :-(


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Noeck]

Hi,

> f1->\fermata R1*3 R1\fermata

You can use \fermataMarkup

{ R1\fermataMarkup }

I know it looks more like a workaround than something one would expect,
but it works.

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Wright]

On Fri 22 Apr 2016 at 16:24:06 (+0100), Anthonys Lists wrote:
> On 22/04/2016 14:49, Paul Scott wrote:
> >>I assume Wol (like me) has the problem where the compressed rest happens
> >>>in the part, not in the full score — but one wants not to have to use
> >>>multiple \tag constructs just to handle this issue.
> >Me too.  I asked a long time ago and got the idea that I was the only
> >one concerned about this.  Essentially why is alignment different for
> >multi-measure rests than notes.
> And other things too? Try the following ...
> 
> f1->\fermata R1*3 R1\fermata
> 
> The first fermata prints fine. The second fermata prints
> "programming error: Object is not a markup." in the log and doesn't
> print. So that's another bug tracked down in my piece, but - from a
> musician's pov - it doesn't make sense that the first example on a
> note should work fine, and the second on a rest produces an error.
> (It never used to work on notes at all, iirc, only as a mark on
> barlines, so maybe I should be grateful for small mercies :-)
> 
> It's easy enough to fix - something like "\markup #symbol.fermata" -
> I'll have to look up the syntax - but it's just frustrating that
> it's not consistent.

That's because whole-bar and multimeasure rests are themselves not
consistent with music notation in general. They have the "wrong"
duration and the "wrong" alignment (placement). They're a convenience
for musicians (especially instrumentalists; singers often hate them)
and a pain for engraving programs.

AIUI I can anchor things horizontally to either barlines or to
notes/rests/spacers. Unfortunately once a whole-bar rest has
jumped to the middle of a bar, it's no longer a useful anchor
for most purposes.

I haven't tried to set your OP's snippet. It might be an idea to post
a sketch of what you want. Possibly you'll improve your chances of
suggestions.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Anthonys Lists  writes:

> On 22/04/2016 14:49, Paul Scott wrote:
>>> I assume Wol (like me) has the problem where the compressed rest happens
>>> >in the part, not in the full score — but one wants not to have to use
>>> >multiple \tag constructs just to handle this issue.
>> Me too.  I asked a long time ago and got the idea that I was the only
>> one concerned about this.  Essentially why is alignment different for
>> multi-measure rests than notes.
> And other things too? Try the following ...
>
> f1->\fermata R1*3 R1\fermata
>
> The first fermata prints fine. The second fermata prints "programming
> error: Object is not a markup." in the log and doesn't print. So
> that's another bug tracked down in my piece,

That's _explicitly_ what \fermataMarkup is for.  If people consulted the
manual before reporting known quirks...

We'd probably have less inclination to address the quirks eventually.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Anthonys Lists]

On 22/04/2016 14:49, Paul Scott wrote:

I assume Wol (like me) has the problem where the compressed rest happens
>in the part, not in the full score — but one wants not to have to use
>multiple \tag constructs just to handle this issue.

Me too.  I asked a long time ago and got the idea that I was the only
one concerned about this.  Essentially why is alignment different for
multi-measure rests than notes.

And other things too? Try the following ...

f1->\fermata R1*3 R1\fermata

The first fermata prints fine. The second fermata prints "programming 
error: Object is not a markup." in the log and doesn't print. So that's 
another bug tracked down in my piece, but - from a musician's pov - it 
doesn't make sense that the first example on a note should work fine, 
and the second on a rest produces an error. (It never used to work on 
notes at all, iirc, only as a mark on barlines, so maybe I should be 
grateful for small mercies :-)


It's easy enough to fix - something like "\markup #symbol.fermata" - 
I'll have to look up the syntax - but it's just frustrating that it's 
not consistent.


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Anthonys Lists]

On 22/04/2016 14:31, Kieren MacMillan wrote:

Wol: Scan through the thread starting 
at  and 
see if anything there helps.

Good luck,
Kieren.
Just scanned it - unfortunately I'm using \markup on an s, rather than 
\mark, for my tune name (because I've already got two colliding marks, 
rehearsal and tempo), so that thread saying "compress MMRs when they 
don't contain blah blah" will fail because I've got a markup in there :-(


If I had some mark I could stick the tune name in that wouldn't collide 
with and be suppressed by the rehearsal mark, then maybe it would work. 
But without writing some new kind of mark (is there one already 
available? it might have been added at some point?) I don't know what 
else to do - using markup seemed the best option. And I don't fancy 
trying to write a new mark, I've dug into this on a couple of occasions 
and got out of my depth rather quickly.


Losing an MMR isn't really a problem, it just looks a little bit odd :-( 
and I come across plenty of music that (imho) has weird MMR settings 
anyway. Usually because they've compressed the end of one phrase into 
the start of another - I really don't like it when a single MMR spans 
several incomplete musical phrases.


Oh well. I'll carry on fiddling :-) But it is frustrating when all I 
want to do is move a bit of text a smidgeon to one side, and I just can 
NOT work out how to do it without all sorts of other unintended side 
effects ...


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Anthonys Lists]

On 22/04/2016 14:31, Kieren MacMillan wrote:

David K wrote:

>Hm?  How could you even have a compressed multi-measure rest when there
>is anything like an "8-bar phrase" in parallel?
>That sounds like a problem that cannot occur.

I assume Wol (like me) has the problem where the compressed rest happens in the 
part, not in the full score — but one wants not to have to use multiple \tag 
constructs just to handle this issue.
Exactly... I write my music with "voiceStaff" to contain all the 
score-level stuff eg tempi, tune names, rehearsal marks etc, and 
"voiceInstrument" to contain the stuff that varies by instrument, eg 
notes, dynamics, anything else like that ...


In the case example, the phrase is eight bars long, commencing with a 
two-bar rest. For another instrument, it won't have a rest. And I don't 
want the output to change dramatically depending on what's in the part.


So of course, because voiceStaff is not meant to contain notes, it uses 
"s" all the time. And I very rarely produce scores, this case is 
absolutely typical for me in that we only have a bass-clef part, and 
because while some players in our section can read both, we have some 
players who can only read bass or treble clef so transposing is a 
regular requirement. So I'll have three parts to do, 1st, 2nd and bass.


And because text seems to centre on the "s" (or something like that), as 
you say, its appearance is affected greatly by what happens to be in the 
part :-( I just want markups to be able to shunt stuff out of the way 
*sideways*. Bearing in mind the parts I'm setting, often the cost of a 
page turn is unacceptable, so to lose a huge amount of space because a 
markup increases staff spacing (or wastes horizontal space pushing music 
aside) is a nightmare. A march part, for example, has to cram an entire 
piece onto a piece of A5 paper (half-letter size, for Americans). And 
no, you can't just turn over ...



Wol: Scan through the thread starting 
at  and 
see if anything there helps.

Thanks, I'll investigate.

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Paul Scott]

On Fri, Apr 22, 2016 at 09:31:17AM -0400, Kieren MacMillan wrote:
> Hi Wol,
> 
> > My usual bugbear ... :-(
> > I have a couple of instances where I have a rehearsal mark, a tempo mark, 
> > […]
> 
> Yeah… this causes me no end of grief, too.
> It probably represents a good 10% of my score/part tweaking time.
> 
> David K wrote:
> > Hm?  How could you even have a compressed multi-measure rest when there
> > is anything like an "8-bar phrase" in parallel?
> > That sounds like a problem that cannot occur.
> 
> I assume Wol (like me) has the problem where the compressed rest happens
> in the part, not in the full score — but one wants not to have to use
> multiple \tag constructs just to handle this issue.

Me too.  I asked a long time ago and got the idea that I was the only
one concerned about this.  Essentially why is alignment different for
multi-measure rests than notes.

Paul


> 
> Wol: Scan through the thread starting at
> 
> and see if anything there helps.
> 
> Good luck,
> Kieren.
> 
> 
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Kieren MacMillan]

Hi Wol,

> My usual bugbear ... :-(
> I have a couple of instances where I have a rehearsal mark, a tempo mark, […]

Yeah… this causes me no end of grief, too.
It probably represents a good 10% of my score/part tweaking time.

David K wrote:
> Hm?  How could you even have a compressed multi-measure rest when there
> is anything like an "8-bar phrase" in parallel?
> That sounds like a problem that cannot occur.

I assume Wol (like me) has the problem where the compressed rest happens in the 
part, not in the full score — but one wants not to have to use multiple \tag 
constructs just to handle this issue.

Wol: Scan through the thread starting at 
 and see 
if anything there helps.

Good luck,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Anthonys Lists  writes:

> My usual bugbear ... :-(
>
> I have a couple of instances where I have a rehearsal mark, a tempo
> mark, and a tune name all wanting to be over the same barline (this is
> an arrangement, where there are several tunes and each is identified
> where it occurs).
>
> So I have something along the lines of
>
> <<
> { s1 | \mark \default \tempo "poco allegretto" s1^\markup "This is the
> army mr jones" s1*7 }
> { c1 | R1*2 }
>>>
>
> However, the two "s1"s are causing the R1*2 to print as two separate
> bars :-( I'm also getting
>
> warning: MultiMeasureRestText has empty extent and non-empty stencil.
>
> in the log, which I guess is related. Any ideas how to get the rest to
> print as a multi-measure rest? The problem, from my pov, is that the
> first, markup, line is meant to be shared across multiple parts, so if
> I do s1*8^\markup, the text is centred over the 8-bar phrase or some
> other wrongness,

Hm?  How could you even have a compressed multi-measure rest when there
is anything like an "8-bar phrase" in parallel?

That sounds like a problem that cannot occur.

> The other problem I have, is is there any way I can shunt markup left
> or right (both tempo and text)? I've been using extra-spacing-width,
> which works a treat sometimes, and is dreadful elsewhere. It's been
> fine for rehearsal marks, but when I use it on tempo and text, it's
> been shoving the music out of the way, which then looks awful. I just
> want to push the text slightly to the right to avoid colliding with
> the rehearsal mark (and I have tried extra-spacing-width leaving one
> or other argument at its default +-infinity, and again it seems to
> work sometimes and be a nightmare elsewhere ...) All the horizontal
> adjustment stuff I've seen seems to be for in-staff objects like
> lines, noteheads, accidentals ... will they work on markups?

Some will.  It's probably easiest fiddling with self-alignment-X if that
is heeded, making one more or less right-aligned and the other left.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Multi-measure rests and mark collisions ...

[Anthonys Lists]

My usual bugbear ... :-(

I have a couple of instances where I have a rehearsal mark, a tempo 
mark, and a tune name all wanting to be over the same barline (this is 
an arrangement, where there are several tunes and each is identified 
where it occurs).


So I have something along the lines of

<<
{ s1 | \mark \default \tempo "poco allegretto" s1^\markup "This is the 
army mr jones" s1*7 }

{ c1 | R1*2 }
>>

However, the two "s1"s are causing the R1*2 to print as two separate 
bars :-( I'm also getting


warning: MultiMeasureRestText has empty extent and non-empty stencil.

in the log, which I guess is related. Any ideas how to get the rest to 
print as a multi-measure rest? The problem, from my pov, is that the 
first, markup, line is meant to be shared across multiple parts, so if I 
do s1*8^\markup, the text is centred over the 8-bar phrase or some other 
wrongness, although that fixes the multi-measure-rest problem.


The other problem I have, is is there any way I can shunt markup left or 
right (both tempo and text)? I've been using extra-spacing-width, which 
works a treat sometimes, and is dreadful elsewhere. It's been fine for 
rehearsal marks, but when I use it on tempo and text, it's been shoving 
the music out of the way, which then looks awful. I just want to push 
the text slightly to the right to avoid colliding with the rehearsal 
mark (and I have tried extra-spacing-width leaving one or other argument 
at its default +-infinity, and again it seems to work sometimes and be a 
nightmare elsewhere ...) All the horizontal adjustment stuff I've seen 
seems to be for in-staff objects like lines, noteheads, accidentals ... 
will they work on markups?


Pointers greatly appreciated ...

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user