Re: Fwd: Point and Click on BreathingSign gives 0 for line, char, col
Hello,
On 12 October 2012 23:55, David Kastrup wrote:
> Richard Shann writes:
>
>> Hi,
>> Thanks for the response.
>> With junk.ly consisting of exactly
>> { c' c'\breathe c' c' }
>> then
>>
>> lilypond junk.ly
>>
>> creates a file junk.pdf with no point and click for the breathing sign.
>> The version is
>> lilypond --version
>> GNU LilyPond 2.12.3
>
> Uh, the current stable version is 2.16, and the previous stable version,
> 2.14, was already released in June last year. Please try checking your
> problems with the latest stable version in future before reporting them:
> any fix we make can only ever affect versions in the future, not in the
> past. Let me take this opportunity to assure you that upgrading to
> 2.16.0 is really a large step forward in usability.
>
and don't forget to use convert-ly (just in case)!
http://lilypond.org/doc/v2.16/Documentation/usage-big-page#updating-files-with-convert_002dly
The spacing algorithms are much, much better now, it's worth it just
for that alone :)
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fwd: Point and Click on BreathingSign gives 0 for line, char, col
Richard Shann writes: > GNU LilyPond 2.12.3 > I cut the file down, and the difference is whether the music is inline > or in a definition, This file gives the 0:0:0 location I might have mentioned it already: reporting bugs for seriously outdated versions is not likely to be useful. All of your examples work correctly in 2.16. There is _nothing_ we can fix because everything _has_ already been fixed. We can't magically make the version you use exhibit the fixed 2.16 behavior. But you can. By installing and using LilyPond 2.16.0. Check out the download pages on http://lilypond.org>. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond and distribution bugtrackers [was: LSR is not at the stable release level]
Graham Percival writes: > On Wed, Oct 03, 2012 at 11:56:37PM +0200, Joseph Rushton Wakeling wrote: >> On 10/03/2012 10:36 PM, Graham Percival wrote: >> >We are not going to sign up bug-lilypond to receive notices >> >automatically. Most reports will not be useful, and they will >> >screw up the automatic tools we use to keep track of whether >> >reports have been dealt with or not. >> >> I also don't think that the volume is ever going to be large enough >> to be problematic. If it _is_, then you have a different problem -- >> large numbers of bug reports that are not getting where they need >> to. > > ok, so you won't mind volunteering to take care of this with your > personal email account. > >> >If you think those notices are worthwhile, then *you* sign up to >> >receive them, and send any good bug reports to bug-lilypond. >> >> If I do this, and they _do_ prove useful, will you reconsider the >> option of automated tracking? > > No. I have thought for a long time about whether I should comment on this. It is hard to argue with success, and Joseph did volunteer to get more involved with the bug squad in response to this posting. > You're being inconsistent. At some point, any bug report needs to > be evaluated by a human. We have enough problems finding humans > to look at the dedicated, high-quality bug reports sent to > bug-lilypond. If you don't think that looking for more bug > reports will be a lot of work, then go ahead and do it yourself. > If you *do* think that looking for bug reports will be a lot of > work, then stop trying to foist that off onto other people. I don't consider it really all that obvious not to monitor low-volume channels with possibly relevant information. However, it _does_ make sense if the monitoring is done by actual human volunteers. They can provide consistent feedback about _what_ to report upstream. They can refer users to our upstream mailing lists when their problems are better dealt with there. And, for better and worse, the _most_ important relevant information is something that we won't notice by redirecting distribution mailing lists. It is the _absence_ of people reporting the availability of new stable upstream versions, the _absence_ of announcements that upstream versions have been dealt with, the _absence_ of relevant replies to previous problem reports. For supporting a particular distribution, those non-messages are important to notice, and we won't notice them when redirecting non-traffic on our standard lists. For that, we really need people who feel responsible for actively monitoring LilyPond on a particular distribution. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Stems in TabStaff are not removed when manual beaming is used
As you can see in the attached image, the pull-off sign (slur in
TabStaff) is moved up when using manual beaming.
It looks like Stems in default TabStaff are just made transparent when
using manual beams. Maybe the stem stencil should be set to false also
in this case.
The problem occurs on 2.14.2, 2.16.0 and latest build from git master.
\version "2.17.5"
first = \relative c' {
%% Stems in TabStaff are not removed when manual beaming is used
e8 b g g' fis( e) d b % automatic beaming
e8[ b g] g'[ fis( e)] d b % manual beaming
%% behind the scenes...
\tabFullNotation
e8 b g g' fis( e) d b % automatic beaming
e8[ b g] g'[ fis( e)] d b % manual beaming
}
second = \relative c {
s1
}
\score {
\new StaffGroup <<
\new Staff <<
\context Voice = "first voice" { \clef "G_8" \voiceOne \first }
\context Voice = "second voice" { \clef "G_8" \voiceTwo \second }
>>
\new TabStaff <<
%\tabFullNotation
\context TabVoice = "tab first voice" { \clef "moderntab"
\voiceOne \first }
\context TabVoice = "tab second voice" { \clef "moderntab"
\voiceTwo \second }
>>
>>
}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Stems in TabStaff are not removed when manual beaming is used
Am 13.10.2012 19:43, schrieb Federico Bruni:
As you can see in the attached image, the pull-off sign (slur in
TabStaff) is moved up when using manual beaming.
It looks like Stems in default TabStaff are just made transparent when
using manual beams. Maybe the stem stencil should be set to false also
in this case.
A bit of investigating shows that
\override Beam #'beamed-stem-shorten = #'(0 0 0)
(and of course a \revert in tabFullNotation) solves the misplaced slur,
but yield in the error message
"No viable beam quanting found. Using unquanted y value."
So this is considered a temporary hack.
The problem occurs on 2.14.2, 2.16.0 and latest build from git master.
\version "2.17.5"
first = \relative c' {
%% Stems in TabStaff are not removed when manual beaming is used
e8 b g g' fis( e) d b % automatic beaming
e8[ b g] g'[ fis( e)] d b % manual beaming
%% behind the scenes...
\tabFullNotation
e8 b g g' fis( e) d b % automatic beaming
e8[ b g] g'[ fis( e)] d b % manual beaming
}
second = \relative c {
s1
}
\score {
\new StaffGroup <<
\new Staff <<
\context Voice = "first voice" { \clef "G_8" \voiceOne \first }
\context Voice = "second voice" { \clef "G_8" \voiceTwo \second }
>>
\new TabStaff <<
%\tabFullNotation
\context TabVoice = "tab first voice" { \clef "moderntab"
\voiceOne \first }
\context TabVoice = "tab second voice" { \clef "moderntab"
\voiceTwo \second }
>>
>>
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
