subject to those
particular licenses.
> --
> Karlin High
> Missouri, USA
Best,
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
On Thu, Apr 22, 2021 at 3:35 PM Jonas Hahnfeld wrote:
> Am Donnerstag, dem 22.04.2021 um 15:33 -0400 schrieb Marnen Laibow-
> Koser:
> >
> >
[...]
>
> >
> > I’m not sure what isn’t true there.
>
> The claim that "no one else was" doing this
On Thu, Apr 22, 2021 at 3:30 PM Jonas Hahnfeld wrote:
> Am Donnerstag, dem 22.04.2021 um 14:59 -0400 schrieb Marnen Laibow-
> Koser:
> > On Thu, Apr 22, 2021 at 2:54 PM Carl Sorensen
> wrote:
> >
> > > The problem is that there is not an .app bundle for 2.22.0.
nd mailing list
> > bug-lilypond@gnu.org
> > https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
On Thu, Apr 22, 2021 at 3:15 PM Carl Sorensen wrote:
>
>
>
>
> *From: *Marnen Laibow-Koser
>
[...]
> Please help out with the Mac build scripts, then! Until the LilyPond
> maintainers choose to take them, they’re in a separate project at
>
> https://gitlab.c
On Thu, Apr 22, 2021 at 3:00 PM Karlin High wrote:
> On 4/22/2021 1:43 PM, Marnen Laibow-Koser wrote:
> > We are currently complying with that requirement by doing Mac
> > builds on a Mac hosted at MacStadium (and whose credentials I should
> share
> > with*someone* be
seful so that the .app bundle has *some* GUI. I’d
rather bundle Frescobaldi than LilyPad, but the advantages of a
self-contained .app bundle are too big to give up.
>
> --
> David Kastrup
Best,
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
that would also be welcome; I’m doing this mostly because no one else
was, not because I particularly want to run the Mac build effort).
>
>
> Thanks,
>
>
>
> Carl
>
>
>
Best,--
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
__
downloads are hosted, is going away at the end of the
month, and I need to figure out a good place to put them. Meanwhile, I've
heard from someone who has some ideas about putting the Mac build pipeline
on GitHub Actions, which apparently now has Mac build hardware available.
I like
with
Apple's own SDK, whose license agreement requires that it be used on Apple
hardware. We are currently complying with that requirement by doing Mac
builds on a Mac hosted at MacStadium (and whose credentials I should share
with *someone* besides myself; who in the project would be a good candi
e MacPorts install on the box that I’m using to produce the
LilyPond builds *does* have to install everything from source, because I
put MacPorts in a nonstandard location to make system administration
easier. Apparently MacPorts builds for a specific installation location...)
Best,
> --
Ma
the list has been working on such a bundle. I
> believe there are links in the chat history, and I’m cc’ing in Marnen in
> case you need help with this approach.
>
Yes, see above. I believe this should be the preferred option for most Mac
users who don’t have a specific reason to need
On Wed, Oct 30, 2019 at 11:58 PM Marnen Laibow-Koser
wrote:
> Hi everyone!
>
> I've just run across a bug in 2.19.61. Normally when lyrics are set to a
> voice with slurs, syllables don't get assigned to the second and subsequent
> notes in a slur. But in 2.19.61, *if th
t;> |
}
verse = \lyricmode {
\repeat unfold 2 { one two three }
}
\score {
\new Staff { \melody }
\addlyrics { \verse }
\layout { }
}
-end LilyPond code-
Let me know if you need any further information to investigate this bug.
Thanks!
Be
at behavior will surprise the
experienced Lilypond user least. For myself, I was *extremely* surprised
that U+3000 doesn't behave like every other space, and so I don't think
this is desirable behavior at all.
Best,
--
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org
_
On Aug 16, 2011, at 10:09 AM, Reinhold Kainhofer wrote:
> Am Dienstag, 16. August 2011, 04:30:34 schrieb Marnen Laibow-Koser:
>> 1 (partcombine-omits-quotes): When two quoted parts are \partcombined, only
>> one part's notes remain in the combined staff. The "2 Flutes&
a bug?
FWIW, if bar 1 of flute 1 is replaced with more of the violin quote, the
notation is correct.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
partcombine-with-quotes.ly
Description: Binary data
partcombine-with-quotes.pdf
Descri
Mats Bengtsson wrote:
[...]
Since the final measure in your example will not be a full
measure,
it seems a bit strange to use a full measure rest symbol and not "r2
r4".
[...]
I agree with you. As far as I know -- and I could be wrong -- accepted
practice is to use a whole rest *only* for a
Han-Wen Nienhuys wrote:
Marnen Laibow-Koser escreveu:
Of course laser printouts are better for this purpose, but not everyone
is lucky enough to have a 1200-dpi laser printer sitting around. My
A 600dpi x 1200dpi printer can be had for less than EUR 100 nowadays,
will produce output that
Han-Wen Nienhuys wrote:
The weight of the barline has to be considered in relation to the visual
weight of the rest of the page. Music is usually played and read
from a page, not from separate symbols.
Agreed. But up to now, we've been focusing on individual symbols. I
would be happy to
Bertalan Fodor wrote:
I think we should definitely go to a print shop and create a film with
some LinoType machine in 4800dpi
[...]
That would be a lovely idea. Unfortunately, there are three problems:
* Money
* Time
* The fact that it would not be representative of the output conditions
of t
Han-Wen Nienhuys wrote:
You cannot judge typography from screen, no matter how much you magnify.
It's just not the same thing.
If you're trying to judge the look of a whole page, of course that's
true. However, for the look of a single character or a small area, I
completely disagree. And
Jan Nieuwenhuizen wrote:
When designing bar
lines, we were looking for a practice that was backed by big houses,
but also something interesting or exceptional(ly beautiful), rather
than something too common and `looking also ok'.
Hmm. I wonder if this was in fact the right way to go: exception
Han-Wen Nienhuys wrote:
Marnen Laibow-Koser escreveu:
[...]
Nope, wrong again. My original judgement came in fact from viewing the
PDF file.
[...]
The fanciest computer displays are 142 dpi (1600x1200 14" laptop
screen). This is not good enough for judging typography.
Augh! The mom
Han-Wen Nienhuys wrote:
I think we have a difference of opinion. I would rather
call that fuzzy and uneven.
Well, at 2400 dpi, yes. But while my scanner has that sort of optical
resolution, I do not. At actual size, the output is actually pretty
hard to tell from laser output.
Best,
Marn
Han-Wen Nienhuys wrote:
[...]
Your judgement of "ugly" was based on prints that come from an inferior
printer.
Nope, wrong again. My original judgement came in fact from viewing the
PDF file.
And I wouldn't call my printer "inferior". Oh sure, it's an inkjet
printer, but the output is fi
Han-Wen Nienhuys wrote:
Hello,
I had another look at a lilypond print-out locally, and I think that
with the settings as is, it looks good, not in the least ugly.
*However*
I already discussed some of this with Jan, and we found that printer
artefacts might also be a factor: Jan's printer does
Jan Nieuwenhuizen wrote:
[...]
Yes, of course. So have I. It's just that Marnen asserts: off the
charts---which is not true---upon which conclusions seem to be drawn,
without further investigation.
What do you mean by "further investigation"? My conclusion was based on
careful examination o
Jan Nieuwenhuizen wrote:
[...]
I just wanted to point out that if
you find thick barlines ugly, you will likely produce scans that have
light bar lines.
Just to make myself completely clear, I did not deliberately set out to
find scores with light barlines. I tried to get a representative
s
Jan Nieuwenhuizen wrote:
[...]
Congratulations, you found some lightly printed editions.
Then that was the luck of the draw. I basically chose a few books more
or less at random, and added some editions whose aesthetics I like (such
as Henle). I will be trying to enlarge my sample and seei
Mats Bengtsson wrote:
Yes, but this is one of the aspects of typesetting layout where
there are no fixed rules, but rather a matter of taste.
[...]
That's true, of course. But if the sample of scores that I have
examined is at all representative, then Lilypond's output is in this
regard so f
Han-Wen Nienhuys wrote:
Thanks for your input.
You're welcome!
I'll keep it in mind when I'm fiddling with fonts
and blackness the next time. It might be a good idea to tune the bar size
down a bit (say: to 1.75), but I'll have to have a good look at the output
first.
Is that 175% of th
Karl Hammar wrote:
[EMAIL PROTECTED]:
However, I think that Lilypond's barlines are so far off the chart that
the higher resolution will not change anything.
You could use:
\override Score.BarLine #'hair-thickness = #1.2
[...]
Yes, I could. However, Lilypond's stated goals include the g
Marnen Laibow-Koser wrote:
Han-Wen Nienhuys wrote:
I am giving approximate dimensions of barlines, stems, and staff lines
in pixels. All scans are 300 dpi, so 1 px = 1/300". Editions are
You need 1200 dpi to get a good impression of the actual thickness.
If file size is a problem
Han-Wen Nienhuys wrote:
I am giving approximate dimensions of barlines, stems, and staff lines
in pixels. All scans are 300 dpi, so 1 px = 1/300". Editions are
You need 1200 dpi to get a good impression of the actual thickness.
If file size is a problem, you can small areas of the page.
Y
Here we go...some scanned images of barlines. They were too big to
attach, but you can download them at
http://doko.ebon-askavi.homedns.org:8080/scans.zip . Image file names
contain edition name and page number; more bibliographic info about each
book I scanned is below.
I am giving approxi
Graham Percival wrote:
Thanks for the report! This is the same problem as
http://code.google.com/p/lilypond/issues/detail?id=217
Sorry about the duplication, then. I wasn't able to find anything
likely in the tracker when I searched.
Best,
Marnen
Thomas Scharkowski wrote:
[...]
I have looked into some other editions (Bärenreiter, Peters,
Breitkopf & Härtel, Schott) - the barlines are always thicker than
the stafflines.
Yes, but by how much?
Maybe these extremely thick barlines are a German practice. I note that
all the editions you
Han-Wen Nienhuys wrote:
You can already set staff-position on the rest object.
Right, but...I'm picking on these issues because I understood that it
was one of your stated goals to make Lilypond produce excellent notation
*without tweaking* as much as possible. Repositioning rests definitel
Werner LEMBERG wrote:
Bärenreiter's barlines are twice as thick as their staff lines?
I've just had a look into BA 4582 (Mozart's Complete Works V/14/1),
engraved 1983: Indeed, the bar lines are almost twice as thick as the
staff lines. Maybe the bar lines can be made thinner *a little bit*,
Marnen Laibow-Koser wrote:
[...]
I'll see what I have available.
A quick look through my music library revealed the following: while some
(not all) editions have barlines *slightly* thicker than staff lines,
the barlines never appear to be more than about 125% the thickness of
the
Han-Wen Nienhuys wrote:
Marnen Laibow-Koser escreveu:
[...]
Acceptable barlines
in engraved music should not be significantly thicker than staff lines.
Compared to what? The thickness is based on Barenreiter BA 350;
Bärenreiter's barlines are twice as thick as their staff lines?
Han-Wen Nienhuys wrote:
Scans, references?
I'll look in my library and see what I can find. At any rate, I find
that the practice I described produces more attractive results than
Lilypond's current default.
Best,
Marnen
___
bug-lilypond mai
When outside the staff, tenuto marks are rather too close to the notes
for legibility, especially on the stem side.
-begin example-
% tenuto-too-close.ly
% Tenuto marks are too close to notes.
% 6 January 2007
\version "2.10.8" % Mac OS X 10.4.8, iBook G4
\paper { ragged-right = ##t }
Werner LEMBERG wrote:
It's hard to find a good default which fits all situations.
Agreed.
I think
the current behaviour of lilypond is just fine (I had a different
opinion previously).
I'm not sure. I think I'd prefer that Lilypond put rests closer to the
middle of the staff, and force t
Joe Neeman wrote:
[...]
The moral of the story is not to trust the rendering of a pdf viewer on a
low resolution monitor;
That's why I zoomed in to a fairly high magnification level.
print out the file and see if the problem is still
there.
The barlines don't appear to stick out when print
I wrote:
Lilypond's default barlines are far, far too thick.
Unfortunately, it's hard to see these problems in the low-res PNG I
sent. I can supply a higher-res image if necessary.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.
Lilypond's default barlines are far, far too thick. Acceptable barlines
in engraved music should not be significantly thicker than staff lines.
Also, at high magnification levels, the top end of the barlines
overshoots the edge of the staff line; the bottom end of the barlines
may do this too
Lilypond does not always avoid collisions of dots with stems in another
voice on the same staff. Note how the dot on the e'' collides with the
stem of the c''.
-begin example-
% polyphonic-dot-collisions.ly
% Dots collide in polyphonic music.
% 6 January 2007
\version "2.10.8" % Mac
Hi.
I find that Lilypond defaults to placing voiceOne rests at a height that
is a bit too high when voiceTwo notes are on the low side. I would tend
to place the rests in this example a full space lower than Lilypond does.
-begin example-
% rests-too-high.ly
% Rests in voiceOne are
50 matches
Mail list logo
