can bendAfter be made to skip over notes?

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-request@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-request@gnu.org

You can reach the person managing the list at
lilypond-user-owner@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 <lilypond@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.sorensen@gmail.com>
To: Mike Dean <deanmi2@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 <deanmi2@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 <thomasmorley65@gmail.com>
To: Carl Sorensen <c_sorensen@byu.edu>
Cc: Mike Dean <deanmi2@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_sorensen@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.sorensen@gmail.com>
To: Thomas Morley <thomasmorley65@gmail.com>
Cc: Carl Sorensen <c_sorensen@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 <thomasmorley65@gmail.com> wrote:
Hi Carl,

Am Mo., 26. Okt. 2020 um 23:04 Uhr schrieb Carl Sorensen <c_sorensen@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 <thomasmorley65@gmail.com>
To: Carl Sorensen <carl.d.sorensen@gmail.com>
Cc: Carl Sorensen <c_sorensen@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.sorensen@gmail.com>:
>
>
>
> On Mon, Oct 26, 2020 at 4:35 PM Thomas Morley <thomasmorley65@gmail.com> wrote:
>>
>> Hi Carl,
>>
>> Am Mo., 26. Okt. 2020 um 23:04 Uhr schrieb Carl Sorensen <c_sorensen@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

From:	98123981293 1293812397123
Subject:	can bendAfter be made to skip over notes?
Date:	Mon, 26 Oct 2020 22:37:27 -0400