RE: Apparent bug: Bracketed TupletNumber affected by Slur

2015-08-27 Thread Daniel Rosen 
Ah, whoops, I changed the code at the last moment before sending it but forgot 
to compile a new .png. Here's the actual output for the code I provided, but as 
you can see from the previous attachment, the issue persists when the durations 
are changed.

DR

From: Simon Albrecht [mailto:simon.albre...@mail.de]
Sent: Thursday, August 27, 2015 7:17 PM
To: Bug-Lilypond 
Cc: Daniel Rosen 
Subject: Re: Apparent bug: Bracketed TupletNumber affected by Slur

Hello Daniel,

only to be sure: does the image really correspond to the code? In the output, 
there are two crotchets, contrary to the three quavers in the code...

Yours, Simon
Am 28.08.2015 um 01:13 schrieb Ralph Palmer:
On Thu, Aug 27, 2015 at 7:10 PM, Ralph Palmer 
mailto:palmer.r.vio...@gmail.com>> wrote:

-- Forwarded message --
From: Daniel Rosen mailto:drose...@gmail.com>>
Date: Thu, Aug 27, 2015 at 5:24 PM
Subject: Apparent bug: Bracketed TupletNumber affected by Slur
To: "lilypond-user Mailing List 
(lilypond-u...@gnu.org)" 
mailto:lilypond-u...@gnu.org>>


The following code produces the attached output, with the TupletNumber way down 
inside the Slur even though there is no apparent reason for the avoid-slur 
property to matter at all-in other words, this code should produce the same 
output as if the \override were commented out. (The bug appears to manifest 
only when the Slur begins on the first note of the tuplet.)

Is this a bug? I can't seem to find anything like it in the bugs list archives.

\version "2.19.25"
\relative c'' {
  \tupletUp
  \override TupletNumber.avoid-slur = #'outside
  \tuplet 3/2 { b8( b b) }
}

DR

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

Thanks for the report, Daniel Rosen. I'm forwarding this to the LilyPond Bug 
list.

Ralph

My apologies to all - I should have copied Daniel Rosen and the LilyPond 
mailing list.

Ralph

--
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com




___

lilypond-user mailing list

lilypond-u...@gnu.org

https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Apparent bug: Bracketed TupletNumber affected by Slur

2015-08-27 Thread Simon Albrecht 

Hello Daniel,

only to be sure: does the image really correspond to the code? In the 
output, there are two crotchets, contrary to the three quavers in the code…


Yours, Simon

Am 28.08.2015 um 01:13 schrieb Ralph Palmer:
On Thu, Aug 27, 2015 at 7:10 PM, Ralph Palmer 
mailto:palmer.r.vio...@gmail.com>> wrote:



-- Forwarded message --
From: *Daniel Rosen* mailto:drose...@gmail.com>>
Date: Thu, Aug 27, 2015 at 5:24 PM
Subject: Apparent bug: Bracketed TupletNumber affected by Slur
To: "lilypond-user Mailing List (lilypond-u...@gnu.org
)" mailto:lilypond-u...@gnu.org>>


The following code produces the attached output, with the
TupletNumber way down inside the Slur even though there is no
apparent reason for the avoid-slur property to matter at all-in
other words, this code should produce the same output as if the
\override were commented out. (The bug appears to manifest only
when the Slur begins on the first note of the tuplet.)

Is this a bug? I can't seem to find anything like it in the bugs
list archives.

\version "2.19.25"
\relative c'' {
  \tupletUp
  \override TupletNumber.avoid-slur = #'outside
  \tuplet 3/2 { b8( b b) }
}

DR


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

Thanks for the report, Daniel Rosen. I'm forwarding this to the
LilyPond Bug list.

Ralph


My apologies to all - I should have copied Daniel Rosen and the 
LilyPond mailing list.


Ralph

--
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com 


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


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

Re: Apparent bug: Bracketed TupletNumber affected by Slur

2015-08-27 Thread Ralph Palmer 
On Thu, Aug 27, 2015 at 7:10 PM, Ralph Palmer 
wrote:

>
> -- Forwarded message --
> From: Daniel Rosen 
> Date: Thu, Aug 27, 2015 at 5:24 PM
> Subject: Apparent bug: Bracketed TupletNumber affected by Slur
> To: "lilypond-user Mailing List (lilypond-u...@gnu.org)" <
> lilypond-u...@gnu.org>
>
>
> The following code produces the attached output, with the TupletNumber way
> down inside the Slur even though there is no apparent reason for the
> avoid-slur property to matter at all-in other words, this code should
> produce the same output as if the \override were commented out. (The bug
> appears to manifest only when the Slur begins on the first note of the
> tuplet.)
>
> Is this a bug? I can't seem to find anything like it in the bugs list
> archives.
>
> \version "2.19.25"
> \relative c'' {
>   \tupletUp
>   \override TupletNumber.avoid-slur = #'outside
>   \tuplet 3/2 { b8( b b) }
> }
>
> DR
>
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> Thanks for the report, Daniel Rosen. I'm forwarding this to the LilyPond
> Bug list.
>
> Ralph
>

My apologies to all - I should have copied Daniel Rosen and the LilyPond
mailing list.

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fwd: Apparent bug: Bracketed TupletNumber affected by Slur

2015-08-27 Thread Ralph Palmer 
-- Forwarded message --
From: Daniel Rosen 
Date: Thu, Aug 27, 2015 at 5:24 PM
Subject: Apparent bug: Bracketed TupletNumber affected by Slur
To: "lilypond-user Mailing List (lilypond-u...@gnu.org)" <
lilypond-u...@gnu.org>


The following code produces the attached output, with the TupletNumber way
down inside the Slur even though there is no apparent reason for the
avoid-slur property to matter at all-in other words, this code should
produce the same output as if the \override were commented out. (The bug
appears to manifest only when the Slur begins on the first note of the
tuplet.)

Is this a bug? I can't seem to find anything like it in the bugs list
archives.

\version "2.19.25"
\relative c'' {
  \tupletUp
  \override TupletNumber.avoid-slur = #'outside
  \tuplet 3/2 { b8( b b) }
}

DR


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

Thanks for the report, Daniel Rosen. I'm forwarding this to the LilyPond
Bug list.

Ralph


-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue submission process?

2015-08-27 Thread James Lowe 
On 27/08/15 19:48, Simon Albrecht wrote:
> Am 27.08.2015 um 20:27 schrieb Ralph Palmer:
>> Greetings -
>> 
>> Is there a new "official" submission process and / or location
>> (web site)?
> Not yet.
>> 
>> If so, could someone please let me (us?) know?
>> 
>> If a new site is on the horizon, but not yet here, is there a
>> projected timeline?
> Yes. The information mainly went over ly-devel, see mainly this
> thread: 
> .
>>
>>
> 
Does anyone besides myself need some explanation / explication?
> Regarding current ‘interim’ policy: James has written about how to
> deal with patches, see 
> .
>
> 
And for bugs/issues there’s only my suggestion of doing it via the bug
> list using some ‘standard form’ for e-mail, which I have already
> been using. Seems it was unwise to have this as a second part in 
> 
>
> 
this post.
> It hasn’t been overly successful to introduce having the [ISSUE
> ] tag in every post in the relevant threads, but for lack of
> alternatives: we (the Bug Squad) will need to collect the
> information when the new tracker will be set up. That will be
> tedious, so let’s hope it’ll be soon :-)
> 
> Yours, Simon
> 
> ___ bug-lilypond
> mailing list bug-lilypond@gnu.org 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 

For issues with Patches that are being tested or in test, that have
not already had an issue associated with them, the reference will be
my Patches Email every 3 days. You can spot those entries as they
won't have an old Google Tracker included in the email I send out.

For issues *without* Patches that come in before the new system is
implemented, that is something more tricky, however I think if you
have 'NEW ISSUE' in the subject field with an appropriate summary
included with it, you will always have the archive to find those, if
there is a conversation then they will be at least threaded (mostly)
so everything will be in one place. It will be harder for 'users' to
keep track of them, but at the moment I am not sure what else we can
do to please everyone.

James




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

Re: New issue submission process?

2015-08-27 Thread Trevor Daniels 

Ralph Palmer wrote Thursday, August 27, 2015 7:27 PM

> Is there a new "official" submission process and / or location (web site)?

Not yet.  During this hiatus any new bug created or any comment added will have 
to be redone once the new Allura tracker is available, if they are to be 
integrated into the tracker database. 

> If a new site is on the horizon, but not yet here, is there a projected
> timeline?

The interim Allura site at SourceForge should be available this weekend.  That 
will enable the bug squad and James to bring the tracker up to date and 
maintain it by entering the backlog by interrogating the mailing lists or their 
own records.  I've asked developers to go easy on changes which affect the 
tracker as this will be quite onerous.  I'll send out details for doing this as 
soon as its available.

Most developers and users will not need write access to this interim 
implementation at SourceForge as the intention is to quickly move the tracker 
to its permanent home at Savannah.  Unfortunately this is not yet ready.  It's 
difficult to guess how long this will take, but if it's more than a week we'll 
need to rethink whether to ask all developers to use the SF implementation.  
Maintaining it by proxy cannot go on for long.

> Does anyone besides myself need some explanation / explication?

I've sent a few mails to the dev list.  Apologies for not copying the bug list.
 
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue submission process?

2015-08-27 Thread Simon Albrecht 

Am 27.08.2015 um 20:27 schrieb Ralph Palmer:

Greetings -

Is there a new "official" submission process and / or location (web site)?

Not yet.


If so, could someone please let me (us?) know?

If a new site is on the horizon, but not yet here, is there a projected
timeline?
Yes. The information mainly went over ly-devel, see mainly this thread: 
.


Does anyone besides myself need some explanation / explication?

Regarding current ‘interim’ policy:
James has written about how to deal with patches, see 
.
And for bugs/issues there’s only my suggestion of doing it via the bug 
list using some ‘standard form’ for e-mail, which I have already been 
using. Seems it was unwise to have this as a second part in 
 
this post.
It hasn’t been overly successful to introduce having the [ISSUE ] 
tag in every post in the relevant threads, but for lack of alternatives: 
we (the Bug Squad) will need to collect the information when the new 
tracker will be set up. That will be tedious, so let’s hope it’ll be 
soon :-)


Yours, Simon

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

New issue submission process?

2015-08-27 Thread Ralph Palmer 
Greetings -

Is there a new "official" submission process and / or location (web site)?

If so, could someone please let me (us?) know?

If a new site is on the horizon, but not yet here, is there a projected
timeline?

Does anyone besides myself need some explanation / explication?

I appreciate your time and attention,

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

[ISSUE 4579] Document tweaking of StaffSymbol and LedgerLineSpanner

2015-08-27 Thread Simon Albrecht 

ID: 4579
STATUS: New
SUMMARY: Document tweaking of StaffSymbol and LedgerLineSpanner
TYPE: Documentation
LABELS:
OWNER:

%%% start message body %%


It regularly causes confusion that individual ledger line stacks can’t 
simply be tweaked. I think this should be documented better, but it 
isn’t easy to find the right place for that. I’d suggest the following:


In LM 4.1.2 
, 
at the end of the fourth paragraph, (i.e. in 
Documentation/learning/tweaks.itely, at the end of line 108) insert
"Spanners cannot be tweaked after their creation. This includes 
@code{StaffSymbol} and @code{LedgerLineSpanner}, which both continue 
throughout the score except if they are terminated by @code{\stopStaff} 
and newly created using @code{\startStaff}."


Although perhaps the last half-sentence should be replaced by a 
reference to a more detailed explanation (necessary anyway), e.g. in NR 
5.3.1 
 
(or elsewhere in 5.3).


Another theoretical possibility, which I would deem most helpful to 
users who encounter the problem, would be a remark at the top of the IR 
page for LedgerLineSpanner. But unfortunately (?) that would require 
major changes in the build system, IIUC.


Should we mark this BLOCKEDON: 3949?

Thanks, Simon

PS. I know that I should learn how to come up with formatted patches ASAP…

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

[ISSUE 4578] Regtest "dynamics-broken-hairpin.ly"

2015-08-27 Thread Simon Albrecht 

ID: 4578
STATUS: Accepted
SUMMARY: Regtest "dynamics-broken-hairpin.ly" is self-contradictory
TYPE: Maintainability
LABELS:
OWNER:

%%% start message body %%



The regtest "dynamics-broken-hairpin.ly" has some contradictions within itself.
The description says:

\header{
texidoc = "Broken crescendi should be open on one side."
}

but the code reads

\relative {
   c''1 \< \break c1\!  \> \break c1\!
}

so each hairpin actually ends before line break and there are no broken
hairpins.

To match the regtest title, the code should read

\relative {
   c''1 \< \break
   c
   c\> \break
   c
   c\!
}

(output attached)
– but then the ‘€˜inner’€™ broken parts are open to both sides, as they should 
be. So this should be described as

\header {
  texidoc = "When a hairpin is broken, the broken parts should be open at the 
‘breaking point’."
}

So, whatever this regtest was designed for, either it needs a clearer
description matching its original intent or different code with a new 
description.

Best regards, Simon





dynamics-broken-hairpin.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond