On Tue 29 Mar 2022 at 10:55:01 (-0600), Carl Sorensen wrote:
> On Tue, Mar 29, 2022 at 5:08 AM Jogchum Reitsma wrote:
> > In bar 8 and 9 of the attached lilypond snippet, there is a split voice,
> > in a repeat block.
> >
> > The text placement I get (added in the attached .pdf) is doubled,
> >
Le 29/03/2022 à 19:41, K. Blum a écrit :
Dear LilyPond community,
up to Ly 2.23.4, the use of
\include "lilypond-book-preamble.ly"
removed any whitespace around the score.
As of Ly 2.23.5, the music is moved to the upper left corner, but the
paper size remains unchanged.
Is this a new
Le 29/03/2022 à 19:51, Knute Snortum a écrit :
I've come across an odd behavior, maybe a bug. I am trying to create
a broken/partial/fragmented beam to the left of the note group. I can
do it to the right just fine. Some code may help illustrate what I mean:
%%%
\version "2.23.7"
% This
Thanks Xavier.
I guess I need more coffee (although I don't drink coffee) :-)
I'll use \dynamicUp because it seems that the typesetter of the music
I'm engraving from seems to be consistent about the right hand
expressive notation is above the staff and the left hand is below the
staff.
On Tue,
Thanks David.
This is strange; perhaps I twiddled the ^ and the \ and just did not see it.
On Tue, Mar 29, 2022 at 11:03 AM David Kastrup wrote:
>
> Kenneth Wolcott writes:
>
> > Hi;
> >
> > I'm obviously missing something trivially simple.
> >
> > I see how to display dynamics above the
>> This sounds sensible; maybe this suppression of processing `\score`
>> blocks can be implemented in Scheme so that LilyPond with a special
>> command line option acts as a syntax checker.
>
> Have you actually tried? Apart from scores placed in explicit books
> and bookparts, LilyPond
On Tue, 29 Mar 2022 at 20:00, Kenneth Wolcott
wrote:
>
> Hi;
>
> I'm obviously missing something trivially simple.
>
> I see how to display dynamics above the staff, but I do not see how
> to display hairpins above the staff.
Hello,
\dynamicUp works for dynamics, hairpins, etc.
Cheers,
Kenneth Wolcott writes:
> Hi;
>
> I'm obviously missing something trivially simple.
>
> I see how to display dynamics above the staff, but I do not see how
> to display hairpins above the staff.
Same way?
{
c'1^\< c'1\!
}
works just fine here.
--
David Kastrup
Hi;
I'm obviously missing something trivially simple.
I see how to display dynamics above the staff, but I do not see how
to display hairpins above the staff.
Thanks,
Ken Wolcott
I've come across an odd behavior, maybe a bug. I am trying to create a
broken/partial/fragmented beam to the left of the note group. I can do it
to the right just fine. Some code may help illustrate what I mean:
%%%
\version "2.23.7"
% This doesn't work: no beams are created
\relative c''' {
Dear LilyPond community,
up to Ly 2.23.4, the use of
\include "lilypond-book-preamble.ly"
removed any whitespace around the score.
As of Ly 2.23.5, the music is moved to the upper left corner, but the
paper size remains unchanged.
Is this a new (intended) behavior? Or have I just been
Hi Jogchum,
On Tue, Mar 29, 2022 at 5:08 AM Jogchum Reitsma wrote:
> Hi,
>
> In bar 8 and 9 of the attached lilypond snippet, there is a split voice,
> in a repeat block.
>
> The text placement I get (added in the attached .pdf) is doubled,
> besides of placing the two stanza fragments just
On Mon, 2022-03-28 at 23:42 +0200, Federico Bruni wrote:
> On Sat, Mar 26 2022 at 22:36:05 +0100, Jonas Hahnfeld via Discussions
> on LilyPond development wrote:
> > Starting with this release, LilyPond requires Guile 2.2
>
> Can anybody remind me how to build guile2 alongside guile1.8? And
Le 29/03/2022 à 09:31, Werner LEMBERG a écrit :
In this context I could imagine a paramater that kind of highlights
the first few error messages (or only shows the first N error
messages) being very forthcoming to some people without a dev
background. Or maybe at the end of the compilation
>
> This sounds sensible; maybe this suppression of processing `\score`
>
> blocks can be implemented in Scheme so that LilyPond with a special
>
> command line option acts as a syntax checker.
>
That would be an improvement. It's still however not what the OP's
Ah, mea culpa.
www.martinrinconbotero.com
>
> On Mar 29, 2022 at 12:58 PM, mailto:d...@gnu.org)> wrote:
>
>
>
> Martín Rincón Boterowrites: > >> Since
> TeX is predominantly employed for compiling LaTeX sources, that >> speaks
>
Martín Rincón Botero writes:
>
>> Since TeX is predominantly employed for compiling LaTeX sources, that
>> speaks more about the LaTeX implementation than TeX itself.
>
> Because I'm under the impression that Lilypond is more similar to
> LaTeX than to TeX,
It totally isn't, neither
Werner LEMBERG writes:
>> Why make the user wait so long to make him fix a misspelled word or
>> make him put a curly brace? A first pass should be done without
>> \score blocks and abort (or at least ask if you want to continue!)
>> if this first pass produces errors.
>
> This sounds sensible;
>
>
> Since TeX is predominantly employed for compiling LaTeX sources, that
>
>
>
> speaks more about the LaTeX implementation than TeX itself.
>
>
>
Because I'm under the impression that Lilypond is more similar to
> Why make the user wait so long to make him fix a misspelled word or
> make him put a curly brace? A first pass should be done without
> \score blocks and abort (or at least ask if you want to continue!)
> if this first pass produces errors.
This sounds sensible; maybe this suppression of
Martín Rincón Botero writes:
> I'm lucky to be able to work using Lilypond through Python. I never
> compile the whole score I'm working on, but only the current "segment"
> (around 2 pages) and the corresponding pages get updated in the
> PDF. Compiling the whole thing is something I do only at
*I'll implement it.
On mar. 29 2022, at 12:06 pm, Martín Rincón Botero
wrote:
> > Sometimes I want to see the output inspite of errors. Aborting
> > immediately if there is a syntax problem is definitely not always the
> > best solution. I fully agree with other people that it should be
> >
> Sometimes I want to see the output inspite of errors. Aborting
> immediately if there is a syntax problem is definitely not always the
> best solution. I fully agree with other people that it should be
> Frescobaldi's job to jump to the first error message (in case it
> doesn't do this already).
> But shouldn't Lilypond check first if the syntax is correct instead
> of spending several seconds/minutes compiling a code that's doomed
> to visually fail?
Sometimes I want to see the output inspite of errors. Aborting
immediately if there is a syntax problem is definitely not always the
> I strongly disagree :-)
> When there is an error, the default should be to continue as long as
> possible. For large projects where the compilation takes time, you want
> to have some viewable output even if there is a glitch somewhere. I also
> think you are overestimating the "developing
> In this context I could imagine a paramater that kind of highlights
> the first few error messages (or only shows the first N error
> messages) being very forthcoming to some people without a dev
> background. Or maybe at the end of the compilation output a clearly
> marked: "First (few?)
I think most developers are used to having a full error log - which is
definitely the right default behaviour for lilypond. On the other hand I
can fully understand that especially for users that aren't used to software
development a full error log can be quite a mess to the (untrained) eye.
In
Le 29/03/2022 à 08:46, Martín Rincón Botero a écrit :
+1. I think making it customizable (with a --cascade-level parameter)
wouldn't add much value considering developing effort, though.
Lilypond, like Python f. ex., should simply report the first error
(and ideally immediately abort
+1. I think making it customizable (with a --cascade-level parameter)
wouldn't add much value considering developing effort, though. Lilypond, like
Python f. ex., should simply report the first error (and ideally immediately
abort compilation).
—Martín.
29 matches
Mail list logo
