Re: Accidentals tied over a system break

2015-10-08 Thread Thomas Morley
2015-10-08 15:40 GMT+02:00 Sven :
> Reading my way through Behind Bars by Elaine Gould, I'm trying to replicate
> some of the examples in LilyPond. One of them contains a tie over a system
> break:
>
> \version "2.18.2"
>
> \relative c'' {
>   r2. fis,4~ | \break
>   fis8 a16 fis r8 r2 \bar "|."
>   }
>
>
> LP puts a sharp in front of the first f# in measure 2 as well as the second
> one. According to Gould repeating an accidental twice in a bar in close
> succession is redundant (and I think I agree with her). To hide the second
> sharp, I've put \once \override Accidental #'transparent = ##t in front of
> it. Is this the preferred way of doing hiding that sharp?
>
> I don't consider this a bug per se, but maybe LP can programmed to avoid
> repeating accidentals in close succession in upcoming versions?
>
> Sven


Is a tied note with Accidental after line-break "in close succession"?
Opinions differ.

Anyway, the documented method to use:

\override Accidental.hide-tied-accidental-after-break = ##t


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Accidentals tied over a system break

2015-10-08 Thread Sven
Reading my way through Behind Bars by Elaine Gould, I'm trying to replicate
some of the examples in LilyPond. One of them contains a tie over a system
break:

\version "2.18.2"

\relative c'' {
  r2. fis,4~ | \break
  fis8 a16 fis r8 r2 \bar "|."
  }


LP puts a sharp in front of the first f# in measure 2 as well as the second
one. According to Gould repeating an accidental twice in a bar in close
succession is redundant (and I think I agree with her). To hide the second
sharp, I've put \once \override Accidental #'transparent = ##t in front of
it. Is this the preferred way of doing hiding that sharp?

I don't consider this a bug per se, but maybe LP can programmed to avoid
repeating accidentals in close succession in upcoming versions?

Sven
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread David Kastrup
Thomas Morley  writes:

> 2015-10-08 15:40 GMT+02:00 Sven :
>> Reading my way through Behind Bars by Elaine Gould, I'm trying to replicate
>> some of the examples in LilyPond. One of them contains a tie over a system
>> break:
>>
>> \version "2.18.2"
>>
>> \relative c'' {
>>   r2. fis,4~ | \break
>>   fis8 a16 fis r8 r2 \bar "|."
>>   }
>>
>>
>> LP puts a sharp in front of the first f# in measure 2 as well as the second
>> one. According to Gould repeating an accidental twice in a bar in close
>> succession is redundant (and I think I agree with her). To hide the second
>> sharp, I've put \once \override Accidental #'transparent = ##t in front of
>> it. Is this the preferred way of doing hiding that sharp?
>>
>> I don't consider this a bug per se, but maybe LP can programmed to avoid
>> repeating accidentals in close succession in upcoming versions?
>>
>> Sven
>
>
> Is a tied note with Accidental after line-break "in close succession"?
> Opinions differ.
>
> Anyway, the documented method to use:
>
> \override Accidental.hide-tied-accidental-after-break = ##t

Ah, but he was not talking about the tied accidental after the break.
He was talking about the accidental following the tied accidental after
the break.  Namely issue 649.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Phil Holmes
- Original Message - 
From: "Thomas Morley" <thomasmorle...@gmail.com>

To: "Sven" <lilypond-u...@hotmail.com>
Cc: "lilypond-user" <lilypond-user@gnu.org>
Sent: Thursday, October 08, 2015 3:10 PM
Subject: Re: Accidentals tied over a system break



2015-10-08 15:40 GMT+02:00 Sven <lilypond-u...@hotmail.com>:
Reading my way through Behind Bars by Elaine Gould, I'm trying to 
replicate
some of the examples in LilyPond. One of them contains a tie over a 
system

break:

\version "2.18.2"

\relative c'' {
  r2. fis,4~ | \break
  fis8 a16 fis r8 r2 \bar "|."
  }


LP puts a sharp in front of the first f# in measure 2 as well as the 
second

one. According to Gould repeating an accidental twice in a bar in close
succession is redundant (and I think I agree with her). To hide the 
second
sharp, I've put \once \override Accidental #'transparent = ##t in front 
of

it. Is this the preferred way of doing hiding that sharp?

I don't consider this a bug per se, but maybe LP can programmed to avoid
repeating accidentals in close succession in upcoming versions?

Sven



Is a tied note with Accidental after line-break "in close succession"?
Opinions differ.

Anyway, the documented method to use:

\override Accidental.hide-tied-accidental-after-break = ##t



I don't believe the OP is complaining about the sharp after the break: 
rather the sharp on the last sounded note.  That doesn't appear needed, 
since we already have a sharp shown on the first note in the bar.


--
Phil Holmes 



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Trevor Daniels

Phil Holmes wrote Thursday, October 08, 2015 3:21 PM

> From: "Thomas Morley" <thomasmorle...@gmail.com>
> To: "Sven" <lilypond-u...@hotmail.com>
> Cc: "lilypond-user" <lilypond-user@gnu.org>
> Sent: Thursday, October 08, 2015 3:10 PM
> Subject: Re: Accidentals tied over a system break
> 
> 
>> 2015-10-08 15:40 GMT+02:00 Sven <lilypond-u...@hotmail.com>:
>>> Reading my way through Behind Bars by Elaine Gould, I'm trying to 
>>> replicate
>>> some of the examples in LilyPond. One of them contains a tie over a 
>>> system
>>> break:
>>>
>>> \version "2.18.2"
>>>
>>> \relative c'' {
>>>   r2. fis,4~ | \break
>>>   fis8 a16 fis r8 r2 \bar "|."
>>>   }
>>>
>>>
>>> LP puts a sharp in front of the first f# in measure 2 as well as the 
>>> second
>>> one. According to Gould repeating an accidental twice in a bar in close
>>> succession is redundant (and I think I agree with her). To hide the 
>>> second
>>> sharp, I've put \once \override Accidental #'transparent = ##t in front 
>>> of
>>> it. Is this the preferred way of doing hiding that sharp?
>>>
>>> I don't consider this a bug per se, but maybe LP can programmed to avoid
>>> repeating accidentals in close succession in upcoming versions?
>>>
>
> I don't believe the OP is complaining about the sharp after the break: 
> rather the sharp on the last sounded note.  That doesn't appear needed, 
> since we already have a sharp shown on the first note in the bar.

Furthermore, if the tie is removed the sharp on the final fis
is also removed.  The issue is, without the \break the final fis
needs the sharp as the second fis doesn't have one, being tied
to the first fis.  Adding the \break causes the second fis to
need (and get) a sharp, but the sharp on the third fis, which is
now redundant, is not removed.  Seems to be a bug to me.

Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Simon Albrecht

On 08.10.2015 16:38, Trevor Daniels wrote:

Furthermore, if the tie is removed the sharp on the final fis
is also removed.  The issue is, without the \break the final fis
needs the sharp as the second fis doesn't have one, being tied
to the first fis.  Adding the \break causes the second fis to
need (and get) a sharp, but the sharp on the third fis, which is
now redundant, is not removed.  Seems to be a bug to me.


And, just as David said, one that is long known and being tracked: 
. There has been 
some discussion, but at any rate it’s nonsense to have both accidentals, 
and IMO the second should be left out.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Urs Liska


Am 08.10.2015 um 15:40 schrieb Sven:
> Reading my way through Behind Bars by Elaine Gould, I'm trying to
> replicate some of the examples in LilyPond. One of them contains a tie
> over a system break:
>
> \version "2.18.2"
>
> \relative c'' {
>   r2. fis,4~ | \break 
>   fis8 a16 fis r8 r2 \bar "|."
>   }
>
>
> LP puts a sharp in front of the first f# in measure 2 as well as the
> second one. According to Gould repeating an accidental twice in a bar
> in close succession is redundant (and I think I agree with her). To
> hide the second sharp, I've put \once \override Accidental
> #'transparent = ##t in front of it. Is this the preferred way of doing
> hiding that sharp?
>

Actually I'm not sure about the proper solution or whether it's a bug
(as David Kastrup suggested).
But to hide the accidental manually you should use \once \omit
Accidental instead of overriding #'transparent. Setting an object
transparent will hide it but keep the space in place (so you'll probably
see an unwanted gap instead.

\hide is an alias for what you did, and \omit is an alias for \override
Accidental #'stencil = ##f.

HTH
Urs

> I don't consider this a bug per se, but maybe LP can programmed to
> avoid repeating accidentals in close succession in upcoming versions?
>
> Sven
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread David Kastrup
Simon Albrecht  writes:

> On 08.10.2015 16:38, Trevor Daniels wrote:
>> Furthermore, if the tie is removed the sharp on the final fis
>> is also removed.  The issue is, without the \break the final fis
>> needs the sharp as the second fis doesn't have one, being tied
>> to the first fis.  Adding the \break causes the second fis to
>> need (and get) a sharp, but the sharp on the third fis, which is
>> now redundant, is not removed.  Seems to be a bug to me.
>
> And, just as David said, one that is long known and being tracked:
> . There has been
> some discussion, but at any rate it’s nonsense to have both
> accidentals, and IMO the second should be left out.

I don't think there's much of a disagreement on that.  It's just that
it's quite tricky to do.  The "remove tied accidental unless after line
break" is somewhat easy to do: the accidental in its final phase of
typesetting checks whether there is a tie leading to it and whether that
tie is just a broken-off part of a tie.  If it is, the accidental is
killed.

However, keeping track of the complex relation between this kind of
line-break related killed accidental and the following one is rather
harder to pin down since the following one needs to have no vicinity to
either tie or line break.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Sven
Sorry, I didn't know this is a known issue.

And thanks for correcting me on how to actually remove the second sharp,
Urs: \once \omit Accidental get's rid of the bugger, while \once \hide
Accidental makes it transparent, leaving its space in tact.

Sven

2015-10-08 19:14 GMT+02:00 David Kastrup :

> Simon Albrecht  writes:
>
> > On 08.10.2015 16:38, Trevor Daniels wrote:
> >> Furthermore, if the tie is removed the sharp on the final fis
> >> is also removed.  The issue is, without the \break the final fis
> >> needs the sharp as the second fis doesn't have one, being tied
> >> to the first fis.  Adding the \break causes the second fis to
> >> need (and get) a sharp, but the sharp on the third fis, which is
> >> now redundant, is not removed.  Seems to be a bug to me.
> >
> > And, just as David said, one that is long known and being tracked:
> > . There has been
> > some discussion, but at any rate it’s nonsense to have both
> > accidentals, and IMO the second should be left out.
>
> I don't think there's much of a disagreement on that.  It's just that
> it's quite tricky to do.  The "remove tied accidental unless after line
> break" is somewhat easy to do: the accidental in its final phase of
> typesetting checks whether there is a tie leading to it and whether that
> tie is just a broken-off part of a tie.  If it is, the accidental is
> killed.
>
> However, keeping track of the complex relation between this kind of
> line-break related killed accidental and the following one is rather
> harder to pin down since the following one needs to have no vicinity to
> either tie or line break.
>
> --
> David Kastrup
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Accidentals tied over a system break

2015-10-08 Thread Urs Liska


Am 8. Oktober 2015 19:59:57 MESZ, schrieb Sven :
>Sorry, I didn't know this is a known issue.
>
>And thanks for correcting me on how to actually remove the second
>sharp,
>Urs: \once \omit Accidental get's rid of the bugger, while \once \hide
>Accidental makes it transparent, leaving its space in tact.

Well, it's "correct", but still it is a hack. Maybe you inferred it from he 
discussion: you get rid of the redindant accidental - but if your line breaking 
should ever cjange it won't automatically come back.

Urs
>
>Sven
>
>2015-10-08 19:14 GMT+02:00 David Kastrup :
>
>> Simon Albrecht  writes:
>>
>> > On 08.10.2015 16:38, Trevor Daniels wrote:
>> >> Furthermore, if the tie is removed the sharp on the final fis
>> >> is also removed.  The issue is, without the \break the final fis
>> >> needs the sharp as the second fis doesn't have one, being tied
>> >> to the first fis.  Adding the \break causes the second fis to
>> >> need (and get) a sharp, but the sharp on the third fis, which is
>> >> now redundant, is not removed.  Seems to be a bug to me.
>> >
>> > And, just as David said, one that is long known and being tracked:
>> > . There has
>been
>> > some discussion, but at any rate it’s nonsense to have both
>> > accidentals, and IMO the second should be left out.
>>
>> I don't think there's much of a disagreement on that.  It's just that
>> it's quite tricky to do.  The "remove tied accidental unless after
>line
>> break" is somewhat easy to do: the accidental in its final phase of
>> typesetting checks whether there is a tie leading to it and whether
>that
>> tie is just a broken-off part of a tie.  If it is, the accidental is
>> killed.
>>
>> However, keeping track of the complex relation between this kind of
>> line-break related killed accidental and the following one is rather
>> harder to pin down since the following one needs to have no vicinity
>to
>> either tie or line break.
>>
>> --
>> David Kastrup
>>
>>
>
>
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user