David Kastrup wrote:
Personally, I am most uncomfortable with the be relative
to current settings once idea: that seems like a total
nightmare in situations using quotes or similar. The
question is where we could access a reasonably default
setting that relative references could be based on.
David Kastrup wrote:
`\magnifyStaff mag' will do these overrides:
for each shrinkable prop S,
S = (* S (/ mag old-mag))
for each unshrinkable prop U,
U =
(if ( mag 1)
(if ( old-mag 1)
U
(/ U old-mag))
as expected.
That was me. I fixed the alignment of the half-note double-stems in
tablature with this commit:
Issue 3999: Make tablature half-note stem-spacing adjustable.
authorMark Polesky markpole...@yahoo.com
Wed, 9 Jul 2014 00:04:25 + (17:04 -0700)
committer Mark Polesky markpole
Janek Warchoł wrote:
So, we can say that \magnifyStaff sets staff size to an
absolute value - defined as the fraction of the default
size - and not relative to the previous size.
Not exactly. A magnifyStaff value is only relative to the
previous staff size the first time it's used in a given
David Kastrup wrote:
but in my repository no commits authored by fred,
Really? Can you try
a281aedda8d5ea550f8b851822315cf154acee52 ?
fred even appears as an author on the savannah repo:
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=a281aed
although strangely it looks like there are
Ha! My old repo stops a day before that change. No wonder I abandoned
it... Okay, when I have some time I'll start updating the small handful of
mislabeled committishes. It's not that many.
Thanks,
Mark
___
lilypond-devel mailing list
On Dec 17 2009, with commit #05eb689, I tracked down the
birth commits for the individual manuals in order to
establish the initial years for copyright purposes:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=05eb689
But now I see that none of the commit numbers I documented
James wrote:
How is that list even generated? I can't figure it out
from the source code.
git grep 01e371f
James,
I know that the IR is auto-generated, I'm actually the one
who added the line you're referencing:
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=05eb689
What I'm
David Nalesnik wrote:
I noticed that the 'baseline-skip property works with the
InstrumentName grob, which confuses me, because in the IR
entry for IntsrumentName, none of the supported interfaces
listed at the bottom provide the 'baseline-skip property.
The stencil for InstrumentName is
David Kastrup wrote:
Does that mean that magnifyStaff would not refer to the
previous value of properties? Because if it did,
\magnifyStaff 1 would seem like a noop.
The first time magnifyStaff is called, it scales everything
as it is, so if the user does this:
%% default 'thick-thickness
I'm wondering whether I should do either of these:
1) rename \magnifyMusic to \magnifyVoice
2) change the \magnifyMusic interface to match \magnifyStaff
Regarding #2, currently \magnifyStaff can be used in a
Staff's \with block, but \magnifyMusic *can't* be used in a
Voice's \with block.
I noticed that the 'baseline-skip property works with the
InstrumentName grob, which confuses me, because in the IR
entry for IntsrumentName, none of the supported interfaces
listed at the bottom provide the 'baseline-skip property.
Should InstrumentName support text-interface, which provides
On Wed, Jul 16, 2014 at 12:01 PM, Paul Morris p...@paulwmorris.com wrote:
The best ideas I've come up with would be either resize or scale.
Since
scale could be confused with the musical meaning of scale, I think resize
is
the better option of these two.
\resizeStaff
\resizeMusic
I'm
In response to http://code.google.com/p/lilypond/issues/detail?id=3952#c7
David, here's a simplified version of the faulty workflow.
The problem occurs in step 5 where I accidentally did
`HEAD..bar' instead of `master..bar' (thinko). In step 7
the accidental reversion of the foo branch happens,
Good idea, Harm. I started a new issue to take care of that:
http://code.google.com/p/lilypond/issues/detail?id=3999
http://codereview.appspot.com/101690043/
On Mon, Jul 7, 2014 at 4:12 PM, thomasmorle...@gmail.com wrote:
On 2014/07/07 20:48:17, Mark Polesky wrote:
[...]
this raises
In response to James, this patch has moved from REVIEW to COUNTDOWN for
July 11.
Mark Polesky: \magnifyMusic - reluctantly surrender to issues 3987 and 3990.
http://code.google.com/p/lilypond/issues/detail?id=3991
Please review at http://codereview.appspot.com/101690043/
Thanks,
Mark
On Mon
Dan Keith,
NullVoice was my idea, for better or worse. I implemented it without
entirely understanding what I was doing, and I probably pushed it in too
fast, without sufficient testing. I wanted to offer users *something* to
use. Anyway, a good place to start fixing it would be to compile a
Well, that's unfortunate. Here are 3 more options:
1) We could just use my code with the arrows, omit the
verbatim, and label the examples as \fill-line and
\justify-line from within the text.
2) We could do this:
\markup \typewriter \fill-line \underline {
|
|
Here's another nasty bug that's hindering progress on my \magnifyMusic
function:
https://code.google.com/p/lilypond/issues/detail?id=3990
Any help is appreciated!
Thanks,
Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Paul Morris wrote:
Also, just a quick thought on magnifyMusic. It would be
nice to somehow capture and restore the current fontSize for
cases like this:
\new Staff \with {
fontSize = #2
} {
c'4 d' e' f'
\magnifyMusic 0.5 { c'4 d' e' f' }
c'4 d' e' f'
}
But I'm not sure how to
David Kastrup wrote:
I don't know how you are planning to do it. It would be
my guess that it is hard to do in a manner that will
behave sensibly when you put that sort of construct into
quoted music. It is probably already hard to do when
using \magnifyMusic in multiple parallel contexts
Abel, my question relates to this situation:
\new Voice \relative g' {
\temporary \override Tie.details.ratio = 0.6
g~ g
\temporary \override Tie.details.stem-gap = 0.4
g~ g
\revert Tie.details.ratio
g~ g
}
I'm looking for the \applyContext equivalent of
\revert Tie.details.ratio
Do I have permission to push trivial patches straight to staging?
Sometimes I want to fix typos and such without bothering with
an issue number and a countdown cycle.
Here's an example:
http://codereview.appspot.com/104500043/
I don't want to make waves by violating protocol, but would this
be
Can anyone help with this bug?
http://code.google.com/p/lilypond/issues/detail?id=3987
I'm at a loss, and it's hindering progress on my \magnifyMusic function.
Thanks,
Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On Wed, Jul 2, 2014 at 12:47 AM, David Kastrup d...@gnu.org wrote:
If the beam/stems were mirror images of each other, the noteheads in the
left group would be closer to the beams than the noteheads in the right
group since the noteheads are attached to the right of the stems rather
than
Can anyone help me solve this?
Why do these two beam groups have different stem lengths?
I prefer the second one, but I have no idea how to get the
first one to look like that.
\version 2.19.9
\relative c'' {
\magnifyMusic 0.5 {
c32[ c d d] d[ d c c]
}
}
Here's the current definition of
1) Slur has a default line-thickness property, so why doesn't PhrasingSlur?
2) If Slur.thickness = 1.2, why does PhrasingSlur.thickness = 1.1?
Are these oversights? Based on my understanding of classical engraving,
regular slurs and phrasing slurs would have been engraved using the same
tool.
Can anyone provide docstrings for these?
These are 5 slur.details properties that are defined in
layout-slur.scm, that are missing from the docstring at the bottom
of slur.cc.
close-to-edge-length
encompass-object-range-overshoot
extra-object-collision-penalty
what does the M mean on Rietveld?
I couldn't find an answer in their docs.
- Mark
attachment: rietveld-m.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
continued from:
http://lists.gnu.org/archive/html/lilypond-devel/2013-08/msg00436.html
Hi everyone,
I'm trying to make something like an `installed-font?'
scheme procedure, but it looks like I need a c++ procedure
first. Something like `ly_font_config_get_fonts', exactly
like the following
So, after Julien's patch
https://codereview.appspot.com/13390043
I finally get a proper error at the configure stage:
ERROR: Please install required programs: International
New Century Schoolbook fonts (make sure the fc-list
utility can see them, or use --with-ncsb-dir)
See
Julien Rioux wrote:
But now I'm curious, how do I get fc-list to see the
fonts in the gsfonts directory?
Looks like you have to run fc-cache to update the
database. Something like: sudo fc-cache -fsv
Julien and David,
I'll start by reiterating that my build now works fine, as
long as I do:
Phil Holmes wrote:
I understand the issue with colons in node names. That
was why I asked this question. I'll ask it again should
there be a documentation writer who has had this to deal
with before: what do we use for node names when there is
punctuation (specifically a colon) in a section
Janek Warchoł wrote:
mmm, this looks impressive!
Since this cannot be placed in LSR, maybe you'd like add
it to a snippet repository which I've just created
together with Urs?
http://github.com/openlilylib/snippets
(Don't worry about having to use git - everything can be
done via a simple
On -user I asked if it were possible to specify a cascade of
alternative font selections à la html/css, and I didn't get
very far.
So I'll ask here, a slightly different question: Is there a
way to implement a scheme function like `installed-font?'
where you could do things like:
(if
David Kastrup wrote:
(if (installed-font? Times New Roman)
(markup (#:override '(font-name . Times New Roman) expr))
(markup expr))
Even without a full solution, does anyone know a
direction to try with this?
lilypond -dshow-available-fonts
Okay, I traced `show-available-fonts' to
Where in the source are the chord symbols for diminished
(like °) and half-diminished (like ø) defined? Are they
glyphs, characters, markups or what? I looked but I can't
find them. And why is the half-diminished sign so much
bigger than the diminished? Is that intentional?
\chords {
c:dim
James wrote:
Moved to 'Needs Work' this countdown
3491 Enhancement Mark Polesky Needs Work Add \displayMarkup command.
...
Thomasmorely651 has some comments
James,
can you move my patch into the countdown for the 17th?
I incorporated Harm's suggestions a day ago.
Thanks,
Mark
David Kastrup wrote:
Partly that's just because potential reviewers also rely
on your decisions, so if you put back a patch from
countdown or don't even place it on one, people might just
have postponed taking a look.
With that in mind, developers should be sure to review my
patch, which is
Ledger line thickness is set with the 'ledger-line-thickness
property of the StaffSymbol grob. So then why does the
LedgerLineSpanner grob have a 'thickness property?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Dan Eble wrote:
Thanks for this hack. I look forward to trying it.
Any feelings on the likelihood that it is going to stop
working in future versions?
Hi Dan,
I totally rewrote the snippet to address a spacing issue
that I had overlooked. Will it stop working in the future?
I hope not, but
In NR 1.5.2 Multiple voices - Automatic part combining, this
appears in the Known issues:
All \partcombine… functions can only accept two voices and
are not designed to work with lyrics; such that when one of
the voices is explicitly named in order to attach lyrics to
it, the partcombiner will
Phil Holmes wrote:
We currently refer to Gardner Read and others in the NR
under the very sparsely populated Contemporary Music
section of the NR:
http://www.lilypond.org/doc/v2.17/Documentation/notation/further-reading-and-scores-of-interest
It strikes me that this would be better at the
James wrote:
Failing all that if you send me git formatted patches, I can at least
push them for you while you sort this out. We've had some checkins
today, so you will probably need to make sure that it is rebased (?)
from current master before you make the patches if you want me to push
Phil Holmes wrote:
Have you tried something like git pull --verbose?
Okay, it's working now. It asked for a password just as before,
but this time it accepted my password. Let's hope it keeps
working. Thanks for your help!
- Mark
___
Unfortunately I'm getting errors when trying to push. I
generated an SSH key long ago when I used to contribute some
years ago, but today it asked for a password which I didn't
know about (none of my usual passwords worked). I did
upgrade my Ubuntu version during the interim, so perhaps
it's
continuation of
http://lists.gnu.org/archive/html/lilypond-devel/2013-07/msg0.html
James wrote:
Hey, why isn't this patch on the countdown list?
https://codereview.appspot.com/10759043/
I posted it to -devel here:
http://lists.gnu.org/archive/html/lilypond-devel/2013-06/msg00252.html
http://lilypond.org/ is currently unavailable.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
James wrote:
What's the rush?
I never said anything about a rush.
My question was What's the right way to do this?.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I wrote:
How do I tweak an individual ledger line from within a chord?
Well, an hour later, and all I've managed to achieve is printing the
staff-positions of the ledger lines that happen to have noteheads on
them (to the standard output), and while that makes me feel like a
minor genius, it
sorry, the last post was supposed to go to -user
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hey, why isn't this patch on the countdown list?
https://codereview.appspot.com/10759043/
I posted it to -devel here:
http://lists.gnu.org/archive/html/lilypond-devel/2013-06/msg00252.html
Thanks.
- Mark
___
lilypond-devel mailing list
There are two separate issues.
1)
We don't want the old docs indexed by Google, because users who google
something like lilypond titles can end up unknowingly reading 2.12
docs, for example (currently the top match, btw).
One consequence of preventing Google from indexing old docs is that
Grahamn Percival wrote:
Eh? If I start at lilypond.org and go to manuals, I end
up on the 2.16 docs. I can only find the 2.17 docs by
going to Community-Development and scrolling down, which
IMO is correctly rather hard to find by accident.
... I just tried searching in the Notation
Hi everyone,
First of all, I'd like to thank all of you for your hard
work -- LilyPond is getting better and better!
So, I'm getting tired of abusing the TextScript,
RehearsalMark, and TextSpanner grobs to do things like
rit. and D.C., because things usually get really messy
with tweaks and
Hey guys,
Could the Hairpin grob be changed to support the
line-spanner-interface?
If not, is there a way to fine-tune the left- and
right-endpoints of Hairpins independently from the
NoteColumns?
Does Hairpin inherit the X-extent property from
DynamicLineSpanner? If so, how does a user
http://codereview.appspot.com/4670056/
Reinhold,
I think the slashedGrace function needs to be described in
the NR (1.2.6), and also preferably listed in changes.tely.
Thanks.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Not sure why, but the doc page CG 12.5 Website build
is broken on kainhofer.com:
http://kainhofer.com/~lilypond/Documentation/contributor/website-build.html
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
James Lowe wrote:
I am making a patch for some updates for Titles and
Headers and a para in the doc currently says:
Text fields left unset in a \header block are replaced
with \null markups so space is not wasted
Then there is an @c from Mark Polesky asking if this is
true?
I
Valentin Villenave wrote:
Speaking of simple melodies, you might disapprove of my
latest doc addition :-)
I Saw Mommy Kissing Santa Claus, à la Messiaen?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
In texinfo:
@cindex foo-- add foo to the concept index
@findex foo-- add foo to the function index
@kindex foo-- add foo to the keystroke index
@printindex cp -- print the concept index
@printindex fn -- print the function index
@printindex ky -- print the keystroke index
Okay, the description I wrote for the 'padding key of the
spacing alists is clearly incorrect, especially the bit
about the unobstructed (invisible) rectangle:
padding – the minimum required amount of unobstructed
vertical whitespace between two items, measured in
staff-spaces. This can be
Mark Polesky wrote:
1)
padding - the minimum required amount of vertical
whitespace between two items, measured in staff-spaces.
When available, skylines are used in the spacing
calculation.
2)
padding - the minimum required amount of vertical
whitespace between the skylines of two items
Mark Polesky wrote:
Oops, sorry about that. I had checked the regression
tests but I forgot to check the compile. It looks like
the changes I made to make-header and make-footer are
causing the problem. I'm double-checking this right now,
and I'll push a compile fix once I verify
James Lowe wrote:
Hello,
Since I pulled
407df9e0f629e1224ccac29c7ea503513e704a55
Clean up declarations-init.ly, paper-defaults-init.ly.
I am now getting compilation errors when I try to make
doc.
I don't know how to remove this from my source code to
verify this, but as this is the
David Kastrup wrote:
We can define all of these as exact quantities:
guile (define mm 1)
guile (define cm (* 10 mm))
guile (define in (* 254 (/ mm 10)))
guile (define pt (/ (* 100 in) 7227))
Probably nice.
This is easier to read, and numerically the same, right?
(define mm 1)
(define cm
Carl Sorensen wrote:
Yes, very nice! I had forgotten that fractions were
exact, too. [...] You might want to consider
(define pt (* 100/7227 in))
Since the point is defined in terms of inches, instead of
mm.
Good point. Now, which of these three sets is best (or at
least preferred),
David Kastrup wrote:
mm = #1.0
cm = #(* 10 mm)
in = #(* 25.4 mm)
pt = #(/ in 72.27)
Wouldn't pt = #(/ (* 2540 mm) 7227) have smaller absolute
error? The current definition of pt has to round 25.4 to
the nearest presentable number, 72.27 to the nearest
presentable number,
James wrote:
I was really making the point from a 'documentation' point
of view. We have some conventions in the doc that may not
necessarily be THE only way of doing things - for example we
ask for the use of { } in certain cases that are not
*required* but are a documentation convention.
James wrote:
If you search in the NR for ragged, you'll find it is
pretty much interchangeably used in the paper{} block
and the layout{} block. Is one correct and the other
deprecated? Are both correct, and if so why?
Something for GLISS?
I don't think anything needs to be changed, but
Any reason why the 'page-breaking \paper variable tends to
be declared with a scheme definition? I typically see it
like this in the docs:
#(define page-breaking ly:minimal-breaking)
I prefer to use this form though:
page-breaking = #ly:minimal-breaking
In my commit b0a027f, I changed the
I found these in paper-defaults-init.ly:
#(define make-header (...))
#(define make-footer (...))
#(define font-defaults '((...)))
#(define text-font-defaults `((...)))
1) Do we need the quasiquote ` for text-font-defaults?
Wouldn't a regular quote ' be fine?
2) Are these \paper
Valentin Villenave wrote:
I did do my homework and have a look at the texinfo
manual, but I thought this was just escaped characters.
Either way, the syntax wasn't quite consistent since there
were some refs with @/ escaping, others without and this
wasn't mentioned in the CG at all. (dots
Valentin,
I'm a little puzzled by your recent patch 1b832d7
Doc: clean up @file{} entries. In the commit description,
you say you're escaping such characters as `.', `/' or
`-'. But the only thing I see in the diff are some 900
additions of
@/
which is the texinfo command to allow line
Trevor Daniels wrote:
...I'd prefer a blank line before and after every @item
including the first one...
+1
But only because I'm too lazy to fix the paragraph
formatting command in Vim (gqap), which turns this:
@item
line 1 here could join
line 2 here
into this:
@item line 1 here could join
Patrick McCarty wrote:
For this situation, I would arrow down to the second line
and type `J' to join the lines.
Or, if there is more than one line to join, and I have a
specific `textwidth' setting, I would do a linewise
highlight (with `V j j j' etc.) and type `gqap'. If the
paragraphs
Mark Polesky wrote:
In fact, we literally have thousands of cases:
$ git grep -c ^...@item\s*.\+ |
sed -n 's/.*://p' |
awk '{total+=$0}END{print total}'
5103
Now I see a thinko in my regex, which counted all instances
of @itemize. But fixing that still leaves thousands, so the
point
These are essentially \paper variables, right?
oddHeaderMarkup
evenHeaderMarkup
oddFooterMarkup
evenFooterMarkup
You have to set them in the \paper block, it seems, so I
would like to categorize them alongside things like
system-separator-markup. Would that make sense?
So maybe this is
James Lowe wrote:
Looks like it will be fairly straightforward in this
case, but let me know if you want help with that
process. I figure I should help you there, since I'm
the one who introduced the conflicts.
If it's not too much trouble I'd appreciate that.
1) Make sure the local master
Graham Percival wrote:
The vertical space renaming uses
@rule ((2, 13, 36))
but that should be 39. Unfortunately, simply updating
this value in python/convert-ly might cause problems when
previously-updated files (now incorrectly tagged as .36)
try to be updated to .39 again.
I'm
I see that interfaces come to the IR from at least three
different types of places:
1) lily/[grobname].cc (e.g. accidental)
2) lily/[grobname]-interface.cc(e.g. align)
3) scm/define-grob-interfaces.scm (e.g. ambitus)
Is there a system to this organization? Is it optimal?
It's
Neil Puttock wrote:
Scheme definitions are only used for interfaces which
either have no code (e.g., dynamic-interface) or have
callbacks defined solely in scheme.
You probably think this is silly, but any objection to me
adding this near the top of define-grob-interfaces.scm?
;; The
James,
I just pushed my patch which renames the vertical spacing
grob properties, which directly affects your patch here, and
will likely require resolving conflicts in git (which can be
annoying sometimes, especially when you haven't done it
before). Looks like it will be fairly straightforward
Joe,
all votes are in except yours, which is kind of a moot point
anyway, since (if you're still up for it) you'll be the one
actually making this change:
1) basic-distanceminimum-distance
2) initial-distanceminimum-distance
3) basic-separation minimum-separation
4)
Should @seealso go at the end of an @unnumberedsubsubsec, or
only at the end of the entire @subsection?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Keith E OHara wrote:
We will use this in context that makes that first
qualifier almost redundant :
\override Context.StaffGrouper #'withingroup-staff-staff-spacing
This is an excellent point, and in response I'd like to
propose one more option -- just remove the withingroup
prefix altogether:
Trevor Daniels wrote:
relatedstaff/unrelatedstaff
Okay, I think enough votes are in to finalize the most
recent proposal:
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html
So relatedstaff/unrelatedstaff it will be. I'll have more
time to start making this change later
After polling some of you individually, the clear winner is
to change the 'space key to 'basic-distance. Joe, can you
take it from here?
Thanks all.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Trevor Daniels wrote:
Mark, since you were the only one to vote for this openly
and Carl, Alexander and I didn't (well, Carl did
initially, then changed his mind) perhaps you need to be a
little more open about the voting process or you'll have
Valentin after you :) Since you chose to have
Oops, forgot to actually *add* Joe to this!
* * * * * * * * * * * *
Mark Polesky wrote:
Okay, I think enough votes are in to finalize the most
recent proposal:
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html
I almost forgot... Can we have one last vote among these
two
You guys are going to *hate* me for doing this, but I just
thought of a way to keep the StaffGrouper grobs consistent
with each other.
Instead of these two:
withingroup-staff-staff-spacing
staffgroup-staff-spacing
we could have these:
within-group-staff-staff-spacing
7 proposals for renaming the 'space alist-key have been
discussed, but a decision has not yet been made. And I just
added an 8th proposal (initial-distance).
The discussion began with the 7 posts starting here:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00085.html
...and
Carl Sorensen wrote:
9) initial-separation
* longer but describes the meaning more accurately now
we have an item-item-spacing format
I vote for 8 or 9.
9.
Does this entail changing 'minimum-distance to
'minimum-separation? I prefer both to use the same noun.
- Mark
Okay, it looks like we're converging here...
Renaming proposals, round 4:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-relatedstaff
inter-loose-line nonstaff-nonstaff
Keith E OHara wrote:
I had imagined you would simultaneously change
staff-affinity (UP / DOWN / CENTER)
toreference-direction (UP / DOWN / CENTER)
so we can remember that this direction tells us which
staff is which between referencestaff and oppositestaff.
I think staff-affinity
In case anyone cares, I finally was able to determine the
reference points for the individual non-staff lines. Here
they are:
CONTEXT REFERENCE POINT
--- ---
ChordNamesbaseline
NoteNames baseline
Lyricsbaseline
Dynamics vertical center
FiguredBass
Trevor Daniels wrote:
I'd prefer to see your image in the docs rather than text.
I don't think Graham will let the image in without the text;
and there's *no way* we're using [verbatim] for this one,
since the code is way too hefty for this section. I'd be
okay with or without the image. I
James wrote:
Unless we really explain this properly in the docs what
this term actually means, it really does put a lot of
people off (i.e. me).
There are two rather large doc patches already under
construction (and being discussed) to address this:
http://codereview.appspot.com/2758042/
(trying to make this as painless as possible...)
Renaming proposals, round 2:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-staff
inter-loose-line nonstaff-nonstaff
Guys,
Here are my proposals for renaming the properties related to
Vertical spacing inside systems.
* * * * * * * * * * * * * * *
I've thought about it, and I think I slightly favor the term
loose line over non-staff line; the word loose is
distinctive and much less likely to get tangled up
1 - 100 of 695 matches
Mail list logo
