ge. Please, take a look at files in attachment.
>
> That file is too big. Please prepare a Tiny example, as detailed
> on our website.
I have receive in private communication the information that indeed the
event chord wrapping workaround solved this problem, so it was not at
all related t
ion issue (I think layout variables
are documented rather lousily if at all), but the behavior itself is
quite what to expect.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
efinition, from the copy of the original Score context
def.
> I now understand how this behaves when layout variables are involved.
> But I have to admit that this is quite strange and only manageable
> with some very thorough explanation.
I am not privy to the design. The only advantage I
Urs Liska writes:
> Thank you David,
> I think I got it now and will find a solution how to deal with it
> correctly and efficiently.
>
> Best
> Urs
>
> Am 21.05.2012 07:20, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Do I understand correc
Janek Warchoł writes:
> David,
>
> On Mon, May 21, 2012 at 7:20 AM, David Kastrup wrote:
>> I don't see anything wrong in the _written_ assumptions. Perhaps the
>> misunderstanding is that you consider context definitions as independent
>> from layout block
oice -- that's where I should have
> put it in the first place!
from the docs:
script-interface:
This grob interface is used in the following graphical object(s): *note
AccidentalSuggestion::, *note DynamicText:: and *note Script::.
Quite a lot of stuff created without an articulation-ty
gt;
Shiver me timbers, I should remember better. Strings are structures,
not values.
Try equal? instead.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
file directly with musicxml2ly.
>
> Changing that line into
>
> b4 \rest r8 a16 [ b16 ] | % 55
>
> solves that problem.
>
> Then, there is an e2 ~ s4. which doesn't make sense (see bar 66 in
> PartPOneVoiceSix, line 226), changing that line into
>
> e2 |
would be nice if at this point of the NR it was clearly
>> pointed out that there _are_ differences for the handling of
>> melismas.
>
> I've created a documentation tracker here:
>
> http://code.google.com/p/lilypond/issues/detail?id=2565
And I think it's important since it stops making the choice sort of
arbitrary.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
-Eluze writes:
> Colin Hall-3 wrote:
>>
>>
>> I didn't know there had a been a new release.
>>
>
> I didn't see any announcement either…
And it was a record-breaking release... Something like 25 handled
issues
tretch used for creating more lines.
> an ugliness?
Maybe. I don't think we try harmonizing total horizontal stretch
between subsequent pages. You can get a dense page followed by a loose
one. It is just unlikely without forced breaks.
--
David Kastrup
___
the EventChord changes would have been
responsible, but it does not seem so. Maybe Stem/Flag? Or was this
indeed intentional?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
nger a need to start a new implicit voice since the upper
staff already _has_ an implicit voice.
So for the lower staff, try writing
\new Voice \autochange ...
and the autochange voice will get started in the lower staff and remain
rooted there.
--
Da
Sami Amiris writes:
> David Kastrup gnu.org> writes:
>
>>
>> Sami Amiris gmail.com> writes:
>>
>> > Please run this, it is self-explanatory. It is an issue with
>> > autochange and
>> > beaming. Is it me, or a bug?
>>
>> Y
Sami Amiris writes:
> David Kastrup gnu.org> writes:
>
>>
>> There are so many things going wrong here that it is not actually easy
>> to start. This is still not a minimal example, and in fact it would
>> warrant several minimal examples.
>
> A
; and I was wrong by 3 orders of magnitude, I'd have at least 95 cents!
I may repeat myself here: invisible objects are to be treated like
visible ones: that is the main point of them. If you don't want them to
be involved in collision avoidance, set their stencil to #f.
--
David Kast
re this makes the warning disappear (but does not
let the bar appear, likely an unrelated problem).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
tly, you just are
less likely to write )word and word( than the other way round.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
"Phil Holmes" writes:
> "David Kastrup" wrote in message
> news:87sje2orzq@fencepost.gnu.org...
>> "Phil Holmes" writes:
>>
>>> But not a closing one. Given that it's impossible that it could be a
>>> slur, I think it
nfigurable;
* code formatting: add space before parentheses in Python code;
* slightly improve exceptions logic;
* add timestamps in build log.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/li
John Mandereau writes:
> Il giorno lun, 18/06/2012 alle 19.42 +0200, David Kastrup ha scritto:
>> dak@lola:/usr/local/tmp/lilypond$ ../lilypond-extra/patches/test-patches.py
>> Error: non-existent directory or directory not containing a valid Git
>> repository: No sectio
"Trevor Daniels" writes:
> Colin Hall wrote Tuesday, June 19, 2012 1:12 AM
>
>> It looks like the behaviour has been explained by David Kastrup here:
>>
>> http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00380.html
>>
>> So,
llowing highly relevant commits have happened, so
you might want to retry with current master, or with 2.15.41 once that
is released. It is likely that your problem is fixed.
commit 8a57f497f6c4f9f00c17040d3c41d30eb2d1b765
Author: David Kastrup
Date: Wed Jun 6 15:38:23 2012 +0200
Issu
David Kastrup writes:
> Rutger Hofman writes:
>
>> Hello list,
>>
>> I meet a buglet in partcombine: a slur is drawn across a rest when it
>> shouldn't. This happens with 2.15.40 on ubuntu-64bit. The bug doesn't
>> occur with 2.14.
>>
>&g
Documentation/notation/input.itely:196:@funindex \bookpart
Documentation/notation/input.itely:273:@funindex \bookOutputSuffix
Documentation/notation/input.itely:274:@funindex \bookOutputName
Documentation/notation/input.itely:346:@funindex \book
Documentation/notation/input.itely:347:@fu
Federico Bruni writes:
> Il 24/06/2012 12:50, David Kastrup ha scritto:
>> git grep -n "index book"
>> Documentation/notation/input.itely:273:@funindex \bookOutputSuffix
>> Documentation/notation/input.itely:274:@funindex \bookOutputName
>> Documentati
ent in position 1 (expecting Pitch): -10
> Exited with return code 1.
>
> This seems to be happening with all of them. Has there been a change
> in the way string tunings are coded?
Yes. Have you tried running convert-ly -ed on your files?
--
David Kastrup
Ken writes:
> David Kastrup gnu.org> writes:
>>
>> Yes. Have you tried running convert-ly -ed on your files?
>>
>
> I did. There was no apparent change, and i received the same message:
> sadly no output either.
So it would appear that your files relied
ngs-init.ly"
So in all translations of the version you have been using, the
information pointed to the right file.
LilyPond developers can't do magic and retroactively change old
documentation to match the version you are actually using. It remains
uldn't it?
\version "2.15.40"
changeBeaming = \set beamExceptions =
#'((end . (((1 . 8) . (4 4)) ((1 . 32) . (4 4 4 4 4 4 4 4)
\relative c'' {
c8 c c c c c c c
\repeat unfold 32 { c32 }
}
\relative c'' {
\changeBeaming
c8 c c c c c c
Colin Hall writes:
> On Mon, Jun 25, 2012 at 12:38:34AM +0200, David Kastrup wrote:
>> Nick Payne writes:
>>
>> > If I set beamExceptions to beam 32nd notes by fours in 4/4 time, this
>> > has the side effect of changing the beaming of 8th notes:
>> >
.
>
> Thanks, David, for helping Ken to figure it out.
>
> It looks like there is no bug to report here.
It might be a problem with convert-ly, but without an actual example I
don't see that it makes sense entering a report.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Colin Hall writes:
> On Mon, Jun 25, 2012 at 07:15:53AM +0200, David Kastrup wrote:
>> Colin Hall writes:
>>
>> > On Mon, Jun 25, 2012 at 12:38:34AM +0200, David Kastrup wrote:
>> >> Nick Payne writes:
>> >>
>> >> > If I s
Micha writes:
> In NR 2.14.2 (and 2.15) section 3.5 (MIDI Output) there is a small typo.
>
> In the sentence "Standard MIDI oputput is somewhat crude" it should
> say "output".
Pushed to staging as
commit 199b1b921ccddca6901b1e012465bc966128fc4e
Author: David
f it is "one over the denominator" in
English, you should _write_ "one over the denominator" rather than "the
one over denominator". I agree that it was both grammatically as well
as mathematically wrong before, but why not fix bo
reators of functionality put in the docs, and more likely than not,
finding out a few things that they failed to put there. That's one very
important non-programmer opening that we have that could use a lot more
talent.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
;.
>
> Thanks for reporting that problem, Micha.
>
> I've created a new issue tracker:
>
> http://code.google.com/p/lilypond/issues/detail?id=2642
>
> I see that David Kastrup has already submitted a patch to fix it.
Actually, the idea was to avoid the red tape for this obviou
int links when this is not yet
done.
While it is probably overkill to have a link that downloads and
bootstraps a LilyPond installation when not yet there, there is some
potential for making things look nicer.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
me p)))
#(display #<)
This will not work before 2.15.twentyish (when I decided that the
terrible error messages for Scheme code were not doing anybody a favor,
and made port-filename, port-line, and port-column point to sensible
locations).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
lilypond/2017-09/msg00022.html
>
> (not so recent I guess)
>
> and I didn't see any reply/confirmation of this being a bug by those that
> know about development.
Enough so that it's keeping 2.20 from being released. This needs to be
fixed
gt; doesn't include this emoji that's fine, but that isn't obvious from the
> above.
Probably depends on the Ghostscript version? Looks fine here:
ski.pdf
Description: Adobe PDF document
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
shows bar numbers in square brackets.
-dverbose might show more
>> With lilypond 2.18.2-1 it works.
>> I know you only accept "tiny examples", so if you are interested to
>> investigate this kind of bug I'll send you my input. Note that if I compile
>&g
slightly to reactivate the bug (which I'd worked
> around by making tiny changes) - but my example brings it up in only 5k
> characters (<50 bars of music).
Which operating system and LilyPond version?
--
David Kastrup
___
Paul Hodges writes:
> --On 05 May 2018 16:02 +0200 David Kastrup wrote:
>
>> Which operating system and LilyPond version?
>
> Windows 10; Lilypond 2.19.28 at the time I was having trouble.
Windows makes debugging considerably harder, and 2.19.28 is rather old
and there have b
Paul Hodges writes:
> --On 05 May 2018 17:00 +0200 David Kastrup wrote:
>
>> You'd have
>> to bring this forward to a more current version to make it worthwhile
>> looking at it closer: it's rather unlikely that anything will be
>> reasonably reproducib
the
code. I'd expect some garbage collection problem where one of the ended
and restarted contexts gets into trouble in between. Any difference
when you remove the bar checks between and before and after the
respective lines? Are any of the accidentals required for triggering
the problem?
Paul Hodges writes:
> --On 05 May 2018 19:24 +0200 David Kastrup wrote:
>
>> Any difference
>> when you remove the bar checks between and before and after the
>> respective lines? Are any of the accidentals required for triggering
>> the problem?
>
> No and
t; eip=004ea392 esp=00b0d7ac ebp=07059948 iopl=0 nv up ei pl nz
>> na po nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
>> efl=00010206
>>
>> AddrPC Params
>> 004EA392 07154BB0 05975BB0 07142110 lilypond.exe!Grob_info::context
>> 00434
oblem is as deep as a
> Python for Windows issue.
Python does not play into it. It's likely GCC and/or Guile related. I
think we comparatively recently updated the toolchain used for compiling
stuff. Can you try with 2.19.81? It was available at some other
download location (our
Paul Hodges writes:
> --On 06 May 2018 11:24 +0200 David Kastrup wrote:
>
>> Can you try with 2.19.81? It was available at some other
>> download location (our customary location was broken IIRC).
>
> You will not be surprised to know that the problem remains the
more than twice and that in
the same expression, I'd just write out segs[j + event_dir] instead and
let the optimizer do the rest. The problematic expression is then not
even generated because of short-circuit evaluation.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> Mamoru TASAKA writes:
>
>> And the attached proposal patch should fix this issue. Please review this.
>
> Well spotted but this patch is butt-ugly by calculating a nonsense
> reference in the troublesome case that is then being ignored.
>
> Sin
>
> For this very reason, I think we should keep the original way of dealing
> with Stem details by modifying the list details, even if this means an
> additional step when using flat flags style.
You don't _need_ to override the whole list. You could just override
single prop
o temporarily
> shift to accidental style 'no-reset."
>
> I can't find any information on that, how does this work?
Probably
\once \accidentalStyle no-reset
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
output is ok:
> https://lists.gnu.org/archive/html/bug-lilypond/2018-05/msg00059.html
> Are they related?
No idea. Have no clue yet where this problem originates and how it can
be suppressed.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
PostScript reads (pasted from less' display)
mark /Creator (LilyPond 2.21.0)
/Title (^A^M)
/DOCINFO pdfmark
which is the correct UTF16-LE string with BOM. GhostScript however
converts the ^M (0x0d) into ^J (0x0a), basically converting an ASCII CR
to an ASCII LF. Unfortuna
ation to show the problem, and
different versions pack the lines differently. So I doubt that the
"right" or "wrong" outcome you see depends on an actual breath-related
code passage but rather on how this particularly example is spread
across lines (or not) in the different LilyPond
0];
> %{
> %{
> (Example of a nested comment, indentation is for cosmetics (and ignored).)
> %}
> We form the sequence, following the Taylor formula.
> Note that we're operating on a vector.
> %}
> seq = d .* (x - c).^n ./(factorial(n))
That seems more like a
y are marked so
that process_acknowledged will set their right bounds to the bar that
has been created. That's all. And looking at
lily/glissando-engraver.cc it certainly looks like setting the right
bound happens before announcing the spanner end.
So I am somewhat at a loss why this should not work for glissandi.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ase.
Huh. So we'd need different right boundaries for X and for Y
coordinates. Or have glissando derive its slope from something other
than its right spanner bound, assuming that that is what it does.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
remolo 16 c'16
> ~
> \repeat tremolo 16 c'16
> }
This is misleadingly formatted since it is interpreted as
mus = {
\repeat tremolo 16
c'16~
\repeat tremolo 16
c'16
}
My own gut feeling is that c'1:16~ is su
David Kastrup writes:
> Thomas Morley writes:
>
>> 2018-06-02 13:04 GMT+02:00 David Baptista :
>>> Good morning to all, I have recently picked up an unexpected behaviour when
>>> using the articulate script in conjuction with tremolo and ties. Here is a
>>
of errors.
>
> I tried 2.19.80.1, 2.19.81.1 and current git, and all have the same
> problem. Everything works fine if I downgrade to guile-2.0.14.
Sounds like an encoding or other I/O problem with the intermediate
PostScript files. Can you use -dno-delete-intermediate-files and
compare the r
edes writes:
> el 2018-06-04 a las 01:06 David Kastrup escribió:
>
>> Sounds like an encoding or other I/O problem with the intermediate
>> PostScript files. Can you use -dno-delete-intermediate-files and
>> compare the resulting intermediate files (named rather rando
all up to date.
>
> if I understand correctly, the above will work on my local copy of
> said branch, to get it public, the updates should be pushed to the
> public branch.
>
> For pushing usual patches to staging from a local branch I use:
> git push origin HEAD:
#:box
> #:override '(box-padding . 0.6) #:box text)))
>
> \relative {
> c'1 \doubleBox "Implicitly Neutral"
> c -\doubleBox "Explicitly neutral"
> c ^\doubleBox Above
> c _\doubleBox Below
> }
doubleBox = -\markup \override #&
"not a function" though. It is a
function with constrained form, but a function nevertheless since it
takes a text/markup parameter.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Aaron Hill writes:
> On 2018-06-07 07:58, David Kastrup wrote:
>> Aaron Hill writes:
>>
>>> On 2018-06-07 06:34, Aaron Hill wrote:
>>>> Hi David,
>>>>
>>>> Correct me if I am wrong, but the second definition is ***not***
>>>&g
Aaron Hill writes:
> On 2018-06-07 10:31, David Kastrup wrote:
>>> The snippet you mentioned does not work as-is on 2.19.81, so I was
>>> curious if there was something new going on with how to define
>>> functions.
>>
>> It will in 2.21.0.
Actuall
t;
> If all you want is to write chords+lyrics, LilyPond may not be the
> best tool for this purpose.
Well, it does transpose reasonably and is capable of adding chord
diagrams.
So there is some incentive of just making it work for this use case.
--
David Kastrup
_
is is all hardwired in the page breaker and not accessible as markup
at the user level.
So definitely something that is not going to change anytime very soon.
might as well document it.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
r not spotting this at the time and the
> rest of the dev team allowing this through. I guess I am just so used
> to using the test-distance reg diff showing up only to show me the
> tests completed 'properly' - i.e if I don't see this reg test diff
> show up I know the pa
, gedit 3.28.1, kate 18.04.1, mupdf
> 1.12, xdg-open 1.1.3
>
> Every system/pdf viewer has to be installed in a way that textedit
> links are supported.
> If you e.g. use kde plasma 5 / okular you have to create a file
> /usr/share/kservices5/textedit.protocol ...
https://xkcd.com/927/>
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ootnote. Wouldn't it be better to have that
> automatically, like with automatic numbers?
A common use case is a raised mark for the reference but a fullsize mark
for the note itself. The explicit footnote mark code is intended to be
able to cater for such special cases. The only way to sens
nnot really speak
for those who have been tasked with picking up the slack. And of course
you being missed cannot be converted into an obligation for you to pick
up again what amounted to doing more than a single's person share of Bug
Squad work.
--
David Kastrup
Palmer Ralph writes:
> On Fri, Jun 22, 2018 at 8:35 AM, David Kastrup wrote:
>> Palmer Ralph writes:
>>
>>> Hi -
>>>
>>> Thanks to all of you for all your hard work.
>>
>> My impression is that you _have_ been missed but I cannot really s
through with the 2.21.0 release?
Because that could significantly narrow down the problem.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
"James Lowe" writes:
> On Mon, 25 Jun 2018 12:50:51 +0200, David Kastrup wrote:
>
>> Aaron Hill writes:
>>
>> > With the release of 2.19.82, I pulled down the latest docs in PDF form
>> > for reference. However, it appears nearly all of them have
Aaron Hill writes:
> On 2018-06-25 04:04, David Kastrup wrote:
>> "James Lowe" writes:
>>> If Aaron has specific examples (which doc, which page) then maybe I
>>> can at least confirm this on master if that is going to help or not?
>>
>> But yes
of bad parallelism? $@ stripping .de. stuff and
similar so that everything is going through the same temporary file (not
likely I guess) At any rate, it doesn't seem to be related to your
recent patches.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ant, but I thought I'd mention it):
multi-job make will serialize the output from various jobs so there is
the possibility of some things happening in parallel that look like
happening after one another.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Knut Petersen writes:
> Am 27.06.2018 um 15:08 schrieb David Kastrup:
>> As a reminder (possibly not relevant, but I thought I'd mention it):
>> multi-job make will serialize the output from various jobs so there is
>> the possibility of some things happening
reality proves something different.
Can it be verified whether or not the logs stem from a run actually
producing the respective valid and/or invalid PDF files or not?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
run actually
>> producing the respective valid and/or invalid PDF files or not?
>
>
> They are the only make doc logs on my GUB machine from the dates when
> I built 19.81 and 19.82, so they must be.
Ah ok, I wasn't aware that they were actual historic rec
hornets' nest with a stick, but
> maybe it gives at least a work around for your project.
Perhaps try running under a debugger and setting a breakpoint on
::warning (or so)? Then make a traceback when the warning is reached
(hopefully from the right point).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Thomas Morley writes:
> 2018-07-01 21:13 GMT+02:00 David Kastrup :
>
>> Perhaps try running under a debugger and setting a breakpoint on
>> ::warning (or so)? Then make a traceback when the warning is reached
>> (hopefully from the right point).
>
> Well, I don&#x
Thomas Morley writes:
> 2018-07-01 23:07 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>>
>>> 2018-07-01 21:13 GMT+02:00 David Kastrup :
>>>
>>>> Perhaps try running under a debugger and setting a breakpoint on
>>>> ::warning (o
was sure about there being some
kind of intersection.
I'll take a thorough look at this code. Looks like it could benefit
from a more graphic approach to intersections than converting everything
into zero-based polynomials and then doing root finding.
--
David Kastrup
__
Carl Sorensen writes:
> On 7/2/18, 6:32 AM, "David Kastrup" wrote:
>
>
> I'll take a thorough look at this code. Looks like it could benefit
> from a more graphic approach to intersections than converting everything
> into zero-based polyno
cumentation/internals/contexts
>
> Oh, and what about Timing? Isn’t that a context too?
Nope.
> Why isn’t it listed in the Internals Reference?
It's merely a context alias you can put in any context, not a context
type. By default Score is alias
ail down the expectations and the reasons for it, see
whether this restricts the possible forms of valid output or rather
"just" requires a certain structure to the input, something which could
be addressed using documentation.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
uessing correctly how the
user wants every conflict to be resolved?
Magic is always a great thing to wish for. Until it does stuff you
actually did not intend it to do.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht writes:
> On 15.07.2018 16:48, David Kastrup wrote:
>> What? Being able to specify two conflicting \layout definitions at once
>> and having LilyPond magically merge them by guessing correctly how the
>> user wants every conflict to be resolved?
>>
ing either music-clone or ly:music-deep-copy, but perhaps I do not
> understand those functions well enough to use properly. I would have
> expected that it would be possible to programmatically achieve the
> equivalent to \musicCopy as in my second example, with something like
> th
David Kastrup writes:
>> David mentioned two issues: using `<<...>>` top-level and using
>> unpitched notes.
>>
>> Consider the following not-quite-as-minimal example:
>>
>>
>> \version "2.19.82"
>> music = { \once
d
output in all situations, either. However, without anybody actually
testing it and telling us what is desired as output, we are pretty much
stuck.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
, but perhaps I do not
> understand those functions well enough to use properly. I would have
> expected that it would be possible to programmatically achieve the
> equivalent to \musicCopy as in my second example, with something like
> this:
Aaron Hill writes:
> On 2018-07-17 11:46, David Kastrup wrote:
>> Aaron Hill writes:
>>> I tried manually duplicating the music:
>>>
>>>
>>> \version "2.19.82"
>>> music = { \once \offset length 5 Stem c'4 c'4 }
basically one of the calls to \offset gets junked because of LilyPond
not being able to disentangle them (one could extend the code to handle
this case but it would still balk at more complex combinations).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht writes:
> On 18.07.2018 10:59, David Kastrup wrote:
>> basically one of the calls to \offset gets junked because of LilyPond
>> not being able to disentangle them (one could extend the code to handle
>> this case but it would still balk at more complex com
1301 - 1400 of 1554 matches
Mail list logo
