Le 16/10/2021 à 16:03, Jonas Hahnfeld a écrit :
Am Samstag, dem 16.10.2021 um 15:49 +0200 schrieb Jean Abou Samra:
Honestly, it doesn't make sense to extrapolate from you to others. I
certainly do if I'm interested in the history of particular decisions,
and I think I've shared collections of
Am Samstag, dem 16.10.2021 um 15:49 +0200 schrieb Jean Abou Samra:
>
> Le 16/10/2021 à 14:18, Jonas Hahnfeld a écrit :
> > Am Samstag, dem 16.10.2021 um 12:55 +0200 schrieb Jean Abou Samra:
> > > We're all volunteers and nobody is entitled
> > > to respond to bug reports. So if one slips
> > >
Le 16/10/2021 à 14:28, David Kastrup a écrit
bug-lilypond@gnu.org is not a subscribers-only list and it is expected
that responses include a Cc: to the sender.
Ah, ok. I had inferred the contrary from
http://lilypond.org/bug-reports.html
b) read up on the categories and flags we use for
Jean Abou Samra writes:
> Le 16/10/2021 à 13:09, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>> Hi James, Werner, all,
I would say that 'most' emails to the bug list do NOT need an
issue, they are either replies to emails or pointers to existing
Issues that explain bug or
Am Samstag, dem 16.10.2021 um 12:55 +0200 schrieb Jean Abou Samra:
> We're all volunteers and nobody is entitled
> to respond to bug reports. So if one slips
> through the cracks occasionally, I believe
> it's better to have it in the database and
> keep it for future developers walking around
>
Le 16/10/2021 à 13:09, David Kastrup a écrit :
Jean Abou Samra writes:
Hi James, Werner, all,
I would say that 'most' emails to the bug list do NOT need an issue,
they are either replies to emails or pointers to existing Issues
that explain bug or technical discussions about why something is
Jean Abou Samra writes:
> Hi James, Werner, all,
>>
>> I would say that 'most' emails to the bug list do NOT need an issue,
>> they are either replies to emails or pointers to existing Issues that
>> explain bug or technical discussions about why something is not a bug
>> but a limitation of
Hi James, Werner, all,
Le 14/10/2021 à 08:43, James a écrit :
Hello,
My own thoughts on this.
On 14/10/2021 01:31, Jean Abou Samra wrote:
Hi,
After having opened a few GitLab issues in response to
bug reports on bug-lilypond, I find James extraordinarily
patient for having done this over
On 15/10/2021 21:21, Timothy Lanfear wrote:
Since 2.23.3, this example produces several error messages of the type
programming error: cyclic dependency: calculation-in-progress
encountered for #'adjacent-pure-heights (VerticalAxisGroup)
continuing, cross fingers
\version "2.23.3"
\layout {
Le 14/10/2021 à 16:12, Peter Toye a écrit :
Hello Carl and Jean,
I've not had an answer to this - has it got lost somewhere?
Dear Carl,
Thanks for pointing out the bracket. Silly me.
But it doesn't help - I copy-and-pasted your code and the hairpin is
still the same size as the top staff
Hello Carl and Jean,
I've not had an answer to this - has it got lost somewhere?
Dear Carl,
Thanks for pointing out the bracket. Silly me.
But it doesn't help - I copy-and-pasted your code and the hairpin is still the
same size as the top staff but the forte sign is smaller. See the
Hello,
On 14/10/2021 08:30, Werner LEMBERG wrote:
Since James is doing most of the work, I think we should do what he
prefers. This doesn't prevent other developers to chime in and help
with handling bug reports. And frequent *and experienced* bug
reporters should be told to directly use the
>> After having opened a few GitLab issues in response to bug reports
>> on bug-lilypond, I find James extraordinarily patient for having
>> done this over the years. However, I don't get the value in this
>> system compared to letting people creating issues on GitLab
>> directly. When we
Hello,
My own thoughts on this.
On 14/10/2021 01:31, Jean Abou Samra wrote:
Hi,
After having opened a few GitLab issues in response to
bug reports on bug-lilypond, I find James extraordinarily
patient for having done this over the years. However, I don't
get the value in this system compared
Timothy,
I'm looking into the issue. Does adding
\tagGroup #'($partCombine)
early in your score work around the problem?
—
Dan
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
On 12/10/2021 22:55, Dan Eble wrote:
Timothy,
I'm looking into the issue. Does adding
\tagGroup #'($partCombine)
early in your score work around the problem?
—
Dan
Yes, adding the \tagGroup does bring back the missing music.
--
Timothy Lanfear, Bristol, UK.
Le 12/10/2021 à 22:31, Timothy Lanfear a écrit :
From at least 2.18 to 2.23.3, it was possible to place \tag and
\keepWithTag outside of \partCombine. Version 2.23.4 requires the
tagging inside \partCombine. I do have a lot of files expecting the
old behaviour.
\version "2.22.1"
{
Per the original error message I posted, it was trying to use version 3.8 of
the Homebrew version. But I tried linking version 3.8, and then version 3.9,
and even 3.6, still got errors. But in each case, python on the system side had
no trouble importing encodings.
> On Oct 12, 2021, at 4:25
Am Dienstag, dem 12.10.2021 um 16:15 -0400 schrieb Jim Weisbin:
>
>
> > On Oct 12, 2021, at 4:13 PM, Jonas Hahnfeld
> > wrote:
> >
> > Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
> > > I was under some pressure to get this working for a client, who
> > > was unfortunately
> On Oct 12, 2021, at 4:13 PM, Jonas Hahnfeld wrote:
>
> Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
>> I was under some pressure to get this working for a client, who was
>> unfortunately on Mac OS Catalina. I tried importing xml files with
>> many many different
Am Dienstag, dem 12.10.2021 um 16:02 -0400 schrieb Jim Weisbin:
> I was under some pressure to get this working for a client, who was
> unfortunately on Mac OS Catalina. I tried importing xml files with
> many many different combinations of Lilypond and Frescobaldi. The
> only combination I could
I was under some pressure to get this working for a client, who was
unfortunately on Mac OS Catalina. I tried importing xml files with many many
different combinations of Lilypond and Frescobaldi. The only combination I
could get to work was with Frescobaldi 3.1.2 and an "unofficial" build of
Am Montag, dem 11.10.2021 um 23:49 +0200 schrieb Jean Abou Samra:
>
> Le 10/10/2021 à 10:15, James a écrit :
> > Hello Jim,
> >
> > I didn't see any replies to this but it seems to me that this might be
> > Frescobaldi specific. The Frescobaldi developer lurks on these lists
> > but it might
Le 10/10/2021 à 10:15, James a écrit :
Hello Jim,
I didn't see any replies to this but it seems to me that this might be
Frescobaldi specific. The Frescobaldi developer lurks on these lists
but it might be worth pinging him directly.
There are a number of ways -
Hello
On 10/10/2021 00:10, Thomas Morley wrote:
I noticed a bug with recent master:
\markup \rounded-box "foo"
prints completely black.
First bad commit is:
commit 0772e38398972d6c2b4ba9e6f42e7725d973e08b
Author: Han-Wen Nienhuys
Date: Sun Aug 1 11:15:02 2021 +0200
Stop passing color
On 04.10.2021 19:42, Jean Abou Samra wrote:
This is just something I noticed, not of any direct importance to me,
but thought you might like to know. I checked convert-ly does not alter
the file.
This is registered as issue #4826,
https://gitlab.com/lilypond/lilypond/-/issues/4826
As an
The following
\version "2.18.0"
{ g'4 f' g' \mark \default}
compiles ok while
\version "2.22.1"
{ g'4 f' g' \mark \default}
reports
Starting lilypond 2.22.1 [test22.ly]...
Processing `/tmp/frescobaldi-uljzgf6d/tmpzpa94ikr/test22.ly'
Parsing...
Interpreting music...
Preprocessing
Le 29/09/2021 à 22:56, leonardlthomp...@gmail.com a écrit :
Hello!
Many of us who use chord symbols in our scores find value in having 'pedal'
as a chord symbol type, which is simply a single unison pitch given by the
chord's root. Both Finale and Musescore successfully export 'pedal' as a
Dear Carl,
Thanks for pointing out the bracket. Silly me.
But it doesn't help - I copy-and-pasted your code and the hairpin is still the
same size as the top staff but the forte sign is smaller. See the attached.
Best regards,
Peter
mailto:lilyp...@ptoye.com
www.ptoye.com
On 9/30/21, 10:32 AM, "Peter Toye" wrote:
Oddly, Frescobaldi doesn't recognise \magnifyMusiceither wher I've put it
or within the brackets.
You haven't matched the required structure for the file. Our parser is
flexible to allow different kinds of music functions, so sometimes the
Dear Jean,
Thanks. That works for the dynamics, but the hairpins are still too large in
the Y-direction.
Oddly, Frescobaldi doesn't recognise \magnifyMusiceither wher I've put it or
within the brackets. The result is the same, however.
\version "2.22.1"
\language "english"
\score {
<<
Le 30/09/2021 à 11:17, Peter Toye a écrit :
It does not seem to be possible to change the size of a Dynamic staff.
Admittedly, at first sight there's no need to, but it means that the font size
of text and the Y-size of graphics like hairpins does not change. This is a bit
of a nuisance -
Le 26/09/2021 à 19:23, Thibaut Cuvelier a écrit :
Dear list,
While working on supporting LilyPond from within LyX' DocBook support, I
stumbled upon a poorly defined behaviour: if the attributes are set using '
instead of ", then LilyPond ignores them.
Hi,
Thanks for reporting this bug
Merci Jean,
Best regards,
Peter
mailto:lilyp...@ptoye.com
www.ptoye.com
-
Thursday, September 23, 2021, 11:18:58 PM, you wrote:
> Le 18/09/2021 à 17:44, Peter Toye a écrit :
>> I've found by experiment that there's something missing from NR 1.3.3
>> Glissando in the
Le 18/09/2021 à 17:44, Peter Toye a écrit :
I've found by experiment that there's something missing from NR 1.3.3 Glissando
in the paragraph about glissandoMap. This seems to imply that you need an
entry for each note in a chord. But it's possible to leave out a gliss line
entirely simply by
Le 22/09/2021 à 14:02, David Kastrup a écrit :
Federico Bruni writes:
Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
ha scritto:
"make doc-clean" appears to work better. I find it somewhat
surprising
that it should not have been implied by "make clean".
IIRC it's implied by
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
> IIRC it's implied by make distclean
At any rate, the
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
> IIRC it's implied by make distclean
Well, but distclean
Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
ha scritto:
"make doc-clean" appears to work better. I find it somewhat
surprising
that it should not have been implied by "make clean".
IIRC it's implied by make distclean
___
Jean Abou Samra writes:
> Le 21/09/2021 à 22:03, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 21/09/2021 à 21:24, David Kastrup a écrit :
I am reverting
commit 79114c78d12a24b6089af0375dcac5b739c29a0c
Author: Jean Abou Samra
Date: Tue Aug 31 17:49:30
Le 21/09/2021 à 22:03, David Kastrup a écrit :
Jean Abou Samra writes:
Le 21/09/2021 à 21:24, David Kastrup a écrit :
I am reverting
commit 79114c78d12a24b6089af0375dcac5b739c29a0c
Author: Jean Abou Samra
Date: Tue Aug 31 17:49:30 2021 +0200
Doc: Better hyphenation in PDF output
Jean Abou Samra writes:
> Le 21/09/2021 à 21:24, David Kastrup a écrit :
>> I am reverting
>>
>> commit 79114c78d12a24b6089af0375dcac5b739c29a0c
>> Author: Jean Abou Samra
>> Date: Tue Aug 31 17:49:30 2021 +0200
>>
>> Doc: Better hyphenation in PDF output for camel-case names
>>
Le 21/09/2021 à 21:24, David Kastrup a écrit :
I am reverting
commit 79114c78d12a24b6089af0375dcac5b739c29a0c
Author: Jean Abou Samra
Date: Tue Aug 31 17:49:30 2021 +0200
Doc: Better hyphenation in PDF output for camel-case names
Node names from the Internals Reference often
Jean Abou Samra writes:
> Le 21/09/2021 à 21:12, David Kastrup a écrit :
>> David Kastrup writes:
>>
>>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>>> Making Documentation/out-www/lilypond-changes.info < texi
>>> Making Documentation/out-www/lilypond-learning.info < texi
>>>
David Kastrup writes:
> David Kastrup writes:
>
>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>> Making Documentation/out-www/lilypond-changes.info < texi
>> Making Documentation/out-www/lilypond-learning.info < texi
>> Making Documentation/out-www/en/notation.texi < tely
>>
Le 21/09/2021 à 21:12, David Kastrup a écrit :
David Kastrup writes:
dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
Making Documentation/out-www/lilypond-changes.info < texi
Making Documentation/out-www/lilypond-learning.info < texi
Making Documentation/out-www/en/notation.texi
David Kastrup writes:
> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
> Making Documentation/out-www/lilypond-changes.info < texi
> Making Documentation/out-www/lilypond-learning.info < texi
> Making Documentation/out-www/en/notation.texi < tely
> Making
That's one of the oldest bugs in LilyPond. The work-around is to put
a grace with a spacer in the other staff too.
%%%
\version "2.22.0"
global= { \time 3/4 }
\score {
\new GrandStaff <<
\new Staff \relative { \global \acciaccatura b'8 c16 }
\new Staff \relative { \global \grace s8 r4}
On 9/14/2021 9:03 AM, Aaron Hill wrote:
It is common, but it is done via \override and not \markup.
fancyText = {
\override LyricText.font-shape = #'italic
\override LyricText.color = #red
}
\new Lyrics \with { \fancyText } \lyricmode { a b c }
\new Lyrics \lyricmode { \fancyText a b
On 9/14/2021 10:51 AM, Werner LEMBERG wrote:
It is mentioned in the documentation around fonts:
http://lilypond.org/doc/v2.23/Documentation/notation/fonts#font-families
Ah, somehow I missed that. Thanks.
Justin, could you suggest an index entry (or whatever) that would have
you enabled to
>> Ah, that's kind of what I was fearing. Obviously (at least I hope
>> it was obvious; maybe it wasn't) I was trying to format an entire
>> group of lyrics, and having to markup each word was both tedious
>> and ugly. In my use case, it looks like \override
>> LyricText.font-size and
On 2021-09-14 6:21 am, Justin Peter wrote:
It doesn't appear that any of this is covered in the documentation -
is wanting to format entire verses/groups of lyrics not a common use
case, or would that be something helpful to add?
It is common, but it is done via \override and not \markup.
Le 14/09/2021 à 15:21, Justin Peter a écrit :
Ah, that's kind of what I was fearing. Obviously (at least I hope it
was obvious; maybe it wasn't) I was trying to format an entire group
of lyrics, and having to markup each word was both tedious and ugly.
In my use case, it looks like
On 9/14/2021 1:02 AM, Aaron Hill wrote:
On 2021-09-13 9:03 pm, Justin Peter wrote:
When using (or rather attempting to use) a \markup block inside of
lyrics, the lyrics become misaligned. Example:
\score {
<<
\new Staff {
\new Voice = "melody" {
\relative { c''4 c c c }
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
>made to extend past their
Le 14/09/2021 à 11:48, Paul Hodges a écrit :
Exactly as the title says - crossStaff works for all stemmed notes, but
quavers which are not beamed lose their flag. I have resorted to
merging in an extra note to get the flag, as in this example which shows
the problem and my hack:
\version
On 2021-09-13 9:03 pm, Justin Peter wrote:
When using (or rather attempting to use) a \markup block inside of
lyrics, the lyrics become misaligned. Example:
\score {
<<
\new Staff {
\new Voice = "melody" {
\relative { c''4 c c c }
}
}
\new Lyrics {
Hello
On 11/09/2021 11:52, Hans Aikema via bug-lilypond wrote:
Running a MusicXML-to-lilypond conversion for a score I received from the arranger as a
Sibelius 8.3.0 MusicXML export (Direct export, not from Dolet) I encoutered breaking errors
due to Sibelius’ use of none-numerical lyric
thanks
On 05/09/2021 18:16, Jean Abou Samra wrote:
Le 05/09/2021 à 10:45, Jean Abou Samra a écrit :
I'll probably propose a patch.
Here you go:
https://gitlab.com/lilypond/lilypond/-/merge_requests/909
Jean
--
Regards
James
___
Le 05/09/2021 à 10:45, Jean Abou Samra a écrit :
I'll probably propose a patch.
Here you go:
https://gitlab.com/lilypond/lilypond/-/merge_requests/909
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
Hello anyone on the bug list, could someone just verify what was
reported by Paul (below) sounds correct and if this is a bug or just a
doc edit (or both).
Thanks,
James
Thanks for reminding.
Le 25/08/2021 à 15:36, Paul Hodges a écrit :
On the page:
Hello anyone on the bug list, could someone just verify what was
reported by Paul (below) sounds correct and if this is a bug or just a
doc edit (or both).
Thanks,
James
On 25/08/2021 14:36, Paul Hodges wrote:
On the page:
>> In my experiment, Cairo without LilyPond does not generate garbled
>> characters. It seems to be a LilyPond issue instead of a Cairo
>> issue. Here's a python-cairo sample that works fine. [...]
>
> I can conform that this small script generates a PDF where
> copy-and-paste works as
On 9/1/2021 9:33 AM, Jean Abou Samra wrote:
Le 31/08/2021 à 23:01, John Wheeler a écrit :
The code that creates the file: internals.texi, which is found in
./scm/documentation-generate.scm and ./scm/documentation-lib.scm,
inserts the following texinfo code near the beginning of the file:
Le 20/08/2021 à 12:09, Matthias Steup a écrit :
I recently updated lilypond from 2.18 to 2.22. Since then the rendered
svg files differ from the pdf files. The fonts used in title,
composer, poet, lyrics change the distance of staffs so that a song
that is rendered to one page in pdf, is
Le 31/08/2021 à 23:01, John Wheeler a écrit :
The code that creates the file: internals.texi, which is found in
./scm/documentation-generate.scm and ./scm/documentation-lib.scm,
inserts the following texinfo code near the beginning of the file:
INFO-DIR-SECTION LilyPond
START-INFO-DIR-ENTRY
*
Hello,
On 21/08/2021 16:43, David Zelinsky wrote:
On this page:
http://lilypond.org/doc/v2.22/Documentation/contributor/requirements-for-running-lilypond
there is a link for DejaVu fonts that points to .
However, dejavu-fonts.org is apparently owned by an internet hosting
company, which seems
>> I've looked up the cairo bug tracker but couldn't find something
>> related to copy-and-paste of CID-keyed fonts. Masamichi-san, could
>> you submit an issue there so that this gets fixed eventually? I
>> guess this would be beneficial for other projects, too.
>
> In my experiment, Cairo
The problem does not appear if the cairo backend is used, see
https://gitlab.com/lilypond/lilypond/-/merge_requests/853.
>>>
>>> This is good news!
>>
>> When copying and pasting from a PDF generated using cairo backend,
>> some characters turned into similar but different characters.
>>> The problem does not appear if the cairo backend is used, see
>>> https://gitlab.com/lilypond/lilypond/-/merge_requests/853.
>>
>> This is good news!
>
> When copying and pasting from a PDF generated using cairo backend,
> some characters turned into similar but different characters. The
>
Jonas Hahnfeld writes:
> Am Dienstag, dem 17.08.2021 um 21:43 +0200 schrieb David Kastrup:
>> Seems a bit wasteful not to include !882 while fixing point-and-click.
>
> Not really, the official binaries continue to be Guile 1.8 so nothing
> really changes there. I wouldn't mind it being there,
Am Dienstag, dem 17.08.2021 um 21:43 +0200 schrieb David Kastrup:
> Seems a bit wasteful not to include !882 while fixing point-and-click.
Not really, the official binaries continue to be Guile 1.8 so nothing
really changes there. I wouldn't mind it being there, but it's not in
master yet and I
Jonas Hahnfeld via bug-lilypond writes:
>> Hello,
>>
>> Thank you for reporting. With
>>
>> $ ~/lilypond2.23.1/bin/lilypond-invoke-editor
>> textedit://input/regression/mozart-hrn-3.ly:3:4:5
>>
>> I get emacs running. With
>>
>> $ ~/lilypond2.23.2/bin/lilypond-invoke-editor
>>
Am Montag, dem 16.08.2021 um 23:16 +0200 schrieb Jean Abou Samra:
> Le 16/08/2021 à 20:26, Karim Haddad a écrit :
> > Hello,
> >
> > Just to report and let you know that the point and click
> > (lilypond-invoke-editor) unfortunately seems broken in the latest lily dev
> > version : 2.23.2
>>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>>> subset versions), the output looks right but when copied from the
>>> generated PDF file, everything becomes garbage. [...]
>>
>> The problem does not appear if the cairo backend is used, see
>>
Hello,
Le 11/08/2021 à 15:07, Mats Bengtsson a écrit :
Hi,
This is probably more of a limitation than a bug, but should at least
be documented. If you try to quote a voice that itself contains quoted
material, the nested quote fails (without any warning message).
Here's a reasonably
Le 16/08/2021 à 20:26, Karim Haddad a écrit :
Hello,
Just to report and let you know that the point and click
(lilypond-invoke-editor) unfortunately seems broken in the latest lily dev
version : 2.23.2
I am on Debian 11 (latest), using xpdf and emacs as editor and viewer.
However it's
>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>> subset versions), the output looks right but when copied from the
>> generated PDF file, everything becomes garbage. [...]
>
> The problem does not appear if the cairo backend is used, see
>
Hi Knut,
> Do you use a lilypond installer or do you build lilypond from source? Which
> operating system do you use?
I am using Ubuntu 21.10 and installed LilyPond from its repository
(2.22.0-10). I also tried the latest stable (2.22.1-1) and development
(2.23.3-1) installer from the LilyPond
Hi Huanyu Liu,
When using certain fonts (in my case, Noto CJK, both pan-CJK and subset
versions), the output looks right but when copied from the generated PDF file,
everything becomes garbage. For example:
\version "2.22.0"
\markup {
\override
>> AFAICS, to make copy and paste work for CID fonts it is necessary
>> to add a ToUnicode map. We don't do that currently. [This is
>> probably worth an entry in our issues database.]
This is now issue #6162.
https://gitlab.com/lilypond/lilypond/-/issues/6162
Werner
>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>> subset versions), the output looks right but when copied from the
>> generated PDF file, everything becomes garbage. [...]
>
> Confirmed.
>
>> It seems to be all about CID. Maybe related to Issue #6058?
>
> Yes and no. The
> When using certain fonts (in my case, Noto CJK, both pan-CJK and
> subset versions), the output looks right but when copied from the
> generated PDF file, everything becomes garbage. [...]
Confirmed.
> It seems to be all about CID. Maybe related to Issue #6058?
Yes and no. The fix for
Sorry, it seems that there are some bugs with my email client. It showed that
the email delivery was failed, so I resent the mail. But actually it
succeeded...
And sorry for the terribly generated layout...
___
bug-lilypond mailing list
I wonder if akin to LaTeX you could do multiple compilation passes to get
those kinds of "references" right...
Le mer. 11 août 2021 à 10:05, Mats Bengtsson a
écrit :
> Hi,
>
> This is probably more of a limitation than a bug, but should at least be
> documented. If you try to quote a voice that
Hello,
On 04/08/2021 02:17, Keith Smith wrote:
> It would be very useful if lilypond had the ability to add MIDI markers
> to the MIDI output. Currently, the structure of a song is difficult to
> produce in MIDI as only \unfoldrepeats is available and constructs like
> D.S. al coda, are not
Le 24/07/2021 à 22:13, Federico Bruni a écrit :
While translating the PO file I saw what I thought it was a typo
(butthe), but it's something else.
$ git grep -n -B2 -A2 butthe po/lilypond.pot
po/lilypond.pot-847-#: musicxml.py:116
po/lilypond.pot-848-#, python-format
Jean Abou Samra writes:
> Thanks for your report. The same happens in Staff:
>
> \version "2.23.4"
>
> {
> \grace {
> \override NoteHead.font-size = 3
> c'
> \revert NoteHead.font-size
> }
> d'
> }
>
> This is because graces have special settings, which
> include a value for
Nate Whetsell writes:
> Hi there,
>
> Thanks for all your work on LilyPond!
>
> In a TabStaff, if a grace note is the first note and the \grace contains
> overrides, the overrides seem to be applied to whatever follows the grace
> note (instead of the grace note itself). Here’s an example that
Le 20/07/2021 à 13:14, Nate Whetsell a écrit :
Hi there,
Thanks for all your work on LilyPond!
In a TabStaff, if a grace note is the first note and the \grace contains
overrides, the overrides seem to be applied to whatever follows the grace note
(instead of the grace note itself). Here’s an
> Processing `../repeat-volta.ly'
> Parsing...
> Interpreting music...[8]
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> fatal error: cannot find SVG font #f
The font problem is issue #3809: the volta number is
[Changing your e-mail address to 'knupero', which is your preferred
one without problems, IIRC]
> [...] here's one hint for the volta-spec-once.ly problem:
> Roboto-Regular is (on my current system) a font without a glyph
> table.
You mean the font doesn't have a 'glyf' table, right? Then you
> On 2 Jul 2021, at 11:44, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 1 Jul 2021, at 23:36, David Kastrup wrote:
>>>
>>> Separate rolls are not separated, articulations are executed on every
>>> single stroke (where they are inaudible for drums) instead of the note
>>> as such,
James writes:
> Hello
>
> On 01/07/2021 22:36, David Kastrup wrote:
>> Please look/listen at the following:
>>
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead of the note
>> as such, ties (indicating an
Hello
On 01/07/2021 22:36, David Kastrup wrote:
Please look/listen at the following:
Separate rolls are not separated, articulations are executed on every
single stroke (where they are inaudible for drums) instead of the note
as such, ties (indicating an actual lack of separation) instead tie
Peter Chubb writes:
> Yes, I wrote articulate.ly thinking mostly of Clarinet music ... so
> we could win the Artemis Orchestra Challenge for mechanical instrument
> ... that it happened to be useful for other things is more of a happy accident
> than anything else.
>
> Ideally it'd be
Hans Åberg writes:
>> On 1 Jul 2021, at 23:36, David Kastrup wrote:
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead of the note
>> as such, ties (indicating an actual lack of separation) instead tie the
> On 1 Jul 2021, at 23:36, David Kastrup wrote:
>
> Separate rolls are not separated, articulations are executed on every
> single stroke (where they are inaudible for drums) instead of the note
> as such, ties (indicating an actual lack of separation) instead tie the
> whole roll into a single
Yes, I wrote articulate.ly thinking mostly of Clarinet music ... so
we could win the Artemis Orchestra Challenge for mechanical instrument
... that it happened to be useful for other things is more of a happy accident
than anything else.
Ideally it'd be integrated into Lilypond's MIDI generator,
Le 14/06/2021 à 08:53, 6d8fd379d7b54...@posteo.net a écrit :
Hi,
I got confused by the Octave Checks documentation:
https://lilypond.org/doc/v2.22/Documentation/notation-big-page#octave-checks
601 - 700 of 28962 matches
Mail list logo
