When I feather these beams, the third beam is simply absent. I suppose this is
a bug (or an undocumented "limitation"?), but is there a practical workaround?
I guess I also need to make the beam thickness less so that the structure
becomes more visible, though I suspect that will be
Hello and Happy New Years
> >
> > I am trying to engrave this piece as per attached, I am going crazy
> > trying to figure out how to replicate the exact beaming of the image.
>
>
>
> When you don't manage to make LilyPond understand what beaming you
> want, th
g you
want, there is an escape hatch you can use to set beams manually.
\version "2.25.0"
\language "english"
\relative c' {
\time 12/8
\key bf \major
r8
<<
{
\override DynamicTextSpanner.style = #'none
fs'16^3\cresc (a g
Hello and Happy New Years
I am trying to engrave this piece as per attached, I am going crazy trying
to figure out how to replicate the exact beaming of the image.
with this code I can make three groups of four demisemiquavers, but they
are beamed by a 8th beam, whereas I want them to be beamed b
On Wed, Dec 21, 2022 at 1:56 PM Kieren MacMillan <
kie...@kierenmacmillan.info> wrote:
> Hi Abraham,
>
> > What solution did Matthew propose for his criticisms? Just curious how
> it turned out to satisfy him.
>
> He basically said “follow Ross’s guidelines”. :)
> I haven’t had time to compare ho
Hi Abraham,
> What solution did Matthew propose for his criticisms? Just curious how it
> turned out to satisfy him.
He basically said “follow Ross’s guidelines”. :)
I haven’t had time to compare how Lilypond’s defaults compare to Ross’s rules…
Cheers,
Kieren.
On Wed, Dec 21, 2022 at 12:47 PM Jean Abou Samra wrote:
> Le 21/12/2022 à 17:16, Kieren MacMillan a écrit :
> >> According to Wikipedia, David Maslanka is a composer who died in
> 2017... ?
> > Oops! I meant Matthew, his son (who is still very much alive, and who
> was at the Salzburg conferenc
Le 21/12/2022 à 17:16, Kieren MacMillan a écrit :
According to Wikipedia, David Maslanka is a composer who died in 2017... ?
Oops! I meant Matthew, his son (who is still very much alive, and who was at
the Salzburg conference with us).
His father — whom I met several times — was a wonderful m
> According to Wikipedia, David Maslanka is a composer who died in 2017... ?
Oops! I meant Matthew, his son (who is still very much alive, and who was at
the Salzburg conference with us).
His father — whom I met several times — was a wonderful man, and a composer of
lovely music.
Kieren.
Le 21/12/2022 à 16:16, Kieren MacMillan a écrit :
Agreed. I recently hired David Maslanka to critique my engravings and
help me finalize a housestyle — the first thing he noticed and
criticized were the beams, especially all the intersections and wedges.
According to Wikipedia, David
Hi Werner,
> What's needed IMHO is an improved algorithm to better quantize
> vertical start and end positions of beams so that the number of
> grazing intersections is reduced and/or optimized.
Agreed. I recently hired David Maslanka to critique my engravings and help me
finaliz
On Wed, Dec 21, 2022 at 3:09 AM Jean Abou Samra wrote:
> Le 21/12/2022 à 01:26, Abraham Lee a écrit :
> > Is there a way to turn the stencil into a composite of the original
> > with a big block of whiteout that follows the entire group's outer
> > skyline so it hides the staff lines? Would be a
that mean
it's the way it *should* be? Or is it just a by-product of the engraving
process that now has to be dealt with? Just thinking out loud.
> What's needed IMHO is an improved algorithm to better quantize
> vertical start and end positions of beams so that the number of
&g
Le 21/12/2022 à 01:26, Abraham Lee a écrit :
Is there a way to turn the stencil into a composite of the original
with a big block of whiteout that follows the entire group's outer
skyline so it hides the staff lines? Would be a nice feature, IMO. I
know the stems can be "frenched", but would be
to remove already engraved staff lines, and the engraver
always started with drawing the staff lines.
What's needed IMHO is an improved algorithm to better quantize
vertical start and end positions of beams so that the number of
grazing intersections is reduced and/or optimized.
But maybe I
All,
When a beam group (especially 1/16 or shorter) crosses a staff line, it can
create some annoying skinny triangles that can be visually distracting.
Here's what I mean:
https://notat.io/download/file.php?id=3646
And here's an example of what the solution might look like:
https://notat.io/d
ctly, but are only
> assigned to one of the words (in the beamed group of words).
>
> The same problem occurs when I manually insert slurs.
That is as intended. \autoBeamOff suggests to LilyPond that beams will
correspond to syllables.
The chapter "multiple notes to one syllable&quo
I have researched this problem to no avail and would appreciate a help out.
When AutobeamOn is selected in the melody clef code, the words line up with
the beamed notes, as they should.
However, when I choose AutobeamOff the notes group correctly, but are only
assigned to one of the words (in the
Hello,
When answering to a digest, please don’t quote the whole digest and change the
subject to whatever you want to reply to. In this case as this does not seem
to be a reply to anything simply write a new mail to lilypond-user@gnu.org.
About your question: You can manually specify Beaming us
A quick workaround:
\version "2.23.5"
global = {
\time 6/8
\tempo "Allegro"
}
goUp = { \change Staff = "right"
\stemDown
}
goDown = { \change Staff = "left"
\stemUp
}
right = \relative c'' {
\global
\once\override Fingering.cross-staff = ##f
8-2-4 \goDown \goUp
Le 05/01/2022 à 20:59, Michael Rivers a écrit :
The fingering here collides with the tempo. If the cross-staff beams
are commented out (all notes on the upper staff), the fingering
displays fine.
Is there a workaround? Am I doing something wrong?
\version "2.23.5"
global = {
The fingering here collides with the tempo. If the cross-staff beams are
commented out (all notes on the upper staff), the fingering displays fine.
Is there a workaround? Am I doing something wrong?
\version "2.23.5"
global = {
\time 6/8
\tempo "Allegro"
}
goUp = { \c
On Wed, Nov 3, 2021 at 11:03 AM Paolo Prete wrote:
>
> Instead of suppressing the warning, given that LilyPond adds an invisible
> "auxiliary" stem to the whole notes, for creating the tremolo beam,
> I think it should be better to explicitly set the stems on both notes,
> according to the beam'
"lower" \lower
>>
}
%%%
On Wed, Nov 3, 2021 at 3:48 PM Knute Snortum wrote:
> On Wed, Nov 3, 2021 at 5:44 AM Paolo Prete wrote:
> >
> > Hello,
> >
> > I'm experiencing strange beams on cross-staff tremolos on whole notes.
> > The beam in t
Masaki, Akikazu <
masaki-0.56714...@zeus.eonet.ne.jp> wrote:
> When tremolo beams between whole notes don't work good, try to specify
> directions of implicit stems of whole notes.
>
>
> \version "2.22.0"
>
> upper = { s1 s }
>
> lower =
When tremolo beams between whole notes don't work good, try to specify
directions of implicit stems of whole notes.
\version "2.22.0"
upper = { s1 s }
lower = {
\clef treble
\override Beam.gap = 3 % a way to fix 2)
\repeat tremolo 8 { \stemUp c''&#
On Wed, Nov 3, 2021 at 5:44 AM Paolo Prete wrote:
>
> Hello,
>
> I'm experiencing strange beams on cross-staff tremolos on whole notes.
> The beam in the below snippet: 1) is not placed at the middle of the two
> notes and 2) it is too close to the ledger lines.
>
>
Hello,
I'm experiencing strange beams on cross-staff tremolos on whole notes.
The beam in the below snippet: 1) is not placed at the middle of the two
notes and 2) it is too close to the ledger lines.
Is this expected?
Is there a way to fix 1) + 2) without \tweak(ing)?
than
are in place. Also, I've left
beams which don't need this adjustment untouched - in a couple of cases
tweaking them to match the extended beams either side of them might look
better.
Thanks for the tip.
Paul
On 28/09/2021 10:14:26, "N. Andrew Walsh"
wrote:
>Hi Paul,
very affected beam, it ensures that they look good and work properly.
Cheers,
A
On Tue, Sep 28, 2021 at 11:08 AM Paul Hodges wrote:
> The composer I'm working on is very fond of having beams over rests -
> and indeed it helps a lot in reading his more complex rhythms. However,
>
The composer I'm working on is very fond of having beams over rests -
and indeed it helps a lot in reading his more complex rhythms. However,
LilyPond is treating rests differently from notes, in that beam
positions are adjusted to suit the notes, whereas rests are then
adjusted to sui
Hello,
I did an exercise for myself (invented!)
Using lyrics, piano + voice.
Lyrics do align correctly.
In this one, I separate things using variables.
It make things easier to edit and expand.
Hope it can help.
(Sorry if it is partly in French, my language...)
Le 25.02.21 à 00:29, John Helly a
quot;hel...@ucsd.edu"
*Subject: *Re: Aligning lyric syllables to notes within beams and slurs?
Thank you, Carl. I will eagerly read it.
I did send these screensnaps for exactly the reason you point out.
Did they not come through?
Screensnaps don’t help very much. We need lilypond code that
From: lilypond-user
on behalf of John Helly
Date: Wednesday, February 24, 2021 at 5:03 PM
To: Carl Sorensen , "lilypond-user@gnu.org"
Cc: "hel...@ucsd.edu"
Subject: Re: Aligning lyric syllables to notes within beams and slurs?
Thank you, Carl. I will eagerly read i
From: lilypond-user
on behalf of John Helly
Date: Wednesday, February 24, 2021 at 4:29 PM
To: "lilypond-user@gnu.org"
Cc: "hel...@ucsd.edu"
Subject: Aligning lyric syllables to notes within beams and slurs?
Aloha.
I'm working on transcribing the sheet music
Aloha.
I'm working on transcribing the sheet music for Wooden Ships (Crosby,
Stills, Kantner) into LP as a learning exercise for myself. I'm
self-taught in reading music so pls forgive blunders (but also pls point
them out).
I'm having trouble aligning the lyrics with the beaming structure
Dear community,
is there a way to avoid the collision between ledger lines and beams in the
following example:
\version "2.20.0"
Music = {
\time 6/8 \clef "treble_8"
r8 g''-> gis fis' r ais
}
\new Staff \Music
Could this be done automatically if there are
On 5/26/20, 1:14 AM, "David Kastrup" wrote:
writes:
>> Hello Valentin,
>>
>> For an unknown reason (at least unknown to me), LilyPond's default
>> beam-thickness is 0.48 staff spaces.
>
> 0.5 would likely result more often in beam thicknesses getting rounded
> up sometimes, down at other tim
supported notation fonts.
See for example
https://github.com/openlilylib/notation-fonts/blob/master/fonts/haydn-default.ily
which happens to include a setting for beams (0.7 because the Haydn
font really is a special case).
Urs
>
> @David: I’m not really sure if that is a problem here. Round
On 5/26/20, David Kastrup wrote:
> 0.5 would likely result more often in beam thicknesses getting rounded
> up sometimes, down at other times, making for an uneven look after
> digitisation.
You’re right in theory, but that doesn’t sound like a convincing
argument within the LilyPond ideological
writes:
> Hello Valentin,
>
> For an unknown reason (at least unknown to me), LilyPond's default
> beam-thickness is 0.48 staff spaces.
0.5 would likely result more often in beam thicknesses getting rounded
up sometimes, down at other times, making for an uneven look after
digitisation.
--
Dav
5
staff spaces.
Classic engravings tend to use even much thicker beams.
I don't know whether LilyPond's standard should be changed, and everyone is
free to change LilyPond's beam thickness by using
\override Beam.beam-thickness = #...
Cheerio,
Torsten
Hello,
Lilypond’s has rather light beams, i.e. the thickness of a beam and the space
between beams is pretty much the same.
In some cases such as longer distance to the sheet or bad lighting this makes
the score more readable, but in other cases, such as a medium reading distance
in good
property grob 'cause))
(tremolo?
(and (ly:prob? beam-cause)
(member
'tremolo-span-event
(ly:prob-property beam-cause 'class)
(and tremolo? (any zero? stem-durs)
%% The function tries to impro
inly unintended) effect is caused
> by the thickness of the invisible stems!
>
> The beam shortening will actually depend on the beam thickness, as the beams
> will start at the left side of the left beam and end at the right side of
> the right beam.
> For further investigation, I
the beam thickness, as the beams
will start at the left side of the left beam and end at the right side of
the right beam.
For further investigation, I've added a layout block to your example:
%%
\layout {
\context {
\Voice
\override Stem.thickness = #100 %
Am Fr., 27. März 2020 um 13:48 Uhr schrieb Malte Meyn :
>
>
>
> Am 27.03.20 um 12:23 schrieb Thomas Morley:
> > I have no clue why this happens and where those added values came from.
> >
> > Any insights?
>
> Wild guess, to be tested: ll. 558 ff. of beam.cc.
>
Hi Malte,
I had a look, alas, with
Am 27.03.20 um 12:23 schrieb Thomas Morley:
I have no clue why this happens and where those added values came from.
Any insights?
Wild guess, to be tested: ll. 558 ff. of beam.cc.
Hi all,
I tried to improve the code from
https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00265.html
but all my attempts resulted in inconsistent behaviour.
Thus I wrote some test-code, see bottom.
Obviously the beam is shortened while applying 'gap, though as soon as
'gap exceeds 2.0
))
\once \override Beam.length-fraction = #1 %should be widened for steeper
slopes
%the following two lines are supposed to make the beams shorter and move
them left, to avoid
%the accidental, or right, to avoid dots, but for some reason the beam
mov
(if rising (cons (car staff-pos-i) (cdr staff-pos-ii)) (cons (cdr
staff-pos-i) (car staff-pos-ii)
#{
\once \override Beam.length-fraction = #1 %should be widened for steeper
slopes
%the following two lines are supposed to make the beams shorter and move
them left, to a
rdier
> > :
> >
> > Dear list!
> >
> > I’m working on a piece with a lot of whole note tremolos and was wondering
> > if any of you have a nice workaround for the beams (issues 318 and 704). I
> > would like them slanted (with the same slope as a regular
ring if
> any of you have a nice workaround for the beams (issues 318 and 704). I would
> like them slanted (with the same slope as a regular beam), centered between
> the noteheads and avoiding accidentals on the second note column, but if you
> have code producing any of these res
Dear list!
I’m working on a piece with a lot of whole note tremolos and was wondering if
any of you have a nice workaround for the beams (issues 318 and 704). I would
like them slanted (with the same slope as a regular beam), centered between the
noteheads and avoiding accidentals on the
Hi Carl,
Thank you so much for the reply, I will report this in the bugs subforum.
Also, thanks for the workaround, I will use it for the moment being.
Best,
Gilberto
--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
On 1/23/20, 7:48 AM, "Gilberto Agostinho" wrote:
Hi everyone,
It seems that the beam concaveness value is ignored when beaming over rests,
in the case of a single note with a single rest. This happens with and
without stemlet. See the code and score below, the groups marke
Hi everyone,
It seems that the beam concaveness value is ignored when beaming over rests,
in the case of a single note with a single rest. This happens with and
without stemlet. See the code and score below, the groups marked with an
asterisk should have been flat (+inf.0 concaveness):
\version
Hi everyone,
It seems that the beam concaveness value is ignored when beaming over rests,
in the case of a single note with a single rest. This happens with and
without stemlet. See the code and score below, the groups marked with an
asterisk should have been flat (+inf.0 concaveness):
\version
e Staff = "upper" \crossStaff e' gis}
> }
>
> \score {
> \new PianoStaff <<
> \new Staff = "upper" \upper
> \new Staff = "lower" \lower
> >>
> \layout {
> \context {
> \PianoStaff
> \con
Hello,
I cannot get the tuplet number to appear directly above the kneed bar. What am
I doing wrong? Is it perhaps the version I am using? Thank you!
\version "2.18.2"
upper =
\relative c' {
\clef treble
\key d \major
%%%...
}
lower =
\relative c {
\clef bass
\key
On Tue, 17 Dec 2019, Paolo Prete wrote:
Here's the fixed version:
waiting for feedbacks!
(Again and again: I write these snippets really in a hurry, in these days. A more
"structured" collaboration is getting necessary for me, at this point)
Put it in a little Github project?
--
MT
Hi David,
I probably have messed something up in the editor coding style. Currently
I'm using at least three different editors ad the same time.
I know it's weird and bad, but don't have time to switch to a proper env.
In Christmas days things are even more difficult...
On Tue, Dec 17, 2019 at
at I previously
>> implemented. This time for the tuning of the beams.
>> This is too a very tedious operation to do with just the code and for
>> this I believe that this tool is also useful.
>> As you can see, the code is not only shorter than the previous one, but
>&
On Mon 16 Dec 2019 at 23:55:52 (+0100), Paolo Prete wrote:
> P.S) I don't know why the browser's viewer messes up the indentation of
> these attachments.
> If so, I ask if are there volunteers to fix that and re-post the snippet (I
> see correct indentation if I paste the code to any online js edit
time for the tuning of the beams.
> This is too a very tedious operation to do with just the code and for this
> I believe that this tool is also useful.
> As you can see, the code is not only shorter than the previous one, but it
> recycles the whole template of the previous snippet, w
On 12/16, Paolo Prete wrote:
> Hello everybody,
>
> here is another snippet that uses the system that I previously
> implemented. This time for the tuning of the beams. This is too a
> very tedious operation to do with just the code and for this I believe
> that this tool i
Hello everybody,
here is another snippet that uses the system that I previously implemented.
This time for the tuning of the beams.
This is too a very tedious operation to do with just the code and for this
I believe that this tool is also useful.
As you can see, the code is not only shorter than
Hi William,
27. Juli 2019 22:38, "William Zeitler" schrieb:
> How would I subdivide tuplets, so the triples are grouped together like:
>
> ===-===-===
You would do that manually, by setting the beamlet count for all affected
positions :-(
Unfortunately LilyPond's handling of beam subdivision
On 7/27/2019 3:38 PM, William Zeitler wrote:
How would I
Step 0: Please start a new thread, so the question doesn't get lost in
the image file format discussion.
--
Karlin High
Missouri, USA
___
lilypond-user mailing list
lilypond-user@gnu.org
http
How would I subdivide tuplets, so the triples are grouped together like:
===-===-===
(I want to do this inside a cadenza if that makes a difference)
\version "2.18.2"
\relative c' {
\time 1/4
\cadenzaOn
\tuplet 9/8 { c'16[ d c b c b a b a] }
\cadenzaOff
}
Many thanks!
William Zeitler
Hi Ben,
For the slash, may I commend to you my very well debugged and mature slash
functions in the openlilylib library? They are quite general anbd have lots
of parameters, If you don't have openlilylib already installed, it is not
daunting as people seem to think. It's easy to install and use. Y
On 7/4/2019 5:50 PM, Aaron Hill wrote:
On 2019-07-04 2:02 pm, Ben wrote:
This is the first time I've encountered the need to hide /grace note/
beams and/or stems. Can someone show me what I am doing wrong?
Here's my attempt, though it may not be the most ideal:
\versio
On 7/4/2019 5:45 PM, Shane Brandes wrote:
\undo \omit Stem
That turns it back on.
regards,
Shane
On Thu, Jul 4, 2019 at 5:07 PM Ben wrote:
Hi all,
This is the first time I've encountered the need to hide grace note beams
and/or stems. Can someone show me what I am doing wrong?
On 2019-07-04 2:02 pm, Ben wrote:
This is the first time I've encountered the need to hide /grace note/
beams and/or stems. Can someone show me what I am doing wrong?
Here's my attempt, though it may not be the most ideal:
\version "2.19.82"
\language "english&
\undo \omit Stem
That turns it back on.
regards,
Shane
On Thu, Jul 4, 2019 at 5:07 PM Ben wrote:
>
> Hi all,
>
> This is the first time I've encountered the need to hide grace note beams
> and/or stems. Can someone show me what I am doing wrong?
>
> I'm attach
Hi all,
This is the first time I've encountered the need to hide /grace note/
beams and/or stems. Can someone show me what I am doing wrong?
I'm attaching an image of what I am after.
Thank you!
Here is my code so far:
\version "2.19.82"
\language &qu
On 23.06.19 21:21, Mats Bengtsson wrote:
Is it somehow possible to tweak the automatic beaming to produce beams
that cross bar lines?
I’m quite sure that’s beyond the current auto-beaming algorithm. What
I’d suggest is relaying the beams to a music expression of their own:
\context Voice
Hi,
Is it somehow possible to tweak the automatic beaming to produce beams
that cross bar lines? I'm typesetting a piece with a syncopated rhythm
which is indicated by beaming eight notes two and two, off the beats. I
can managed to make the automatic beaming handle it within the bars
Hello everyone,
My problem comes from the incompatibility of proportionally spacing the
notes within feathered beams and the completion heads engraver. I'm trying
to achieve this result (in the manual):
But the completion heads engraver completely messes it up, forcing me to
choose a re
On Mon, Mar 25, 2019 at 7:43 AM David Kastrup wrote:
> Abraham Lee writes:
>
> > Hi, David!
> >
> > On Sun, Mar 24, 2019 at 8:38 AM David Kastrup wrote:
> >> >
> >> > Here's my first page of this piece.
> >>
> >> I'd have been interested in the second one, the multi-string passages
> >> close t
Yes, thanks. I should mention that "copying this from another source"
is a bad idea _unless_ you are creating an Urtext since things like the
fingering are copyrighted (except for quite old editions). This may be
particularly infuriating concerning the Bach solo string pieces since
a) the mor
Abraham Lee writes:
> Hi, David!
>
> On Sun, Mar 24, 2019 at 8:38 AM David Kastrup wrote:
>> >
>> > Here's my first page of this piece.
>>
>> I'd have been interested in the second one, the multi-string passages
>> close to the end. Since there are fingerings in your page, you are
>> obviously
Hi, David!
On Sun, Mar 24, 2019 at 8:38 AM David Kastrup wrote:
> Abraham Lee writes:
>
> > Hi, Chad!
> >
> > On Fri, Mar 22, 2019 at 11:19 AM Chad Linsley wrote:
> >
> >> Hi all,
> >>
> >> I’m by no means a seasoned Lilypond pro but I
Abraham Lee writes:
> Hi, Chad!
>
> On Fri, Mar 22, 2019 at 11:19 AM Chad Linsley wrote:
>
>> Hi all,
>>
>> I’m by no means a seasoned Lilypond pro but I’ve been exploring how the
>> program handles beams. In the essay, the 1950 Barenreiter Bach cello suite
Hi, Chad!
On Fri, Mar 22, 2019 at 11:19 AM Chad Linsley wrote:
> Hi all,
>
> I’m by no means a seasoned Lilypond pro but I’ve been exploring how the
> program handles beams. In the essay, the 1950 Barenreiter Bach cello suite
> edition is held up as a benchmark of high quality en
Hi all,
I’m by no means a seasoned Lilypond pro but I’ve been exploring how the
program handles beams. In the essay, the 1950 Barenreiter Bach cello suite
edition is held up as a benchmark of high quality engraving. Seeing this
really helps the user understand why Lilypond’s default slurs are
"N. Andrew Walsh" writes:
> Hi David,
>
> On Fri, Jan 11, 2019 at 5:58 PM David Kastrup wrote:
>
>>
>> Just put the whole path in "double quote marks".
>>
>
> thanks. OK, now I must confess I don't really know what was going wrong
> exactly, but I resolved the error.
You cannot "resolve" this e
Hi David,
On Fri, Jan 11, 2019 at 5:58 PM David Kastrup wrote:
>
> Just put the whole path in "double quote marks".
>
thanks. OK, now I must confess I don't really know what was going wrong
exactly, but I resolved the error.
My main file had a bunch of variables defining each instrument, and a
"N. Andrew Walsh" writes:
D> On Fri, Jan 11, 2019 at 5:21 PM David Kastrup wrote:
>
>>
>> You have to start gdb with the name of your LilyPond executable.
>>
>> --
>> David Kastrup
>>
> Ugh, OK, now it's getting confusing.
>
> Since gdb can't handle whitespaces in the path,
Just put the whole p
On Fri, Jan 11, 2019 at 5:21 PM David Kastrup wrote:
>
> You have to start gdb with the name of your LilyPond executable.
>
> --
> David Kastrup
>
Ugh, OK, now it's getting confusing.
Since gdb can't handle whitespaces in the path, I copied the whole project
directory into a new folder, and rewr
"N. Andrew Walsh" writes:
> On Fri, Jan 11, 2019 at 4:36 PM David Kastrup wrote:
>
>>
>> I cannot really find the location where this error would get triggered,
>> so indeed a backtrace in gdb would be helpful.
>>
>>
> When I get to the (gdb) prompt, I try this:
> (gdb) run /[PATH]/plus-minus\ e
On Fri, Jan 11, 2019 at 4:36 PM David Kastrup wrote:
>
> I cannot really find the location where this error would get triggered,
> so indeed a backtrace in gdb would be helpful.
>
>
When I get to the (gdb) prompt, I try this:
(gdb) run /[PATH]/plus-minus\ example\ 1.ly -file
Starting program: /[
"N. Andrew Walsh" writes:
> Hi David,
>
> On Fri, Jan 11, 2019 at 4:06 PM David Kastrup wrote:
>
>> With the given example, I get no problem with either one or both of
>> those changes.
>>
>> How about actually posting the full error message?
>>
>
> Like I said: it works fine on its own; but wit
Hi David,
On Fri, Jan 11, 2019 at 4:06 PM David Kastrup wrote:
> With the given example, I get no problem with either one or both of
> those changes.
>
> How about actually posting the full error message?
>
Like I said: it works fine on its own; but within a larger orchestral
piece, under those
"N. Andrew Walsh" writes:
> I have the following code:
>
> \version "2.19.82"
>
> \relative c' {
> \clef alto
> \override Score.Stem.stemlet-length = #0.75
> deh,2\f~ deh
>
> | %2
> deh2
> %\once \override Beam.positions = #'(2.5 . 1.5)
> c'16\rest[ deh,8.]
>
> }
>
> That compiles fine on
I have the following code:
\version "2.19.82"
\relative c' {
\clef alto
\override Score.Stem.stemlet-length = #0.75
deh,2\f~ deh
| %2
deh2
%\once \override Beam.positions = #'(2.5 . 1.5)
c'16\rest[ deh,8.]
}
That compiles fine on its own. However, in the context of a full orchestra
scor
p.s. Notice how telling Lilypond to consider the feathered measure separately
from the rest, it does something different spacing-wise (which may or may not
be what you want):
\version "2.19.82"
\layout {
system-count = 4
}
\new Staff
\relative c' {
\newSpacingSection
\override Beam.grow-di
Hi Reggie,
> Show me how as the work continues "naturally"" it would
> space out. It doesn't it's always clumpy.
[…]
> It looks terrible even worse with testing breaks.
Lilypond is satisfying the requirements you have provided, either via explicit
breaks (see your examples) or system-count (see
Kieren MacMillan wrote
> Hi Reggie,
>
>> WHy does measure now have no spacing out duration even though I use { }
>> around the whole feather area? See it works then it doesn't work.
>
> No… it works and then it still works. ;)
>
> \new Staff
> \relative c' {
> \override Beam.grow-direction = #
Kieren MacMillan wrote
> Hi Reggie,
>
>> WHy does measure now have no spacing out duration even though I use { }
>> around the whole feather area? See it works then it doesn't work.
>
> No… it works and then it still works. ;)
>
> \new Staff
> \relative c' {
> \override Beam.grow-direction = #
1 - 100 of 832 matches
Mail list logo
