Re: Using \partial with TACET

[Jacques Menu]

\markup{\huge\bold TACET}

solves you second question.


> Le 8 oct. 2015 à 18:04, Jacques Menu <address@hidden> a écrit :
> 
> Hello A,
> 
> \version "2.19.28"
> 
> VITympanoMusic = \new Voice \relative c {
>  \clef bass
>  \partial 8
>  r8 |
>  R2*54^\markup { \center-align TACET }
>  R2.*29^\markup { \center-align TACET }
> }
> 
> {
> \VITympanoMusic
> }
> 
> This has 29 times three quater notes, so if you use the default 4/4, then you 
> get:
> 
>       warning: barcheck failed at: 3/4
> 
> But has DK says, we don’t know how you use this...
> 
> JM
> 
> 
>> Le 8 oct. 2015 à 16:12, David Kastrup <address@hidden> a écrit :
>> 
>> "N. Andrew Walsh" <address@hidden> writes:
>> 
>>> Hi List,
>>> 
>>> I'm working on a collection of masses, which I've broken up into a tree of
>>> files: each mass is in its own directory, with separate files for each
>>> movement and a master file listing all the \includes. There are also now
>>> separate files for each movement's \score block, so I can have different
>>> layout options per movement (this also seems necessary if I want each
>>> \music block to be contained in a differently-named variable to call up
>>> later when making the parts).
>>> 
>>> Here's my issue: in the last mass, the tympani part is tacet. I want the
>>> Tympani to show up in the score in the first system only; but in the part,
>>> I would like to have the \header block for that mass over a \markup
>>> declaring TACET in big block letters (potentially over a compressed
>>> rest-bar). I can do this for simple movements, but now I have one with a)
>>> an 8th-note pickup, and b) a meter change in the middle. If I have the
>>> following in the Tympani variable:
>>> 
>>> VITympanoMusic = \new Voice \relative c {
>>> \clef bass
>>> \partial 8 r8 | R2*54^\markup { \center-align TACET }
>>> R2.*29^\markup { \center-align TACET }
>>> }
>>> 
>>> Lily throws a barcheck failure (but looks fine in the score). Is there a
>>> better way to do this? am I doing something wrong here, or is this a bug
>>> with Lily herself?
>> 
>> I don't see any meter change.  I don't see a minimal example one could
>> compile.  I don't even see a version number.
>> 
>> How do you suppose anybody is going to analyze your problem without
>> knowledge about the actual corresponding LilyPond file and the actual
>> corresponding LilyPond binary?
>> 
>> -- 
>> David Kastrup
>> 
>> _______________________________________________
>> lilypond-user mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>