It seems that \skip1,
_, and "" all have subtle differences which the documentation doesn't make
sufficiently clear...
Below is the mail that summarised these findings.
Paul
From: Michael Werner
To: Paul Hodges
Cc:
Sent: 04/12/2023 12:37
Subject: Re: Centering a word before
Replace the \skip 4 with "", as in:
%
\version "2.25.0"
{ c' (d') e' f' }
\addlyrics { foo __ "" bar }
%
Paul
From: Michael Käppler via bug-lilypond
Hi all,
please consider the following example:
\vers
This is an artefact of some poorer PDF viewers; your example shows perfectly in
Acrobat. Sadly, I see the effect often in Frescobaldi (on Windows) when not
zoomed in, but have got used to it - zooming in always shows that the
postscript is correct.
Paul
From: John F. Gibson
Gould illustrates this happening for beamed quavers (page 64), but doesn't
address this exact case of crotchets that I can find.
Paul
From: Simon Albrecht
To: Lilypond bug list
Sent: 28/02/2023 11:41
Subject: Melody_engraver and tied notes
Hello everyone
Actually, the time signature should be 3/4.
Paul
From: Silvain Dupertuis
To:
Sent: 16/12/2022 13:30
Subject: Minor correction on documentation
Maybe I should send this note on documentation to another mail, but I did not
find which one.
I just notice that on this example
ping in many cases.
You must write c2 to reset the duration.
HTH
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Is this not you want:
\version "2.22.2"
{
\time 3/4
\partial 4*2 % defines bar as holding two crotchets
f'4 f' |
\time 2/4
R2 |
R2 |
}
Paul
From: Ole V. Villumsen via bug-lilypond
To: "bug-lilypond@gnu.org"
Sent: 28/10/2022 10:52
Subj
There are only two crotchets between your 3/4 signature and your 2/4 signature
- what do you expect to happen?
Paul
From: Ole V. Villumsen via bug-lilypond
To: "bug-lilypond@gnu.org"
Sent: 28/10/2022 10:52
Subject: Full bar rest printed incorrectly after time
(and in the past earlier versions), and have never
encountered the problem you describe.
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
be of benefit elsewhere, as I have many places that the bracket's RH
edge merges with the barline, for instance, which may be a logical consequence
of \set tupletFullLength = ##t, but is sadly ugly as a result.
Paul
From: Thomas Morley
> Does adding
> \set tupletFullLengthNote
was able to remove
that from the example.
Paul
From: Thomas Scharkowski
Why do you use tupletFullLength = ##t here?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
for now with a hacky workaround (I reduce the length of the item
before the clef and put a tiny spacer rest after it), but obviously I'd rather
not do that in general.
Paul
Triplet Error.pdf
Description: Adobe PDF document
Triplet Error.ly
Description: Binary data
Thanks, that clarifies things and simplifies them as well. It seemed
surprising to me that this could be wrong.
Paul
On 14/09/2021 11:03:01, "Jean Abou Samra" wrote:
>
>This is expected. \crossStaff is meant to be used
>only in the voices that should have their stems
&
er versions of LilyPond at LilyBin.
Regards,
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
to specify and use #
instead of \ for these procedures.
Regards,
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
s is Bartók, who was famously meticulous in his notation; note how he
elides acciaccatura slurs with slurs over the following notes when he
wants them.
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Double Oops!! The first quote mark is the correct one - omit the one at
the end (though in fact Windows tolerates it, which is how it got in
there unnoticed).
Paul
On 22/09/2019 15:50:55, "Paul Hodges" wrote:
>Oops! Omit the quote mark in the middle of my statement after
Oops! Omit the quote mark in the middle of my statement after .py.
Paul
On 22/09/2019 11:57:06, "Paul Hodges" wrote:
>Thanks very much for this!
>
>I couldn't work out how your suggested changes can be applied in a
>Windows installation, so instead I did the following:
erfectly for me, and is a significant improvement to
Lilypond for my usage!
Regards,
Paul Hodges
On 14/07/2019 21:59:41, "Knut Petersen"
wrote:
>Hi Gilberto!
>>>Try if replacing
>>>
>>> musicxml ...
>>>
>>>with
>>>
>>> python
.
>programming error: mis-predicted force, 108.120472 ~= 110.892885
>
I get that from time to time as well; I associate it with tricky beam
positioning which is on the edge of OK.
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lis
"\oneVoice" and "\voiceOne",
"\voiceTwo" etc commands, and maybe the staff property: "\consists
"Merge_rests_engraver"". It took me a while, not because the
documentation is lacking, but because it took me a while to realise that
the fa
the length of the piece, only adding local voices occasionally
when called for. Writing like this the problem doesn't appear.
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
on any XML generated
by Sibelius 7.5 (the version I have) or MuseScore (current). In both cases, I
can read them into Dorico which can then rewrite them in a way that the
Lilypond converter reads successfully.
Paul
From: Victor Rouanet
To:
Sent: 24/08/2018 10:33 AM
Subject
f the slight inconsistency in behaviour,
the error returned first time was 255, and subsequently it was
-1073741819.
Paul
--
Paul Hodges
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
etter things to be spending time on.
Paul
--
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
the fault did not return with the
same change... (I recall that being a characteristic when I first hit
the issue).
So we have a problem which is (1) history dependent, and (2) it seems,
Windows only. I even wonder now wonder if the problem is as deep as a
Python for Windows issue.
Paul
--
Pa
- but I'm happy to cooperate in any way I can (remember, I have a
lifetime of computer experience, though no specific knowledge of the
languages in use here).
Anyway, I'll try to find a smaller change that changes the behaviour,
and if possible two or three.
a single character change which turns the
issue on and off... (but I'm cooking now, and will be out all day
tomorrow).
My computer has 16GB of main memory, so is not short (indeed it had
32GB when this first came up).
Paul
--
Paul
___
bug-lilypon
PS - The group of commented lines near the end are the version I
changed it to for successful compilation; the three following lines are
the version I restored to bring back the fault.
Paul
--
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
r a system reboot, but I can't be
completely certain. It did make me wonder about some memory management
issue being involved, though (but I suppose that's pretty obvious
anyway).
Paul
--
Paul Hodges
___
bug-lilypond mailing list
bug-lilypond@gnu.o
--On 05 May 2018 16:02 +0200 David Kastrup <d...@gnu.org> wrote:
> Which operating system and LilyPond version?
Windows 10; Lilypond 2.19.28 at the time I was having trouble.
Paul
--
Paul Hodges
___
bug-lilypond mailing list
bug-lilypon
bug (which I'd worked
around by making tiny changes) - but my example brings it up in only 5k
characters (<50 bars of music).
Paul
--
Paul Hodges
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
to know this wonderful program well enough to
contribute to a fix, I just thank those who have made it and continue
to maintain and enhance it!
Paul
--
Paul Hodges
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Ah, the perils of recursion! (says an aged programmer)
Paul
From: Simon Albrecht <simon.albre...@mail.de>
To: Lilypond bug list <bug-lilypond@gnu.org>
Sent: 06/04/2018 11:48 PM
Subject: Long compile times with many empty bars
Hello everybody,
I was a b
on the documentation page (which I also get at home
with 2.19.80) does not match the result on the corresponding page for
2.18, and is clearly wrong.
I cannot find any documentation suggesting that the usage should have
changed.
Regards,
Paul
--
Paul Hodges
shown on the documentation page (which I also get at home with
2.19.80) does not match the result on the corresponding page for 2.18, and is
clearly wrong.
I cannot find any documentation suggesting that the usage should have changed.
Regards,
Paul
Hi all,
I found an inconsistency in SVG output vs PDF output. Took me awhile to
figure out what was adding the unwanted spacing to the SVG. (I've used
"title" for the example but the story is the same for "composer" etc.)
Thanks,
-Paul
\version "2.19.52"
thanks!
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
be
nice to have point-and-click for clefs, but I can't claim to understand
the larger implementation implications one way or another.
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
t accidental in one part which didn't show and
a note later in the bar had a missing accidental as the result of this.
Although that could be patched with a "!", it was clear something was
wrong, but there was no clue to help with finding it.
> I'm not top posting.
% Note heads in different voices are combined
% even though they have different accidentals
\version "2.19.42"
\language "english"
<<
{ g'4 gs'4 }
\\
{ gs'4 g'4 }
>>
Result: https://cassland.org/images/PWH-wrongly-combined-noteheads.png
rrent serif style is the path of least resistance, of course.)
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
bout the
> alias part - but of course that doesn't mean it cannot be an enhancement.
Ok, I'd still say it’s a regression since 2.18 produces svg files that better
reflect user input than 2.19, but I’ll take an enhancement. :-)
Thanks,
-Paul
___
bug-lil
rif” is the better default. Or we could specify both a specific font
and a generic fallback like "TeX Gyre Schola, serif”. That’s an option with
the svg font-family property.)
So this seems like a regression to me, or at least a good feature request.
-Paul
; }
Looks good! Nice to have a workaround for this until the font itself is
adjusted (assuming it will be).
Cheers,
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
> On Feb 13, 2016, at 4:05 PM, Urs Liska <u...@openlilylib.org> wrote:
>
> would it be possible to (optionally) export text fonts as outlines in the SVG?
This would be a nice option to have at some point, but I can’t speak to
feasibility / amount of effort e
lines? i.e. with
\override NoteHead.color = #blue
Thanks,
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ve sans-serif text in inkscape and the
frescobaldi svg viewer.
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
“LilyPond Sans Serif” and “LilyPond Serif” are aliases. So it
appears that the code that produces the svgs is including the alias names for
“font-family" rather than what the alias refers to (e.g. “sans-serif” or
"Century Schoolbook L”).
-Paul
__
scaling of 250/276 should make the solid notes equal to
one staff-space. (Or should it be 275/276 to make it the "distance between the
bottom of a staff line to the top of the next staff line up”?)
-Paul
\version "2.19.36"
example = \relative {
c' d e f g a b c
}
{
\example
}
d note find any direct procedure to get the 'default style
> ( '() do not work):
Well, I was only intending that code for testing purposes. Looks like you’ve
got a good start on something for actual use.
Cheers,
-Paul
___
bug-lilypond mailing list
don't have English Windows,
> > but perhaps, current directory settings in English Windows is
> > ``Start in'' in shortcut properties.
> >
> Thanks Hosoda-san.
>
> Paul if you could verify this, and it is the case as described here, we
> can then perhaps make some adjustments t
tisimst gmail.com> writes:
>
> Paul,
>
> The very first time compiling any .ly file should take longer because LP
> creates a font cache (note that this also applies whenever you change the
> contents of the system font directory). After that you should notice
> &qu
to verify the test.ly procedure, mistaken in thinking
that it actually initiates the software, rather than initiating me. Things
went a lot better when I started ignoring it.
I also felt the test.ly took a long time to generate, but that was more
likely the result of repeated restarts and system house-keep
Hi Federico,
> On Dec 1, 2015, at 10:56 AM, Federico Bruni <f...@inventati.org> wrote:
>
> Thanks for the reminder. I probably forgot it when working on this:
> https://github.com/fedelibre/LilyDev/pull/4
>
> I'll add it tomorrow
Tha
o say:
If this is not the case you can easily turn it on by adding the following
line in ~/.bashrc:
# add lily-git to the PATH
PATH=$LILYPOND_GIT/scripts/auxiliar:"${PATH}"
This worked fine, but it would be better not to have to take this extra step,
for those using lily
;>
(example from 2.18 notation reference)
However, font-shape is no longer listed as an interface for LyricText and
this instruction appears to be ignored. If it's been removed intentionally,
is there a replacement or workaround?
Thanks,
Paul
_
> On Oct 18, 2015, at 4:21 AM, David Kastrup <d...@gnu.org> wrote:
>
> It does a "\temporary \override". Well spotted.
Thanks for clarifying that and for pointing out the other similar updates that
are needed. Improving the doc strings would defini
The docs appear to be inconsistent about ly:context-pushpop-property. Does it
do a \temporary \override or just an \override ?
-Paul
_
ly:context-pushpop-property
do a \temporary \override or a \revert on a grob property
http://www.lilypond.org/doc/v2.19/Documentation
This is a nice addition! I'm not opposed to StaffAxis either, but here's
another suggestion to consider: StaffRow.
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
variable in LilyDev
- edit the script to use LILYPOND_BUILD_DIR
See message below for more details.
Thanks,
-Paul
Begin forwarded message:
From: David Kastrup d...@gnu.org
Subject: Re: add stencil-whiteout-outline function (issue 236480043 by
paulwmor...@gmail.com)
Date: June 2, 2015
-get or the synaptic package manager. The oldest version
available from the astyle website is 2.03 [2].
Possible solutions: install astyle 2.02 in LilyDev by default, or revise
fixcc.py so it works with astyle 2.01.
-Paul
[0] http://lilypond.org/doc/v2.19/Documentation/contributor/lilydev
http
:
REQUIRED_ASTYLE_VERSION = Artistic Style Version 2.02
Should I simply edit that to say 2.04 ? Can we assume that it will still
work as expected with the newer version?
Thanks,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/fixcc-py-and-astyle-dependency-problem
Colin Campbell-8 wrote
Done, Paul:
Issue 4326
lt;https://code.google.com/p/lilypond/issues/detail?id=4326gt;:
Enhancement: simplify accepting a new custom context like an existing
context
Thanks Colin!
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Make
:
Enhancement: simplify accepting a new custom context like an existing
context
and then just a link to this discussion thread would suffice, especially the
message with David's proof of concept code here:
http://lists.gnu.org/archive/html/bug-lilypond/2015-03/msg00022.html
Thanks,
-Paul
--
View
by the translators all will
be well. (I don't think we need a tracker issue for this? But I leave that
up to the bug squad.)
Cheers,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/LP-website-right-column-has-strange-look-in-other-langage-than-english-tp173117p173119.html
\override NoteHead.color = #blue
\context {
\Voice
\name myOtherVoice
\alias Voice
\override NoteHead.color = #green
}
}
}
Nice! That solves that.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Make-defining-new
is
needed.
\score {
\new myVoice { c' d' e' f' }
\accept-like Voice myVoice \layout {
\context {
\Voice
\name myVoice
\alias Voice
\override NoteHead.color = #blue
}
}
}
So it's probably best to just recommend that as the way to do it in all
cases.
-Paul
\alias Voice
\override NoteHead.color = #blue
}
\context {
\Voice
\name myOtherVoice
\alias Voice
\override NoteHead.color = #green
}
}
}
That's less elegant as the user has to switch into scheme to supply the
first argument.
-Paul
--
View
, where would this go in the code base? If you like I can work up a
patch with documentation for the manuals, but I don't know what file to add
it to.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Make-defining-new-contexts-simpler-with-better-alias-functionality
.”
Paul Morris:
Most of the time if we want commands that work in X to work in Y (by using
\alias X), we also want Y to be accepted wherever X is accepted.
So when Z is determining whether to accept a new context Y... have it first
check Y's name, and if the name is unknown (not in its accepts
Paul Morris wrote
(The only possible down side I see is that users may find it strange to
supply an output definition as a function argument, but I don't know of a
way around that.)
Well, here's one possible way.
-Paul
\version 2.19.16
accept-like =
#(define-scheme-function (parser location
In the docs, update dependency info from guile “(1.8.2 or newer)” to just
“(1.8.2)” until guile 2.0 support is stable. As reported on the user list here:
http://lilypond.1069038.n5.nabble.com/Kubuntu-GCC-compile-with-guile-2-td169498.html
changes, etc
global = { \time 4/4 s1 \time 3/4 \grace s8 s2. }
\new Staff \global { c''1 c''2. }
\new Staff \global { c''1 \grace b'8 c''2. }
Usually I include the \global in the top staff ( or top of each group of
staves).
You may see how this relates to your solution.
HTH
Paul Scott
On Wed, Aug 27, 2014 at 02:19:26AM +, Dan Eble wrote:
I'm not top posting
% programming error: Object is not a markup.
% This object should be a markup: ()
\version 2.13.18
\relative c'' {
\time 3/4
R2.\fermata
}
That should be R2.\fermataMarkup
for a whole measure rest.
Paul
part should be notated at the beginning of the B part,
rather than at the end of the A part, to easily see them when repeating back
to the start of the B part. Hence the use of partial in the middle of a
piece.)
Cheers,
-Paul
\version 2.19.11
melodyOne = \relative {
\time 6/8
a'8
maybe that wouldn't be needed after David's new patch?
http://lilypond.org/doc/v2.19/Documentation/notation/displaying-rhythms#upbeats
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/barcheck-failure-with-partial-in-middle-of-piece-tp165402p165417.html
Sent from
Here's an obscure one: when ledger line positions have been overridden, the
positions of dots on dotted notes are still shifted to avoid ledger lines that
are no longer there. They don't seem to be shifted based on actual ledger line
positions.
-Paul
\version 2.18.2
greenNote = \once
-length
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
and it is clearly impossible to create a
minimal example. They are always medium sized .ly files or larger.
Paul Scott
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
The following changes the clef for the cancelled key signature but uses
the previous clef for the new key signature.
\version 2.19.5
{
\key f \major R1 \cueClef bass \key g \major R1 \cueClefUnset
R1 \cueClef alto \key bes \major R1
}
Paul Scott
not correspond with the titles.
I'm seeing a similar pattern with other searches too, not just with
title:defining. Does anyone else see this?
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/LSR-search-results-title-text-doesn-t-match-links-or-images-tp161698.html
Schneidy wrote
Should be fixed now.
~Pierre
Hi Pierre,
Wow that was fast! Thanks!
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/LSR-search-results-title-text-doesn-t-match-links-or-images-tp161698p161709.html
Sent from the Bugs mailing list archive
Trevor Daniels wrote
However, I'm not sure that the change proposed by Paul is correct.
I think the current wording is correct.
Try this, and you'll see the long line runs off the right side of the
page.
No line break is inserted to prevent it; only the manual ones are
actioned.
I tried
Paul Morris wrote
Hmmm... one way to look at this is that the docs here:
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
give the impression that LilyPond has a mode that will _only_ insert
breaks where there are explicit break commands (***and nowhere else
an automatic line break or page break if these commands were not
present.
Thanks for considering,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/page-break-permission-f-doesn-t-work-for-the-final-manual-pageBreak-tp159763p159789.html
Sent from the Bugs mailing list
Here's a revision of that example[1] that does a better job of illustrating
the effects of those two commands.
-Paul
[1] http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
\paper {
indent = #0
ragged-right = ##t
ragged-bottom = ##t
}
music = \relative c'' { c8 c c c
line break or page break if these commands were not present.
Below is a suggested revision that does a better job of illustrating the
effects of those two commands.
Thanks,
-Paul
%
\version 2.18.0
\paper {
indent = #0
ragged-right = ##t
ragged-bottom = ##t
}
music = \relative c
this. I've started another thread
about the example.
Cheers,
-Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
an
additional page. See the three examples below.
The docs say: When page-break-permission is overridden to false, Lily will
insert page breaks at explicit \pageBreak commands and nowhere else.
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
-Paul
%% EXAMPLE 1
reason. Will
these survive the upgrade process without being lost?
There are several of these I've contributed in this category. Here is one
of them, for example:
Dashed individual staff lines [needs LSR upgrade]
http://lsr.di.unimi.it/LSR/Item?u=1id=880
Thanks again,
-Paul
--
View
runs the new
version.
At least, we did so last time.
Ofcourse you could download the tarball, too. As kind of backup.
Ok, Thanks! Maybe I will download a backup copy just for good measure.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/LSR-v2-18-Work
displayed.
So that's roughly 80% at this point (531 / 660).
(That's assuming that the number of web pages in /v2.18/ and /v2.17/ are
similar.)
--
Paul Morris
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Web-site-manual-search-defaulting-to-2-17-tp158320p158479.html
Looks like the following works. I just added a second argument to the lambda
expression. It is just ignored, but it prevents the error.
(n) - (n x)
HTH,
-Paul
\version 2.18.0
\layout {
\context {
\Score
barNumberVisibility = #all-bar-numbers-visible
barNumberVisibility
In 2.17 you no longer need to use #' with \tag, \removeWithTag, or
\keepWithTag. This is a helpful simplification but it is not yet reflected in
the docs.[1] For example:
\tag #'aa % old way
\tag aa % new way
Dotted lists work too:
Instead of:
\removeWithTag #'aa
... Is the idea to eventually make \tag violin1 work, and then
update the docs at that point?)
Thanks again for the explanation,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/docs-no-longer-needed-with-tag-removeWithTag-keepWithTag-tp156200p156207.html
Sent from
Paul Morris wrote:
Currently the function make-connected-path-stencil[1] does not allow you to
specify the starting point (origin) of the path, but arbitrarily hard-codes
it
as (0 0). This makes the function less flexible for no good reason.
Hello bug squad,
I'd like to withdraw
origin wherever
this function has been used, to keep from mangling existing stencils...)
Thanks for considering,
-Paul
[1] http://lsr.dsi.unimi.it/LSR/Item?u=1id=891
[2] http://code.google.com/p/lilypond/issues/detail?id=3624
___
bug-lilypond mailing
origin wherever
this function has been used, to keep from mangling existing stencils...)
Thanks for considering,
-Paul
[1] http://lsr.dsi.unimi.it/LSR/Item?u=1id=891
[2] http://code.google.com/p/lilypond/issues/detail?id=3624
___
bug-lilypond mailing
Paul Morris wrote
A proposed revision making this change is in the attached file.
Looks like the attachment did not make it through, so pasting it inline
below. (Also, I only sent one email, but it looks like it posted twice for
some reason...)
-Paul
\version 2.17.29
% Most of this code
1 - 100 of 284 matches
Mail list logo
