lilypond-user
[Top][All Lists]
Advanced

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

Re: alternate notes within a part


From: David Wright
Subject: Re: alternate notes within a part
Date: Sun, 9 Jan 2022 21:46:23 -0600
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon 10 Jan 2022 at 01:54:03 (+0100), Valentin Petzel wrote:
> Am Montag, 10. Jänner 2022, 01:32:55 CET schrieb David Wright:
> > On Sun 09 Jan 2022 at 23:36:41 (+0100), Valentin Petzel wrote:
> > > Am Sonntag, 9. Jänner 2022, 23:05:15 CET schrieb David Zelinsky:
> > > > I'm engraving a part that can be played either on cello or bassoon, but
> > > > with several differennces for short sections:  e.g. a clef change for
> > > > one and not the other; a different octave for a few measures; double
> > > > stops or not.
> > > > 
> > > > I want to have just one version of the source, assigned to a variable
> > > > (e.g. cello-bassoon-notes = {...} ), with the differences indicated by
> > > > short tagged sections (like \tag #'cello {...} \tag #'bassoon {...} ),
> > > > so that I can produce output for each instrument seperately from the
> > > > same source.
> > > > 
> > > > There seem to be a couple of problems using tags like this.  First, it's
> > > > kludgy because when the notes are parsed, Lilypond includes all notes
> > > > from both tagged parts, and complains about bar check failures.  That
> > > > doesn't really matter, since when the notes are used (as say
> > > > \keepWithTag #'cello) it all comes out right.  And I can avoid the
> > > > warnings if I tag full measures only.  But as I said, it's kludgy.
> > > > 
> > > > Worse is that a clef change in one tagged part affects all the
> > > > subsequent music.  And similarly, in \relative mode, the tags are
> > > > ignored when Lilypond determines the octave of following notes.
> > > > 
> > > > Is there a better way to accomplish what I'm trying to do?  Or do I
> > > > really just need to maintain completely separate versions for the two
> > > > instruments?
> > > 
> > > Much of what you’re describing should not happen. \keepWithTag and
> > > \removeWithTag remove the music before it is parsed.
> > > 
> > > It is true that using tags with relative music can be a bit messy, as
> > > depending on which part you remove the following music will change. You
> > > can
> > > circumvent this by putting your tagged music in absolute mode.
> > 
> > I can't replicate that. AIUI the \music=\relative{…} has its pitches
> > baked in when the closing brace is read /on input/, regardless of
> > any tags read. When the music is set in \score{…}, the pitches can't
> > change.
> > 
> > OTOH any clefs in \music are only enacted as the music is typeset,
> > so they shouldn't be included in \music, but separately. Otherwise,
> > were a tagged section to finish in the wrong clef, you would have to
> > insert an extra clef but suppress its printing—not worth the hassle.
> > 
> > > Can you send us an example of your problems to see where it may come from?
> 
> You’re right. \relative does in fact directly change the music events 
> (instead 
> of doing it during translation), so removing tagged stuff should not make a 
> difference.
> 
> I’m not exactly sure about what you mean with the clefs. If one tag changes 
> the clefs it would be reasonable to assume that at the end of the tagged 
> music 
> the clef is changed back, like
> \tag #'

You're right. I had forgotten that although you have to cancel the
change of clef with another clef ("extra" clef would be a misnomer),
LP will not print it when it's redundant. So at least that's one
simplification.

I would agree about taking care with what you enclose in \relative { … },
avoiding structure as much as possible. For example, I would not follow
NR in the sections "Different time signatures with (un)equal-length
measures", "Additional voices to avoid collisions" and "Vertically
aligning ossias and lyrics", where several Staffs/Voices are enclosed
by one \relative. It makes any rearrangement of staves' and voices'
ordering very tedious.

Cheers,
David.

Attachment: clef.ly
Description: Text document

Attachment: clef.pdf
Description: Adobe PDF document


reply via email to

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