e very few mails of yours that do not leave me scratching my
head. And I am not exactly unversed with LilyPond, music, and
mathematics. If you want to have your mails to have any impact at all,
you need to cater for a broader audience than very, very few
specia
Malte Meyn <lilyp...@maltemeyn.de> writes:
> Am 21.02.2016 um 11:54 schrieb David Kastrup:
>>
>> So in summary: you state to LilyPond that you never want to see an
>> accidental before a natural G and you complain that you see no
>> accidental before a n
}
> \midi {}
> }
>
> this renders to
>
> http://www.kielnet.net/home/erich.meyer/fehlersuche.png
>
> As you can see , it is missing in the first two measures the sign in front
> of the G's ; in the third beat is shown a not quite correct sign.
I have no idea why you wou
n you do a more complete image,
including ledger lines and larger note values (half, semibreve, breve,
longa)?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
quires _nothing_ happening
musically during the compressed range.
Not a bug. That's by design.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
to have been a bug report already but I can't find any.
That looks like LilyPond-book being only half-functional, assuming that
the given lilybook.lytex file is well-formed (not exactly a given
either). In that case, I would suspect the culprit to be the wrong
Python version: LilyPond's Python
ed
> by lilypond-book.
Or that there was some \begin{lilypond} not properly matched by
\end{lilypond} and thus not detected by the regexp looking for _both_.
Then it would get copied to the .tex file unchanged.
--
David Kastrup
___
bug-lilypond mailing l
ranslators list
(listed in the Contributor's Guide) just in case some German contributor
is not actually lying dormant but furiously translating chapter after
chapter, in order to avoid parallel work.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
t nothing changed. Am I doing wrong? I
> don't want to offend somebody, however, what do I have to do to fix the
> mistake?
Check that your mails are present in the archive? Is there an archive?
--
David Kastrup
___
bug-lilypond mailing list
bug-li
ates a copy. #test does not
create a copy. Use ly:music-deep-copy or music-clone for getting the
equivalent of \test. Many of LilyPond's music manipulating functions
are _destructive_ in order to allow for incremental manipulation of
large/growing music expressions.
There is no inconsistency. Just
Simon Albrecht <simon.albre...@mail.de> writes:
> On 18.01.2016 17:32, David Kastrup wrote:
>> Simon Albrecht <simon.albre...@mail.de> writes:
>>
>>> In a large project I ran into the following problem: If I define and
>>> call a function in Scheme-onl
hich fits better. Alternatives could also be
> useful in cases like "ev-ery" vs. "ev'ry”. — Dan
Well, TeX has "discretionary" nodes for that sort of thing: you spell
out the unbroken version and both broken parts explicitly.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
there a TODO list somewhere?
>
> No progress, as far as I know.
>
> Nobody is willing to work on maintaining an Allura deployment. Josiah
> was the only one who seemed to have the skills and the will to do it,
> but he vanished.
This wasn't the situation
work sensibly with multiple occurences of \partial while still
warning about bad uses.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ents on to the lilypond executable, and
consequently the lilypond executable has no clue just _what_ to compile)
and follow the instructions on
<URL:http://www.lilypond.org/windows.html>, "Running on the
command-line".
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
your point well. You can easily try putting ^ before the [ beam to
check the result.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
usic function arguments apart is
tricky enough as it stands.
Would \tuplet 3/2 4 2 be a quarter triole followed by a half note, or a
half triole to be grouped in groups of quarter length?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
t matter.
I read in the manual:
Manual beams
In some cases it may be necessary to override the automatic beaming
algorithm. For example, the autobeamer will not put beams over rests or
bar lines, [...]
So the behavior is known, documented, and deliberate.
--
David Kastrup
__
The triggering assertions should likely as a first measure be replaced
by programming errors and fixed at some point of time.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ient when inserting \displayLilyMusic into
existing music expressions since it does not affect their interpretation
when printing a rendition of them.
Sometimes you indeed only want to print some expression without letting
LilyPond do anything else with it. In that case, you can place \void
before
2 cis( g-1> d2)
> }
[...]
>From the issue description of issue 4625 implementing in-chord slurs:
Output is still rather rough. Basics are there now, but the
finetuning leaves a lot to be desired.
The heavy lifting is done, but it requires further work by programme
evs will chip in here.
>
> version 2.19.32 builds fine. It maybe worthwhile to look into what has
> changed. We had this build problem of the documentation before, but I
> don't remember which 2.19.xx version
2.19.24 introduces a garbage marking problem in connection w
nt
place every time.
> Guile2 is not specific to the building of the documentation as far as
> I am aware.
The documentation is complex, and LilyPond does not work on complex
scores using Guile2. It's not more than proof-of-concept quality right
now.
--
David Kastrup
>> Should I add an example to issue 4654 anyway?
>
> Let's put relevant info in the issue on the tracker, as I've done right now.
> I'd call the info about tablature relevant, ofcourse.
>
> Although, I don't think the bug is triggered by text (vs numbers) or
> custom defined fret-tables, see my recent post there
Ok, got it.
It's only offset-fret which does the damage?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Thomas Morley <thomasmorle...@gmail.com> writes:
> 2015-11-07 0:06 GMT+01:00 David Kastrup <d...@gnu.org>:
>>
>> Ok, got it.
>>
>> It's only offset-fret which does the damage?
>
> Just investigating offset-fret.
> At first glance the return-valu
e. The formatted output will likely be the same, but avoiding
an overfull source line is better style.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
2086/
Well, some basics would certainly not be amiss, yes. I'm not overly
enthused about these statistics as they tell only a small part of the
story, but then better to tell a small part rather than nothing.
--
David Kastrup
___
bug-lilypond maili
ype
bt
at the point of failure in order to get a backtrace. This will give us
more information about the context of the assertion failure and might
suggest a reasonable path forward.
Thanks
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gn
're interested.
That looks rather messy (basically something like an invalid iterator).
I'm afraid that this one is not likely to be pinned down without an
actual minimal example since it seems to rely on a particular history of
things.
It's reproducible? Did the same file compile previously
"Phil Holmes" <m...@philholmes.net> writes:
> - Original Message -----
> From: "David Kastrup" <d...@gnu.org>
>
>> Phil, this is absolutely serious stuff, likely causing crashes for large
>> scores on most platforms. Too bad we did no
David Kastrup <d...@gnu.org> writes:
> Dan Eble <d...@faithful.be> writes:
>
>> Forgive me for being brief, but I thought I should at least mention
>> this in case someone would like to approach it with code review:
>>
>> Thread 0 Crashed:: Dispatch
ously. The force commands work until
the next force command is made unless you use a "once" form (the input
syntax has changed, but "once" is contained in one form or another in
the resulting command).
> So if you could get his attention--maybe make a donation--he could
> p
efinite changes in the last release.
So an actual input file triggering the problem would be important.
Preferably, of course, when the error would be reproducible.
Also a disassembly of Slur_proto_engraver::derived_mark() so that one
has a chance to figure out the exact instruction of th
inherited
this mess. Before \temporary, there was just "\override" which did the
same as the Scheme functions "*-set" rather than "*-override", namely
always implying pop-first = #t .
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
"Phil Holmes" <m...@philholmes.net> writes:
> "David Kastrup" <d...@gnu.org> wrote in message
> news:87twpt4rx3@fencepost.gnu.org...
>
>> The LSR version of vspace (when was this ever a good idea?) by now has
>> markedly diverged from the
he built-in variant, so it really should get
removed and its effect compensated.
So it might make sense to run
convert-ly -f 2.17.18 -t 2.17.19
on the LSR snippet (though it's possible that this has already been done
once and should not be repeated) before throwing out its own vspace
definition.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Francisco Vila <paconet@gmail.com> writes:
> 2015-10-11 9:07 GMT+02:00 David Kastrup <d...@gnu.org>:
>> Francisco Vila <paconet@gmail.com> writes:
>>
>>> 2012/3/16 Xavier Scheuer <x.sche...@gmail.com>:
>>>
eeping track of the complex relation between this kind of
line-break related killed accidental and the following one is rather
harder to pin down since the following one needs to have no vicinity to
either tie or line break.
--
David Kastrup
___
bug-lilyp
Simon Albrecht <simon.albre...@mail.de> writes:
> On 04.10.2015 16:58, David Kastrup wrote:
>> Simon Albrecht <simon.albre...@mail.de> writes:
>>
>>> perhaps this is more of an enhancement (?), but currently PNG files
>>> are output wit
Well, why would you select landscape orientation if you don't want it?
Are you sure you don't actually mean
\paper { #(set-paper-size "a10landscape") }
namely just a landscape paper format but no landscape orientation?
--
David Kastrup
___
b
David Kastrup <d...@gnu.org> writes:
>> Currently, the top level .gitignore (of LilyPond's repository) contains this
>> pattern:
>>
>> build/
>>
>> I found no pattern negating this, in any .gitignore file (at any directory
>> level).
>>
>
markdblackwell <markdblackwel...@gmail.com> writes:
>> Any chance to see an uncensored version of this on the actual mailing list?
>> --David Kastrup
>
> Thanks for that. :) Now, I've added the archive to my toolbar for future
> checking.
>
> The full text follo
Status: New
Owner: dakas
Type: Defect
Patch: new
Rietveld issue: 266150043 (https://codereview.appspot.com/266150043)
Summary:
Don't dump Midi data to screen on write error
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https
Issue 4614 [Make interpretation of `\chordmode { c:sus c:5 }` more conventional]
Status: Fixed
Tag: Fixed_2_19_28
Comment:
Pushed to staging as merge commit
* commit a226ead901d6717c99f728c6959af46734117e7b
|\ Merge: 43e591c b61b2fc
| | Author: David Kastrup <d...@gnu.org>
| | Date: S
Issue 4131 [Reimplement forced partcombine decisions via context properties]
Patch: new
Rietveld issue: 144600043 (https://codereview.appspot.com/144600043)
Comment:
Reimplement after issue 4609 makes this possible
--
David Kastrup
___
bug-lilypond
David Kastrup <d...@gnu.org> writes:
> I suddenly realized that in all other occurences of the final chord, the
> final f' was missing in the tablature versions, apparently overprinted
> by a 4 with whiteout.
Forgot to mention: this is input/regression/tablature-slurs-with-beam
e.cc.
Add ly:pure-call and ly:unpure-call functions
Remove unused function chain-grob-member-functions
Issue 4618: Correct argument handling of Unpure_pure_call::call
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.o
Issue 4610:
Patch: new
Rietveld issue: 261300043 (https://codereview.appspot.com/261300043)
Message:
Add missing brace. No idea how this escaped testing.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org
Simon Albrecht <simon.albre...@mail.de> writes:
> On 25.09.2015 21:36, David Kastrup wrote:
>> Simon Albrecht <simon.albre...@mail.de> writes:
>>
>>> Thank you.
>>> Issue 4618 has been updated.
>>>
>>>
>> [...]
&g
Simon Albrecht <simon.albre...@mail.de> writes:
> Thank you.
> Issue 4618 has been updated.
>
> Yours, Simon
>
> On 25.09.2015 16:34, David Kastrup wrote:
>> Type: Maintainability
>> Owner: d...@gnu.org
>> Status: Started
>> Patch: new
>> Rie
Simon Albrecht <simon.albre...@mail.de> writes:
> On 25.09.2015 23:09, David Kastrup wrote:
>> edit 4618 to look as
>> before, and add a new one.
>
> Done. It’s now #4620.
Thanks, and sorry for not making my intent clear pre
agline?) makes up for
something around 50 characters.
Music engraving by LilyPond 2.17.28—www.lilypond.org
52 characters, minus 4 spaces. Whoever thought the tagline was
important?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
formation?
> Could my setup be the cause?
My guess would be that you used
--enable-guile2 highly experimental GUILE 2 support. Default: off
If you did: there is a reason this is called "highly experimental" and
defaults to off, so it would definitely have b
IFIER
and that error is based exclusively on the _content_ of ")" and not
related to any independently produced warnings. For example, you can
write \] and just get
/tmp/riga.ly:1:1: warning: cannot find start of ligature
Making an error based on context-spec-music would be quite strange,
Simon Albrecht <simon.albre...@mail.de> writes:
> On 23.09.2015 16:52, David Kastrup wrote:
>> and that error is based exclusively on the _content_ of ")" and not
>> related to any independently produced warnings. For example, you can
>> write \] and
be use cases with a different number of arguments.
Rietveld issue: 262500043 (https://codereview.appspot.com/262500043)
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
tisimst <tisimst.lilyp...@gmail.com> writes:
> On 9/22/2015 9:42 AM, David Kastrup [via Lilypond] wrote:
>> Pierre Perol-Schneider <[hidden email]
>> > writes:
>>
>> >>I'm not top posting
>> >
>> > Hi
otes in them.
Which is not surprising at all. What is the misalignment you are
talking about?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
The regtests clearly show horizontal centering of TabNoteHead not
working at all.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
-note-head::print which
masked the missing default of self-alignment-X.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht <simon.albre...@mail.de> writes:
> <https://sourceforge.net/p/testlilyissues/issues/4615/>
> Needs:design?
The historic tabs you managed to dig up are quite definitely
baseline-oriented. So I think we can give this a trial in the submitted
form.
Issue 4609
Status: Fixed
Tags: Fixed_2_19_28
Message:
Pushed to staging as merge commit
* commit 313d11786149a101118f3db1ab319ca0c7b6f113
|\ Merge: bf7f767 28add69
| | Author: David Kastrup <d...@gnu.org>
| | Date: Sun Sep 20 15:16:31 2015 +0200
| |
| | Merge branch 'iss
David Kastrup <d...@gnu.org> writes:
> Type: Enhancement
> Status: Started
> Owner: d...@gnu.org
> Patch: new
> Summary:
> Make interpretation of \chordmode { c:sus c:5 } more conventional
>
>
> Contains commits:
>
> Run scripts/auxiliar/makelsr.py
&g
of sus and sus4
Change NR to reflect new equivalence of c:5 and c:1.5
Run scripts/auxiliar/update-with-convert-ly.sh
convert-ly rule c:5.x, c:5^x, c:sus -> c:3.5.x, c:3.5^x, c:5
Let \chordmode { c:5 } mean <c' g'> rather than <c' e' g'>
Let c:sus be interpreted as c:sus4
--
This is a failed assertion, so I expect the difference in behavior for
released versions to be accountable to issue 2787, version 2.19.21.
In other words, I expect the code to be equally bad before version
2.19.22 but be silent about it unless compiled with
--disable-optimising.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
)
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
b,8 r8 c r}
> >>
>
> << \tuplet 3/2 {g'8 c g'} \\
> {e, r} >>
>
> }
>
> \score {
> <<
> \new Staff {
> \lower }
>>>
> \layout {
> \context { \Staff \RemoveEmptyStaves }
> }
> }
<URL
strictly inside of the given polygon. An
extroversion value of 0 draws exactly along the given polygon, and a
value of 1 will draw just outside of the given polygon.
Rietveld issue: 261300043 (https://codereview.appspot.com/261300043)
--
David Kastrup
for that. In particular, this causes code like
{ c'1-\parenthesize\repeatTie }
to compile without spurious parens and error messages.
Rietveld issue: 26643 (https://codereview.appspot.com/26643)
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond
issue 4131 without
the principal shortcomings that stalled it.
Rietveld issue: 265180043 (https://codereview.appspot.com/265180043)
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ng music...
>
> Preprocessing graphical objects...
>
> Finding the ideal number of pages...
>
> Fitting music on 1 page...
>
> Drawing systems...
>
> Exited with exit status 1. Yours, Simon
I just pushed a trivial fix to staging.
--
David Kastrup
_
Simon Albrecht <simon.albre...@mail.de> writes:
> Am 04.09.2015 um 04:09 schrieb David Kastrup:
>> Simon Albrecht <simon.albre...@mail.de> writes:
>>
>>> Hello,
>>>
>>> consider the following example:
>>>
of offsetter into new function grob-transformer
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht <simon.albre...@mail.de> writes:
> Am 09.09.2015 um 08:28 schrieb David Kastrup:
>>
>>> <https://sourceforge.net/p/testlilyissues/issues/4597/>
>>>
>>> My ‘possibly related’ statement was only supposed to indicate that
>>>
tisimst <tisimst.lilyp...@gmail.com> writes:
> On 9/9/2015 10:57 AM, David Kastrup [via Lilypond] wrote:
>> David Kastrup <[hidden email]
>> > writes:
>>
>> > Here is the difference: The first variant adds the lyrics to \new Staff
>> > \altoOne
\voiceTwo s1 }
> >>
> }
> \addlyrics \altText
> >>
> }
> %
Sigh. It is _not_ exactly the same. Your inline example uses slurs,
your variable example doesn't.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
he \relative, it does not have a chance to
combine with \new Staff in a useful manner. So basically you get
\score {
<<
\new Staff \relative << \new Voice="xxx" { d'2 ... cis}
\new Lyrics \lyricsto "xxx" ... >>
>&g
David Kastrup <d...@gnu.org> writes:
> Here is the difference: The first variant adds the lyrics to \new Staff
> \altoOneVoice. The second variant adds the lyrics to { d'2 ... } even
> _before_ \relative is called. \addlyrics is sort of sticky. Once the
> \addlyric
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
I can't see the described problems. It seems like they were last tested
with version 2.13.15 about 6 years ago, so they had a lot of opportunity
for getting fixed.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https
.19.26 I'm on a 64-bit LINUX
> Trying with a build from master, lilyDev (32bit Debian), I do get
> substitute settings
Can you try some other font name expected to work and containing exactly
15 characters?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Thomas Morley <thomasmorle...@gmail.com> writes:
> 2015-09-05 18:37 GMT+02:00 David Kastrup <d...@gnu.org>:
>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>
>>> `/home/hermann/lilypondH/lilypond-2.19.26/build/lily'
>>> make: *** [all] F
/build/lily'
> make: *** [all] Fehler 2
I remember instances of that, usually in the context of templates.
gcc --version ?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
here, since it displays a font
>> problem (or bug).
>>
>
> Though, if 2.18.2 displays nicely (and it does), I'd tend to think
> something on our part causes this misbehahiour.
> (Ofcourse "Times New Roman" _is_ installed)
Well, at least it's not related to "
Type: Documentation
Patch: New
Owner: d...@gnu.org
Status: Started
Rietveld issue: 262310043 (https://codereview.appspot.com/262310043)
Issue description:
Doc string fix in wake of issue 4426
--
David Kastrup
___
bug-lilypond mailing list
bug
tyStaves. What should it do
instead in your opinion and why? LilyPond follows instructions here.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
<c''>^~ <c''> } { <a'>_~ <a'> } >>
\new Voice << { <c''^~> <c''> } { <a'_~> <a'> } >>
{ <c''^~ a'_~> <c'' a'> }
and the _result_ from typesetting your input is just like before issue 2240.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ilypond.gnu.org should the need
arise. I don't know if and how the subdomain management of gnu.org is
organized, so maybe we should first get agreement on which variants
would be preferable in case that .gnu.org favors one approach over the
other?
--
David Kastrup
_
://lsr.di.unimi.it/LSR/Item?id=751.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Phil Holmes m...@philholmes.net writes:
David Kastrup d...@gnu.org wrote in message
Documentation/snippets/automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly
by replacing
\override Stem.neutral-direction = #'()
with
\stemNeutral
which
David Kastrup d...@gnu.org writes:
Simon Albrecht simon.albre...@mail.de writes:
Am 26.08.2015 um 18:52 schrieb David Kastrup:
New issue 4577
Status: Started
Summary: Add StaffAxis context type
Tags: Type-Enhancement Patch-new
Rietveld issue: 265730043 (https://codereview.appspot.com
Status: Started
Omner: d...@gnu.org
Type: Documentation
Patch: new
Rietveld issue: 260960043 (https://codereview.appspot.com/260960043)
Issue description:
NR Changing Defaults: Explain sticky contexts accurately
--
David Kastrup
___
bug-lilypond
tisimst tisimst.lilyp...@gmail.com writes:
On 8/26/2015 4:45 PM, David Kastrup [via Lilypond] wrote:
tisimst [hidden email]
/user/SendEmail.jtp?type=nodenode=180230i=0 writes:
- CompositeStaff
- HybridStaff
- StaffBlend
- AssortedStaff
Maybe StaffAxis is the best one.
Of those
CollapsedStaff
\new Staff ...
\new Lyrics ...
\new ChordNames ...
seems pretty descriptive, more so than MixedStaff.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht simon.albre...@mail.de writes:
Am 26.08.2015 um 18:52 schrieb David Kastrup:
New issue 4577
Status: Started
Summary: Add StaffAxis context type
Tags: Type-Enhancement Patch-new
Rietveld issue: 265730043 (https://codereview.appspot.com/265730043)
Issue description:
Add
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
tisimst tisimst.lilyp...@gmail.com writes:
I'm not necessarily against it being called StaffAxis, but I wonder
if something like MixedStaff is more appropriate? Just thinking out
loud. I love this idea, btw.
StaffAxis
David Kastrup d...@gnu.org writes:
tisimst tisimst.lilyp...@gmail.com writes:
I'm not necessarily against it being called StaffAxis, but I wonder
if something like MixedStaff is more appropriate? Just thinking out
loud. I love this idea, btw.
StaffAxis is as appropriate as it gets
New issue
Status: Started
Summary: Add StaffAxis context type
Tags: Type-Enhancement Patch-new
Rietveld issue: 265730043 (https://codereview.appspot.com/265730043)
Issue description:
Add StaffAxis context type See the regression test for more info.
--
David Kastrup
tisimst tisimst.lilyp...@gmail.com writes:
On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
David Kastrup [hidden email]
Perhaps OneStaff?
\oneVoice _is_ sort of the name for not separating voices vertically.
I can see that, but it still doesn't seem quite right to me. As I've
. There are a number
of uses for that, for both parallel and immediately successive contexts.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
401 - 500 of 1473 matches
Mail list logo
