Re: -dbackend=eps clips lowest beam
On 15 Sep 2012, at 23:55, eluze wrote: > > Damian leGassick wrote >> >> Hi all >> >> If I run this with no arguments (or have a tagline) everything's fine >> if run the file with -dbackend=eps the bottom stem is clipped >> >> any clues? >> >> > > how do you open the eps file? I use IrfanView and have no problem! > > Eluze > > interesting... i get this with acrobat, illustrator and preview (mac): space_prob.pdf Description: Adobe PDF document I wonder whether it's a mac thing - or maybe ghostscript Damian ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ambitus-Bug
On Sat, Sep 15, 2012 at 07:26:55PM +0200, Knut Petersen wrote: > Have a look at the attached source and the png, the problem is obvious. > The first appearance dictates which of the two enharmonic equivalents is > chosen for the ambitus. Thanks for the report, Knut. You have encountered a known issue, please see: http://code.google.com/p/lilypond/issues/detail?id=762 Cheers, Colin. Bug squad -- Colin Hall ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: -dbackend=eps clips lowest beam
sorry, when I compiled I had inadvertently added a second score and then it worked. but this also is a clue: add a simple \markup " " at the end of your file and then it should not cut off the beams. I'll investigate later and send it to the bug list if needed! Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/dbackend-eps-clips-lowest-beam-tp133006p133022.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: -dbackend=eps clips lowest beam
> but this also is a clue: add a simple \markup " " at the end of your > file and then it should not cut off the beams. > > I'll investigate later and send it to the bug list if needed! http://code.google.com/p/lilypond/issues/detail?id=720 It would be good if some images could be added for reference. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: not so nice horizontal spacing
On Sat, Sep 15, 2012 at 10:21 AM, Stefan Thomas wrote: > Dear Robert, > thanks for Your proposals. > I think a dotted quarter rest isn't a good solution. > Musicians normally don't like them because they can easily be overlooked. > And there is no keysignature, it's so called "atonal" music. So, the only thing that can be done is to make accidental spacing tighter - see issue 2142 and friends. http://code.google.com/p/lilypond/issues/detail?id=2142 cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: RemoveEmptyStaffContext and merge rests snippet not co-operating
On Wed, Sep 05, 2012 at 01:17:35AM -0700, eluze wrote:
>
> Frank Steinmetzger wrote
> >
> >
> > While the empty staves get removed as expected, using this feature breaks
> > the
> > merge-rests code -- I get two rests above each other.
> >
>
> for me it works - can you provide an example?
OK, finally I found the time to deal with this. I found out that among the
things that \RemoveEmptyStaffContext changes are the settings that merge rests.
I attached a mini-example to demonstrate. In my normal setup I have a global
include file which pre-defines some layout stuff. It has a layout block which,
to enable merging of rests, contains:
\context {
\Staff
\override RestCollision #'positioning-done = #merge-rests-on-positioning
\override MultiMeasureRest #'Y-offset = #merge-multi-measure-rests-on-Y-offset
}
I simulated this in my attached example by having a \layout block at the top
of the file. The result is that, as soon as I add \RemoveEmptyStaffContext to
the score, the rests are no longer merged. I need to repeat the code from the
global \layout block in the score's \layout (*below* \RemoveEmptyStaffContext).
--
Gruß | Greetings | Qapla'
Please do not share anything from, with or about me with any Facebook service.
They say memory is the second thing to go. I forgot what the first thing was.
#(define (rest-score r)
(let ((score 0)
(yoff (ly:grob-property-data r 'Y-offset))
(sp (ly:grob-property-data r 'staff-position)))
(if (number? yoff)
(set! score (+ score 2))
(if (eq? yoff 'calculation-in-progress)
(set! score (- score 3
(and (number? sp)
(<= 0 2 sp)
(set! score (+ score 2))
(set! score (- score (abs (- 1 sp)
score))
#(define (merge-rests-on-positioning grob)
(let* ((can-merge #f)
(elts (ly:grob-object grob 'elements))
(num-elts (and (ly:grob-array? elts)
(ly:grob-array-length elts)))
(two-voice? (= num-elts 2)))
(if two-voice?
(let* ((v1-grob (ly:grob-array-ref elts 0))
(v2-grob (ly:grob-array-ref elts 1))
(v1-rest (ly:grob-object v1-grob 'rest))
(v2-rest (ly:grob-object v2-grob 'rest)))
(and
(ly:grob? v1-rest)
(ly:grob? v2-rest)
(let* ((v1-duration-log (ly:grob-property v1-rest 'duration-log))
(v2-duration-log (ly:grob-property v2-rest 'duration-log))
(v1-dot (ly:grob-object v1-rest 'dot))
(v2-dot (ly:grob-object v2-rest 'dot))
(v1-dot-count (and (ly:grob? v1-dot)
(ly:grob-property v1-dot 'dot-count -1)))
(v2-dot-count (and (ly:grob? v2-dot)
(ly:grob-property v2-dot 'dot-count -1
(set! can-merge
(and
(number? v1-duration-log)
(number? v2-duration-log)
(= v1-duration-log v2-duration-log)
(eq? v1-dot-count v2-dot-count)))
(if can-merge
;; keep the rest that looks best:
(let* ((keep-v1? (>= (rest-score v1-rest)
(rest-score v2-rest)))
(rest-to-keep (if keep-v1? v1-rest v2-rest))
(dot-to-kill (if keep-v1? v2-dot v1-dot)))
;; uncomment if you're curious of which rest was chosen:
;;(ly:grob-set-property! v1-rest 'color green)
;;(ly:grob-set-property! v2-rest 'color blue)
(ly:grob-suicide! (if keep-v1? v2-rest v1-rest))
(if (ly:grob? dot-to-kill)
(ly:grob-suicide! dot-to-kill))
(ly:grob-set-property! rest-to-keep 'direction 0)
(ly:rest::y-offset-callback rest-to-keep)))
(if can-merge
#t
(ly:rest-collision::calc-positioning-done grob
#(define merge-multi-measure-rest-on-Y-offset
;; Call this to get the 'Y-offset of a MultiMeasureRest.
;; It keeps track of other MultiMeasureRests in the same NonMusicalPaperColumn
;; and StaffSymbol. If two are found, make transparent one and return 1 for
Y-offset of
;; the other one.
(let ((table (make-weak-key-hash-table)))
(lambda (grob)
(let* ((ssymb (ly:grob-object grob 'staff-symbol))
(nmcol (ly:grob-parent grob X))
(ssymb-hash (begin
(if (not (hash-ref table ssymb))
(hash-set! table ssymb (make-hash-table 1)))
(hash-ref table ssymb)))
(othergrob (hash-ref ssymb-hash nmcol))
(measure-count (if (ly:grob? grob)
(ly:grob-property grob 'measure-count)
0)))
(if (ly:grob? othergrob)
(begin
;; Make merged rest transpa
Re: RemoveEmptyStaffContext and merge rests snippet not co-operating
2012/9/16 Frank Steinmetzger :
> On Wed, Sep 05, 2012 at 01:17:35AM -0700, eluze wrote:
>>
>> Frank Steinmetzger wrote
>> >
>> >
>> > While the empty staves get removed as expected, using this feature breaks
>> > the
>> > merge-rests code -- I get two rests above each other.
>> >
>>
>> for me it works - can you provide an example?
>
> OK, finally I found the time to deal with this. I found out that among the
> things that \RemoveEmptyStaffContext changes are the settings that merge
> rests.
>
> I attached a mini-example to demonstrate. In my normal setup I have a global
> include file which pre-defines some layout stuff. It has a layout block
> which,
> to enable merging of rests, contains:
>
> \context {
> \Staff
> \override RestCollision #'positioning-done = #merge-rests-on-positioning
> \override MultiMeasureRest #'Y-offset =
> #merge-multi-measure-rests-on-Y-offset
> }
>
> I simulated this in my attached example by having a \layout block at the top
> of the file. The result is that, as soon as I add \RemoveEmptyStaffContext to
> the score, the rests are no longer merged. I need to repeat the code from the
> global \layout block in the score's \layout (*below*
> \RemoveEmptyStaffContext).
> --
> Gruß | Greetings | Qapla'
> Please do not share anything from, with or about me with any Facebook service.
+1
> They say memory is the second thing to go. I forgot what the first thing was.
lol
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
Hi Frank,
\RemoveEmptyStaffContext is deprecated and you will not find any entry
about it in the NR of "2.14.2".
Well, for reasons of compatibility you'll find the old definitions in
engraver-init.ly, so I wonder why it doesn't work.
But if you switch to the new syntax:
\layout {
\context {
\Staff \RemoveEmptyStaves
}
}
it _will_ work.
Attached mwe-rev.ly only. 336.ily isn't changed.
HTH,
Harm
mwe-rev.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: RemoveEmptyStaffContext and merge rests snippet not co-operating
Thomas Morley writes:
>> \context {
>> \Staff
>> \override RestCollision #'positioning-done = #merge-rests-on-positioning
>> \override MultiMeasureRest #'Y-offset =
>> #merge-multi-measure-rests-on-Y-offset
>> }
>>
>> I simulated this in my attached example by having a \layout block at the top
>> of the file. The result is that, as soon as I add
>> \RemoveEmptyStaffContext to
>From ly/engraver-init.ly
%% Keep the old definitions in here for compatibility (they erase previous
%% settings to the corresponding context!).
%% For new scores, one should simply insert the \RemoveEmptyStaves settings
%% into the desired context. That's just as easy, requires only one line more
%% (the \*Staff), but preserves previous context mods.
%% TODO: DEPRECATED_2.13.17, remove at some point in the future
RemoveEmptyStaffContext = \context {
\Staff
\RemoveEmptyStaves
}
As you can see, RemoveEmptyStaffContext consists of a copy of \Staff
(made at the time ly/engraver-init.ly is loaded) with an additional
modification "\RemoveEmptyStaves". This is basically a changed copy of
\Staff kept under a different name. If you include this in a layout
definition, by virtue of having copied
\name "Staff"
from the original definition of \Staff, LilyPond will know that this is
intended for overwriting the definition of \Staff.
Any changes made previously to \Staff after the definition of
RemoveEmptyStaffContext will be gone. Broken by design, so it got
deprecated. Perhaps we are not doing people a favor keeping it around.
> \RemoveEmptyStaffContext is deprecated and you will not find any entry
> about it in the NR of "2.14.2".
> Well, for reasons of compatibility you'll find the old definitions in
> engraver-init.ly, so I wonder why it doesn't work.
See above.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
\bar ":"
Hi list, Is it possible to force an extra bar line in the form \bar ":" when inserted into a multi-stave score to only apply to one staff instead of the default where the dots are added to all staves? Many thanks, Peter -- //= -> Peter O'Doherty -> http://www.peterodoherty.net -> m...@peterodoherty.net -> https://joindiaspora.com/people/70716 //= ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: RemoveEmptyStaffContext and merge rests snippet not co-operating
On Sun, Sep 16, 2012 at 07:08:47PM +0200, David Kastrup wrote: > […] Any changes made previously to \Staff after the definition of > RemoveEmptyStaffContext will be gone. Broken by design, so it got > deprecated. Perhaps we are not doing people a favor keeping it around. Good to know, thank you. I’ll amend my templates right away... But the following stays the same, right? \context \Score \override VerticalAxisGroup #'remove-first = ##t PS.: Sorry David, again I forgot that in mutt I need a different key to reply to the list instead of the sender. -_- -- Gruß | Greetings | Qapla' Please do not share anything from, with or about me with any Facebook service. Three words to describe myself? Not good at maths. signature.asc Description: Digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: -dbackend=eps clips lowest beam
Werner LEMBERG wrote > > > http://code.google.com/p/lilypond/issues/detail?id=720 > I don't think it's the same bug > It would be good if some images could be added for reference. > here they are: http://lilypond.1069038.n5.nabble.com/file/n133040/png_snippet_with_changeStaff.ly png_snippet_with_changeStaff.ly the beams are cut off at top and bottom http://lilypond.1069038.n5.nabble.com/file/n133040/png_snippet_with_changeStaff.png --- works when \markup is added at top and bottom http://lilypond.1069038.n5.nabble.com/file/n133040/png_snippet_with_changeStaff-1.png --- the same pitches in a single staff: http://lilypond.1069038.n5.nabble.com/file/n133040/png_snippet_with_changeStaff-2.png Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/dbackend-eps-clips-lowest-beam-tp133006p133040.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \bar ":"
2012/9/16 Peter O'Doherty :
> Hi list,
>
> Is it possible to force an extra bar line in the form
>
> \bar ":"
>
> when inserted into a multi-stave score to only apply to one staff instead of
> the default where the dots are added to all staves?
>
> Many thanks,
> Peter
Hi Peter,
two possible methods:
(1) overriding BarLine glyph-name:
%% one %%%
musA = \relative c'' {
c1
\once \override Staff.BarLine #'glyph-name = #":"
d
\break
e f
}
musB = \relative c' {
c1 d
e
\once \override Score.SpanBar #'glyph-name = #"|"
\once \override Staff.BarLine #'glyph-name = #":"
f
}
\score {
\new StaffGroup <<
\new Staff
\musA
\new Staff
\musB
>>
}
%%% end of one %%
(2) moving "Timing_translator" and "Default_bar_line_engraver" from
Score- to Staff-level:
two %
musI = \relative c'' {
c1
\bar ":"
d
\break
e f
\break
g a
\bar ":|"
}
musII = \relative c' {
c1 d
e
\bar ":"
f
g a
\once \override Score.SpanBar #'glyph-name = #"|." \bar ":|"
}
\score {
\new StaffGroup <<
\new Staff
\musI
\new Staff
\musII
>>
\layout {
\context {
\Score
\remove "Timing_translator"
\remove "Default_bar_line_engraver"
\override SpanBar #'glyph-name = #"|"
}
\context {
\Staff
\consists "Timing_translator"
\consists "Default_bar_line_engraver"
}
}
}
%%% end of two %%
Sometimes you have to
\override Score.SpanBar #'glyph-name = ...
in both cases.
See also:
http://lilypond.org/doc/v2.17/Documentation/internals-big-page#default_005fbar_005fline_005fengraver
http://lsr.dsi.unimi.it/LSR/Item?id=344
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Bar check fail with pick-ups in repeats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why does the attached file fail?
Simplified:
c c c c | c c c |: c | c c c c | 1. c c c :| 2. c c c c | c c c c ||
It seems to me, according to what (I recall that) I learned throughout
school, that this is correct; and when unfolded, all the bar lines are
fine. So why does LilyPond complain about this? (Specifically, that
at the end of the first bar of the 2nd ending, the bar is 3/4 complete.)
It appears that the incomplete bar in the first alternative is
carrying over into the second, which is nonsensical.
I’ve tried playing around with various combinations of \partial, but
can’t seem to get anything to work right. Any suggestions would be
most welcome.
Thanks,
Chris
- --
Chris Maden, text nerd http://crism.maden.org/ >
LIVE FREE: vote for Gary Johnson, Libertarian for President.
http://garyjohnson2012.com/ > http://lp.org/ >
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9 A210 4A51 DBAC 5C5C 3D5E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQVpJsAAoJEEpR26xcXD1eLmsIANPwyh3pYsKhos2o0gjEZXQ1
Cw2zhz8JzGlAswYf4D4nEm3MA7IbHRolcGe/NFXZxi1ylKB8j2oz38lzlgLE7UrP
vsE0YE2mVUiTEyoQWKIUpSamg5dQZI5BKImdaN61PYrYeBRDTgW59Umv50QBtB1K
eXuSEFhmPOnNlUd8bAPibaB5+4/OO5FCYyGuL3xDuue2e265TkWKZXV9/w6+Ylqg
jq5rPTQKHp+wEWTiCJyTqzBz87db1NRCIx20LOlQb4199jNy9DSUIjYOtkw5JgWn
Qg1fP0IJyhhgkkAqfc5FwjQJJQ+kW2AQZIxm5jlKi8nFpWZseh+3/qQFshPF6Pg=
=0qmC
-END PGP SIGNATURE-
\version "2.12.3"
\new Staff <<
\time 4/4
\relative c' {
c c c c | c c c
\repeat volta 2 {
c | c c c c |
}
\alternative {
{
c c c
}
{
c c c c |
}
}
c c c c \bar ".|"
}
>>
barcheckfail.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bar check fail with pick-ups in repeats
On Sun, Sep 16, 2012 at 8:01 PM, Christopher R. Maden wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Why does the attached file fail?
>
> Simplified:
>
> c c c c | c c c |: c | c c c c | 1. c c c :| 2. c c c c | c c c c ||
>
> It seems to me, according to what (I recall that) I learned throughout
> school, that this is correct; and when unfolded, all the bar lines are
> fine. So why does LilyPond complain about this? (Specifically, that
> at the end of the first bar of the 2nd ending, the bar is 3/4 complete.)
>
> It appears that the incomplete bar in the first alternative is
> carrying over into the second, which is nonsensical.
>
> I’ve tried playing around with various combinations of \partial, but
> can’t seem to get anything to work right. Any suggestions would be
> most welcome.
>
> Thanks,
> Chris
Is this what you want?
\version "2.12.3"
\new Staff <<
\time 4/4
\relative c' {
c c c c | c c c
\repeat volta 2 {
c | c c c c |
}
\alternative {
{
\set Timing.measureLength = #(ly:make-moment 3 4)
c c c
}
{
\set Timing.measureLength = #(ly:make-moment 4 4)
c c c c |
}
}
c c c c \bar ".|"
}
>>
See
http://lilypond.org/doc/v2.16/Documentation/notation/long-repeats#normal-repeats
for more information.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bar check fail with pick-ups in repeats
Christopher R. Maden maden.org> writes: > It appears that the incomplete bar in the first alternative is > carrying over into the second, which is nonsensical. Yes. LilyPond counts beats straight through the repeats. Someday someone will volunteer the effort to improve that. Until then, you shorten a measure by hand as described in the manual, under "Long Repeats" or look up \alternative in the index. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom key signature at line break
On Tue, Sep 11, 2012 at 10:12 AM, Janne Uusitalo wrote: > On Sat, Sep 8, 2012 at 1:03 AM, Thomas Morley > wrote: > at the end of a line I'd change the order in which KeyCancellation and KeySignature appears. This requires some new settings in KeySignature > > Thanks for this suggestion. I applied your customBreak "as is" but to > little avail. (I can only detect a slight change in the alignment of > the clef following the line break.) My bad, I had a bunch of other staff stuff going on at the same time, including explicitKeySignatureVisibility set to #end-of-line-invisible in order to remove some extra spacing caused by hidden staves, etc. In short, there was nothing wrong with Harm's code nor LilyPond's standard behavior: the 'extra' sharp will not be omitted by default. Thanks for looking into it. Janne ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: -dbackend=eps clips lowest beam
>> http://code.google.com/p/lilypond/issues/detail?id=720 >> > I don't think it's the same bug Hmm. I see that the rendering of the documentation snippets has changed fundamentally because the code has been changed, hiding the deficiency. Compare this http://lilypond.org/doc/v2.14/Documentation/notation/displaying-pitches#automatic-accidentals with this: http://lilypond.org/doc/v2.16/Documentation/notation/displaying-pitches#automatic-accidentals If I compile the 2.14 snippet for the first image http://lilypond.org/doc/v2.14/Documentation/8f/lily-b2620bcb.ly with 2.17.1, I get the attached PDF file which shows the problem. Maybe a different bug, but certainly related. > the beams are cut off at top and bottom > http://lilypond.1069038.n5.nabble.com/file/n133040/png_snippet_with_changeStaff.png Ouch :-) Werner lily-b2620bcb.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
