Hi list,

I usually use the following snippet to handle glissandi across hidden
noteheads:

glissandoSkipOn = {
  \override NoteColumn.glissando-skip = ##t
  \hide NoteHead
  \override Accidental.transparent = ##t
  \override NoteHead.no-ledgers = ##t
}

is it possible to implement something similar for bendAfter? A quick check
of the archives did not reveal anything relevant but please link me if this
has already been covered. Pic attached with the line as I want it to look
in green.

Thank you,
Kyle

On Mon, Oct 26, 2020 at 7:01 PM <lilypond-user-requ...@gnu.org> wrote:

> Send lilypond-user mailing list submissions to
>         lilypond-user@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/lilypond-user
> or, via email, send a message with subject or body 'help' to
>         lilypond-user-requ...@gnu.org
>
> You can reach the person managing the list at
>         lilypond-user-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lilypond-user digest..."
> Today's Topics:
>
>    1. Re: I ought to have a bar line here... (Aaron Hill)
>    2. Re: I ought to have a bar line here... (Carl Sorensen)
>    3. Re: I ought to have a bar line here... (Thomas Morley)
>    4. Re: I ought to have a bar line here... (Carl Sorensen)
>    5. Re: I ought to have a bar line here... (Thomas Morley)
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Hill <lilyp...@hillvisions.com>
> To: lilypond-user@gnu.org
> Cc:
> Bcc:
> Date: Mon, 26 Oct 2020 15:17:32 -0700
> Subject: Re: I ought to have a bar line here...
> On 2020-10-26 3:03 pm, Mike Dean wrote:
> > Hi Carl:
> > Is \include "english.ly" different from \language "english"?
> >
> > Part of my residing in the weeds is not being sure where \define
> > command
> > (and its relatives like \defineBarLine) ought to go...while the
> > compilation
> > didn't crash, the bar line construction was ignored in this case
> > Mike Dean
>
> \language "english" is preferred over \include "english.ly".  The latter
> is a vestige of older LilyPond versions where the \language command did
> not exist, and the "english.ly" include files did more stuff.  Now,
> "english.ly" is just a \version and \language statement.
>
> I think you can get away with \defineBarLine being inside music, but it
> would probably be poor practice.  It is better to place all definition
> (or definition-type things) at the top-level.  The only exceptions are
> things that specifically require scope, like \paper variables.
>
> ----
>
> As to why the bar line did not appear in your snippet, you redefined the
> bar twice in the same moment.  Only use \bar once.  In this case you
> would place the \bar command at the end of the alternative or at the
> beginning of the "Trio" section.  As to which, that is probably personal
> taste.
>
>
> -- Aaron Hill
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Carl Sorensen <carl.d.soren...@gmail.com>
> To: Mike Dean <dean...@aquinas.edu>
> Cc: Lilypond-User Mailing List <lilypond-user@gnu.org>
> Bcc:
> Date: Mon, 26 Oct 2020 16:26:53 -0600
> Subject: Re: I ought to have a bar line here...
>
>
> On Mon, Oct 26, 2020 at 4:07 PM Mike Dean <dean...@aquinas.edu> wrote:
>
>> Hi Carl:
>> Is \include "english.ly" different from \language "english"?
>>
>
> It's an old form that predates \language "english".  I'm an old dog, so
> sometimes I forget the new tricks.  At any rate, your snippet didn't
> include \language "english", so I had to fix it.
>
>
>>
>> Part of my residing in the weeds is not being sure where \define command
>> (and its relatives like \defineBarLine) ought to go...while the
>> compilation didn't crash, the bar line construction was ignored in this case
>>
>
> \define always goes at the top level -- outside of any other expressions.
>
> The other change I had to make in order to avoid errors was to replace #f
> with "" as the third element in the \defineBarLine list.  The documentation
> allows the use of #f, but it threw an error and I changed it to "",
> which worked.  That was a successful guess on my part.
>
> Carl
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Morley <thomasmorle...@gmail.com>
> To: Carl Sorensen <c_soren...@byu.edu>
> Cc: Mike Dean <dean...@aquinas.edu>, "lilypond-user@gnu.org" <
> lilypond-user@gnu.org>
> Bcc:
> Date: Mon, 26 Oct 2020 23:34:44 +0100
> Subject: Re: I ought to have a bar line here...
> Hi Carl,
>
> Am Mo., 26. Okt. 2020 um 23:04 Uhr schrieb Carl Sorensen <
> c_soren...@byu.edu>:
> >
> > Try this:
>
> > \defineBarLine ".|:-|." #'("|." ".|:" "")
>
> Though, \defineBarLine ".|:-|." #'("|." ".|:" #f) _should_ work as well.
>
> It's a bug in 'ly:bar-line::calc-anchor' in bar-line.scm, triggered by
> the RehearsalMark requiring an anchor.
> The anchor-calculating procedure compares the span-glyph using
> string=? which bombs out if span-glyph is not a string.
> One should likely use equal? here.
>
> I'll check that more thoroughly and probably ut up a patch.
>
> Cheers,
>   Harm
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Carl Sorensen <carl.d.soren...@gmail.com>
> To: Thomas Morley <thomasmorle...@gmail.com>
> Cc: Carl Sorensen <c_soren...@byu.edu>, "lilypond-user@gnu.org" <
> lilypond-user@gnu.org>
> Bcc:
> Date: Mon, 26 Oct 2020 16:46:49 -0600
> Subject: Re: I ought to have a bar line here...
>
>
> On Mon, Oct 26, 2020 at 4:35 PM Thomas Morley <thomasmorle...@gmail.com>
> wrote:
>
>> Hi Carl,
>>
>> Am Mo., 26. Okt. 2020 um 23:04 Uhr schrieb Carl Sorensen <
>> c_soren...@byu.edu>:
>> >
>> > Try this:
>>
>> > \defineBarLine ".|:-|." #'("|." ".|:" "")
>>
>> Though, \defineBarLine ".|:-|." #'("|." ".|:" #f) _should_ work as well.
>>
>> It's a bug in 'ly:bar-line::calc-anchor' in bar-line.scm, triggered by
>> the RehearsalMark requiring an anchor.
>> The anchor-calculating procedure compares the span-glyph using
>> string=? which bombs out if span-glyph is not a string.
>> One should likely use equal? here.
>>
>
> Thanks, Harm!  Sometimes it's almost as good to be lucky as to be good.
> You are absolutely right, of course, and were I not too lazy to do so, I'd
> have looked up the  line where the actual error was.  Instead I just saw
> that #f didn't work, so I changed to "",
>
> Also, Mike, while my comment about \define always going at the top level,
> that same thing is NOT true in general for functions of the form
> \defineXXX.  I can't think of any cases where it causes problems to put
> them at the top level.  But it's not strictly required, and the use of
> \defineBarLine inside the music expression was not the cause of the errors.
>
> I just wanted to clear up my possibly confusing statement.
>
> Thanks,
>
> Carl
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Morley <thomasmorle...@gmail.com>
> To: Carl Sorensen <carl.d.soren...@gmail.com>
> Cc: Carl Sorensen <c_soren...@byu.edu>, "lilypond-user@gnu.org" <
> lilypond-user@gnu.org>
> Bcc:
> Date: Mon, 26 Oct 2020 23:58:53 +0100
> Subject: Re: I ought to have a bar line here...
> Am Mo., 26. Okt. 2020 um 23:47 Uhr schrieb Carl Sorensen
> <carl.d.soren...@gmail.com>:
> >
> >
> >
> > On Mon, Oct 26, 2020 at 4:35 PM Thomas Morley <thomasmorle...@gmail.com>
> wrote:
> >>
> >> Hi Carl,
> >>
> >> Am Mo., 26. Okt. 2020 um 23:04 Uhr schrieb Carl Sorensen <
> c_soren...@byu.edu>:
> >> >
> >> > Try this:
> >>
> >> > \defineBarLine ".|:-|." #'("|." ".|:" "")
> >>
> >> Though, \defineBarLine ".|:-|." #'("|." ".|:" #f) _should_ work as well.
> >>
> >> It's a bug in 'ly:bar-line::calc-anchor' in bar-line.scm, triggered by
> >> the RehearsalMark requiring an anchor.
> >> The anchor-calculating procedure compares the span-glyph using
> >> string=? which bombs out if span-glyph is not a string.
> >> One should likely use equal? here.
> >
> >
> > Thanks, Harm!  Sometimes it's almost as good to be lucky as to be good.
> You are absolutely right, of course, and were I not too lazy to do so, I'd
> have looked up the  line where the actual error was.  Instead I just saw
> that #f didn't work, so I changed to "",
>
> Patch's up
> https://gitlab.com/lilypond/lilypond/-/merge_requests/483
>
> Cheers,
>   Harm
>
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

Reply via email to