Re: Beautify Grob_array and stop using std::vector::data() (issue 264950043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Sat, 05 Sep 2015 17:49:44 -0700,  wrote:


I have simply removed the comments warning about filtering
ordered arrays.


That seems to be correct.  Those comments were incorrect.
The filter_map* functions do not, in fact, change the order of the array under 
the meaning of 'ordered_'.  Pál's comment makes sense.

There is no sorting method in Grob_array so there is no reason to suspect that the member 
'ordered_' has anything to do with order under a sorting criterion.  Looking at the 
commits that touch 'ordered_' it is clear that its meaning was "this array should 
stay in its current order" and that removal of elements doesn't count as a change in 
order and substituting Grobs inherit the order the Grobs they replace.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Issue 4059: Document MIDI mapping and MIDI effects (issue 249980043 by tdanielsmu...@googlemail.com)

[Keith OHara]

On Mon, 06 Jul 2015 15:19:20 -0700,  wrote:


Setting
midiChannelMapping to 'voice often prevents the context properties
from having effect."


Doesn't the paragraph under 'voice above explain explicitly what
happens?  That seems better than the rather vague "often prevents the
context properties ...".  There already is a reference back to that
explanation.



I didn't think the paragraph under 'voice sufficiently discouraged its use.  It 
describes a first-approximation of the behavior, but the description isn't 
complete, and the behavior isn't transparent:
\score{
  \new Staff <<
\new Voice = "violin" {
  c'4
  % set the voice below to flute
  \set Staff.midiInstrument = "flute"
  r g' r }
\new Voice = "flute" {
  % set the voice above to violin
  \set Staff.midiInstrument = "violin"
  r4 c' r g' } >>
  \layout{}
  \midi{\context {\Score midiChannelMapping=#'voice }}

I don't think midiChannelMapping='voice has any use.  Somebody added the code 
under sponsorship from Fruity Loops Sequencer, so if it has any use it is in 
conjunction with that software, so let the sponsor document it there.

That programmer who added the code didn't know about Lilypond's 
engraver/performer method of routing events and property-changes to output, and 
didn't know much about midi, so the data flow doesn't make much sense in the 
context of Lilypond and MIDI.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Avoid treating x as relative in \relative { \autochange {x} } (issue 250170043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Sat, 04 Jul 2015 05:45:04 -0700,  wrote:


Nobody knew \autochange was broken until Thomas found an unused
variable, so these test are useful if \autochange is useful.



Well, \autochange could have been useful, even to users of \relative if they 
used their \relative inside the \autochange.   You don't have a very strong 
argument for yet another regression test.

It is nice if the behavior matches the documentation, and if it stays that way.
Your method of "these two measures should look the same" helps a lot.

You could make the music look a little more normal, though:

% \autochange needs to be given pitches in their final octaves,
%  so if \relative is used it must be applied inside \autochange.
% The pitches in \autochange are unaffected by an outer \relative,
%  so that the printed output shows the pitches that \autochange used.
\new PianoStaff {
  \autochange \absolute {g4 c g' c}
  \relative \autochange {g4 c g' c}  % relative is ignored
  \autochange \relative {g4 c, g'' c,,}
}


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)

[Keith OHara]

On Sat, 20 Jun 2015 22:28:13 -0700, David Kastrup  wrote:


"Keith OHara"  writes:


Some people don't like side-effects in loop-control conditionals

 while (scm_is_pair (scm_cdr (signature)) //  more slots ?
&& scm_is_pair (scm_cadr (signature)) // next one optional ?
&& (signature = scm_cdr (signature)));// deal with it now.


Count me among "some people" here.


Me too.  A minute after I sent this I thought of a simpler way at
https://codereview.appspot.com/247190043/


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)

[Keith OHara]

On Mon, 08 Jun 2015 18:04:44 -0700,  wrote:


No dice.  The main problem is dealing with all combinations of running
out of signature and running out of available arguments.  If you treat
the optional argument skipping in an inner loop, you may still run out
of signature, and in that case you still need to treat the case where
you have simultaneously run out of arguments (namely because the
non-matching argument triggering the skipping was \default aka
*unspecified) separately _and_ break out of all loops.  Since you have
already fetched the next signature bit (since you would not know whether
it was optional and skipping should continue), you can't return to the
main loop which would fetch it again but need to clad the whole in one
while (scm_is_false (scm_call_1 (pred, arg))) of its own.  Treating all
the terminating condition combinations in inner loop and outer loop
separately causes the control structures to fray apart more than the
"skipping" flag does, to the degree where the cleanest solution to
handle one of the innermost loop termination conditions with a goto
statement.


Well, the inner loop can decide whether to continue by peeking-ahead at the 
next entry in the signature.  Then the jobs of the inner/outer loops remain 
clean.

Some people don't like side-effects in loop-control conditionals

 while (scm_is_pair (scm_cdr (signature)) //  more slots ?
&& scm_is_pair (scm_cadr (signature)) // next one optional ?
&& (signature = scm_cdr (signature)));// deal with it now.

so maybe I'll use test-in-the-middle loop, but that needs only break one loop.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: simple-spacer: inappropriate assert; issue 4448 (issue 249820043 by k-ohara5...@oco.net)

[Keith OHara]

On Fri, 19 Jun 2015 23:59:11 -0700,  wrote:



https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc
File lily/simple-spacer.cc (right):

https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc#newcode199
lily/simple-spacer.cc:199: programming_error ("misuse of expand_line");
Any sensible fallback behavior for this "misuse of expand_line"?  If we
can reliably guess what the intent of the "misuse" is (after all, it
would appear that the situation comes about from reasonably regular
input rather than explicit user error), one could just do that and
forget about the programming error.


These two asserts cannot be triggered in current code, except maybe through 
roundoff error, because the only calls of the function are protected my 
matching conditionals in Simple_spacer::solve()

The third assert is the one that trips (windows-only).



Is there something reasonably "continuous" one can do so that small
errors lead to small offsets?


The following line obviously returns a quantity that changes continuously 
across the assert condition,
so I am 90% sure you are defying national stereotypes and using irony.

In that case, yes, I do think the behavior that was being protected against is 
so benign that there need be no traps at all for these conditions.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: balloon-text: robust with empty stencils; issue 4447 (issue 243610043 by k-ohara5...@oco.net)

[Keith OHara]

On Fri, 19 Jun 2015 23:50:50 -0700,  wrote:


https://codereview.appspot.com/243610043/diff/1/lily/balloon.cc#newcode94
lily/balloon.cc:94: b.widen (padding, padding);

Basically we have two options here: not draw a box at all (it would be
my guess that this is probably what happened previously when assertions
were disabled) or draw a box around the not-with-stencil anchor point.


The former behavior leaked NaNs and corrupted spacing on the whole line.

This is for the situation where a user, through misunderstanding or oversight, requested 
an indicator box be drawn around an object that does not actually appear in print.  A 
tiny empty box says clearly "I heard you ask for a box, but I didn't recognize or 
find what you wanted me to draw it around."


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)

[Keith OHara]

On Sun, 07 Jun 2015 23:09:31 -0700,  wrote:


So your problem appears to be that you understand the code but it does
something you did not expect.  Cross-check from the user end with the
"Extending LilyPond" guide's explanation of optional arguments.


It is Extending section 2.2.2.  Yuck.  A comment pointing to Extending-2.2.2 
would help.

The behavior in the parser is forced because LilyPond uses no delimiters for 
the arguments to a function.  Scheme has delimiters so you know where the end 
of the argument list is, so we could use a simpler rule for optional arguments 
in Scheme interface.

Or you could scan arguments using a recursive-descent method in C, so the 
parallel with the parser is maybe a bit more clear.

Or maybe advance through 'signature' to the next non-optional argument 
immediately upon using a default value, rather than setting 'skipping'.

The re-structuring I suggested was intended also to change the if-else 
branching so that you don't need the 'continue's.


https://codereview.appspot.com/244840043/



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: add stencil-whiteout-outline function (issue 236480043 by paulwmor...@gmail.com)

[Keith OHara]

On Mon, 01 Jun 2015 19:29:41 -0700,  wrote:


scripts/auxiliar/update-with-convert-ly.sh
I get this:

make: *** No rule to make target `python-modules'.  Stop.
xargs: ./out/bin/convert-ly: No such file or directory
xargs: ./out/bin/convert-ly: No such file or directory

I'm running LilyDev3 in a virtual machine.  (Feeling like I'm in over my
head with this one.)


Looking at the first few lines of update-with-convert-ly, it looks like it 
expects you to have defined the build directory as BUILD_DIR where most other 
scripts expect LILYPOND_BUILD_DIR.  Maybe

export BUILD_DIR=$LILYPOND_BUILD_DIR



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: git-cl upload has stopped working (so has patchy)

[Keith OHara]

Trevor Daniels  treda.co.uk> writes:

> The next step is to decide our preference: do we want to take on the
> commitment to maintain Allura ourselves or use the maintained version at
> SourceForge.  Which would we prefer?  (FWIW my preference would be
> to run Allura at Savannah as our primary DB, with a backup being maintained 
> at SF, which I would be happy to do on a monthly basis.)
 
I just read the threads since March on this topic.
I'm not willing to help with administration, so appreciate everyone who is.
If running Allura on savannah.gnu.org is possible that does seem best.

There is another fallback in the native bug-tracking on Savane.
It does handle a larger project
 https://savannah.gnu.org/bugs/?group=octave
and accepts images, but you have to click the attachment links to see them
 http://savannah.gnu.org/bugs/?func=detailitem&item_id=28346
The user interface is nostalgic, but usable.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: add stencil-whiteout-outline function (issue 236480043 by paulwmor...@gmail.com)

[Keith OHara]

On Sun, 31 May 2015 05:03:05 -0700, Simon Albrecht  
wrote:


(A convert-ly rule may be needed… maybe in any case to
change whiteout to whiteout-box? ...or maybe not?)


Looking at the existing uses of \whiteout Xxx.whiteout, it does seem
best to leave the plain box whiteout in existing scores. Convert-ly to
\whiteout-box one way to preserve the behavior, but it would be better
to leave the old markup function \whiteout for the old behavior, and add
\whiteout-outline.

If I may chime in here: I think this is unnecessarily conservative. The
new method for whiteout is certainly much more elegant and more what one
would expect in the first place, than the method we have been using.
It’s rather going to be special cases in which \whiteout-box would be
preferable, and in most cases it will be \whiteout-outline, not the
other way around. \whiteout-outline is just a bit too clumsy to be used
for what is a real improvement.


The markup-function name could easily be shortened so something like \outline.

Searching mutopiaproject.org for 'whiteout' I found a few uses like this
  \markup \whiteout \pad-markup #0.4 \dynamic ff
which work differently with the new behavior so the padding no longer affects 
the white-out dimension.  That is what made me more conservative.  A convert-ly 
rule to preserve the old behavior would be fine.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Master fails to compile

[Keith OHara]

On Thu, 28 May 2015 01:36:54 -0700, David Kastrup  wrote:


"Keith OHara"  writes:


I had an old RedHat installation with gcc updated as far as I could to
4.6.  In the next few weeks I'll find some reasonably-modern linux.


Well, using no longer supported systems with network access (and it's
pretty hard to work on current LilyPond source without network access)
is a security nightmare.  Old GNU/Linux installations are actually
pretty popular as mail hubs for malware distribution.



Updating most software, was no problem, even synchronizing to the release of 
the whole distribution.  But gcc and glibc tend to lag behind.  The latest 
Centos that works on a 32-bit i386 is CentOS 6.6 (supported through 2020) with 
gcc 4.4.7.  I'm looking into switching to Debian.


The tricky bit about the function template in Smob_base template  static SCM smob_trampoline (SCM self) is the way
it creates functions in Smob_base that call member functions of the
derived classes like Listener.  Following what happens requires a lot
of flipping back and forth between header files.


Smob_base may not be the best place.  I remember wanting to put it in
Dispatcher itself at first and I got some private/protected thing in the
way.  But it might make more sense to pierce the encapsulation with some
sort of "friend" declaration (if unavoidable) rather than move the whole
functionality there.



If you can define the trampoline as a static member of the class whose member 
function is being called, that will be less surprising.   It might be a bit 
ugly to have the boiler-plate code in each derived class that uses the 
mechanism, but the boilerplate is recognizable if we can see it all at once.
   LY_DECLARE_SMOB_APPLY_INIT(smob_apply_trampoline, 1, 0, 0)
   static SCM smob_apply_trampoline(SCM self, SCM arg) {
 return unsmob(self)->listen(arg);
   }
   SCM listen(SCM ev) {
...}


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Master fails to compile

[Keith OHara]

On Mon, 25 May 2015 23:10:17 -0700, David Kastrup  wrote:


Keith OHara  writes:


If I can't get the dependencies worked out I'll be tempted to skip
the macro and use scm_call_1() through scm_call_3() in place of each
of the three macro expansions.


Why?  Seriously.  10.04 is not even supported by Ubuntu itself any more.



Phil has the Ubuntu.  I had an old RedHat installation with gcc updated as far 
as I could to 4.6.  In the next few weeks I'll find some reasonably-modern 
linux.

The tricky bit about the function template in Smob_base
  template  static SCM smob_trampoline (SCM self)
is the way it creates functions in Smob_base that call member functions of the 
derived classes like Listener.  Following what happens requires a lot of 
flipping back and forth between header files.

It took me quite a while to figure out why you register with scm_set_smob_apply() a 
static member function of Smob_base rather rather than something in 
Listener directly.  After a while I concluded that the goal was to put the trampoline 
code all in one place.  This seemed odd as the general-case (four cases) trampoline 
outnumbered the use cases.

You might want to expand the macro in-place, and follow each expansion with the 
definition of the trampoline function  --  or let the routine implementing "apply 
smob" be a static member function, so it serves as its own trampoline.  Hundreds of 
times, even.  Once for every Smob-derived class, even.

It's just the balance between code duplication and obfuscation.


I have a patch cooking that will convert hundreds of Scheme callbacks to
member functions with that technique.  Part of the reason is to get
argument type checks in for stuff like

(ly:grob::stencil-height 0)

which just segfaults right now.  Having a member function instead of a
static member makes the code simpler while the static template generated
by this technique does the typechecking while creating a this-pointer
from an SCM.  And if you call the member function via C++ with an
existing instance pointer, you bypass the typechecking.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Master fails to compile

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> 
> I've managed to work out how to upgrade Ubuntu 10.04 to gcc 4.8.1 
> with the help of StackOverflow, and can now compile again.

I'm still working on sorting out dependencies.

The troublesome macro asks is used in only three places, creating
in each place a templated function call with the same name, asking
the compiler to call the correct one of four variants of the function
based on the argument count of a passed function pointer.

If I can't get the dependencies worked out I'll be tempted to skip
the macro and use scm_call_1() through scm_call_3() in place of each
of the three macro expansions.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PDF is broken for notation{} encoding

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> >> > whenever we use   notation{text}, then there is a paragraph break 
before
> >> > the "text".  It took a while to figure out the guilty commit, but it is
> >> > 9f3c7711bb73baf3aea8502227fb5fd2d2851753: "update texinfo.tex from
> >> > upstream".
> >> >

I think you found the correct cause, but I cannot see how it causes this
exact problem.  Every macro defined in our include-files *macros.texi is
preceded by an extra line-break.  The pdfs on the webpage show the problem.

The change to texinfo was requested here
http://lists.gnu.org/archive/html/bug-texinfo/2015-04/msg00037.html
and made here
http://lists.gnu.org/archive/html/texinfo-commits/2015-04/msg00030.html
but that change makes 'active' in the TeX sense a range of characters
that are non-printing in Latin1.

If I could remember how to run texinfo on a 5-line example file, I might
send a bug-report to texinfo


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5a5a oco.net)

[Keith OHara]

Wols Lists  youngman.org.uk> writes:

> On 23/05/15 23:39, Keith OHara wrote:
> >  googlemail.com> writes:
> >> > I'd prefer the syntax and options to parallel those of
> >> > \relative.  That is, an optional prefix pitch to indicate
> >> > the starting octave, and taking the starting octave from
> >> > the first contained note if the prefix is omitted. 
> 
> > We could implement this, but ...
> 
> Is this a good idea though? 

I think not, and everyone seems at least content to do without this
behavior, at least for now.  (I wasn't sure until now which behavior
you were favoring, in the case of an omitted reference pitch.)

> If I want "\fixed c {}" but my first note
> just happens to be d' then it's going to be a pain. 

Well, the pain is limited to that involved in typing the explicit 'c',
or the extra few letters in \absolute

We will have the following choices, out of which maybe will emerge a
second pattern as generally useful as many people find \relative{} :

\absolute {\key g\major \clef alto \time 3/4
| d'8 d' b4 d' | b g a8 b8 | c'4 a d' | b g4. d'8
| d'4 b d' | b g a8 b8 | c'4 a d' | b g2 }

\fixed c {\key g\major \clef alto \time 3/4
| d'8 d' b4 d' | b g a8 b8 | c'4 a d' | b g4. d'8
| d'4 b d' | b g a8 b8 | c'4 a d' | b g2 }

\relative {\key g\major \clef alto \time 3/4
| d'8 d b4 d | b g a8 b8 | c4 a d | b g4. d'8
| d4 b d | b g a8 b8 | c4 a d | b g2 }

\relative d' {\key g\major \clef alto \time 3/4
| d8 d b4 d | b g a8 b8 | c4 a d | b g4. d'8
| d4 b d | b g a8 b8 | c4 a d | b g2 } 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: pure/impure?!?!

[Keith OHara]

On Sun, 24 May 2015 01:55:30 -0700, David Kastrup  wrote:


Anyway: how do impure functions reference (and trigger?) line breaks?


Non-'pure' functions reference line-breaks very indirectly.  Spanners are 
broken into two or more grobs at line-breaking, so their functions work on the 
split Grobs that have a line-break column as a bound.

I would have to trace to find the path whereby functions trigger line-breaking. 
 I think the path is when the Y-extent of a Grob depends on the Y-extent of a 
VerticalAxisGroup.   The pure version of the VerticalAxisGroup.Y-extent uses 
functions like rest_of_line_pure_height(,start,end) while the non-pure version 
ends up calling generic_group_extent(), which I suspect eventually calls the 
line-breaker.

The facility for any 'pure' estimate of a property to depend on the start/end 
columns seems to have started with the *_of_line_pure_height() of 
VerticalAxisGroups.  I cannot think of any other object for which they are 
used.   The 'start'/'end' parameters are passed down the call stack, so if a 
'pure' property depends ultimately on the Y-extent of a VerticalAxisGroup, it 
would need a sensible start/end pair; I do not know of a case where the 'pure' 
call-chains for properties of Items (as opposed to Spanners) ask for 
VerticalAxisGroup dimensions.

Conceptually, the height of the arc of a slur could be estimated for a 
potential line-breaking, but that has not been implemented.  If in the future 
we implement that, it seems that the control logic that is evaluating potential 
line-breaks would need to provide start/end information, or better the 
horizontal positions of the slur bounds, to the height-estimator for the Slur; 
I cannot imagine a way for Slur to seek out the potential line-breaks.

But I think we can remove the 'start'/'end' parameters from 'pure' functions 
for Items.  Items have a 'pure' version of their functions as a way to promise 
that these functions *not* depend on line-breaking.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: pure/impure?!?!

[Keith OHara]

David Kastrup  gnu.org> writes:

> Ignored or not: those are values indicating breakpoints of the current
> system.  They should not even be available for functions evaluated
> before any line-breaking.  Or maybe they are called for one of a set of
> tentative not-final line breaks, but in that case it would make little
> sense to call the post-linebreak (impure?) functions without the actual
> linebreak information.
> 

Yes.  The parameters 'start' and 'end' let the page-breaking code
estimate how tall each system will be by calling the pure-height function
on each VerticalAxisGroup, which might call pure-height on its contained
spanners like Slurs, whose height could depend on where the line-breaks
are.  The results are cached in a hash table indexed by the start/end pair.

The idea was to consider line-breaks and page breaks simultaneously, to
find the best overall page layout.  In practice, this does not work very
well because 1) there is no time to do a trial horizontal spacing for
each line-break set, so the page fit is evaluated with conservatively 
estimated heights of systems only, not skyline  2) in frenched scores,
where well-chosen line-breaks let us remove more empty staves, the
page-fit score often favors generating mostly-empty staves to fill pages
more uniformly.

We can't simply remove the simultaneous consideration of line- and 
page-breaks, because page-turn-breaking needs to put the final line-
break on each odd page at a feasible point.  We might be able to shift
to two strategies: 1) line-breaking then best-fit onto pages using the
skylines of the lines,  2) page-turn-breaking at feasible places, then
line breaking within each page.

The usual (not 'pure') functions to determine Y-offsets are free to look
up properties of other objects, that can call functions to look up the
line-breaking results or induce line-breaking if it hasn't been done yet.

The 'pure' functions are supposed to avoid calling functions with the
side effect of inducing line-breaking, and that has caused a
proliferation of 'pure' versions of functions where we would not expect
a distinction between pre-/post line-breaking



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5a5a oco.net)

[Keith OHara]

Wols Lists  youngman.org.uk> writes:

> On 21/05/15 07:36, k-ohara5a5a  oco.net wrote:
> > I'm proposing to push a \fixed c' {} that always takes a reference 
> > pitch, as in the current patch.
 
> So the behaviour is different from \relative, which doesn't have to
> have a reference pitch. 

Before version 2.18, \relative{} defaulted to relative c'{} but that was
deprecated with version 2.12.  
Since version 2.18 \relative{} defaults to \relative f{}, which acts the
same as taking the starting octave from the first pitch
  \relative {c''4 c g' g} == \relative c'' {c4 c g' g}

I have seen two different suggestions for what default behavior to use
if the reference pitch after \fixed is omitted.  Neither default seems
obvious to me, so I'm proposing we use \fixed with an explicit pitch until
it becomes clear that one usage is natural and useful enough to be default.

1) Something like the old \relative {} -> relative c' {}

> If \fixed takes an optional (defaults to c') reference pitch then the
> underlying code will be the same.

Earlier versions of the proposed patch did this, but defaulting to c not c'


2) Something like the new \relative {c'' ...} -> relative c'' {c ...}

 googlemail.com> writes:
> I'd prefer the syntax and options to parallel those of
> \relative.  That is, an optional prefix pitch to indicate
> the starting octave, and taking the starting octave from
> the first contained note if the prefix is omitted. 

We could implement this, but unlike \relative where each octave mark
increments the octave of the previous pitch, there is no simple way to
start the machinery of \fixed so that the octave shift is determined by
the first pitch it acts upon. 
We need code to explicitly find the first pitch and extract its octave.

--
absolute =
#(define-music-function (parser location pitch music)
   ((ly:pitch?) ly:music?)
   (_i "Shift the octave of each pitch in @code{music} according to
the ocatve marks @code{pitch}.  If @code{pitch} is ommitted, use the
octave marks from the first pitch found in @code{music} to shift the
octave of all the pitches in @code{music} except the first.
The result is absolute music, wrapped as @samp{RelativeOctaveMusic} to hide
it from surrounding @code{\\relative} and @code{\\absolute} commands.")
   (define (extract-octave-from-first-pitch m)
 (if (eq? (ly:music-property m 'name) 'RelativeOctaveMusic)
 #f
 (or (let ((p (ly:music-property m 'pitch)))
   (and (ly:pitch? p)
 (let ((octave-marks (1+ (ly:pitch-octave p
   ;;Reverse-shift the first pitch,
   ;; so later we can shift back with all the others
   (ly:music-transpose m (ly:make-pitch
  (- octave-marks) 0 0))
   octave-marks)))
 (let ((e (ly:music-property m 'element)))
   (and (ly:music? e)
(extract-octave-from-first-pitch e)))
 (let loop ((elts (ly:music-property m 'elements)))
   (and (pair? elts) 
(or (extract-octave-from-first-pitch (car elts))
(loop (cdr elts

   (let ((octave-marks (or (and pitch 
(1+ (ly:pitch-octave pitch)))
   (extract-octave-from-first-pitch music)
   0)))
 (display octave-marks) (newline)
 (cond ((not (= 0 octave-marks))
(ly:music-transpose music (ly:make-pitch octave-marks 0 0))
;;In order to leave unchanged the notes in any enclosed
;; \absolute or \fixed or \relative, make a cancelling shift
(map (lambda (m)
   (ly:music-transpose m (ly:make-pitch
   (- octave-marks) 0 0)))
 (extract-named-music music 'RelativeOctaveMusic)
   (make-music 'RelativeOctaveMusic 'element music))


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add French-specific note names (issue 239930043 byv.villenave gmail.com)

[Keith OHara]

Trevor Daniels  treda.co.uk> writes:

> >> BTW dear lilylist: where do you have the 'ñ' on your keyboards?
> > 
> We don't have it anywhere on the English keyboard.
> 
You might have more than you think, or can easily get more.
The US-International layout has the accented characters of English,
in the same places, plus more; the right-bottom row with right-Alt gives
 ñ µ ç . ¿
The layout is the same under Windows and Linux, at least.

Modern text editors will save the result as unicode.
We do have the problem in the US that Alt-Gr is often set as a second Alt.
At work I have sent some partial emails because I had not enabled the 
Alt-Gr key, and the keys that should give me ß gave instead Alt-s => Send.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 17 May 2015 04:58:22 -0700,  wrote:


The proper name for this would \absoluteWithFixedOctaveOffset, but
that's too long and the acronym is similarly uninspiring.  All three of
the proposed options appear in this name, so the question is, "Which
alludes most memorably to the actual function?".  At the risk of going
round in circles, on reconsidering in this light, I rather favour
retaining \absolute.  The other terms are modifiers to the primary
function; the offset is both apparent and optional, "absolute" is used
in the text and is an established concept.



The word "absolute" is established in the docs and in the user community to mean the method of 
entering pitches where octave marks ' and , count octaves from the "small octave" of Helmholtz 
notation, so the octaves are indicated against an absolute reference.  As Carl pointed out, a function that 
applies an octave offset changes that reference, so is different from "absolute".

The two functions \fixed and \relative each convert user input into absolute 
pitches.
\relative applies octave marks relative to the previous pitch; \fixed adds 
octave marks to those of a fixed pitch.

The primary function of the music-function \absolute is to write a stretch of 
absolute pitches within \relative, but the primary function of \fixed will be 
to choose the fixed octave from which entered octave marks count.

I switched the name in the patch from \absolute to \fixed when I made the function skip over any 
enclosed \relative section.  The docs say the starting pitch in \relative is an absolute pitch, and 
I didn't want to start making the distinction of "absolute octaves"  versus "the 
octave established by the enclosing absolute" so I made the change
  \absolute c'' {c e g \relative c, {c e g} } => c''4 e'' g'' c' e' g'
  \fixed c'' {c e g \relative c, {c e g} }   =>  c''4 e'' g'' c, e, g,

For some reason I find the word 'fixed' easier to type than 'absolute'

I started looking ahead at further documentation, and found \fixed more natural
https://codereview.appspot.com/235010043/diff/120001/Documentation/learning/tutorial.itely
but I backed away from adding anything to the Tutorial because \relative is 
enough to learn there.

BTW, I started replacing @lilypond[relative=2] with complete examples
  https://codereview.appspot.com/237340043/
I replaced with explicit \relative, but the patch set is a quick way to skim 
the examples in the Learing Manual where we chose to hide the '\relative' and 
imaging how \fixed or \absolute might work.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 10 May 2015 00:25:18 -0700,  wrote:


On 2015/05/09 23:58:22, Keith wrote:


It is a bit of an inconvenience that
\relative skips over \transpose, and I suspect \relative has this
feature so that we do not get rising octaves in
\relative c \transpose c c' {c c c c}


We could change that if desired.


Good point, but the change is probably too disruptive of old scores.



   \fixed c'' { c  e g c \transpose c d {c4 e g c}}
=>  c'' e'' g'' c'' { d'' fis'' a'' d'' }


The question is rather what happens when writing \transpose c c' in the
middle.  In that case I'd expect, like discussed for \relative, to have
the transposition temporarily reversed before applying the \fixed, and
then transpose back again.


For \absolute c'  or  \fixed c'  there is no need for special effort.
These operations commute with transpose.
  \fixed c' { c4 e g c \transpose c d' {c4 e g c}}
  =>  c'4 e'4 g'4 c'4 { d''4 fis''4 a''4 d''4 }


https://codereview.appspot.com/235010043/



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make \shiftOff an assertive \override, not a \revert (issue 190500043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 10 May 2015 11:02:21 -0700,  wrote:


It's not clear why you are now mixing in variants of conversion rules
for issue 4372.


I noticed that my rule made the same \b mistake as yours, and they are right 
next to each other, and I thought it was an easy fix, so I tried fixing both at 
once.


But at any rate I think you need to explain why you think that you want
a convert-ly rule to retain behavior that you consider
a) to not correspond to the documentation or expected behavior
b) to not deserve a command of its own
c) you do not consider worth documenting separately
d) which requires explicit protection of the documentation from
conversion


It was hard to decide whether to have the convert-ly rule or not for \shiftOff.

For existing music that used the old shiftOff = \revert 
NoteColumn.horizontal-shift,
the replacement \undo\shiftOn  has the same expansion.

I searched for uses of \shiftOff and found that Urs Metzger has a few pieces on 
mutopiaproject that use \shiftOn \shiftOff pairs as if they were a set/revert 
pair.  The convert-ly rule doesn't help for those examples, though, because 
they have hand-adjusted shifts in the other voices.

The \revert version generated "too many clashing notecolumns" warnings, which is now 
"need a \shiftXxx", and I thought it a bit safer to keep a warning.

The manuals did not use \shiftOff in LilyPond code where it had any effect, but 
only talked about its desired effect in the text.  Thus the manuals should not 
get any convert-ly rule.


If you revert the convert-ly rule, it would be more tidy if you also reverse 
its changes in
'Documentation/learning/fundamental.itely' and 
'Documentation/fr/learning/fundamental.itely'
Only three lines each file.   :%s/\\undo\\shiftOn/\\shiftOff/g


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make \shiftOff an assertive \override, not a \revert (issue 190500043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 10 May 2015 05:06:24 -0700,  wrote:


In addition, the following commit
commit a1d73a332fc4d1cb99bace19a5ec2c35262429e7
Author: Keith OHara 
Date:   Tue Dec 30 23:30:27 2014 -0800

 Update by hand instead of convert-ly

 The documentation already described the new behavior of \shiftOff

did not bother updating the version numbers in the translations.  In
consequence, running scripts/auxiliar/update-with-convert-ly.sh now will
overwrite the German, Spanish, Catalan, French, Hungarian, Italian,
Japanese and other translations with inappropriate changes.



Oops.  Yep, I had intended to bump version numbers across translations.
I'll clean that up in an follow-up to issue 44242


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[Keith OHara]

On Mon, 04 May 2015 23:58:12 -0700, Valentin Villenave  
wrote:


Speaking as someone who regularly gives LilyPond initiation seminars
for adults and children, the hardest part is explaining to them why
\relative mode is not on by default.


What if they didn't have to type all those 's in absolute mode ?
You might not need to explain relative mode at all.

It was hard for me to remember when in \relative I needed g' to get a G5 but 
later in a very similar circumstance the same pitch is spelled g

  \relative {r2 c'4 c | g' g a a | g2 f4 f | e4 e d d | c2 g'4 g
   | f4 f e e | e4 d g g | f4 f e e | e4 d c c
   | g' g a a | g2 f4 f | e4 e d d | c2 r }

  \absolute c' {r2 c4 c | g g a a | g2 f4 f | e4 e d d | c2 g4 g
   | f4 f e e | e4 d g g | f4 f e e | e4 d c c
   | g g a a | g2 f4 f | e4 e d d | c2 r }


If the melody crosses above and below C

  \relative {c''4 c e8 c g4 | g8 g16 g g8 g e'4 c
   | c4 c e8 c g4 | g8 g16 g g8 g c2
   | c8 c c e g e c4 | g8 g' g, g' e4 c
   | c8 c c e g e c4 | g8 g' g, g' c,2 }

then absolute mode needs a lot of octave marks, but all the pitches that sound 
low get consistently a low octave mark

  \absolute c'' {c4 c e8 c g,4 | g,8 g,16 g, g,8 g, e4 c
   | c4 c e8 c g,4 | g,8 g,16 g, g,8 g, c2
   | c8 c c e g e c4 | g,8 g g, g e4 c
   | c8 c c e g e c4 | g,8 g g, g c2 }


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \change Voice

[Keith OHara]

On Sun, 26 Apr 2015 14:35:33 -0700, Dan Eble  wrote:


If there existed a command to redirect the sequential iterator’s output to 
another Voice context without requiring a wrapper context, it could not 
function in a parallel sequence; the commands would have to be injected into 
the part sequence itself.


Well, the current \partcombine works that way, using events like solo-one-event 
or unisono-event that signal to part-combine iterator to redirect one of the 
the two sequential iterators that part-combine-iterator.cc tracks.

Breaking up the music into subsequences still looks better overall to me.  I 
tried writing the output of a hypothetical \partcombine that no longer depends 
on part-combine-iterator.cc

  \partcombine
{R1*3 g''2 d''2 }
{R1 r2 b2 R1 b2 d'2 }

% Breaking into subsequences
  \new Staff <<
\context Voice = "one" \with { \voiceOne }
\context Voice = "two" \with { \voiceTwo }
\context Voice = "solo"
\context Voice = "shared"
{
  \context Voice = "shared" {R1 r2}
  \context Devnull { r2 }
  \context Voice = "shared" {R1 }
  \context Voice = "one" { g''2 }
  \context Voice = "shared" { d'' }
}
{
  \context Devnull {R1 r2}
  \context Voice = "solo" { \mark"solo II" b2 }
  \context Devnull { R1 }
  \context Voice = "two" { b2 }
  \context Voice = "shared" { d'2 }
} >>

% Using a parallel sequence of \change events
   \layout {
   \context {
 \name "Thread"
 \type "Engraver_group" }
   \context {
 \Voice
 \accepts "Thread" } }

  \new Staff <<
\context NullVoice = "null"
\context Voice = "one" \with { \voiceOne }
\context Voice = "two" \with { \voiceTwo }
\context Voice = "solo"
\context Voice = "shared"
\new Thread <<
  {
\change Voice = "shared" s1 s2
\change Voice = "null" s2
\change Voice = "shared" s1
\change Voice = "one" s2
\change Voice = "shared" s2
  }
  { R1 r2 r2 R1 g''2 d''2 } >>
\new Thread <<
  {
\change Voice = "null" s1 s2
\change Voice = "solo" \mark"solo II" s2
\change Voice = "null" s1
\change Voice = "two" s2
\change Voice = "shared" s2
  }
  { R1 r2 b2 R1 b2 d'2 } >> >>

In any case, if you want to retire the part-combine-iterator, you need new code 
to properly break rests.  I think there are still bugs with \partcombine when 
rests overlap changes of state, so the rewrite might solve some bugs.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \change Voice

[Keith OHara]

On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble  wrote:


I think \context...{} segments make a better implementation of \partcombine 
than re-routing outlets in the part-combine-iterator.cc


I believe that would work, but it looks less tidy than keeping the original 
part intact and wrapping it in a context which moves between Voice contexts.


  ... c4 } \context Voice = "one" { d4 ...
is only slightly less tidy than
... c4 \change Voice = "one" d4 ...

If you were thinking of a separate sequence of {... s1 \change Voice = "one" 
s2...} in parallel with the part, then the \change method could be more tidy.

The wrapping context, though, means that we have to explicitly specify Voice in 
any overrides that should carry through to the combined part
\partcombine { c'4 d'4 } {\slurDashed g'4( b') }
\partcombine { c'4 d'4 } {\override Voice.Slur.dash-definition = #'((0 1 0.4 
0.75)) g'4( b') }

If your wrapping context is not aliased to Bottom, maybe you could convert-ly 
to specify the Bottom context
\override Bottom.Slur.dash-definition = #'((0 1 0.4 0.75))

My guess is that the wrapping context will cause mysterious behavior that 
outweighs its tidiness.



It would definitely be a challenge to reconstruct the part for 
\displayLilyMusic; I’d probably stash the original parts in a property just for 
that purpose, which seems like a dumb idea.



Don't reconstruct the input if you can show the output.
If \partcombine produces a music expression with context changes, rather than 
structures like 'split-list, then we would want \displayLilyMusic to show the 
result of \partcombine, not try to guess the input.

The documented purpose of \displayLilyMusic is to show the result of music 
function, displayed in LilyPond input syntax.
  \displayLilyMusic \relative c' {c4 e g c e g c e g c e g }
  \displayLilyMusic \transpose c bes {c4 e g c }
  \displayLilyMusic \appendToTag#'t d' { c'4 e' \tag#'t <> c' }
  \displayLilyMusic \removeWithTag#'t << { c'4 e' g' c''} {c'4 \tag#'t e' g' c''} 
>>

Only in cases where the music output from a function cannot be directly 
expressed in Lilypond input syntax, does \displayLilyMusic try to guess the 
function that produced the music.  This reverse-engineering always seems a bit 
silly, but producing valid LilyPond input for these cases means we can use 
\displayLilyMusic more easily for its primary purpose.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \change Voice

[Keith OHara]

On Fri, 24 Apr 2015 22:04:28 -0700, David Kastrup  wrote:


Keith OHara  writes:


The thing you want to change is the "outlet" of the sequential
iterator.


That's just \context Voice = "xxx".  However, it does not take engravers
and properties along, as opposed to \change ...


Yes.  The current part-combine-iterator does not carry properties along either,
which is to first approximation what we want, when a line of music moves from 
'a2' with \oneVoice to 'two' with \voiceTwo style.

A big difference is that \change... changes routing so that all following music 
is affected, while \context... applies to only the following music expression.  
We would need to form sequential music  groups in order to use the \context... 
method.

\new Staff <<
  \context Voice = "up" \with { \voiceOneStyle } s1*2
  \context Voice = "down" \with { \voiceTwoStyle } s1*2
  { \context Voice = "up" { f'2 f' }
\context Voice = "down" { e' e' }
  } >>

Current \partcombine does not collect segments into sequential music groups, 
but it could do so.  The analysis pass of \partcombine looks at the music 
globally to find the transition points that it puts in 'split-list, so a next 
pass can form sequential music groups between the transition points.

  \partcombine
{R1*3 g''2 d''2 }
{r1 r2 b2 R1 b2 d'2 }

could be transformed into

  \new Staff <<
\context Voice = "one" \with { \voiceOne }
\context Voice = "two" \with { \voiceTwo }
\context Voice = "solo"
\context Voice = "shared"
{
  \context Voice = "shared" {R1 r2}
  \context Devnull { R2 }
  \context Voice = "shared" {R1 }
  \context Voice = "one" { g''2 }
  \context Voice = "shared" { d'' }
}
{
  \context Devnull {r1 r2}
  \context Voice = "solo" { \mark"solo II" b2 }
  \context Devnull { R1 }
  \context Voice = "two" { b2 }
  \context Voice = "shared" { d'2 }
} >>

I imagined the splitting of multi-measure rests being done in the grouping pass, rather than in the iterator 
as it is done now.  If we define the names "one", etc., in just one place, then we can choose to 
replace "solo" with "shared" so that they use the same Voice.

I think \context...{} segments make a better implementation of \partcombine 
than re-routing outlets in the part-combine-iterator.cc


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \change Voice

[Keith OHara]

Dan Eble  faithful.be> writes:

> 
> Would it be hard to make \change Voice work as below without relying on
> the extra “NoteSequence” context?
> 
> \layout {
>   \context {
> \name "Thread"
> \type "Engraver_group"
>   }
>   \context {
> \Voice
> \accepts "Thread"
> \defaultchild "Thread"
>   }
> }
> 

I think it would be hard.

The code uses the concept that \change... takes a context from one enclosing
context into another.  Usually there is no context like NoteSequence that
lives inside a Voice.

(The code in change-iterator.cc is written in a general way, so that \change
GrandStaff="b" finds the highest context below the enclosing GrandStaff and
moves that context to GrandStaff "b", but I don't think anything other than
\change Staff works in a useful way.)

We probably don't want Thread to be created by default, because then
all \overrides for the Voice need an explicit 'Voice'.

Once I read old old mailing list message about contexts called "threads"
that would live inside Voice, which might be a similar idea.  I think
people decided the idea caused too much complication.


The thing you want to change is the "outlet" of the sequential iterator.
So rather than a \change event that is acted upon by change-iterator.cc
you might want a partCombineStatus event that is acted upon by sequential-
iterator.cc.

That, though, would look similar to the current part-combine iterator.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Avoid floating-point compares on Stem:head_positions; issue 4310 (issue 217720043 by k-ohara5...@oco.net)

[Keith OHara]

On Wed, 11 Mar 2015 02:10:29 -0700,  wrote:


_How_ do we arrive at different versions of 3.0 here, or at GCC
considering 3.0 > 3.0 ?


Probably we get different numbers that are close to 3.00... or 2.99...

The head positions are individually multiplied by staff-space in 
Grob::get_offset() and then divided by staff-space 
Staff_symbol_referencer::internal_get_position() and at magstep=2 staff-space 
is 2^(1/3)

I think a standard-conforming implementation should give bit-identical 
floating-point results for these parallel computations, but suspect some 
compiler option is set to allow non-conformance (retaining the most-recent 
value in register with its guard bits intact for the comparison, maybe).

In general, I think it wisest for us to code in a way that allows floating 
point to be inexact. The broader change that I considered was to count only 
only [+inf -inf] as the 'empty' interval in is_empty() as we considered doing 
before.


https://codereview.appspot.com/217720043/



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lilypond build: version

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> I completed a full GUB build of lilypond yesterday 

That's very good news.
I was beginning to worry.  Thanks for taking the time to work through 
the problems.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4275: Allow user-defined rest styles. (issue 200860043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Sat, 31 Jan 2015 14:49:29 -0800,  wrote:


https://codereview.appspot.com/200860043/diff/20001/lily/rest.cc#newcode166
lily/rest.cc:166: + offset);
On 2015/01/31 06:02:50, Keith wrote:

I guess that get_position() could possibly trigger a full layout, but

I can't

tell for sure without booting Linux to experiment.


I don't know what "trigger a full layout" means.



I meant that get_position() might call functions that call other functions that 
choose line-breaks, set beam slopes, etc.  I was trying to imaging how there 
might be a cyclical dependency.
  \new Staff \transpose c c' <<
{r2 g'2}
\\ {r2 d2 }
\\ {e8 f g a b2} >>
  #(ly:set-option 'debug-skylines)
  \layout {\context { \Score
\override PaperColumn.stencil = #ly:separation-item::print } }
The ledgers on the upper half-rest potentially depends on beam slope, which 
depends on horizontal spacing.


https://codereview.appspot.com/200860043/diff/20001/lily/rest.cc#newcode203
lily/rest.cc:203:
On 2015/01/31 06:02:50, Keith wrote:

The comments depend on the meaning of the word 'pure' as used by a

subset of

LilyPond programmers.  You could just say:
// Get a stencil, but if 'pure'=true do so without testing if the rest

needs a

ledger


If pure=true, do not cache the result in the stencil-pure property.


Oh.  Then I was wrong about this patch making it less likely to repeatedly look 
up the rest glyph, and I am no longer see the point of a separate 'stencil-pure 
property.

This patch only solves issue 4245 for users who know how to put their custom 
rest stencil in a pure-unpure-container.

The pre-patch approach seemed reasonable, in that it evaluated the X/Y-extent 
by calling he stencil-building function, while leaving a link to that function 
in the 'stencil property for re-evaluation when time comes to print a 
possibly-moved rest.  The problem with the pre-patch code is that it assumes 
the Rest.stencil points to the built-in default.

After an earlier patch  the usual way to 
handle stencils that change shape depending on other layout is to put the smarts in the 
X/Y-extent, rather than the 'stencil.  It would be more similar to other Grobs if you can make 
the Rest.stencil actually 'pure' in the sense of returning a stencil without asking for the 
beam slopes that (probably) cause the cycle.  Probably Rest.staff-position rather than 
get_position() can determine whether to use the ledgered version, without triggering beam slope 
calculations.  Then the 'X/Y-extent callbacks can use get_pure_property("stencil") to 
determine the extents, and later the print routine will re-evaluate the stencil function.  For 
that to work properly, all code that moves rests up and down would need to update the 
Rest.staff-position, but that seems like a good idea anyway.



(This is because the CG says looking up a pure property should never
result in a call to set_property.)


Usually, when a property holds a function, LilyPond's evaluation routines 
evaluate the function once and then overwrite the property with the result.  
Progress is thus made in determining the layout.

The idea of 'pure' evaluation of properties that hold functions was to delay 
progress in determining the layout.  Joe Neeman's approach to choosing line- 
and page-breaks evaluates tentative layouts, requiring that we evaluate the 
functions in properties like 'Y-extent, but leave the function in place for 
future evaluation.  The 'pure' methods leave any function in place, and also 
promise not to cause any irreversible progress in determining the layout.

The rule that a 'pure' evaluation may not set_property() might help to keep 
promise not to irreversibly advance layout, but the rule does lead to a lot of 
re-computation.  There is no problem setting properties that are known to be 
final before line-breaks are determined.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Wed, 28 Jan 2015 17:40:33 -0800,  wrote:


Yes, the ledgered rest stuff is a big tangle.
See https://codereview.appspot.com/200860043/ for the best I've been
able to do without changing Rest_collision.



Shucks.
The similar issue with Accidentals (issue 3646) was not so bad.
There we could look up the stencil one, put it in the 'stencil property like 
usual for purposes of line spacing, and then just after line-breaking remove 
the accidentals on notes tied to a previous note on the same line.

I had hoped that for Rests we could look up a tentative glyph and put it in the 
'stencil for use in spacing, then after the last step of vertical position is 
done, substitute the ledgered glyph when appropriate.

I'll try to look at the new patch over the weekend, but if you didn't see a way 
to untangle the tangle I'm not likely to either.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Tue, 27 Jan 2015 05:09:58 -0800,  wrote:


On 2015/01/27 05:21:47, Keith wrote:

I discovered this when I tried to use get_property("stencil") from
Rest::height while trying to fix issue 4245.



It looks like some rests (whole and half rests) have two glyphs, with and 
without the ledger line, so the *final* stencil should not be generated until 
after rest_collision is finished, and maybe after beams are set and rests moved 
to avoid them, when we finally know if the rest needs a ledger.

So when you ask for the stencil in order to figure note-spacing, the routine to 
generate the stencil asks for most all layout to be completed, so it knows in 
the general case whether it should fetch the glyph with a ledger.

There is some code trying to handle that problem in
  Rest::generic_extent_callback (Grob *me, Axis a)
(but it seems strange that if we want the a=Y_AXIS extent, it includes a 
possible ledger -- we would seem to need to know the height of a rest in order 
to know how far we need to move it to clear a note.)
I do not like that it re-fetches the glyph from font forge every time 
generic_extent_callback() is called; hopefully the extent is cached somewhere.

It seems that we want to look up a tentative rest glyph (either with or without 
ledger) to get the extent, figure out note spacing and line-breaking, and 
rest-collisions, and beaming, all with that extent, and then finalize the 
stencil at some point after we are finished moving rests vertically, but before 
printing.

If you can follow the sequence of calls between Scheme and C, maybe you can find a simple 
way to get this tentative extent for issue 4245.  Use of the "pure-height" in 
rest-collision.cc would assume, for purposes of placing a given rest, that every other 
rest is on staff-center.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

[Keith OHara]

On Tue, 20 Jan 2015 13:19:26 -0800,  wrote:


https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode8
ps/encodingdefs.ps:8: /LilyNoteHeadEncoding [
On 2015/01/18 06:33:02, Keith wrote:

This is a little different from "FetaNoteheadsEncoding" in
'mf/out/feta-noteheads11.enc' generated by

'scripts/build/mf-to-table.py'

I need some advice on what to do here from Knut.

https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode108
ps/encodingdefs.ps:108: /noteheads.d0doFunk {<01> show} def
On 2015/01/18 06:33:02, Keith wrote:

I suppose you use PS definitions here because the Scheme code does not

know the

encoding table, so the Scheme does not know what number to write in

'\?? show'

Again I cannot comment - Knut?

https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm
File scm/output-ps.scm (right):

https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm#newcode64
scm/output-ps.scm:64: (ly:inexact->string i 8)))
On 2015/01/18 06:33:02, Keith wrote:

This is the old code that output PS 'show' rather than 'glyphshow'


I don't know what to do here (if anything).



Nothing need be done about these threee.
They were only suggestions for simplification -- and note even suggestions, 
just hints that simplification might be possible.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: mentorship

[Keith OHara]

Kevin Barry  gmail.com> writes:

> Thank you for responding. I would like to be able to contribute code to the
> project but I'm not really a programmer (I'm a music academic). I worked
> through some chapters of SICP in the past, so I have a rudimentary
> understanding of ... the first few chapters of SICP. I would like to learn
> more, if that's something that would help. Otherwise I will help any way
> that might be needed. I don't have any specific goals other than
> contributing somehow and maybe learning more about programming along the
> way.

https://code.google.com/p/lilypond/issues/detail?id=703
is an interesting case.  Eight people 'starred' it to indicate interest.

The tricky bit is figuring out how we might make LilyPond easier to use
for a variety of instruments.  The relevant code is in Scheme, which I
is the language used in "Structure and Interpretation of Computer Programs"


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB fail with smob templates

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> >> Phil Holmes  philholmes.net> writes:
> >>> /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--
lilypond.git-
> >>> release-unstable/lily/include/smobs.tcc:131: error: invalid operands 
of
> >>> types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct*
> >>> (Smob_base::*)()' to binary 'operator!='

This involves the address of a function in a templated class, the
behavior of which didn't get resolved until C++ defect 115 and gcc 4.5.0


We could probably use some other test to see if the base mark_smob()
function has been redefined in the derived class ... or put the 
responsibility to register mark_smob() into each derived class.

> OK: here's the result of a grep for gnu/gcc on the GUB machine:
[...]
> It looks like a bit of a mish-mash.  But if we were going to upgrade from 
> what is mostly gcc 4.1.1/2, which version should we go to?

Phil,
 How does the upgrade to gcc 4.8.2 look now ?

The changes from Masamichi to librestrict look safe,
and the later floating-point-endless-loop-eating-all-memory should be
gone now that I've re-worked the skyline merge code.

If gcc 4.8.2 still looks difficult, I'll look into problem with the
templates.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reduce size of *TeX generated pdfs with lilypond snippets

[Keith OHara]

On Sun, 28 Dec 2014 21:10:59 -0800, Werner LEMBERG  wrote:


 https://codereview.appspot.com/191360043/

Unfortunately, this doesn't correctly include the new file
`encodingdefs.ps' – it is tagged as a `binary'...


Oops, forgot to change the settings.
There is no existing file to compare to, so the 'download' link gives you as 
much as the comparison would.


My first impression that we do not want this patch,


Can you explain why?  As Knut writes, he wants it encapsulated with a
command line option so that it has be to explicitly activated.  It
should be thus straightforward to remove the related code as soon as a
better solution becomes available.


It was only a first impression.
I thought that the effort to implement and at least minimally document the 
command-line option would be greater than the value to the users of TeX + 
LilyPond + pdfsizeopt (excluding Knut, who can already already use his patch).

If you find it straightforward to encapsulate the code, then we can probably 
incorporate it.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reduce size of *TeX generated pdfs with lilypond snippets

[Keith OHara]

Knut Petersen  t-online.de> writes:

> The attached patch (against 2.18.2) changes the way lilypond
> uses fonts to draw glyphs.
> 
> It avoids to used glyphshow for all emmentaler glyphs and
> adds encoding vectors to the emmentaler fonts before they
> are used. It also changes the ghostscript parameters used
> to generate pdfs from postscript code.
> 

I put the patch in the usual LilyPond form at
 https://codereview.appspot.com/191360043/
along with links to LilyPond history and the Ghostscript discussion.

This helps with TeX documents having several LilyPond inclusions,
but only after post-processing with pdfsizeopt.py.

My first impression that we do not want this patch, but might be wise
to go back LilyPond's former use of encoding vectors, if we can avoid
whatever problems induced HanWen to move to using glyph names in the .ps.





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: crosslinks update

[Keith OHara]

Jean-Charles Malahieude  orange.fr> writes:

> I've locally merged master into translation, and before merging 
> translation back to staging will correct bad cross-links.
> 

Sorry, I should have changed the rlearning links.

> Don't forget that translators use the English node 
> names with   translationof.
> 

I do not know, however, who should update the translationof links.

In Learning, "translationof Accidentals and key signatures" will be 
"translationof Pitches and key signatures" and
"translationof Accidentals" will be "translationof Pitch Alterations"
(the second is present in only some languages)

In Notation the "node Accidentals" and "translationof Accidentals"
remain unchanged.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: mentorship

[Keith OHara]

Kevin Barry  gmail.com> writes:

> 
> > It depends on which part of LilyPond you want to help with as to the
> > availability of people to help you. Is there a particular skill-set, set
> > of issues or area of LilyPond you are particularly interested in?
> 
> Thank you for responding. I would like to be able to contribute code to 
the
> project but I'm not really a programmer (I'm a music academic). I worked
> through some chapters of SICP in the past, so I have a rudimentary
> understanding of ... the first few chapters of SICP. I would like to learn
> more, if that's something that would help. Otherwise I will help any way
> that might be needed. I don't have any specific goals other than
> contributing somehow and maybe learning more about programming along the
> way.
> 
> Kevin
> 


Given that you know a lot about how various kinds of printed music 
are supposed to look, and have an interest in how the program works,

I suggest you watch for interesting bug-reports, follow the resolutions,
and compile lilypond and test the patches if you can set up a computer
to do that.

Often we have enhancement requests
http://code.google.com/p/lilypond/issues/detail?id=1503
that turn out not to be completely wise
http://code.google.com/p/lilypond/issues/detail?id=4222

Sometimes the main question is one of how to design a feature to be useful
http://code.google.com/p/lilypond/issues/detail?id=1321
http://code.google.com/p/lilypond/issues/detail?id=3279


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Keith OHara]

Dan Eble  faithful.be> writes:

> > On Dec 8, 2014, at 08:21 , David Kastrup  gnu.org> wrote:
> > 
> > Masamichi HOSODA  sea.plala.or.jp> writes:
> > 
> >>> I agree that changing the algorithms is preferred; I didn’t mean to
> >> suggest otherwise.  But if that’s not going to happen overnight, and
> >> there is a way to mitigate the problem in the meantime without
> >> touching the code, the people affected would value it.
> >> 
> >> I tried "-mfpmath=sse -msse2".
> >> It worked fine. bad_alloc didn't occur.
> >> Correct PDF was generated.
> >> 
> >> It can be a workaround until changing the algorithms.
> > 
> > It's not architecture independent.  And may blow up for other reasons.
> 
> But it’s good to know that the problem was floating point and not memory 
corruption, so thanks for testing it.
> 

This sounds like the runaway-loop problem we noticed when allowing
zero-width items into skylines.   I opened issue 4229 and will post
a patch.




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part combiner: separate split state and voice names

[Keith OHara]

Urs Liska  openlilylib.org> writes:

> Keith wrote:
> > I suggest looking over the existing partcombine bugs, and orchestral 
> > scores, to see what problems generally need solving.

> If there's anything I can do to help (without understanding more than 
> basic Scheme and without any option to help on the C++ part) please let 
> me know. Maybe it helps that I'm currently working on a big orchestral 
> score?

I remember that you were once trying to define \new Voices in the music
you gave to \partcombine (but it seems you decided you did not need to) : 
 http://lists.gnu.org/archive/html/lilypond-user/2014-10/msg00509.html
This doesn't work because \partcombine rearranges the music into Voices
that it defines, with names "one" "two" "shared" "solo". With the color
coding below, you can see that LilyPond's layout receives notes in four
distinct voices from \partcombine.

soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
\new Staff <<
\context Voice = "one" { \override NoteHead #'color = #red }
\context Voice = "two" { \override NoteHead #'color = #green }
\context Voice = "shared" {\override NoteHead #'color = #blue }
\context Voice = "solo" {\override NoteHead #'color = #grey }
\partcombine \soprano \alto >>

Dan has for a long time wanted to be able to control which voices get
which notes, while still having \partcombine do the tedious work of
finding where the parts can be joined into chords, figuring rests, etc.

For example, it seems that "one" "shared" and "solo" could be reduced to one
Voice, allowing us to continue dynamics from a solo part into a2, for example,
when we force the transition with \partcombineChords.

Dan's recent question was whether two notation elements from the same 'part'
(e.g. FluteII) at the same moment, might ever need to go into to different
LilyPond Voices for purposes of layout.  The current mechanism describes, at
any moment in time, the state of the combined music: unison, chords, solo, etc.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part combiner: separate split state and voice names

[Keith OHara]

On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble  wrote:



I have a question.  If the Scheme code produces something like (‘apart “one” 
“two”) with “one” and “two” being the chosen output voices for the input parts 
at the moment, would it make sense to write those decisions back to the input 
parts themselves and have the iterator find them there?  Would that allow finer 
control over the routing than there is now (say different routing of 
simultaneous events in the same part) or have any other advantages?



I thought about it.  I'm not sure.

There is some reason that the existing \partcombine makes a separate 
split-list, rather than embedding the results of the analysis in the two parts. 
 It might be simply because part_combine_iterator normally looks only at 
properties of the PartCombineMusic itself, not the sequential music contained 
within.

The question seems to be whether the results of the analysis of \partcombine 
mostly describes the state of the combined parts, or mostly information about 
individual parts.

I suggest looking over the existing partcombine bugs, and orchestral scores, to 
see what problems generally need solving.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part combiner: separate split state and voice names

[Keith OHara]

On Sat, 29 Nov 2014 18:09:34 -0800, Dan Eble  wrote:


On Nov 29, 2014, at 18:48 , Keith OHara  wrote:


Oh, so you meant let the Scheme portion dictate to partcombine_iterator which 
_input_ voice, as it iterates the music expression produced by \partcombine, to 
use.


My reasoning probably needs more clarification.  The iterator takes sequences 
of events and routes them into voices.  So, I thought that where now the Scheme 
portion produces simply ‘unisilence, it might produce something like (’silence 
“shared” #f) to tell the iterator that both parts are silent, the first part 
should be placed into the voice named “shared”, and the second part should be 
dropped.  That’s what I meant by telling the iterator which output voice to use.

Telling the iterator which input to use would be something like defining new 
states ‘unisilence1 and ‘unisilence2.



Adding the new split-state tags 'unisilence1' and 'unisilence2' would preserve 
the relative roles of the \partcombine function and the part_combine_iterator

The function \partcombine analyzes the music to describe which part or parts 
must be printed and when they should be combined in chords.  That analysis is 
what you want to improve so that
  \partcombine {R1 R1} {R1 r4 b2.}
reports that the first beat of the second measure is not really 'unisilence', 
but 'silence2'.

The part_combine_iterator takes the results of \partcombine and decides what 
events to send to what Voices.

Maybe you can make \partcombine completely take over the routing decisions.  
Then maybe the iterator would be reduced to following orders, and keeping track 
of which voices need to start or stop multimeasure rests.

If \partcombine can only assume part of the responsibility for routing 
decisions, though, I seems cleaner to enhance the set of split-state tags to 
completely describe the results of \partcombine's analysis, rather than tell 
part_combine_iterator (partially) how to do its job.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part combiner: separate split state and voice names

[Keith OHara]

On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble  wrote:


On Nov 29, 2014, at 16:46 , Keith OHara  wrote:


Dan Eble  faithful.be> writes:


I would like the Scheme portion of the part
combiner to dictate the names of the voices to use at every moment.


Simply letting us specify the Voices _once_ for the whole output of
\partcombine would help a lot.


It would, and I’m glad you’re encouraging me to dig up my ancient patch to do 
that, but I wasn’t thinking of making any user-visible changes in the scope of 
the work suggested in this thread.  (That could come later.)


Well, if I can't use it, I am less motivated to review it.

I am eager for either nameable outputs from \partcombine, or VoiceGroup, in 
LilyPond so we can have a stable and functional \partcombineUp/Down.


Include an example in your patch, where we want to rearrange the routing
of soloI, unison, etc., to Voices mid-piece.


This suggestion was motivated by recent work on cases in which both parts are 
resting.  If the desired action is to route only one of the voices to the 
shared voice, the Scheme half currently can only say “unisilence” and the 
Part_combine_iterator picks a voice.  The problem is that sometimes it doesn’t 
pick well.  It seems that the Scheme half has the information to make a better 
decision.



Oh, so you meant let the Scheme portion dictate to partcombine_iterator which 
_input_ voice, as it iterates the music expression produced by \partcombine, to 
use.

That makes more sense.  However, the current problem with the iterator picking which 
input part to route to output Voice "shared", seems best solved by your current 
patch, that marks these situations as 'apart-silence' whenever there is a difference 
between the input parts.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part combiner: separate split state and voice names

[Keith OHara]

Dan Eble  faithful.be> writes:

> I would like to break the rigid link between the split states 
> (apart, unisilence, etc.) and the names of the
> voices into which the Part_combine_iterator routes events.  

The patch back at
http://lists.gnu.org/archive/html/lilypond-devel/2008-09/msg00079.html
makes sense, and seems flexible enough.  The awkward part was naming
the Voice contexts for the four states of music.  Given that you need
that information in the output of \partcombine
 pc = \displayMusic \partcombine {b2 b ...} {b2 b ...}
for the iterator to see, it seems that music properties are the only
places to put it. Maybe one property that takes the full list of context
names...

> I would like the Scheme portion of the part
> combiner to dictate the names of the voices to use at every moment. 

Simply letting us specify the Voices _once_ for the whole output of
\partcombine would help a lot.

Include an example in your patch, where we want to rearrange the routing
of soloI, unison, etc., to Voices mid-piece.

The example in the 2008 thread, setting unison directions, is better done
with \context Voice="shared" {\voiceOne} than by changing Voices.

The first use I can imagine is that I would usually want the shared Voice
to be identical with the first-part Voice, but sometimes would want the
shared events to go to the second-part Voice.  In that case, I am thinking
of the Voice output arrangement all at once, so specifying a list of four
is natural.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Fri, 07 Nov 2014 04:37:41 -0800,  wrote:


On 2014/11/06 05:44:50, Keith wrote:

Changing the current global variable 'partcombine-chord-range' will

not become

the user interface.


All I meant for that variable was to avoid repeating the same magic
numbers three times.  Is there a more idiomatic way to do that in
Scheme?  Should I have commented it?



No, that seems fine as it is.
I was trying to go through the possible user-interfaces systematically, and 
exposing that global variable was one possible interface.  I had trouble 
articulating exactly /why/ simply changing that global variable wouldn't become 
the user-interface.

I forgot the originally-suggested possible interface for the user to change the 
chord-range, by setting some context property of the temporary Voice contexts, 
the ones used by \partcombine to iterate through its inputs.  Then we could 
change chord-range in the middle of the music, but I'm not sure the 
\partcombine logic can handle mid-music changes.  The analysis is global, so if 
you double-stem the e' below, probably the slurs should separate and all 
slurred become double-stemmed (like \partcombine already does if there is a 
voice-crossing).
  \partcombine
   {e'( e' b' f')}
   {c'( e' g' c')}
Changing chord-range just before the e' might (or might not) fool \partcombine.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads gmail.com)

[Keith OHara]

On Mon, 03 Nov 2014 05:11:02 -0800, Dan Eble  wrote:


On Nov 3, 2014, at 02:25 , Keith OHara  wrote:

That kind logic is already at the end of 
Time_signature::special_time_signature() now, but I don't see any way to use it 
for anything except 2/2 and 4/4.


The logic used for neomensural, mensural, and any other style that is not 
explicitly named


Oh. Now I see how it works. I should have read the doc-string at the bottom of 
time-signature.cc.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads gmail.com)

[Keith OHara]

On Sun, 02 Nov 2014 18:11:58 -0800, Dan Eble  wrote:


On Nov 2, 2014, at 14:52 , Keith OHara  wrote:


The current code has some logic to choose a glyph timesig.C34 if...



I followed everything you said except this, maybe because of the sudden mention of 
3/4.  Are you implying that changing the “complex logic" to

  1. if there is a glyph of the right name, use it
  2. otherwise, fall back on numbered style

would be a good idea? I was considering that.


That kind logic is already at the end of 
Time_signature::special_time_signature() now, but I don't see any way to use it 
for anything except 2/2 and 4/4.

I was arguing that as the use-cases get more specific, where you would want to 
pick a particular glyph, figuring out what options to set is harder than the 
direct approach:

  {\override Staff.TimeSignature.stencil = #ly:text-interface::print
   \override Staff.TimeSignature.text =
   \markup {\musicglyph #"timesig.C22" \musicglyph #"timesig.C22" }
   \time 4/2 b1 b1 }



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads gmail.com)

[Keith OHara]

Dan Eble  faithful.be> writes:

> On Nov 1, 2014, at 18:48 , Noeck  gmx.de> wrote:
> >> 
> >> * leave the default style alone
> >> * add to the C style: 4/2 -> CC, 2/1 -> cut-CC
> >> 
> >> This would end the equivalence of default and C styles.  
> >> Does that seem like a bad idea to any seasoned
> >> Lilypond developers?  

This is a bad idea.

The time required for a user to find and understand the single-C style 
is greater than the time to find an example of a custom time signature
made using markup on the LSR.
Then the user can further customize the markup, or use the concept
elsewhere.

Any added complexity has some risk of surprising side-effects
(e.g. https://code.google.com/p/lilypond/issues/detail?id=1926 )

Computers are helpful when they help us follow a pattern, as the
single-digit style does, or a solid convention like the default style.
Computers are frustrating when we need to figure out what they
are doing.

> > style
> > defaultc¢   2/4  2/1  4/2  8/4  3/4  6/8
> > C  c¢   2/4  ¢¢   cc   8/4  3/4  6/8 <---
> > single-C   c¢   [¢]   ¢c   8/4  3/4  6/8 <---
> > numbered  4/4  2/2  2/4  2/1  4/2  8/4  3/4  6/8
> > single-digit   42224836

If I needed to set the Schubert Op90n3, which looks like 4/2 to me,
I might notice a single-C style in the manual, figure out how to use
it, wonder why the c's are not barred where Schubert has them barred,
look into the code, be confused, decide to use markup like I should
have in the first place.

The single-C style is borderline useful as a style, double-c is not.

The current code has some logic to choose a glyph timesig.C34 if we 
set style=C in 3/4 time, but it seems that code is disabled by complex
logic.  Cleaning that up, as part of moving toward scheme markup,
would be nice.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: staff-symbol-referencer: ledger logic; issue 4184 (issue 167040043 by k-ohara5...@oco.net)

[Keith OHara]

'notehead' noted.

On Sat, 01 Nov 2014 23:43:34 -0700,  wrote:
/* If we are closer to the staff than the notehead,
   quantize for ledger lines. */

But I wonder whether this is the best description – it's rather about
note heads and attached grobs having the same direction, right?


Well, if by 'direction' of the notehead you mean its position relative to the 
staff, then yes, but he code does not use the word 'direction' for that.

The comment says loosely what case we are trying to catch, and fits either old 
or new code.
Matching the code would be "if the Script is above(below) the Head but below(above) 
the staff, avoid ledger lines"


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: how to make space between time signature and following material squeezable

[Keith OHara]

This is 
  https://code.google.com/p/lilypond/issues/detail?id=1785

For four years this space was too compressible, and would not stretch.
The behavior did not match the names of the settings and code comments,
so I raised issue 1785 to make the space rigid.

Another option, semi-fixed-space in place of fixed-space, looked like
a better choice for the space after prefatory matter.
However we do not want the space to stretch, and there is no setting for
compressible-only space.

I'll mark issue 1785 as open.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ballads gmail.com)

[Keith OHara]

  gnu.org> writes:
> On 2014/10/31 22:50:35, Dan Eble wrote:
> 
> > One thing just occurred to me.  If this option is going into the UI,
> do you
> > think the numbers should be 1-based for easier comprehension by
> musicians?  

> As a UI, numbers instead of intervals (possibly represented only by a
> pitch in relation to c' like \transposition does) do not make much
> sense.

I may be having trouble with the negative sentence construction, but
if you mean that
  \partcombine  {} {}
would be the intuitive way to indicate seconds through octave may be
be combined into chords, then I disagree.  Or, maybe you were joking.

Numbers are very good for representing intervals; we use numerical
names to represent them.  Numbers are also good for representing
differences in staff-position as well.  Either 1-based or 0-based
should be fine, if the docs consistently speak in terms of intervals
of the chords, or in terms of the graphical separation between noteheads,
respectively.

> Regarding such user interface extensions, I think we should rather go in
> the direction of
> https://code.google.com/p/lilypond/issues/detail?id=1321#c30>.
> Using context modifications makes it reasonably straightforward to add
> arbitrary named settings in arbitrary order on demand.

Well, the currently-proposed patch at your link uses optional
arguments to \partcombine, which would also be appropriate here
for the chord-range, and later for 'no-solo.  If that is the 
direction you mean, we all agree:  optional input argument #'(2 . 8)

If you mean to use context properties, they cannot be context 
properties of the output Voices because those are not created when
the chord-range needs to have its effect.  they cannot be
properties of the temporary Voices for the same reasons that idea
failed for the interface to force part-combine decisions.

Generally issue 1321 concerns how the voices output from partcombine
are set on the staff, so it should not change the input interface to
partcombine at all.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Fri, 31 Oct 2014 15:50:35 -0700,  wrote:


One thing just occurred to me.  If this option is going into the UI, do
you think the numbers should be 1-based for easier comprehension by
musicians?  For example, use '(1 . 9) to allow chording unisons to
ninths, rather than '(0 . 8)?



Good to think of this now, because it is awkward to change later.

I think either convention will be fine, if the doc strings are clear.

I understood the zero-based system without hesitation, because your docstring said the 
numbers were  "the distance (in steps) between notes".There are probably 
cases where negative values are appropriate, so as to set two parts as chords even if 
they cross, on the conductor's score.  Negative values make more sense on the zero-based 
scheme.



https://codereview.appspot.com/144170043/



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[Keith OHara]

On Thu, 30 Oct 2014 20:19:01 -0700,  wrote:


This is the beginning of the function I've actually been
using:

(define-public (dfe-determine-split-list evl1 evl2 chord-range
enable-solo)
   "@var{evl1} and @var{evl2} should be ascending. @var{chord-range} is a
pair (min . max) defining the distance (in steps) between notes that may
share a stem. If @var{enable-solo} is false, skip solo analysis and
display the rests of both voices."


If I understand, this is the style where if one part plays solo, you show the 
rests of the resting part on the score.  J.F.Lucarelli used that style for 
Dvorák Symph #7 at
 http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1901
which is a good test-case for partcombine and its override functions.

"skip solo analysis" doesn't make sense unless you read the code.  I guess the idea is 
"instead of using SoloI/II, display the rests of the resting part."


Based on the feedback I've received so far, it seems that reimplementing
this solo control like the forced partcombine states would be the best
approach for that, leaving me free to add the chord-range as an optional
parameter to \partcombine without fear that the options will get out of
hand.  What do you say?


A reasonable choice, given that a no-solo override is related to the other 
PartCombineForceEvents (and given the fact that there is no context shared by 
the inputs to \partcombine, in which to set context properties like we would 
normally prefer).


https://codereview.appspot.com/144170043/




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Issue 3324: Add explanation of clashing note columns warning (issue 154640043 by tdanielsmu...@googlemail.com)

[Keith OHara]

On Thu, 23 Oct 2014 02:43:56 -0700,  wrote:


On 2014/10/22 05:58:54, Keith wrote:


I have been thinking that when the user gives explicit \voiceOne or \shiftOn to 
the voices, Lily should set those voices at the shifts requested, even if two 
voices have the same shift


I had forgotten that I already pushed that patch.


Not sure I understand this.  Doesn't \voiceThree already set the shifts?


Yes it does.
I was emphasizing the case where a user sets the same shift on two voices, 
because I didn't realize that you had seen the patch that I was thinking of.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4169: Line and page breaking syntactic sugar (issue 156400043 by tdanielsmu...@googlemail.com)

[Keith OHara]

On Tue, 21 Oct 2014 09:33:56 -0700,  wrote:


I've decided to keep the reverts for the On predefs, since \once does
not do what [the name implies] with these overrides.


Yuck.  The problem seems to be that the override takes effect at the first beat 
in a bar, after the paper-column for the previous barline has been generated, 
and the \once makes the override expire before the next bar.

Unfortunately this also means that
 \override Score.NonMusicalPaperColumn.line-break-permission = #'allow
  R1
only has effect /after/ the R1.

We have a workaround for that timing problem in \overrideProperty, and then 
\once works fine with

autoLineBreaksOn = {
 \overrideProperty Score.NonMusicalPaperColumn.line-break-permission #'allow
 \override Score.NonMusicalPaperColumn.line-break-permission = #'allow }

autoLineBreaksOff = {
 %?? \overrideProperty Score.NonMusicalPaperColumn.line-break-permission ##f
 \override Score.NonMusicalPaperColumn.line-break-permission = ##f }

I put the %?? because I'm not sure whether it is more intuitive if
  \autoBreaksOff
  R1
should forbid a break before the R1, or mean "here is your last chance to break, 
Lily".


https://codereview.appspot.com/156400043/



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)

[Keith OHara]

On Mon, 08 Sep 2014 16:28:24 -0700, Dan Eble  wrote:


How about placing the voices inside a VoiceGroup context, moving the 
Accidental_engraver there, and leaving the NullVoice outside, like in my recent 
partcombine experiments?



Usually, accidentals are reported up the context hierarchy.
We can do things like this
%% Cautionary accidentals to cancel accidentals anywhere on the score
 \set Score.localAlterations = #'()
 \set Score.autoCautionaries   % 0 -> current measure only
 = #`(Score ,(make-accidental-rule 'any-octave 0))

If reports of accidentals do not penetrate your VoiceGroup, it would be an 
exception to the general rule.  I think it might be because localAlterations is 
not initialized in VoiceGroup.


Another quick way to hide pitches from the Accidental_engraver note-heads is to 
set NoteHead.style=#'harmonic and Staff.harmonicAccidentals=##f

I am leaning toward generalizing that mechanism so that any voice could say "I 
should not have any accidentals printed".  Then the Accidental_engraver handles 
things consistently: it knows that it generated no accidentals reports no accidentals for 
cancellation.


On the other hand, maybe it is better to put NullVoice at the Score level, and 
let people, like you, who want the unprinted pitches to be logically associated 
with the Staff, move NullVoice on their own.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 07 Sep 2014 01:21:58 -0700,  wrote:


But messing up the basic grob definition by fetching internals and
meddling through them locally: no.


Well, you say "messing up the basic grob definition"
I say "reading the basic definition, and making a local modified copy"

We can do in LilyPond code with ly:grob-interfaces, making a copy with one 
interface removed, and storing the shorter list in the NullVoice context 
definition with an \override, so the changes to apply to grobs made in this 
context.

LilyPond tries to be robust to grobs different interfaces, by checking 
has-interface() before using the properties associated with that interface.

It turns out that there is a hierarchy in define-event-classes that says all 
note-events are musical-events and all musical-events are rhythmic-events.  
Maybe we have assumed that the correspondingly-named interfaces have a 
corresponding hierarchy.

I'll try some other way of telling Accidental_engraver to ignore NullVoice.  
I'm trying to let people move NullVoice to Staff without reintroducing the 
known issue of the cancellation accidentals in
 \new Staff <<
   \new NullVoice {cis dis es fis}
   \new Voice {r4 c d e } >>


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4083: Implement \tagGroup command (issue 137920043 by d...@gnu.org)

[Keith OHara]

Patch set 5 will probably be fine.

My concern was that someone would be confused that adding to the list of tags 
to keep
  \keepWithTag editorial { ... \tag#'editorial \tag#'score \bar'||'  }
  \keepWithTag part.editorial { ... \tag#'editorial \tag#'score \bar'||'  }
can reduce the things that are kept.  But that will not likely come up, and you 
do explain it in the docstring for \keepWithTag

Don't put too much value on symmetry between how the tags in \keepWithTag, and 
the tags on each given piece of music enter, into the keep-or-remove decision.  
One set defines a single filter, the other describes each item that is going 
through the filter.  The keep-or-remove decision is part of an asymmetric 
operation.


On Sat, 06 Sep 2014 12:45:40 -0700,  wrote:


On 2014/09/06 18:55:42, Keith wrote:

The old patch :
\keepWithTag will keep music if any tag matches,
removing music with unmatching tags,
but ignoring tags in a different tagGroupfrom any of the tags to keep.


But "if any tag matches" becomes very tricky to explain when one needs
to implement a behavior where \tag A { \tag B ... is supposed to be
equivalent to \tag A \tag B ... while \keepWithTag A \keepWithTag B is
different from \keepWithTag A.B even when A and B are in different tag
groups.


The explanation above does cover the points you think might be tricky.

\tag A { \tag B ...   has not to date been equivalent to   \tag A \tag B ...
The explanation above says when B would be "ignored" by keepWithTag.  If A is 
ignored, or if B is ignored, the expressions just above are equivalent.

\keepWithTag A.B might keep more music than \keepWithTag A \keepWithTag B. The 
explanation above seems to make that clear, because it is easier to match "any 
tag" in A and B than to match each of A and B.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4078: Doc: Use variables rather than instrument definitions (issue 138950043 by tdanielsmu...@googlemail.com)

[Keith OHara]

On Sun, 31 Aug 2014 00:14:11 -0700,  wrote:


On 2014/08/31 06:58:47, Keith wrote:

https://codereview.appspot.com/138950043/diff/1/Documentation/notation/vocal.itely#newcode2646

\set instrumentCueName = "Flute"
This is the *other* use of instrumentSwitch,
which I'll probably put back to a <>^\markup


I think one of the points of the instrument switches was that you could
do as many as you liked in a row (namely, attaching the instrument
switch to the start of any music variable to be used for a particular
instrument) without triggering extraneous switch messages.

<>^\markup would seem to defeat that part of the original design.  While
we don't need the instrumentSwitch command as such, the respective
engravers weeding out duplication still serve a purpose.


This particular engraver seems to try, but fails, to suppress repeated 
identical settings.  (Maybe incorrect use of Scheme's eq? to compare the 
strings?)

{ \set instrumentCueName = "hautbois"
   c'4
   \set instrumentCueName = "hautbois"
   \set instrumentCueName = "cor.Ang."
   c'4
   \set instrumentCueName = "cor.Ang."
   c'4
   \set instrumentCueName = "cor.Ang."
   c'4 }

However, the (mis)use of instrumentCueName for labeling the instrument that is 
playing a cue (the topic of the documentation linked above) would not seem to 
benefit from suppression of repeated settings.  The use-case is something like

oboeNotes = \relative c'' {
   R1*32
   \new CueVoice { \set instrumentCueName = "flute" }
   \cueDuring #"flute" #UP { R1 }
   g2 c,
   R1*32
   \new CueVoice { \set instrumentCueName = "flute" }
   \cueDuring #"flute" #UP { R1 }
   g2 c, }


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Die, instrumentSwitch. (issue 133390043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 31 Aug 2014 01:06:46 -0700,  wrote:


A few minor comments below, but I don't see
how we can just remove the instructions for
setting up InstrumentSwitch without some replacement.
InstrumentSwitch is used by \cueDuring and friends.


\cueDuring itself does not use InstrumentSwitch; we were manually creating a 
temporary cueVoice just before the \cueduring.   That takes the font-size from 
CueVoice to use for the printed text, which is nice, but any overrides require 
a non-obvious path through InstrumentSwitch
  \new CueVoice \with {
\override InstrumentSwitch.direction = #DOWN
\override InstrumentSwitch.font-shape = #'italic
instrumentCueName = "Tuba" }
  \cueDuring "tuba" #DOWN { R1 g'2 bes' }

So the replacement for this use of InstrumentSwitch
   <>_\markup\italic\teeny"Tuba"
 is covered by the markup docmentation

The history is long.
I argued that the use of instrumentSwitch, to label the instrument playing 
cues, was useless
 http://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00148.html
and we removed it for some time,
 
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=4c1aa3b16f7b94ca32b0c022f60ed66826d031b0
 
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=539934ff10d5ab0d4e06dedcb8ff5a54ed43d427

But we used a construction that used zero-length durations, which we later 
removed
 
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=4ab6e4df934e57c51dbbdbf2c209273c6cb5b888

Instead of <>^\markup, I went back to the instrumentCueName; the reason I gave 
in the reitveld was complaints about the markup being tricky
 http://lists.gnu.org/archive/html/lilypond-user/2011-10/msg00118.html
That was dumb.  I had long-since stopped using instrumentCueName, so had 
forgotten that it is much more tricky to use.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: indclude notnames bn, etc., in English (issue 133840043 by k-ohara5...@oco.net)

[Keith OHara]

On Mon, 25 Aug 2014 00:28:14 -0700,  wrote:


Excuse my ignorance, is this going to need any extra documentation or
perhaps a changes.tely entry?

https://codereview.appspot.com/133840043/



I read through the documentation and saw no changes except mentioning the 
alternative names for bn, etc., just after the alternative spelling 'ases' for 
'asas'.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

On Sat, 23 Aug 2014 13:16:22 -0700, Dan Eble  wrote:


On Aug 23, 2014, at 08:03 , Dan Eble  wrote:

I think I’m really close (again!) to getting modern-voice-cautionary 
accidentals with combined-part stems by defining a new accidental style that 
disregards the part combiner’s voices.


It looks to me like make-limited-accidental-rule limits the creation of 
accidentals to a particular context, but it seems the accidental engraver would 
still consider the history of pitches recently seen throughout the staff.

Each context Staff, Voice, your previous SpecialVoiceGroup,  keeps track of 
accidentals in a data structure called localAlterations.  You might need to 
initialize it with \set SpecialVoiceGroup.localAlterations = #'()

Your previous approach with the SpecialVoiceGroup seemed more promising, if 
that group includes only the separate voices for each part, and if you move the 
accidental_engraver to that group.


It appears that in some cases both a cautionary and a normal accidental are 
typeset.  If just the normal accidentals were typeset, the output of the 
following example would be exactly what I want.  Is this a bug?



In your latest code, the interaction between contexts and the setter routines 
is complicated, but as I understand it, the partcombine voices are still 
producing accidentals following the portion of the rule that was not restricted 
to NullVoice.  That portion includes a rule to produce Cautionaries, but no 
rule for normal Accidentals.  Those voices, made by partcombine, produce the 
cautionary (in black) because those voices didn't produce any normal 
accidentals.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

On Sat, 16 Aug 2014 11:29:29 -0700, Dan Eble  wrote:


On Aug 11, 2014, at 02:43 , Keith OHara  wrote:


I'll still put NullVoice in \score by default, so it doesn't interact with the 
accidental engraver, or anything else that we haven't noticed yet, and let you  
\new Staff \with { \accepts NullVoice } when you really want NullVoice included 
in the Staff.


Isn’t this backwards?


Not if there are uses of NullVoice as a completely invisible voice.  If 
NullVoice does not show its own accidentals, alterations on NullVoice notes 
should not count for figuring which further notes need visible accidentals.


The bugs with part-combined accidentals seem to arise from the part combiner’s 
destroying information (and creating misleading information) by reassigning 
notes to other voices.  Instead of removing the NullVoice which has the 
valuable original information useful to the Accidental engraver, shouldn’t 
there be a way to make the Accidental_engraver ignore the voices created by the 
part combiner?  Here is an example that shows combined issues with accidentals, 
lyrics, and dynamics.

\accidentalStyle modern-voice-cautionary



  \partcombine \soprano \alto


One person wrote the accidental-setter to accept per-voice accounting; a 
different person wrote \partcombine.  I don't think either programmer 
considered using \partcombine with per-voice accidentals.

A lot of what \partcombine does, printing "solo" and suppressing rests during 
solos, and single-stemming unisons, does not seem to be traditional for engraving 
four-part harmony.  That makes me hope that someone has found a simpler way to combine 
two voices per staff without the complications of \partcombine.

Your method of using NullVoices to handle the Accidentals instead of the Voices 
seems like a sensible way to adapt LilyPond.  The combination of moving 
NullVoice to Staff, and changing the other Voices accordingly, could then be a 
packaged set of context definitions using the Voice building-blocks in a 
different way.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

On Sun, 10 Aug 2014 17:15:47 -0700, Dan Eble  wrote:



On Aug 10, 2014, at 15:40 , Dan Eble  wrote:

On Aug 10, 2014, at 14:55 , Keith OHara  wrote:

You could then enter \accepts NullVoice into just those Staffs where you use 
this technique.
(Usually, \partcombine refuses to change the voicing during dynamics, resulting 
more often in doubled dynamics;  I didn't know it would lose dynamics.)

Doh!  I just remembered that I’m not using the default functions for generating 
the part combiner split list.  I’m using 2.16(?) with my own modifications that 
make it look better for vocal music.  I’ll test the default and provide an 
example.  Maybe I need to merge the scheme code from the newer release into my 
own.


Please try this.  The first score is missing a dynamic mark.  The second score 
has both, with each on the correct side of the staff.


So \partcombine has another limitation in that it sets \partcombine b4\f b\p  
as unison despite the different dynamics.  Using \partcombineApart is the 
simple solution.

If you meant \new Staff <<..>>  in your example then I see now NullVoice helps. 
 \new Dynamics \soprano above the Staff would do similar, but then all the dynamics would 
be set on the same line.

I'll still put NullVoice in \score by default, so it doesn't interact with the 
accidental engraver, or anything else that we haven't noticed yet, and let you  
\new Staff \with { \accepts NullVoice } when you really want NullVoice included 
in the Staff.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

On Sun, 10 Aug 2014 10:05:04 -0700, Dan Eble  wrote:


Patch set 3 seems more useful to me than patch set 4.


Yep.  I'll combine the best of both:
1) NullVoice in Score by default, so that the invisible notes do not affect the 
setting of accidentals
2) settings enabled so that you can move NullVoice to Staff without the bugs we 
know how to solve


With NullVoice accepted by Staff, I am able to use NullVoice \with {  } to overcome another shortcoming of part-combined music, which is that 
simultaneous dynamics in the two source voices are lost if the notes to which they 
are attached are moved [by \partcombine?] into the shared voice.  My workaround fails 
when the NullVoice is accepted by Score instead of Staff.


You could then enter \accepts NullVoice into just those Staffs where you use 
this technique.
(Usually, \partcombine refuses to change the voicing during dynamics, resulting 
more often in doubled dynamics;  I didn't know it would lose dynamics.)


Also, the documentation should probably include \killCues on the notes within 
NullVoice.  Without it, there are warnings and extra notes in a score that has 
cues.  (Unless there’s something that could be done to NullVoice to make 
\killCues unnecessary.)



Here, I think it would be much better advice to enter the music so that the notes intended 
for NullVoice are not fed into \addQuote.   That would seem more natural if NullVoice is 
entered outside of the \new Staff <<..>>.  I don't use lyrics so have trouble 
imagining a practical example.

The NullVoice context does not have any natural way to know that notes sent to 
it, are also being sent to \addQuote, nor to apply \killCues in some other 
context that uses \cueDuring on that qoute.


I’m also trying to figure out if there is a simple way to add MIDI performance 
to NullVoice.



Should there be a simpler pre-packaged way to do this?



Currently, NullVoice provides the correct timing for MIDI output of any Lyrics 
attached to it, without sending any note-events to MIDI.  That seems to be what 
we should expect from an otherwise-invisible voice.

The most clear way of sending the notes, unprinted in the score to MIDI is with 
a separate \score for MIDI output, in which we put those notes (presumably 
stored in a variable) in a regular Voice.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4024: Clarify break-align symbols and space-alist args in IR. (issue 114160044 by markpole...@gmail.com)

[Keith OHara]

On Tue, 29 Jul 2014 13:12:47 -0700,  wrote:


Ah, I see.  Here's the confusion: when paired with right-edge, *all* 5
of the spacing-styles actually do something (to be clear, they all do
the same thing: they behave like extra-space, with space that doesn't
stretch).  Anyway, am I correct in concluding that right-edge is only
intended to work with extra-space?  I've edited the patch according to
that understanding; please review and comment again if you would.


That looks like what the code in 'break-alignment-interface.cc' would do.

When I worked on the spacing code, the behavior of these space-alist settings 
was maddening, and I had always planned to simplify them.  I like the idea of 
documenting them now, because that summarizes what we would have to think about 
in a convert-ly rule if we do simpify them.


For some reason Rietveld doesn't show the deltas from the previous patch
set (maybe because I rebased?), so you'll just have to read it again.


We can still see that delta if we ask for it in the pull-down menus :
https://codereview.appspot.com/114160044/diff2/1:60001/scm/define-grob-properties.scm


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 27 Jul 2014 23:07:58 -0700,  wrote:


The ugliness is with messing up the whole grob definition of a NoteHead
(which is fixed to the degree of being documented in the Internals
Reference) inside of a particular context.


I thought that was pretty, as well.
We override the defaults of grobs all the time to suit particular contexts (\omit 
NoteHead for example).  And this seemed a clear way of saying "all the default 
interfaces of a NoteHead except rhythmic-head".

I see that we usually don't change interfaces, though.


It is easy to make the rest of the code accept an object with
rhythmic-head-interface that is unattached to any Rhythmic_Column
(just removing a test and warning in rest-collision.cc as I recall).
 The thing I didn't like
about that was changing completely unrelated code to accommodate the
weirdness of NullVoice.


I don't see anything wrong with letting code work in more combinations
than originally envisioned.  Where is the point in having separate
building blocks if you can only assemble them in a single way?


Well, the code worked, but gave a warning.  We might want to warn that someone 
is assembling blocks in a dangerous way.   Looking at the history, this warning 
does not seem helpful.

I can remove that warning, and restore the \omit Accidental*
so that someone can have Staff accept NullVoice


The point would be to stop the Tie_engraver from bothering about
melismaBusy at all.


Splitting the melismaBusy function from Tie_engraver, etc., and putting it in a 
new engraver does seem sensible.


But isn't NullVoice for faking lyrics to a synthetic voice that is _not_
actually being printed?  That would imply that we want to rather align
to the existing NoteHeads/NoteColumns rather than the NullVoice one.
And even if there are no actual notes (like in a chant situation), we'd
rather align on a well-spaced pattern rather than one based on imaginary
noteheads, optical stem adjustments and what not.


(We don't get stem-corrections without stems.)
My first inclination was to produce no NoteHead grobs.  LyricExtenders and I 
think LyricHyphens needed work to help them find the NoteColums within their 
parent PaperColumns (like Janek made happen for LyricText).

With all that, NullVoice can be just Devnull plus a melisma_signal_engraver.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by janek.lilyp...@gmail.com)

[Keith OHara]

On Sun, 27 Jul 2014 09:44:22 -0700,  wrote:


On 2014/07/26 21:36:12, Keith wrote:

On 2014/07/26 06:49:41, janek wrote:
>
> Setting TextScript.cross-staff property to #f is required to

ensure

> that there are no collisions between TextScripts and cross-staff

notes:



The concept of a "cross-staff note" seems strange.  It appeared with

the change

for issue 2527 https://codereview.appspot.com/6827072#msg13




Hmm.  Do i see correctly that the patch in
https://codereview.appspot.com/6827072 was then partially reverted with
commit 7891600a5dd421c1f25776ea3b405c64f4f14752 ?


Right.  NoteColumns are no longer cross-staff.
If we mark TextScript.cross-staff=#t it collides with /any/ note.

Cross-staff things are skipped during outside-staff placement
  axis-group-interface.cc:939
(though it seems they could, with more code, be placed relative to their parent 
staff, without being included in the parent staff's skyline).

Most things that go cross-staff use the side-position-interface to avoid 
collisions, but the engraver for TextScripts does not put anything into its 
'support' list so that method has no effect.

I think the example of issue 1300 succeeds only because TextScript is put in a 
ScriptColumn with the accent.  It collides in the stable release if there is no 
accent, or a trill in place of the accent.

define-grob-properties says 'cross-staff' means that the object can change 
shape or move relative to its parent, depending on how staves are spaced on the 
page.   TextScripts do not yet respond to staff-spacing, except when they are 
in a ScriptColumn that knows how to avoid a cross-staff beam, and that case 
seems inconsistent.


Shall i revert commit
2371d6ba3b62d4d6dc349ab50fa0d76eadfba044 for now?


I don't know.   The case of issue 1300 was not a realistic input, and similar 
cases fail in the stable build.  On the other hand, from the tracker issue, it 
looks like your commit doesn't provide us with any improvements.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

Dan Eble  faithful.be> writes:

> It sounds like you are saying the issue with spurious accidental 
> cancellations is fixed in 2.19.9 

No, NullVoice still has those problems, because it still creates
invisible note-heads, and applies various workarounds so that the
note-heads don't have any effect except for positioning Lyrics.

2.19.9 positions Lyrics better if you enter Lyrics with durations,
no longer needing the note-heads for positioning.  This opens the
door to avoid the problems in NullVoice.

> Entering lyrics with durations is inconvenient.  

So we want to get durations from music in a NullVoice. 
What I posted earlier was a suggested re-definition of NullVoice that
does only what is needed.

I see now that my suggestion does not align lyrics to moments
between printed note columns (which is done if you enter lyrics 
with durations) so we would have to include a Rhythmic_column_engraver 
and convince it to produce note-columns even when there are zero note
heads.





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: AccidentalCautionary in NullVoice

[Keith OHara]

Dan Eble  faithful.be> writes:

> On Feb 9, 2014, at 21:19 , Dan Eble  faithful.be> wrote:
> 
> > Here is a work-around for
> > https://code.google.com/p/lilypond/issues/detail?id=3834 

NullVoice looks like a long list of workarounds.

Now that Janek has independent Lyrics aligned as of version 2.19.9,
entering with durations { La2. di4 da1 } works pretty well,
and NullVoice need only watch for slurs, etc., and signal melismata.

Try

\layout {
\context {
  \name "NullVoice"
  \type "Engraver_group"
  \description "For aligning lyrics without printing notes"

  \alias "Staff"
  \alias "Voice"

  \consists "Tie_engraver" 
  \consists "Beam_engraver"
  \consists "Slur_engraver"
  % maybe a single scheme engraver to signal melismata 
}}



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: fix Issue 2462. (issue 108280044 by janek.lilyp...@gmail.com)

[Keith OHara]

On Fri, 04 Jul 2014 14:38:19 -0700, Janek Warchoł  
wrote:


2014-07-04 23:26 GMT+02:00 Janek Warchoł :


That's actually not what i want to do; I apologize for being unclear.
I *want* the columns to behave the same way in case of both
accidentals and lyrics (and everything else).  The desired behaviour
is that changing min_distance shouldn't affect ideal distance.


Sensible, for the data object Springs.  The special behavior when min_distance 
is larger or within 0.3 of ideal is confusing.  The fact that the special 
behavior appears only after using merge_springs() makes things more confusing.

Notice that frax/springs keeps that special behavior, in Spring::length().  The 
natural, force=0, length of a spring is *always* at least min_distance+0.3


Achieving this [desired, not-special] behaviour when columns arewide due to 
lyrics is simple:



but there
are side effects (too tight spacing in some cases, for example in
beam-rest-extreme.ly) which i'm unable to fix.


Trace back and see what code uses that +0.3 to good effect, though probably by 
accident.

Only spacing-spanner.cc uses Spring::merge_springs(), and when setting 
'beam-rest-extreme.ly' it is used to 'merge' only one spring!

So one good effect is that accidentals are prevented from getting too close to 
the previous note.  That would be better handled with padding associated with 
the accidental


You could limit the changes in one patch, if you like, by moving the "ideal = 
max(idea, min_distance +0.3)" to the point where spacing-spanner.cc finds 
min_distance to avoid collisions.  A magic number is better than a magic number in a 
mysterious place, and making the 0.3 a parameter is safer to do after we narrow down its 
beneficial effect.

If merge_springs() behaves more simply, it might do a little better for

(I notice that the option 'average-spacing-wishes' is no longer checked; the 
code seems to always average spacing between voices.)


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: fix Issue 2462. (issue 108280044 by janek.lilyp...@gmail.com)

[Keith OHara]

On Wed, 02 Jul 2014 23:56:20 -0700,  wrote:


you should try
to make the change consistently everywhere ?


Yes, that's what i'm aiming for.  However, as you remember, some of
these changes produce unwanted side-effects


I remember you said there were side effects, but you did not until now
say what they were.

You say you want ideal spacing to be at least as large as the required
'rod' that prevents collisions, if the collisions involve accidentals,


0.3 is needed to "slow down" approaching min_distance_, for example in
beam-rest-extreme.ly - because of the accidentals and suspended notes,
the min_distance_ is bigger than distance_, which means that even for
"natural" (ragged-right) spacing the springs would be set to the min
distance (making the accidentals touch previous notes).  We want to add
some space [to the ideal distance_ -KOH], so that the accidentals willtouch 
previous notes only when there is a significant compressing force.



but not if the note-columns are wide due to lyrics.


Description:
When objects like lyrics are added to the PaperColumns, LilyPond inserts
rods between these columns to ensure that the objects won't overlap.
However, the ideal distance should remain unchanged.


It is surprising that you distinguish those cases by lengthening the ideal
spacing in  merge_springs() but not lengthening the ideal spacing in
set_blocking_force().  I would have expected both functions to be used in
each of your examples, the one with accidentals and that with lyrics.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: NR Pitches.itely - added 2 new snippets (issue 110240044 by pkx1...@gmail.com)

[Keith OHara]

On Mon, 30 Jun 2014 14:40:17 -0700,  wrote:


Is it worth making the Notation Reference longer?


What do you suggest?


Depending on your opinion about the NR length, maybe leaving these examples in 
lsr only.


https://codereview.appspot.com/110240044/diff/40001/Documentation/notation/pitches.itely#newcode1325
Documentation/notation/pitches.itely:1325: \override
Staff.KeySignature.flat-positions = #'((-5 . 5))
On 2014/06/29 03:17:00, Keith wrote:

This already shows how to print key signatures over a different or

wider range

of the staff.  You might consider this good enough.


I don't understand what you mean. Good enough compared to what?


Good enough alone, without the creating-custom-key-signatures.ly snippet.
The double-clef would fit in tweaking-clef-properties.ly

Or, the double-clef might be a better example for \translate in appendix A.10.2
\markup {
   \combine
 \musicglyph #"clefs.C"
 \translate #'(2.5 . 2) \musicglyph #"clefs.G"
}

If you don't mind the NR length, this all looks good as it is.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3254: align unassociated lyrics using NoteColumn extent. (issue 108110044 by janek.lilyp...@gmail.com)

[Keith OHara]

On Thu, 26 Jun 2014 01:01:11 -0700,  wrote:


pushed as c73b41b3e7be6d7280c6336cf03610cd7aed3000 - thanks for review!
I'll post a follow-up patch later today.

https://codereview.appspot.com/108110044/



It seems that after this patch, the old well-tested Devnull context should do 
everything that the new NullVoice does, without the complications and remaining 
problems.

Do you also expect this to be true?   If you understand the full purpose of 
NullVoice and can check that Devnull fills the need, you might create a patch 
to make NullVoice a simple alias for Devnull (and reverse any patches related 
to NullVoice that we wouldn't otherwise want in the code).


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line-breaking bug in 2.19

[Keith OHara]

On Mon, 17 Feb 2014 00:24:22 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 23:50:06 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł  
wrote:


2014-01-17 17:55 GMT+01:00 Keith OHara :

Starting with version 2.19.0, the bassoon part from
<http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
gets a short line.



I can revert the commit
  
https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb
(resolving conflicts by hand) to remove the problem.



Tuplets are not required, so here is a closer-to-minimal example:

\version "2.19.1"
\new Staff \relative c' {
  \override Score.SpacingSpanner.shortest-duration-space = #1.6
  e16 f g e d c d e f e d c d e f e
  g g f e d e c c f e e d e c c f
  \break
  e1 e e e }


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line-breaking bug in 2.19

[Keith OHara]

On Sun, 16 Feb 2014 23:50:06 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł  
wrote:


2014-01-17 17:55 GMT+01:00 Keith OHara :

Starting with version 2.19.0, the bassoon part from
<http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
gets a short line.



I can revert the commit
  
https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb
(resolving conflicts by hand) to remove the problem.



\version "2.19.1"
\new Staff \relative c' {
  \override Score.SpacingSpanner.shortest-duration-space = #1.75
  e16*2/3 f g e d c  d e f e d c
  d e f e g g  f e d e c c
  \break
  e1 e e e }


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line-breaking bug in 2.19

[Keith OHara]

On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara  wrote:


On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł  
wrote:


2014-01-17 17:55 GMT+01:00 Keith OHara :

Starting with version 2.19.0, the bassoon part from
<http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
gets a short line.



I put a version of the sources that works with version 2.19 at 
<http://k-ohara.oco.net/Lilypond/>

With that version the short line is in the Trumpet part (not the Bassoon part).


There is a line in the Trumpet part that consists of one measure of cue notes, 
and lilypond 2.19 puts this one measure alone on a line.  I can copy the cue 
notes directly into the Trumpet part, in the usual Voice not the CueVoice, and 
still see the problem.  This single measure is a full measure of triplet 16th 
notes.  I can rewrite them as 16*2/3 notes and still see the problem.  If I 
rewrite as 16 32 32 the problem goes away and I see reasonable line-breaking.

I can revert the commit
 
https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb
(resolving conflicts by hand) to remove the problem.

I still have not been able to extract an example of reasonable size that shows 
the problem.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line-breaking bug in 2.19

[Keith OHara]

On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł  
wrote:


2014-01-17 17:55 GMT+01:00 Keith OHara :

Starting with version 2.19.0, the bassoon part from
<http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
gets a short line.



I have tried to minimize the example, but unfortunately convert-ly is
not enough to make the score compile with 2.19,


I used one tiny bit of Scheme, which convert-ly cannot update automatically.

I put a version of the sources that works with version 2.19 at 
<http://k-ohara.oco.net/Lilypond/>

With that version the short line is in the Trumpet part (not the Bassoon part).


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: NR: Removed example for alternate repeats (issue 61170044)

[Keith OHara]

On Mon, 10 Feb 2014 04:31:25 -0800,  wrote:


These three examples are more useful as regression tests than as
documentation.



Are they robust enough? Do they exercise each property properly?


They seem good enough, but it is not essential to add them to /input/regressoin/
They won't get lost, being findable in the mailing list archives, and there is 
tracker issue 3841 to remind us to get the newly-working behavior into 
regression tests eventually.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

line-breaking bug in 2.19

[Keith OHara]

Starting with version 2.19.0, the bassoon part from

gets a short line.

The first commit where this happens is f8416b for issue 3304 (making horizontal 
spacing even) but it seems that for any values of the ideal horizontal spacing, 
the line-breaker should find full lines.  The original cause might be from one 
of the line-breaking issues like 3441.

It will take some time to minimize the example, as it always does.  But I 
thought having the information here might help if anybody else has noticed some 
aspect of the problem.

I'll try to revert the most-likely cause before 2.19.1<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: regtest for new glyphs necessary?

[Keith OHara]

Marc Hohl  hohlart.de> writes:

> I am about to upload a patch for these four glyphs within the next
> days, but I wanted to ask whether a new (or enhanced existing)
> regtest is necessary for this type of enhancement?

They could conceivably be broken accidentally, by a mistaken change 
to our .mf files or a metafont bug, so a regression test is useful.
LilyPond probably has too many tests, but you could add to 'clefs.ly'


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)

[Keith OHara]

On Thu, 26 Dec 2013 22:47:41 -0800, Trevor Bača  wrote:


I suppose it's important to note that all of my scores use proportional
notation everywhere. So I imagine that most of the horizontal spacing
improvements don't actually impact my scores. (The recent spacing changes
optimize Lily's *default* spacing, correct?)


This patch does concern the default method of horizontal spacing.

The bug that this is meant to fix 
(http://code.google.com/p/lilypond/issues/detail?id=3304) can be seen even with 
proportionalNotationDuration, if there are interleaved rhythms on a line that 
is stretched or compressed.  Probably, though, you also set 
'uniform-stretching', which removes the problem.

This patch makes the default spacing case stretch/compress more like it does 
with uniform-stretching, while keeping the detailed spacing adjustments in 
response to things like neighboring stem directions that 'uniform-stretching' 
would normally skip.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)

[Keith OHara]

On Sun, 22 Dec 2013 11:45:49 -0800, Devon Schudy  wrote:


Unfolding during iteration doesn't extend well to voltas, because it
changes their length. Even if the length is updated, the old length
has already been used by the parent iterator to compute moments for
subsequent events. So unless this can be changed,


Okay.  That eager evaluation of lengths by the iterators also frustrated my 
attempt at a \RestUntil function (to fill the tuba part, for example, with 
rests until the next tempo change) so we might change that someday.


Keith wrote:

I think we need the tremolo-type property to hold the 32 from input c2:32


On TremoloEvent, yes. But do we need it on TremoloRepeatedMusic? I
suppose it might be handy for tweaking.


I see.  It is not very likely that anyone refers to tremolo-type of the Music, 
so possible tweaking does not seem enough reason to keep it.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)

[Keith OHara]

On Sat, 21 Dec 2013 00:23:05 -0800,  wrote:


Keith comments:

The other limitation of \unfoldRepeats is that it fails to see repeats

in

parallel expressions << {\repeat volta 2 s1 } {c2 d2} >> while this

approach

using the iterators will see them and be able to expand them when

requested.

I think he is wrong about that.  I don't see anything inherent in this
code that would work differently here.


I meant the future of this approach, after there is the option to unfold volta 
repeats.

I was thinking that by doing the unfolding in the iterators
(as opposed to working on music expressions as \unfoldRepeats does)
it would be at least possible to expand volta repeats.

It would not be easy, because there are nonsense cases like
  << {s1 \repeat volta 2 s1 } {c1~ c2 d2} >>
and probably some very similar things that actually make sense.

It would take significant work to communicate between various iterators,
similar to the efforts Mike made to break slurs at repeats.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Sat, 14 Dec 2013 23:57:20 -0800, Mike Solomon  wrote:


On Dec 15, 2013, at 12:58 AM, Keith OHara  wrote:


The most transparent reorganization might be to have all properties that can 
hold data use the usual callback mechanism: where the callback function is used 
just once, and the data it returns takes the place of the callback.


This is indeed transparent, but given that a single object can return many pure 
heights based on the begin/end values being used or based on how far downstream 
we are, it’s not clear what this property would look like.



There would be no more 'pure properties' as you use that term.
The property 'height' would give the final height.
If the object changes height based on layout, 'height' would be a callback.

Code that works while layout is tentative would not call callbacks,
but could lookup a property 'height-estimator' that links to the pure_height() 
function.


This seems to get the same result we have now while adding a lot of extra 
properties.


Extra properties on those Grobs that use them, in place of the 
unpure-pure-containers.
Reorganization for transparency makes complexity visible.


I like the idea of there being a single property that is honed in on with 
successive estimates until we get the perfect value.


But so far, we do not use the previous estimate of a property to inform the 
next estimate.  In fact, with only one slot to hold either the property value 
or the function to compute it, Grobs keep secret any progress they have made 
toward a better estimate, and even forget it themselves.

Simple properties like 'height' could hold either data or simple callbacks that 
are executed once, with these callbacks allowed to *pull* information from 
other grobs and cause their callbacks to execute as well.

Separate function-properties like 'height-estimator' could provide estimates 
when we must avoid forcing other decisions.  They could use /data/ in other 
Grobs' properties, but not callbacks.  These function-properties belong to the 
Grob, so can write the result to its 'height when that estimate is good enough 
to share.  You have wanted to use a preliminary shape for cross-staff slurs to 
inform layout, for example.

The code re-shaping things like Slurs after page-spacing could *push* an 
improved shape onto the 'stencil' and 'height' properties.


Something about using the container (the property) as a holder of the estimates 
and the final item itself feels sound design-wise.


At the moment, the property does not hold any estimates; it holds either the 
final data or various functions to fetch the data, and some of these functions 
operate under subtly different rules, both in your unpure-pure-container system 
and Joe's former system.

This subtleties confuse people: issues 3512 and 3482, and the difficulty I had 
in this thread understanding that the same function was called multiple times 
to repeatedly build 'vertical-skylines around each letter.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Sat, 14 Dec 2013 14:58:52 -0800, Keith OHara  wrote:


Several considered line-breaks might have the same 'start' and 'end' around the 
hairpin, but the upper-level axis-group structure caches results for each 
start/end pair so just one skyline is generated for each distinct pair request. 
 The path that generates these calls, however, bypasses the cache, and causes 
repeated generation of the skyline.


Sorry, I was pointing a few lines up when I typed "these calls" but of course 
you can't see that.  That second sentence should be :

The path that generates the calls with start=0 end=10 and with start=0 
end=2^31, however, bypasses the cache, and causes repeated generation of the 
skyline.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon  wrote:


On Dec 14, 2013, at 9:35 AM, David Kastrup  wrote:


Most of the contortions seem focused about when or when not and how to
pass begin/end columns.  It would seem to make sense to turn them into
dynamic parameters *begin* *end* that you can then query with (*begin*)
and (*end*).  If (*begin*) returns ##f, we can assume being in a pure
calculation.

That would seem to get rid of most of the current interface
complications.


I can see the utility of having one function instead of two for these things.

The current pure and non-pure functions are often wrappers around a single 
internal function that has a bool parameter called “pure”, so this would 
eliminate the need for the wrapper functions.



Well, the presence of 'begin' and 'end' parameters is a far less important 
distinction, between the pure-estimate and unpure-final versions of a function, 
than the vastly different roles of these functions in layout.

When the same code is shared too much between these roles, LilyPond does some 
immensely silly things.

DynamicLineSpanner uses the same code for 'vertical-skylines' in both 'pure' and 
'unpure' roles.  This causes a spanner p 
'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'

--
The most transparent reorganization might be to have all properties that can 
hold data use the usual callback mechanism: where the callback function is used 
just once, and the data it returns takes the place of the callback.

The layout engine could use get_property_data() freely, but before it has set 
line-breaks the layout engine would refrain from calling any callback functions 
directly.  Instead of a callback for 'height', layout functions would look up 
the grob property 'tentative-height-estimator' where tentative-*-estimators are 
always functions that take the start-end columns as parameters.

The tentative-height-estimator for something like a Slur or VerticalAxisGroup would 
return its best guess for the height, while the estimator for a Clef would simply 
get_property("height") causing its stencil to be formed and leaving the 
resulting data in the 'stencil' and 'height' properties for further use.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup  wrote:


That does not make sense.  If you want call-once behavior, you can just
use a callback.


At the moment, the decision on whether to preserve the callback pointer in the 
grob property, or fill the property with the returned value, depends on the 
method used to request the property, get_pure_property() versus get_property(). 
  A callback would be called multiple times (and it would have to support the 
unpure-pure calling convention).

The information of whether the callback is providing a value that /should/ be 
kept as final is better stored in the Grob itself, so I am thinking of ways to 
reorganize.

The way stencil callbacks are evaluated now is interesting.  The stencil callback itself 
is a simple callback, but when the layout engine wants to know the size of a stencil it 
does get_pure_property("Y-extent").  Y-extent property is set to either execute 
the stencil callback, or estimate a height without building the final stencil, as 
appropriate for each Grob.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Dec 13, 2013, at 9:07 AM, Keith OHara  wrote:


Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). 
 Inserting print statements to trace those calls I find that FT_Get_Name_Index 
is called:
7 times for each character in a Tempo


The layers of functions that result in repeated calls to the skylining code 
have changed since the original skylines patch.  The latest change was

author  David Kastrup   
 Thu, 21 Feb 2013 19:02:48 + (20:02 +0100)
 Issue 3200: Make ly:make-unpure-pure-container accept a single callback

 Like with fixed values, this gets duplicated for the pure value as
 well, but converted into a callback taking two more arguments (which
 are ignored).

This type of unpure-pure-container is not a container of two functions but 
rather a single callback function, that promises to refrain from forcing 
line-break decisions (to be 'pure') and that ignores the two arguments giving 
the start- and end- of the line it would be on in the tentative line-breaks 
under consideration.

In this case repeated calls will recompute the same value, so I see no reason 
to keep the function-call pointer in place after the first use.  So I suggest 
we treat this case as if it were a simple lookup of a property, rather than a 
'pure' lookup.  http://codereview.appspot.com/42190043

This case includes the function to find skylines for Lyrics and TextScripts.


On Thu, 12 Dec 2013 23:45:45 -0800, Mike Solomon  wrote:


My LilyPond is not working for some reason (see previous e-mail about 
debugging).  Once I get it up and running, I’ll have a go at this.



Could you look at issue 3512 first ?
If we get clear on what unpure-pure is all about we might be able to simplify 
things.

For example, it seems to me that the unpure-pure-container with a single 
callback is not logically connected to any other unpure-pure-containers, so 
should have its own tag and different behavior.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Fri, 13 Dec 2013 01:38:23 -0800, Werner LEMBERG  wrote:


I will check whether I can improve that in FreeType.


Is there a reason this would have such a significantly different
impact in Windows?


No.  It's exactly the same code on both platforms.  However, for
lilypond, even a single-element cache would help, see attached
quick'n'dirty patch (for FreeType).



The repeated look-ups of the same character, however, are not likely to be 
successive calls to FT_Get_Name_Index(), so will not find the answer in such a 
cache.

I do see how sfnt_get_name_index() does a linear search through the font to 
find a matching name.  Much better if LilyPond could look up text characters by 
their Unicode encoding.

The issue with Lilypond 2.17.95 is a more complicated than the original case 
where we noticed that these look-ups took longer on Windows:  
http://code.google.com/p/lilypond/issues/detail?id=1926


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Thu, 12 Dec 2013 23:07:19 -0800, Keith OHara  wrote:


I am happy to say that I was wrong here.

Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). 
 Inserting print statements to trace those calls I find that FT_Get_Name_Index 
is called:
7 times for each character in a Tempo


I had failed to notice how the 'pure' calls to vertical-skylines are 
implemented.

Most properties, if directed to a callback function, have result of the 
callback function replace the pointer to that function.  This way the function 
does its job just once.

Sizes of spanners, that do depend on layout but are needed to evaluate potential 
layouts, are cached in Spanner::get_cached_pure_property() for each combination of 
'start' & 'end' columns that define the line of music on which they might 
appear.

If the property-lookup is 'pure' (tentative) then usually callback functions 
are not called.
Previously, functions providing stencils of objects whose shape does not depend 
on page-layout were on a pure-print-callback list, so their shapes could be 
used during layout decisions.

At the moment, there is an unpure-pure-container wrapper around the (expensive) 
function that builds skylines for text.  For some reason this allows repeated 
function calls to re-compute the property, even when the 'pure' and 'unpure' 
versions are the same.

Somewhere there should be a way to mark the skylines as "independent of layout" 
and the method should be used for vertical-skylines of text.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara  wrote:


After a brief look at the code, it looked like for each glyph being laid out 
there is one extra call of Open_type_font:: or Pango_font::name_to_index(), 
which is the function called by find_by_name() that caused the extra time with 
issue 1926.



I am happy to say that I was wrong here.

Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). 
 Inserting print statements to trace those calls I find that FT_Get_Name_Index 
is called:
7 times for each character in a Tempo
5 times for each character in a Text Script
...
1 time for each notehead
5 times for each rest

If I use boxes instead of glyph outlines for vertical-skylines:
0 times for each character in a Tempo (probably just uses the Unicode index)
0 times for each character in a Text Script ( " )
1 time for each notehead
5 times for each rest

So the outlines for each letter are re-built several times (through some path 
in the code that I have not yet found).  Whether the expensive part is the 
FreeType function call, or joining about 60 boxes per character into the 
skyline for the word, there is a good chance that we can save both by building 
skylines once for each word.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup  wrote:


"Keith OHara"  writes:


The last time we had a doubling of time required on Windows relative
to Linux, issue 1926, it was repeated calls to find_by_name() that go
through Pango to the font server.

Here the outlines seem to be properly cached; it looks like each text
glyph is looked up just one extra time.


Once every time it is written, or once per document?  And what does
"just one extra time" mean?  One extra per which occasion?


After a brief look at the code, it looked like for each glyph being laid out 
there is one extra call of Open_type_font:: or Pango_font::name_to_index(), 
which is the function called by find_by_name() that caused the extra time with 
issue 1926.

That is, for every 'mf' in the piece, we look up two glyphs by name 'm' and 'f' 
from the font to get a skyline for the 'mf', each skyline is built just once.  
The look-ups are extra over those used to implement the stencil.

One extra lookup per glyph might be enough to explain the difference.  We need 
to look up the glyph to get a skyline, but maybe could cache its index into the 
font in the stencil.

What did you mean to suggest here? :

In this case, the answer is to cache frequently accessed
information instead of requesting it again and again.




The call the to FreeType glyph-outline code might cause the extra
time, or maybe Guile is less efficient on WinXP, as every nook and
cranny in every letter is represented in the skylines objects in
Scheme.


If there are differences in speed, I can't imagine them to be in
anything but possibly garbage collection/allocation, and it seems
unlikely that they would not then have been apparent with other uses.



Probably true.  I mentioned these possibilities after noticing that there are 
quite a few boxes required to represent the outline of each letter..

What did you mean to suggest here? :

Maybe caching in unsuitable form?  Cached data should be in a form
directly usable for processing (with some possible tradeoffs between
memory impact and unpacking speed), not in the form that
function/library/system calls will return it.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara  wrote:


On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes  wrote:


When I benchmarked with and without
skylines, I found there was only a noticeable difference with a lot of
markup or similar: "normal" music had almost no effect.  As a result, I
concluded with skylining was the correct default.



I'll try your Mikado on my WinXP system,


Chorus Number 5 takes 17.2s with 2.16.2, and takes 31.1s with 2.17.95

This ratio of times is worse than Phil saw when he timed the full Act1 using 
Win64Vista.  So maybe the larger slowdown is localized to WinXP.  Disabling all 
the vertical-skylines-from-stencil-integral settings brings the time down to 
16.2s with version 2.17.95.

The last time we had a doubling of time required on Windows relative to Linux, 
issue 1926, it was repeated calls to find_by_name() that go through Pango to 
the font server.

Here the outlines seem to be properly cached; it looks like each text glyph is 
looked up just one extra time.  The call the to FreeType glyph-outline code 
might cause the extra time, or maybe Guile is less efficient on WinXP, as every 
nook and cranny in every letter is represented in the skylines objects in 
Scheme.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes  wrote:


When I benchmarked with and without
skylines, I found there was only a noticeable difference with a lot of
markup or similar: "normal" music had almost no effect.  As a result, I
concluded with skylining was the correct default.



I agreed about the default being good, but normal music was 30% slower
 http://lists.gnu.org/archive/html/lilypond-devel/2013-09/msg00234.html

(We see there the effect of Mike's commit that cached the (millions) of 
page-fillings from Joe's line-breaking scheme; that caching made 2.14 3x faster 
than 2.12.)

I had seen the same, moderate, effect on Linux, but the same music suffers more 
with skylines on my WinXP system.  I'll try your Mikado on my WinXP system, to 
narrow down the key components that show the 2x slowdown.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup  wrote:


"Keith OHara"  writes:


I timed one big score, Movement 1 of 
<http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
 2.16.2  2.17.95
 WinXP   2m 30s  5m 10s
 Fedora  1m 50s  1m 50s



Have you used the GUB-compiled binary package, or Fedora's built-in or a
self-compiled package?  I think that you probably can only make
platform-specific comparisons if you use GUB for all.


GUB-compiled packages in all cases give the same results as above.

Most of the increase in time to set this score happened between 2.17.0 and .1
 2.16.2 2m 30s
 2.17.0 2m 28s
 2.17.1 4m 06s
so it is probably the issue 2148 patch, use of outlines instead of boxes for 
layout.

I did speed-test that patch, but under Linux.  Maybe the system calls to the 
font server, to get outlines for the glyphs, take longer under Windows.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reduce offsets of \super and \sub (issue 35320043)

[Keith OHara]

On Sat, 30 Nov 2013 23:56:09 -0800,  wrote:


I have one request: this patch makes the situation better, and even if
the baseline-skip approach is wrong, it was already used that way so
it's not making things worse.  I suggest to push this patch, and then
work on making this smarter (in the spirit of "best is the enemy of the
good").


Definitely.

The patch as it is already fixes both cases here
  \markup {  \concat { 8 \super va }
\fontsize #3 \concat { 8 \super va } }
because \fontsize changes baseline-skip in harmony.

Scaling on font-size would properly change the #:properties line of some of 
these functions, which affects `make doc`, and last time I did that in this 
file it was a disaster (http://codereview.appspot.com/9295044/).





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel