lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Wright
Subject: Re: Multi-measure rests and mark collisions ...
Date: Sun, 24 Apr 2016 23:31:33 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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

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.

> >>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.
> >
> >
> 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.
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
> push sideways (and I seem to remember David Kastrup saying "how the
> ... do you expect me to code that" or words to that effect, it's a
> very hard problem). But from my point of view, the cost of that
> extra wasted line because markup stacks can be astronomical - the
> cost of a page turn can easily be thirty seconds in a performance,
> and I've known it be "forever", when a player has tried to do it
> quickly and lost his music in the process ...

Oh, there are worse cases than that. A marching band can't turn the
page in the middle of a piece.

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?

> What I want, is to move "This is the army ..." slightly to the
> right, so it fits next to the A, and it should then push the B to
> the right out of the way, and the music fit neatly underneath.
> Because one instrument may have a single MMR between A and B, while
> another instrument plays the entire tune. And that is my problem in
> a nutshell - what the instrument has affects how the markup is
> displayed, when I would rather the markup affect how the instrument
> is displayed.
> 
> This is why, as Kieran said, such a large amount of time can be
> spent on silly little layout tweaks, and as I say, in my case just
> letting it spill onto a second page is a very *expensive* option.

The more preconditions you set (rehearsal marks cannot be right
justified, to clear the way for the other marks amd tempo indications;
long tune titles must be included; multiple rests must be consolidated;
no page turns are allowed; ...) the more work you or LP have to do.
The more unconventional they are, the more they fall into your lap.
And in what area of computing does the last 10% not take 90% of the
time? (I still don't know what you're trying to accomplish, or what
you have managed in the past, like remembering those empty chords.)

Cheers,
David.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]