Re: Setting Slur.positions to 0s can still move slurs

[Aaron Hill]

On 2021-04-07 7:52 am, Nate Whetsell wrote:

Setting Slur.positions to #'(0 . 0) appears to still move slurs.


The Internals reference [1] comments on the the positions property of 
the slur-interface:


"For slurs, this value selects which slur candidate to use; if extreme 
positions are requested, the closest one is taken."


The snippet [2] you mentioned is poorly worded in my opinion.  Setting 
positions does not move the Slur, rather it tells LilyPond to try to use 
a Slur that has its ends points on the specified staff position.  As 
such, #'(0 . 0) does not mean there is to be no effect on the Slur, 
rather it instructs LilyPond to prefer a Slur where the ends lie on the 
center line.


To actually move a Slur, you could adjust its control-points property, 
which holds the shape of the candidate Slur that was selected by 
LilyPond.  The \shape command [3] is typically used to do this as it 
allows you to specify individual offsets to be applied to each control 
point.


[1]: 
https://lilypond.org/doc/v2.22/Documentation/internals/slur_002dinterface

[2]: https://lsr.di.unimi.it/LSR/Item?id=684
[3]: 
https://lilypond.org/doc/v2.22/Documentation/notation/modifying-shapes



-- Aaron Hill

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

Setting Slur.positions to 0s can still move slurs

[Nate Whetsell]

Hi there,

Thank you for all your work on LilyPond!

Setting Slur.positions to #'(0 . 0) appears to still move slurs. Here’s an 
example that illustrates the behavior:

```
\version "2.22.0"
{
  \override Beam.auto-knee-gap = #8 % This makes the example clearer but isn't 
needed
  c8( c'') c( c'')
  \override Slur.positions = #'(0 . 0)
  c( c'') c( c'')
}
```

The description at—

https://lilypond.org/doc/v2.22/Documentation/snippets/expressive-marks#expressive-marks-moving-slur-positions-vertically
 
<https://lilypond.org/doc/v2.22/Documentation/snippets/expressive-marks#expressive-marks-moving-slur-positions-vertically>

—says: “Positive values move the slur up, and are appropriate for notes with 
stems down. Negative values move downward slurs further down.” Based on this, 
I’d expect setting Slur.positions to #'(0 . 0) to not move slurs at all. 
Instead, it appears that setting Slur.positions to #'(0 . 0) can move slurs 
quite a bit.

All the best,
Nate
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

> On Apr 7, 2017, at 03:58, David Kastrup  wrote:
> 
>> Please try this.  I haven’t tested your patch.
> 
> I'm sort of annoyed at the somewhat roundabout \RemoveEmptyStaves bit
> but I guess that's likely a pretty direct way to figure out where the
> NullVoice went.  One doesn't get to see a lot of it otherwise.

I feel the same, but the only other idea I had involved lyrics, which
would have been more complicated.  In its favor, this test covers
something that I actually noticed rather than something contrived.

Thanks again for fixing the problem.
— 
Dan


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

Re: Change_iterator refuses to move a NullVoice into a Staff

[David Kastrup]

Dan Eble  writes:

>> Tracker issue:
>> 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
>> Rietveld issue:
>> 322820043 (https://codereview.appspot.com/322820043)
>
> Thank you.
>
>> Could you rework your almost minimal example into a regtest?
>> Those give me much more of a headache than most code changes
>> since there is no "obviously best" regtest to aim for.
>
> Please try this.  I haven’t tested your patch.

I'm sort of annoyed at the somewhat roundabout \RemoveEmptyStaves bit
but I guess that's likely a pretty direct way to figure out where the
NullVoice went.  One doesn't get to see a lot of it otherwise.

I guess I'll take it.  Thanks.

-- 
David Kastrup

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

> Tracker issue:
> 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
> Rietveld issue:
> 322820043 (https://codereview.appspot.com/322820043)

Thank you.

> Could you rework your almost minimal example into a regtest?
> Those give me much more of a headache than most code changes
> since there is no "obviously best" regtest to aim for.

Please try this.  I haven’t tested your patch.
—
Dan

%{
nullvoice-change.ly

NullVoice responds to \change Staff as a Voice would.  The first line
of the output is a single treble-clef staff.  The second line is a
single bass-clef staff.
%}

\version "2.19.58"

music = \fixed c' {
  c1
  \break
  \change Staff = "After"
  c
}

\new StaffGroup \with {
  \RemoveEmptyStaves
  \override VerticalAxisGroup.remove-first = ##t
} <<

  \new Staff = "Before" <<
\new NullVoice { \music }
  >>

  \new Staff = "After" {
\clef bass
$(skip-of-length music)
  }

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[David Kastrup]

Dan Eble  writes:

> Back to the bug: I appreciate that it’s not obvious what to do with 
> Change_iterator, but is there anything obvious that could be done to 
> NullVoice that (without defeating its purpose) would cause \change Staff to 
> pass over it?

Current branch: contextchange
Tracker issue: 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
Rietveld issue: 322820043 (https://codereview.appspot.com/322820043)
Issue description:
  Allow \change to same context type  The \change command no longer
  refuses to change the parent of a context when the context itself
  would be of the proper type to change to.  This allows changing the
  parent of a context that could be nested, like StaffGroup in
  StaffGroup or NullVoice in Staff (since NullVoice is also aliased to
  Staff).

Could you rework your almost minimal example into a regtest?  Those give
me much more of a headache than most code changes since there is no
"obviously best" regtest to aim for.

Thanks

-- 
David Kastrup

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

David Kastrup <address@hidden> writes:

> For something like
> 
> \change StaffGroup = "what"
> 
> the change iterator looks at the current context hierarchy upwards until
> it finds a "StaffGroup" as a parent.  The layer below that is the
> context to move, and if it is significantly similar in specification to
> the context that should be/become its parent, it might become hard to
> move back and forth.
> 
> So it's likely a bit of work/thought to make sure one does not create
> context trapdoors from which it is hard to escape.  Hovercraft parent
> contexts.

A context change involves specific pruning and grafting points, but the current 
syntax of the command can be ambiguous.

The grafting point is ambiguous if there multiple contexts with the same type 
and ID nearby (a vague statement betraying vague understanding).  I see that as 
a possibility, though the user’s option to choose context IDs seems to mitigate 
that problem.

The pruning point is ambiguous if the \change command is nested in more than 
one context of the given type.  This is the case in my situation where 
NullVoice is aliased to Staff, but I actually want to prune between the 
enclosing Staff and the NullVoice.

* * *

Now that I’ve said that, I’ve been able to work around my problem by creating a 
new kind of context to target (see below).  I haven’t tested it in a serious 
score yet.  I don’t much mind having to define a special context, but I do 
consider it ugly that the \change command must refer to a context outside 
Lilypond’s standard model.

Back to the bug: I appreciate that it’s not obvious what to do with 
Change_iterator, but is there anything obvious that could be done to NullVoice 
that (without defeating its purpose) would cause \change Staff to pass over it?

Regards,
— 
Dan

\version "2.19.58"

sopranoNotes = \fixed c' {
  c1 d e f
  \break
  \change TrueStaff = "S"
  g a b c'
}

\layout {
  \context {
\Staff
\name TrueStaff
  }
  \context {
\ChoirStaff
\accepts TrueStaff
  }
}

\new ChoirStaff \with {
  \RemoveEmptyStaves
  \override VerticalAxisGroup.remove-first = ##t
} <<

  \new TrueStaff = "S" \with {
instrumentName = "S"
shortInstrumentName = "S"
  } {
$(skip-of-length sopranoNotes)
  }

  \new TrueStaff = "SA" \with {
instrumentName = "SA"
shortInstrumentName = "SA"
  } <<
\new Voice { \sopranoNotes }
\new NullVoice = "soprano" { \sopranoNotes }
  >>

>>


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

Re: Change_iterator refuses to move a NullVoice into a Staff

[David Kastrup]

David Kastrup <d...@gnu.org> writes:

> Dan Eble <d...@faithful.be> writes:
>
>> %{
>> NullVoice is unlike a Voice in this respect: trying to move it to a
>> different Staff with \change fails with this warning:
>>
>> Change_iterator::process (): NullVoice = `soprano': 
>> cannot change `Staff' to `S': not changing to same context type: Staff
>>
>> Apart from the warning, this is inconvenient.  The NullVoice remaining
>> in the original staff keeps the original staff alive, demanding manual
>> work to make it disappear.
>>
>> The NullVoice context definition contains both of the following:
>>
>>   \alias "Staff"
>>   \alias "Voice"
>>
>> My knowledge of contexts is not extensive, but I suggest that the test
>> that \change applies is too simple.
>
> The test is
>
>   else if (it.get_outlet ()->is_alias (to_type))
> {
>   // No enclosing context was found because the iterator's immediate
>   // context is the kind that was sought.
>   /* We could change the current translator's id, but that would make
>  errors hard to catch.
>
>  last->translator_id_string () = get_change
>  ()->change_to_id_string (); */
>   result = _f ("not changing to same context type: %s", ly_symbol2string 
> (to_type).c_str ());
> }
>
> and that's indeed crapola.  What the test should do is check whether the
> current context type would be accepted into the hierarchy of the
> proposed parent.

Well, that's a bit too simplistic because there is no "current context
type".

For something like

\change StaffGroup = "what"

the change iterator looks at the current context hierarchy upwards until
it finds a "StaffGroup" as a parent.  The layer below that is the
context to move, and if it is significantly similar in specification to
the context that should be/become its parent, it might become hard to
move back and forth.

So it's likely a bit of work/thought to make sure one does not create
context trapdoors from which it is hard to escape.  Hovercraft parent
contexts.

-- 
David Kastrup

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[David Kastrup]

Dan Eble <d...@faithful.be> writes:

> %{
> NullVoice is unlike a Voice in this respect: trying to move it to a
> different Staff with \change fails with this warning:
>
> Change_iterator::process (): NullVoice = `soprano': 
> cannot change `Staff' to `S': not changing to same context type: Staff
>
> Apart from the warning, this is inconvenient.  The NullVoice remaining
> in the original staff keeps the original staff alive, demanding manual
> work to make it disappear.
>
> The NullVoice context definition contains both of the following:
>
>   \alias "Staff"
>   \alias "Voice"
>
> My knowledge of contexts is not extensive, but I suggest that the test
> that \change applies is too simple.

The test is

  else if (it.get_outlet ()->is_alias (to_type))
{
  // No enclosing context was found because the iterator's immediate
  // context is the kind that was sought.
  /* We could change the current translator's id, but that would make
 errors hard to catch.

 last->translator_id_string () = get_change
 ()->change_to_id_string (); */
  result = _f ("not changing to same context type: %s", ly_symbol2string 
(to_type).c_str ());
}

and that's indeed crapola.  What the test should do is check whether the
current context type would be accepted into the hierarchy of the
proposed parent.

A more rigid test would be to check whether the current context type
would be accepted by the parent directly.  But I'm not sure we should
rely on such knowledge as a user interface: there might be good reasons
for moving additional (mostly implicit) layers into the context
hierarchy without having to change the bulk of the music.

-- 
David Kastrup

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

On Apr 4, 2017, at 22:57, Colin Campbell <c...@shaw.ca> wrote:
> 
> 
> Staff "S" doesn't have a NullVoice defined. I modified your code as follows, 
> and it seems to do what you want, although you still get a warning because 
> the \changeStaff event happens in both a regular Voice and a NullVoice.b

Thank you for taking the time, but your suggestion is not what I’m looking for. 
 I do in fact want what you have observed, but working: both the Voice and the 
NullVoice, at the moment that \change Staff = “S” appears, should move from 
their current Staff to Staff “S”.
— 
Dan


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

Re: Change_iterator refuses to move a NullVoice into a Staff

[Colin Campbell]

On 2017-04-04 07:54 PM, Dan Eble wrote:

On Mar 25, 2017, at 14:34, Dan Eble <d...@faithful.be> wrote:

NullVoice is unlike a Voice in this respect: trying to move it to a
different Staff with \change fails with this warning:

Change_iterator::process (): NullVoice = `soprano':
cannot change `Staff' to `S': not changing to same context type: Staff




Staff "S" doesn't have a NullVoice defined. I modified your code as 
follows, and it seems to do what you want, although you still get a 
warning because the \changeStaff event happens in both a regular Voice 
and a NullVoice.b Perhaps others can take it further?


**

\version "2.19.54" %% just because it's what I'm using

sopranoNotes = \fixed c' {
  c1 d e f
  \break
  \change Staff = "S"
  g a b c'
}

\new ChoirStaff \with {
*% \RemoveEmptyStaves**
** % \override VerticalAxisGroup.remove-first = ##t*
} <<

  \new Staff = "S" \with {
instrumentName = "S"
shortInstrumentName = "S"
  }
*  \new NullVoice = "S" {*
$(skip-of-length sopranoNotes)
  }

  \new Staff = "SA" \with {
instrumentName = "SA"
shortInstrumentName = "SA"
  } <<
\new Voice { \sopranoNotes }
\new NullVoice = "soprano" { \sopranoNotes }
  >>

>>

*


HTH,

Colin

--
I think age is a very high price to pay for maturity.
-- Tom Stoppard
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

%{
NullVoice is unlike a Voice in this respect: trying to move it to a
different Staff with \change fails with this warning:

Change_iterator::process (): NullVoice = `soprano': 
cannot change `Staff' to `S': not changing to same context type: Staff

Apart from the warning, this is inconvenient.  The NullVoice remaining
in the original staff keeps the original staff alive, demanding manual
work to make it disappear.

The NullVoice context definition contains both of the following:

  \alias "Staff"
  \alias "Voice"

My knowledge of contexts is not extensive, but I suggest that the test
that \change applies is too simple.
%}

\version "2.19.54" %% just because it's what I'm using

sopranoNotes = \fixed c' {
  c1 d e f
  \break
  \change Staff = "S"
  g a b c'
}

\new ChoirStaff \with {
  \RemoveEmptyStaves
  \override VerticalAxisGroup.remove-first = ##t
} <<

  \new Staff = "S" \with {
instrumentName = "S"
shortInstrumentName = "S"
  } {
$(skip-of-length sopranoNotes)
  }

  \new Staff = "SA" \with {
instrumentName = "SA"
shortInstrumentName = "SA"
  } <<
\new Voice { \sopranoNotes }
\new NullVoice = "soprano" { \sopranoNotes }
  >>

>>


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

[Issue] Move \once action from iterators to listeners

[David Kastrup]

Issue: Move \once action from iterators to listeners
Type: Enhancement
Owner: d...@gnu.org
Patch: new
Summary:
Move \once action from iterators to listeners

This ends the dependency of the events generated for \once\unset and
\once\set on the current context (bad for recording and replaying events
like with the part combiner and quoted music).  It also implements
\once\revert and makes every \once\override and \once\revert impervious
to any other overrides and reverts that may happen at the same time.


Also contains commits (obviously making issue 4596 abandoned):

Issue 4596/6: Document \once \revert


Issue 4596/5: Regtest for \once \revert


Issue 4596/4: Let \displayLilyMusic heed \once \unset and \once \revert


Create ly:context-matched-pop-property


Add Grob_property_info::temporary_{override,revert} functions


Let nalist_to_alist accept temporary overrides/reverts



At the current point of time, some Midi properties (balance, pan and
others) are implemented via SetProperty events.  Those have not yet
been converted to deal with \once.  The disadvantage of this patch is
that all recipients of SetProperty/UnsetProperty/Override/Revert now
have to implement the "once" property themselves.  The advantage is
that at the time of recording events, the actual property values for
undoing the action are not reliably known and shifting the
implementation of \once to the listeners makes its behavior reliable.

As a side effect, it should be possible to revisit issue 4131 without
the principal shortcomings that stalled it.

Rietveld issue: 265180043 (https://codereview.appspot.com/265180043)

-- 
David Kastrup

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

Re: [Issue] Move \once action from iterators to listeners

[Simon Albrecht]

<https://sourceforge.net/p/testlilyissues/issues/4609/>
with 4596 reclassified
Thank you,
Simon

Am 15.09.2015 um 21:10 schrieb David Kastrup:

Issue: Move \once action from iterators to listeners
Type: Enhancement
Owner: d...@gnu.org
Patch: new
Summary:
Move \once action from iterators to listeners

This ends the dependency of the events generated for \once\unset and
\once\set on the current context (bad for recording and replaying events
like with the part combiner and quoted music).  It also implements
\once\revert and makes every \once\override and \once\revert impervious
to any other overrides and reverts that may happen at the same time.


Also contains commits (obviously making issue 4596 abandoned):

Issue 4596/6: Document \once \revert


Issue 4596/5: Regtest for \once \revert


Issue 4596/4: Let \displayLilyMusic heed \once \unset and \once \revert


Create ly:context-matched-pop-property


Add Grob_property_info::temporary_{override,revert} functions


Let nalist_to_alist accept temporary overrides/reverts



At the current point of time, some Midi properties (balance, pan and
others) are implemented via SetProperty events.  Those have not yet
been converted to deal with \once.  The disadvantage of this patch is
that all recipients of SetProperty/UnsetProperty/Override/Revert now
have to implement the "once" property themselves.  The advantage is
that at the time of recording events, the actual property values for
undoing the action are not reliably known and shifting the
implementation of \once to the listeners makes its behavior reliable.

As a side effect, it should be possible to revisit issue 4131 without
the principal shortcomings that stalled it.

Rietveld issue: 265180043 (https://codereview.appspot.com/265180043)




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

Re: Move?

[Ralph Palmer]

On Fri, Jul 10, 2015 at 7:59 AM, Federico Bruni f...@inventati.org wrote:

 Il giorno ven 10 lug 2015 alle 13:56, Ralph Palmer ralphbugl...@gmail.com
 ha scritto:

 What is the current status of the move away from Google Code? Do I have to
 learn a new system for reviewing emails and submitting issues? If so, I
 would like to get started as soon as possible.


 Hi Ralph

 I'm deploying Allura for the first time, so I have no idea how long it
 will take. Hopefully I'll have some time to work on it in the coming days.

 Anyway, I don't think that you will have much to learn, except for the
 different interface.


Thanks for the update, Federico.

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

Move?

[Ralph Palmer]

Greetings -

What is the current status of the move away from Google Code? Do I have to
learn a new system for reviewing emails and submitting issues? If so, I
would like to get started as soon as possible.

Once again : I'm amazed by and grateful for such a wonderful piece of
software!

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

Re: Move?

[Federico Bruni]

Il giorno ven 10 lug 2015 alle 13:56, Ralph Palmer 
ralphbugl...@gmail.com ha scritto:
What is the current status of the move away from Google Code? Do I 
have to
learn a new system for reviewing emails and submitting issues? If so, 
I

would like to get started as soon as possible.


Hi Ralph

I'm deploying Allura for the first time, so I have no idea how long it 
will take. Hopefully I'll have some time to work on it in the coming 
days.


Anyway, I don't think that you will have much to learn, except for the 
different interface.





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

Re: Issue 2176 in lilypond: Move auto-beaming before the engraving stage.

[lilypond]

Comment #1 on issue 2176 by d...@gnu.org: Move auto-beaming before the  
engraving stage.

http://code.google.com/p/lilypond/issues/detail?id=2176

I don't see that this is possible since beaming is timing-dependent, and  
the timing is reliably established only at engraving time.



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

Re: Issue 2176 in lilypond: Move auto-beaming before the engraving stage.

[lilypond]

Comment #2 on issue 2176 by mts...@gmail.com: Move auto-beaming before the  
engraving stage.

http://code.google.com/p/lilypond/issues/detail?id=2176

I have a series of functions I use for algorithmic composition that  
calculate timing info for a music stream.  The only thing that would screw  
this up is if the timing translator is moved out of the score context.


In fact, the timing translator can likely be rewritten as well and replaced  
by a function that takes a music stream and adds timing-related events.


In general, anything that falls into the category data accompanying a  
stream seems that it should be added to the stream before entering  
engravers.



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

Issue 2176 in lilypond: Move auto-beaming before the engraving stage.

[lilypond]

Status: Accepted
Owner: mts...@gmail.com
Labels: Type-Enhancement

New issue 2176 by mts...@gmail.com: Move auto-beaming before the engraving  
stage.

http://code.google.com/p/lilypond/issues/detail?id=2176

I've seen several problems come up with auto beaming over the past two  
years that could all be solved by running the music stream through a music  
function before hitting the engraver.  These problems stem from the fact  
that beams are announced at later timesteps than those at which they are  
created.


The good news is that there's already lots of good Scheme code in place -  
someone just has to nix the engraver and write a function that combs  
through music to populate it with beam events.



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

Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals

[lilypond]

Updates:
Status: Verified
Labels: -Patch-push

Comment #8 on issue 2005 by philehol...@gmail.com: scripts move  
unnecessarily away from accidentals

http://code.google.com/p/lilypond/issues/detail?id=2005

(No comment was entered for this change.)


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

Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals

[lilypond]

Updates:
Status: Fixed

Comment #7 on issue 2005 by mts...@gmail.com: scripts move unnecessarily  
away from accidentals

http://code.google.com/p/lilypond/issues/detail?id=2005

Pushed to dev/staging as 7358116188985b145e760497c847908ad98706c0.


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

Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals

[lilypond]

Updates:
Labels: -Patch-new Patch-review

Comment #4 on issue 2005 by pkx1...@gmail.com: scripts move unnecessarily  
away from accidentals

http://code.google.com/p/lilypond/issues/detail?id=2005

Passes Make but no reg test diffs show.

James


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

Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals

[lilypond]

Updates:
Labels: Patch-new

Comment #2 on issue 2005 by mts...@gmail.com: scripts move unnecessarily  
away from accidentals

http://code.google.com/p/lilypond/issues/detail?id=2005#c2

Fixes issue 2005 (too much script padding between certain scripts and  
accidental)


http://codereview.appspot.com/5328063


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

Re: Issue 2005 in lilypond: scripts move unnecessarily away from accidentals

[lilypond]

Updates:
Status: Started
Owner: mts...@gmail.com

Comment #3 on issue 2005 by pkx1...@gmail.com: scripts move unnecessarily  
away from accidentals

http://code.google.com/p/lilypond/issues/detail?id=2005

(No comment was entered for this change.)


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

Issue 2005 in lilypond: scripts move too far for accidentals

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Ugly Regression

New issue 2005 by k-ohara5...@oco.net: scripts move too far for accidentals
http://code.google.com/p/lilypond/issues/detail?id=2005

% since the fix f1bb461 for issue 1951
{b!-. b!--}

Attachments:
staccato.png  1.3 KB


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

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Updates:
Status: Verified

Comment #11 on issue 1353 by pnorcks: chordnames may move erratically on  
the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Looks good.


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Updates:
Status: Fixed
Owner: Carl.D.Sorensen
Labels: fixed_2_13_47

Comment #10 on issue 1353 by carl.d.s...@gmail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

I can see no problem with adding ChordNames to the contexts accepted by  
GrandStaff (although it is likely to be seldom used).  Then PianoStaff  
(which is likely to use chords relatively often) inherits ChordNames from  
GrandStaff.


This change is made in commit a104097f9687568053a85dcc5eb65abd27449ef2

Regtest is input/regression/chord-names-in-grand-staff.ly, and is in commit  
4c5a7b177c95eea78231aad923c6bd6b75f6ecb1







___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #8 on issue 1353 by pkx1...@hotmail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Is this a bug or 'expected' behaviour and if so, we perhaps need a doc  
update?


I don't know if this an @knownissue or a bug (in which case there is  
nothing to document) or if this should be an enhancement.


I'm open to suggestions either way


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #9 on issue 1353 by jameseli...@googlemail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

I don't know if an enhancement or bug is the proper method here, apparently  
ChordNames is included by default in:

• ChoirStaff
• StaffGroup
• Score

and it is not present in:
• PianoStaff
• GrandStaff

And, as far as I can tell, the erratic behavior is present for both. Is  
there any (dis)advantage to (not) having this context also available by  
default in these contexts?


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #6 on issue 1353 by byu9...@gmail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

So does this issue now become invalid, since the mistake is putting a  
ChordNames context in a context that doesn't accept it?


Or what exactly is the issue to be solved here?


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #3 on issue 1353 by jameseli...@googlemail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Adding ChordNames to PianoStaff looks like it solves the problem for me. I  
don't get the erratic output.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #4 on issue 1353 by pkx1...@hotmail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

No I don't have the issue anymore if I use this construct however the  
chords are above the top staff and no longer below the staff.


The behaviour is now completely different.

Ditto GrandStaff BTW.


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #5 on issue 1353 by n.puttock: chordnames may move erratically on  
the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353


however the chords are above the top staff and no longer below the staff.


That's correct for the snippet above since \chords is the first context  
inside the PianoStaff.  If you wanted it below, you'd place it after the  
second \new Staff.





___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #2 on issue 1353 by n.puttock: chordnames may move erratically on  
the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Do you still get the erratic behaviour if you allow ChordNames to be  
accepted by PianoStaff?


\layout {
  \context {
\PianoStaff
\accepts ChordNames
  }
}


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Defect Priority-High OpSys-OSX

New issue 1353 by jameseli...@googlemail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Compiling the following input on mac OSX 10.6 successively yields erratic  
output: the placement of the chord names changes on each compile.

\version 2.13.35

RH = \relative c'' {
\repeat unfold 30 { a8 a a a }
}

LH = {
   \clef bass
   \repeat unfold 30 { a8 a a a }
}

\score {
   \new PianoStaff
   
\chords { f1*5 bes :m }
\new Staff  \RH
\new Staff  \LH
   
}

The full terminal output is included here:
22:03:15 jamesbailey lilypond snippets:lilydev --png -o chords_compile_1  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `chords_compile_1.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed
22:03:57 jamesbailey lilypond snippets:lilydev --png -o chords_compile_2  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
programming error: insane spring min_distance requested, ignoring it
continuing, cross fingers
Layout output to `chords_compile_2.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed
22:04:12 jamesbailey lilypond snippets:lilydev --png -o chords_compile_3  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `chords_compile_3.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed
22:04:24 jamesbailey lilypond snippets:lilydev --png -o chords_compile_4  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `chords_compile_4.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed
22:04:32 jamesbailey lilypond snippets:lilydev --png -o chords_compile_5  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `chords_compile_5.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed
22:04:47 jamesbailey lilypond snippets:lilydev --png -o chords_compile_6  
chords.ly

GNU LilyPond 2.13.36
Processing `chords.ly'
Parsing...
Interpreting music... [8][16][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `chords_compile_6.ps'...
Converting to PNG...
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.


success: Compilation successfully completed


Attachments:
chords_compile_1.png  24.8 KB
chords_compile_2.png  24.8 KB
chords_compile_3.png  24.7 KB
chords_compile_4.png  24.8 KB
chords_compile_5.png  24.8 KB
chords_compile_6.png  24.8 KB


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1353 in lilypond: chordnames may move erratically on the page on OSX 10.6

[lilypond]

Comment #1 on issue 1353 by pkx1...@hotmail.com: chordnames may move  
erratically on the page on OSX 10.6

http://code.google.com/p/lilypond/issues/detail?id=1353

Note that this only occurs when using \new PianoStaff .. or \new  
GrandStaff ... All other staff-types or just using ... cause the  
chords to be above the staves (instead of below both) and then they do not  
jump about.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Bug? Vertical spacing algorithm changed? (lyrics move notes)

[Risto Vääräniemi]

Hi,

I just compiled a piece of music that I created earlier this summer
and I noticed that if I modify the minimum-Y-extent the lyric text
sometimes moves the following notes. I wonder if this is a deliberate
change or a bug?

The behaviour changed between 2.11.52 and 2.11.53.

I have attached two example images and the code (not very minimised
but hopefully understandable).

-Risto

%%
\version 2.11.48

one = \relative c'
{
  r4 a a a
}

two = \relative c' \new Voice = vTwo
{
  c2  c
}

words = \lyricmode
{
  Something...
}

\score
{
  
\new Staff = sOne { \one }

\new Staff = sTwo { \two }

\new Lyrics \with {alignAboveContext = sTwo}
  \lyricsto vTwo \words
  

  \layout
  {
\context
{
  \Lyrics
\override VerticalAxisGroup #'minimum-Y-extent =
  %#'(-0.75 . 2.0) %% default values give normal results
  #'(-0.5 . 0.5) %% custom values don't
}
  }
}
%%
attachment: lyrics_move_notes_52.pngattachment: lyrics_move_notes_53.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Phrasing Slurs don't move in polyphonic contexts.

[Erik Sandberg]

On Saturday 03 December 2005 11.56, Cameron Horsburgh wrote:
 The documentation in 6.6.1 Basic Polyphony states:

 quote
 The separator causes Voice contexts to be instantiated. They bear the
 names 1, 2, etc. In each of these contexts, vertical direction of
 slurs, stems, etc., is set appropriately.
 \quote

 However, this behaviour doesn't seem to apply for phrasing slurs. It seems
 I have to explicitly call \phrasingSlurUp/Down to get the desired
 behaviour.

This is now fixed.

-- 
Erik Sandberg
Maintainer of the Lilypond bug CVS archive,
http://savannah.gnu.org/cgi-bin/viewcvs/lilypond/lily-bugs/bugs/
http://lilypond.org/bugs/v2.7/


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Phrasing Slurs don't move in polyphonic contexts.

[Erik Sandberg]

On Saturday 03 December 2005 11.56, Cameron Horsburgh wrote:
 The documentation in 6.6.1 Basic Polyphony states:

 quote
 The separator causes Voice contexts to be instantiated. They bear the
 names 1, 2, etc. In each of these contexts, vertical direction of
 slurs, stems, etc., is set appropriately.
 \quote

 However, this behaviour doesn't seem to apply for phrasing slurs. It seems
 I have to explicitly call \phrasingSlurUp/Down to get the desired
 behaviour.

The following patch (to latest CVS) fixes this. However, I don't know about 
conventions: Should phrasing slurs always have the same direction as slurs in 
polyphonic situations?

RCS file: /cvsroot/lilypond/lilypond/scm/music-functions.scm,v
retrieving revision 1.156
diff -u -r1.156 music-functions.scm
--- scm/music-functions.scm 8 Nov 2005 14:46:20 -   1.156
+++ scm/music-functions.scm 5 Dec 2005 09:53:36 -
@@ -285,7 +285,7 @@
  'grob-property gprop))

 (define direction-polyphonic-grobs
-  '(Stem Tie Rest Slur Script TextScript Dots DotColumn Fingering))
+  '(Stem Tie Rest Slur PhrasingSlur Script TextScript Dots DotColumn 
Fingering))

 (define-safe-public (make-voice-props-set n)
   (make-sequential-music


-- 
Erik


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond