custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

Hello,

I'm currently attempting to write a custom engraver in scheme.
This is the shortened code:

;; global variables to be used in `do-something'
#(define g_filled #f)
#(define g_direction 0)
#(define g_finger 0)
#(define g_string-number 0)
;; 


#(define-public (music-cause grob)
  (let*
  ((event (event-cause grob)))

(if (ly:stream-event? event)
(ly:event-property event 'music-cause)
#f)))


#(define my-engraver
   (list

 (cons 'acknowledgers
   (list
 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
 (let* ((event (event-cause grob))
(mus (music-cause grob))

;; TODO: how do I get *into* this articulations list?
(articulations (ly:music-property mus 'articulations)))

   ;; note head filling depends on duration
   (set! g_filled (ly:moment)
  (elements)
  (duration . #)
  (articulations #))
   ((display-methods #)
(name . FingeringEvent)
(types general-music fingering-event 
event)) >)
  (digit . 2)
  (origin . #))
 ((class . fingering-event)) >
 )
  (pitch . #)
  (origin . #))

((display-methods #)
 (name . NoteEvent)
 (types general-music event note-event rhythmic-event melodic-event)) >

I'm trying to get to the music object *inside* the `articulations' list,
but I cannot seem to find a way to do so. Simply getting the property
`articulations' with ly:music-property returns a list, but I cannot run
cdr or car on that list to get to the Stream_event.

Is there a way to do this? Maybe this is the wrong approach. Is there
another way to get access to all music properties from within an
acknowledger?
Can I use more than one interface in the same acknowledger?

I tried using event listeners before to collect the note properties, but
this fails as soon as there is more than one voice, because the
acknowledgers are called after *all* the listeners at a certain moment.

I'd appreciate any comments or hints.

Thanks,

Rekado

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

Re: GOP-PROP 8: issue priorities (radical update)

[Graham Percival]

On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote:
> 
> Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM
> >Because having some issue officially block stable release is the
> >only
> >way of seriously pushing developers to fix it?
> 
> Wouldn't work.  Few, if any, developers use lily-git.tcl so
> are unlikely to be in a position to fix it.

Using lily-git.tcl and being able to fix it are completely
different things.  IIRC the only people who have worked on
lily-git.tcl are the original author of it, Carl, and me -- none
of these people actually use lily-git.tcl.

Besides, lily-git.tcl is only a small fraction of the things which
may stop a contributor from helping out.  If savannah is down,
then nobody can push (or pull) anything.

> Developers seem to become more productive when
> releases are make frequently.  If releases stop, for whatever
> reason, development slows down. So if this is intended as
> a means of coercion I think it is misguided.

I disagree; developers are more productive when there's more
*unstable* releases; stable releases don't really affect things
(other than the prospect of a stable release increasing work).

No, there's no doubt in my mind that including "stops development"
as a Critical issue would help get them solved sooner.  The only
question in my mind is whether this is an acceptable departure
from the "describe bugs in neutral terms... each contributor can
interpret the results as he or she sees fit" idea.

I honestly think that we *should* depart from that overall idea in
this case, but I'm troubled by my inability to give a convincing
reason (even to myself) as to why.

Cheers,
- Graham

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

Re: GOP-PROP 5: build system output (final)

[Matthias Kilian]

On Tue, Aug 09, 2011 at 04:34:57PM +0100, Phil Holmes wrote:
> >I'm afraid I'm with Reinhold. As a *programmer*, I consider it very bad
> >practice to ignore warnings. For the system to hide them from me, well !!!
> 
> 
> They're not being ignored.  They're not even being seen.  Please address my 
> point of how you would see them in 37,000 lines of console output.

Many people are building *any* large projects with something like

make 2>&1 | tee m.log

and then look at m.log after the build. I do so, and I do so by
default.  When building distribution packages for OpenBSD, I also
log the complete output of extracting, patching, configuring,
building and installing and look at that log file. I won't look at
any project specific logfiles.

Important stuff *has* to go to stdout or stderr. If every project
would invent its own way to hide important messages from stdout/stderr
*by default* and put them into project specific logfiles, it would
a hell for everyone who's porting those project to specific operating
system distributions.

I don't want to have to look *where* too look for warnings and
errors.

However, the normal build output won't be touched, as Graham wrote.
It's only about the doc output for now, if I understood Graham
correctly.

Ciao,
Kili

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

Re: GOP-PROP 5: build system output (final)

[Matthias Kilian]

On Tue, Aug 09, 2011 at 04:26:00PM +0100, Wols Lists wrote:
> > out/parser.cc:2392: warning: conversion to 'short int' from 'int' may
> > alter its value
[...]
> [...] That "out/parser" is a perfect example - it *may*
> be innocuous, or it *may* be a serious problem. It really ought to be
> checked out and fixed, and if I were a boss, I would have no qualms
> whatever about saying "fix it".

It depends on the bison version. I don't get this warning with
bison-2.3.

Ciao,
Kili

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

Re: GOP-PROP 9: behavior of make doc

[Jean-Charles Malahieude]

Le 10/08/2011 05:40, Graham Percival disait :

This new proposal focuses on "make doc" specifically.

http://lilypond.org/~graham/gop/gop_9.html


** Proposal summary

If there are build problems, then it should be easier to find out
why it’s failing. This will be achieved with log files, as well as
possibly including scripts which automatically display portions of
those log files for a failing build.

We will also add targets for building a specific manual (for
quick+easy checking of doc work), as well as for building all
documentation in a specific language (either English or a
translated language).



As a translator, I need the original (English) as well, just as a matter 
of comparison, at least when working on texidocs title and headers.
In other words, I'll always build the English version along with the 
French one.


Cheers,
Jean-Charles


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

Re: Progress on loose columns. (issue4841052)

[mtsolo]

I think I've hit loose column nirvana with this most recent patch set.
The only thing that I know I need to work on is the magic left_padding
number of 0.15 in spacing-loose-columns.cc .  I know this should be made
a property but I don't know where (I can implement it like it was
implemented in previous incarnations of this patch and tack it onto the
SpacingSpanner if people think that's a good idea).  Also, the name is
crappy: it is not padding per se in that it is not always added.
Rather, it is a distance tacked onto the horizontal length between two
between-columns after which loose columns start relaxing from their
tight spacing to their ideal spacing.  Perhaps this is in fact the
definition of "padding," but I'm not sure.  Anyway, I'd appreciate
suggestions of (a) what to call this; and (b) what grob to stick it to
as a property.

Cheers,
MS

http://codereview.appspot.com/4841052/

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

Re: GOP-PROP 8: issue priorities (radical update)

[Trevor Daniels]

Graham Percival wrote Wednesday, August 10, 2011 9:09 AM



On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote:


Wouldn't work.  Few, if any, developers use lily-git.tcl so
are unlikely to be in a position to fix it.


Using lily-git.tcl and being able to fix it are completely
different things.  IIRC the only people who have worked on
lily-git.tcl are the original author of it, Carl, and me -- none
of these people actually use lily-git.tcl.


I don't believe either you or Carl needs any coercion to fix
lily-git.tc.


Besides, lily-git.tcl is only a small fraction of the things which
may stop a contributor from helping out.  If savannah is down,
then nobody can push (or pull) anything.


Neither can a release be made anyway.

So these "reasons" are no justification for this policy.  You
still haven't convinced me it will actually have any effect.

Don't get me wrong.  Whether we place these issues in a
critical category or not is hardly a vital decision, but here
we're talking about deciding Policy.  Policy decisions
must be based on sound and justifiable arguments, not
opinion or expediency.  So my concern is that we are not
following a sufficiently sound approach here.

Trevor




-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3824 - Release Date: 08/09/11


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

Re: custom engraver in scheme: accessing nested Music object

[Reinhold Kainhofer]

Am Wednesday, 10. August 2011, 09:44:00 schrieb Ricardo Wurmus:
> Hello,
> 
> I'm currently attempting to write a custom engraver in scheme.
> This is the shortened code:

It will increase the chances for a useful answer dramatically if you could 
attach a working example that one just has to run through lilypond, rather 
than trying to read your code, trying to image how to use it, constructing the 
example myself and then try to figure out how to solve it. 

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

On Aug 10, Reinhold Kainhofer wrote:
> Am Wednesday, 10. August 2011, 09:44:00 schrieb Ricardo Wurmus:
> > Hello,
> >
> > I'm currently attempting to write a custom engraver in scheme.
> > This is the shortened code:
>
> It will increase the chances for a useful answer dramatically if you could
> attach a working example that one just has to run through lilypond, rather
> than trying to read your code, trying to image how to use it, constructing the
> example myself and then try to figure out how to solve it.

I was trying to simplify it, because my scheme-foo is only a day old.
But I guess you are right. Here is a working example of my engraver:

  https://github.com/rekado/Lilystick

The engraver is in stick-tab-engraver.ly, a test file using the engraver
is test.ly. Running `lilypond test.ly` will generate roughly what I want.
This all fails, though, when more than one Voice is used.

The reason for that is that I'm using event listeners to collect note
properties and evaluate them in the acknowledger code. The listeners are
executed first for all notes at a moment, and then the achnowledger code
(stick-fingers grob) runs. Hence, the global variables (g_string-number,
g_finger ...) are overwritten.

To overcome this, I want to let the acknowledger grab note properties
for each individual grob, instead of having the listeners grab them.

Rekado

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

Re: custom engraver in scheme: accessing nested Music object

[Reinhold Kainhofer]

Am Wednesday, 10. August 2011, 13:55:49 schrieb Ricardo Wurmus:
> On Aug 10, Reinhold Kainhofer wrote:
> > > This is the shortened code:
> > It will increase the chances for a useful answer dramatically if you
> > could attach a working example that one just has to run through
> > lilypond,
> 
> I was trying to simplify it, because my scheme-foo is only a day old.
> But I guess you are right. Here is a working example of my engraver:
> 
>   https://github.com/rekado/Lilystick
> 
> The engraver is in stick-tab-engraver.ly, a test file using the engraver
> is test.ly. Running `lilypond test.ly` will generate roughly what I want.

Sorry, but where is the part about articulations? I wasn't asking for an early 
version of a larger project, which doesn't even include the code that you are 
asking about.

In particular, you say that the music-cause contains the articulations (and 
you even copied some output). 

I have now spent ~25 minutes trying to strip down the engraver and adding what 
you had in your first mail, but I can't reproduce anything. The music-cause 
simply does not have any articulations here. 
So, I now wasted almost half an hour for what? 

> In my code, the `mus' variable contains the music object, which has a
> property `articulations'. This is what the music object looks like when
> displaying it:

If you really want us to spend time helping you, please send us a file that is 
(1) simple (i.e. not all the fancy stuff in tab-stick-engraver.ly that does 
not have anything to do with your question) and
(2) that can be saved on disk and directly run through lilypond.

Your original example was simple, but it had things like (do-something..), 
which is not defined, it had no sample use, it lacked the \layout block etc. 

I'm attaching my version of your example in a form as we would expect it, if 
you want the slightest chance of some help. Note that you can simply save it 
on disk, run lilypond on it and you get the result. 
As I said above, I can't reproduce your claim that the music-cause has the 
articulations, so probably I did something different from what you had in mind 
(but didn't include it in your list). Please adjust the file to show your 
problem (and only your problem). In the future, this is the form that we would 
expect from you.

So, if you really want us to spend precious time helping you, please make our 
life easier by sending really small, relevant examples.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
\version "2.14.2"

#(define-public (music-cause grob)
  (let* ((event (event-cause grob)))
(if (ly:stream-event? event)
(ly:event-property event 'music-cause)
#f)))

   
#(define stick-tab-engraver
   (list
 (cons 'acknowledgers
   (list
 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
 (let* ((mus (music-cause grob))
;; TODO: how do I get into this articulations list?
(articulations (ly:music-property mus 'articulations)))
   (display "Music: ")(display mus)(newline)
   (display "Articulations: ")(display articulations)(newline)
)))

\layout {
  \context {
\Voice
\remove "Fingering_engraver"
\consists \stick-tab-engraver
  }
}

\relative c'' {
  c4-1\4 d-2\3 e-3 f-4
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Does better polynomial calculations for avoid objects. (issue4860042)

[mtsolo]

Reviewers: ,

Message:
Hey all,

My summer of Lily plugs along with a fix for Issue 1328.  It also
generally cleans up a lot of little collisions in the regtests between
slurs and articulations.

Passes regtests.

Cheers,
MS

Description:
Does better polynomial calculations for avoid objects.

Please review this at http://codereview.appspot.com/4860042/

Affected files:
  M flower/include/polynomial.hh
  M flower/polynomial.cc
  A input/regression/slur-avoid.ly
  M lily/bezier.cc
  M lily/include/bezier.hh
  M lily/slur.cc
  M scm/define-grobs.scm
  M scm/script.scm



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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

> I have now spent ~25 minutes trying to strip down the engraver and adding what
> you had in your first mail, but I can't reproduce anything. The music-cause
> simply does not have any articulations here.
> So, I now wasted almost half an hour for what?

Oh shoot, I confused my example scores. I just noticed that the
articulations key (and the music-cause) only appears in the event list
when there are simultaneous notes.

This invalidates the approach (or rather "workaround"); anyway, I have
attached a simple working example (articulations.ly) that generates the
output I presented in my first email. I'm afraid it is not worth
spending time on this anymore, now that the inadequacy of this procedure
is established.

I'm very sorry to have wasted your time. Your comments actually helped
me to see how flawed my approach really is. Thank you for that.

> As I said above, I can't reproduce your claim that the music-cause has the
> articulations, so probably I did something different from what you had in mind
> (but didn't include it in your list). Please adjust the file to show your
> problem (and only your problem). In the future, this is the form that we would
> expect from you.
> So, if you really want us to spend precious time helping you, please make our
> life easier by sending really small, relevant examples.

Noted and understood. Thanks for your patience.

I think I will have to start from scratch (again).
This is what I'm trying to do for each note in the score:

   1. get the string number
  (string-number-interface)
   2. get the finger info
  (finger-interface)
   3. get the stem direction
  (stem-interface)
   4. replace the note head dependent on 1-3
  (note-head-interface)

I tried to add acknowledgers for all these interfaces, but the function
for the note-head-interface was always called *before* the others (see
attached example ack-order.ly).
Is there a way to change that order, or call the note-head-interface
function again at the very end for processing a grob?

I'm sure I'm missing something obvious here. (My ignorance even after
reading the documentation for multiple times annoys me so much.)
#(define-public (music-cause grob)
  (let*
  ((event (event-cause grob)))
(if (ly:stream-event? event)
(ly:event-property event 'music-cause)
#f)))

#(define stick-tab-engraver
   (list
 (cons 'acknowledgers
   (list
 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
 (let* ((context (ly:translator-context engraver))
(event (event-cause grob))
(mus (music-cause grob))

;; get music object inside articulations
;; TODO: how do I get to the music-cause property in 
the Stream_event?
(articulations (ly:music-property mus 'articulations)))

   ;; output articulations, so I can see how to
   ;; get to the music object inside.
   (display articulations)(newline)

   ;; replace the note head
   (do-something grob


#(define (do-something grob)
   (display "Not important\n"))


% --


\version "2.14.2"

\score {
  <<
\time 2/4
\new Staff {
  \clef "treble"
  \key g \minor
  \new Voice {
\relative c'' {
  d4-1\4
}
  }
}
\new Staff {
  \clef "bass"
  \key g \minor
  \new Voice {
\relative g {
  % ugh, articulations only exist when
  % there are simultaneous notes
  
}
  }
}
  >>

  \layout {
\context {
  \Staff
  \remove "Fingering_engraver"
  \consists \stick-tab-engraver
}
  }
}
#(define stick-tab-engraver
   (list
 (cons 'acknowledgers
   (list
 (cons 'string-number-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get string-number info and store in var
   (display "getting STRING info\n")
   ))

 (cons 'finger-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get fingering info and store in var
   (display "getting FINGER info\n")
   ))

 (cons 'stem-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get stem direction info and store in var
   (display "getting STEM info\n")
   ))

 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: replace the note head
   (do-something grob)))

#(define (do-something grob)
   (display "Replacing note head\n"))


% --


\version "2.14.2"

\score {
  <<
\time 2/4
\new Staff {
  \clef "treble

Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)

[reinhold . kainhofer]

On 2011/07/29 04:39:27, Keith wrote:

On Thu, 28 Jul 2011 05:46:29 -0700,

 wrote:


> Message:
> On 2011/07/26 02:17:28, Keith wrote:
>> I like it, although I can still get the error if I put a new voice

in

> the quoted
>> expression like this:
>>quoteMe = \relative c' \new Voice {
>
> Yeah, but then we have a general problem: Which voice do we want to
> quote?
>
I would not expect LilyPond to divine the answer to that question,
but it would be nice to avoid exiting the program with
   ERROR: Value out of range: 0


I have now fixed this by (1) always using the first subexpression that
really has some contents (in your example, the contents of the \new
Voice) and (2) printing a warning in the output (with the exact location
of the addQuote call).


http://codereview.appspot.com/4816044/

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

Re: custom engraver in scheme: accessing nested Music object

[Neil Puttock]

On 10 August 2011 15:00, Ricardo Wurmus  wrote:

> Is there a way to change that order, or call the note-head-interface
> function again at the very end for processing a grob?

Acknowledger order depends on the order engravers are \consist-ed (the
only exception is if you set must-be-last to #t)

If you want to do useful things to the NoteHead, you should wait until
all the acknowledging has finished, i.e., store the NoteHead grob and
process the information in a process-acknowledged or
stop-translation-timestep function.

BTW, if you're prepared to wrap the notes in a chord (so you have
access to 'articulations), you won't even need a scheme engraver (all
the processing can take place in the NoteHead's stencil callback).

Cheers,
Neil

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

Re: GOP-PROP 9: behavior of make doc

[Phil Holmes]

- Original Message - 
From: "Keith OHara" 


Have I said recently how much I really really like `make bin` ? 



Have you tried make -s website?

--
Phil Holmes


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

Re: GOP-PROP 9: behavior of make doc

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

There's a lot of awesome stuff there.  "make bin" only needed two
lines of "syntactic sugar".  Compiling an individual manual is
something that doc people have been requesting for *years*.  I've
known that it was possible for years, and always gave a vague
guideline on how to do it.  Phil recently tried it and said that
it didn't work, and I was sufficiently annoyed that I went and
figured it out.
(but the instructions aren't in the CG, so we'll probably go
through the same thing in another 6 months)



I was looking at this yesterday, but it seemed to be doing a complete make 
doc.  So I nuked build, started again, and make doc failed.  I've just nuked 
build, pulled and am running make.  I'll let you know...


--
Phil Holmes



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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

On Aug 10, Neil Puttock wrote:
> On 10 August 2011 15:00, Ricardo Wurmus  wrote:
>
> > Is there a way to change that order, or call the note-head-interface
> > function again at the very end for processing a grob?
>
> Acknowledger order depends on the order engravers are \consist-ed (the
> only exception is if you set must-be-last to #t)
>
> If you want to do useful things to the NoteHead, you should wait until
> all the acknowledging has finished, i.e., store the NoteHead grob and
> process the information in a process-acknowledged or
> stop-translation-timestep function.

Thank you very much for the information. This is the bit I must have
overlooked.

> BTW, if you're prepared to wrap the notes in a chord (so you have
> access to 'articulations), you won't even need a scheme engraver (all
> the processing can take place in the NoteHead's stencil callback).

It should be a generic engraver, so I cannot assume that notes will
always be wrapped in a chord. I'll play around with defining a function
for process-acknowledged and see where it leads me.

> Cheers,
> Neil

Best,
Rekado

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

Re: GOP-PROP 9: behavior of make doc

[Graham Percival]

On Wed, Aug 10, 2011 at 03:51:15PM +0100, Phil Holmes wrote:
> So I nuked build, started again, and make doc
> failed.  I've just nuked build, pulled and am running make.  I'll
> let you know...

If that happens again, please keep it and report any error
messages you can find -- although we're still discussing the
"issues priorities" GOP question, there doesn't seem to be any
disagreement that failing to build from a clean build tree should
be a Critical issue.

Cheers,
- Graham

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Francisco Vila]

2011/8/9  :
> I'd make the tie slightly shorter.  I find it awkward that two adjacent
> ties collide so easily, for example here
> {
>  \time 3/4
>  \relative c' { c2 e4 g2 e4 }
>  \addlyrics { gran- de_a- mi- go }
>  \addlyrics { pu- "ro y ho-" nes- to }
>  \addlyrics { pu- ro~y~ho- nes- to }
> }
> (example from documentation), or in the example you attached on the
> tracker issue page.

I have never liked this example in the documentation.

Firstly, it seems to mix Portuguese and Spanish.

Secondly, it does not follow the policy for syllable separator, which
is '[space]--[space]', not '-[space]'.

Finally, 2nd and 3rd stanzas look _very_ improbable to me in that it
has three syllables on a single note, which requires two lyric ties.
o~y is a synalepha and it could be a in-word diphthong, y~ho is
another synalepha, but o~y~ho is not a triphthong and can not be a
three-vowel synalepha.

If nobody finds a real example in literature, I suggest to remove the
problematic case, it is too artificial.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: custom engraver in scheme: accessing nested Music object

[Reinhold Kainhofer]

Am Mittwoch, 10. August 2011, 17:11:44 schrieb Ricardo Wurmus:
> On Aug 10, Neil Puttock wrote:
> > BTW, if you're prepared to wrap the notes in a chord (so you have
> > access to 'articulations), you won't even need a scheme engraver (all
> > the processing can take place in the NoteHead's stencil callback).
> 
> It should be a generic engraver, so I cannot assume that notes will
> always be wrapped in a chord. I'll play around with defining a function
> for process-acknowledged and see where it leads me.

One detail that might be interesting for you is that you can define engraver-
wide variables by wrapping the whole engraver in a (let (..) ...) block.
See e.g. the scheme engraver instance regtest (input/regression/scheme-
engraver-instance.ly in the source code tree):

\header {

  texidoc = "Scheme engravers may be instantiated, with
  instance-scoped slots, by defining a 1 argument procedure which
  shall return the engraver definition as an alist, with the private
  slots defined in a closure.  The argument procedure argument is the
  context where the engraver is instantiated."

}

\version "2.14.0"

\layout {
  \context {
\Voice
\consists
#(let ((instance-counter 0))
   (lambda (context)
 (set! instance-counter (1+ instance-counter))
 (let ((instance-id instance-counter)
   (private-note-counter 0))
   `((listeners
  (note-event
   . ,(lambda (engraver event)
(set! private-note-counter (1+ private-note-counter))
(let ((text (ly:engraver-make-grob engraver 'TextScript 
event)))
  (ly:grob-set-property! text 'text
 (format #f "~a.~a" instance-id
 private-note-
counter))
  }
}

<<
  \relative c'' { c4 d e f }
  \\ \relative c' { c4 d e f }
>>


In this example, instance-counter is a global variable, which is reused by 
every voice, while instance-id and private-note-counter are variables that are 
separate for each voice. In this example, instance-id stores the number of the 
voice, while private-note-counter counts the number of notes in each voice 
separately. 
In particular, the engravers used in the first and in the second voice will 
have different private-note-counter variables.

You can use this to collect information from all encountered objects and thin 
in 'process-acknowledged or 'stop-translation-timestep procell all of them at 
once. For a list of all possible "functions" inside the engraver, see 
input/regression/scheme-engraver.ly


Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: Treats multi measure rest staff position like rest staff position. (issue4822046)

[n . puttock]

LGTM.


http://codereview.appspot.com/4822046/diff/4001/input/regression/multi-measure-rest-staff-position.ly
File input/regression/multi-measure-rest-staff-position.ly (right):

http://codereview.appspot.com/4822046/diff/4001/input/regression/multi-measure-rest-staff-position.ly#newcode1
input/regression/multi-measure-rest-staff-position.ly:1: \version
"2.15.7"
2.15.9

http://codereview.appspot.com/4822046/diff/4001/input/regression/multi-measure-rest-staff-position.ly#newcode9
input/regression/multi-measure-rest-staff-position.ly:9: \relative c'{
c' {

http://codereview.appspot.com/4822046/diff/4001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):

http://codereview.appspot.com/4822046/diff/4001/lily/multi-measure-rest.cc#newcode177
lily/multi-measure-rest.cc:177: if ((mdl == 0) && (me->get_property
("staff-position") == SCM_EOL))
remove extra parentheses

http://codereview.appspot.com/4822046/

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

Better pure height approximations for beamed rests. (issue4860043)

[mtsolo]

Reviewers: ,

Description:
Better pure height approximations for beamed rests.

Please review this at http://codereview.appspot.com/4860043/

Affected files:
  A input/regression/beam-rest-extreme.ly
  M lily/rest.cc


Index: input/regression/beam-rest-extreme.ly
diff --git a/input/regression/beam-rest-extreme.ly  
b/input/regression/beam-rest-extreme.ly

new file mode 100644
index  
..770bd78939efbfa3ff6fc6428addb46bf0e75254

--- /dev/null
+++ b/input/regression/beam-rest-extreme.ly
@@ -0,0 +1,14 @@
+\version "2.15.9"
+
+\header {
+  texidoc = "Beamed rests are given a pure height approximation
+that gets their spacing correct in the majority of circumstances.
+"
+}
+
+\relative c'' {
+  16[ r  ]
+  16[ r  ]
+  16[ r  ]
+  16[ r  ]
+}
Index: lily/rest.cc
diff --git a/lily/rest.cc b/lily/rest.cc
index  
97deba3f8fc93b41cce9767f0a17b851bcafe301..ea0fdda77ace62736b95b799d43e4a3af2c126f7  
100644

--- a/lily/rest.cc
+++ b/lily/rest.cc
@@ -19,13 +19,16 @@

 #include "rest.hh"

+#include "beam.hh"
 #include "directional-element-interface.hh"
 #include "dots.hh"
 #include "font-interface.hh"
 #include "international.hh"
 #include "output-def.hh"
 #include "paper-score.hh"
+#include "pointer-group-interface.hh"
 #include "staff-symbol-referencer.hh"
+#include "stem.hh"
 #include "stencil.hh"
 #include "grob.hh"

@@ -54,6 +57,7 @@ Rest::y_offset_callback (SCM smob)
   if (!position_override)
 amount += 2 * ss * get_grob_direction (me);;

+
   return scm_from_double (amount);
 }

@@ -226,7 +230,59 @@ Rest::pure_height (SCM smob,
 {
   Grob *me = unsmob_grob (smob);
   SCM m = brew_internal_stencil (me, false);
-  return ly_interval2scm (unsmob_stencil (m)->extent (Y_AXIS));
+  Interval ext = unsmob_stencil (m)->extent (Y_AXIS);
+
+  int line_count = Staff_symbol_referencer::line_count (me);
+  Real ss = Staff_symbol_referencer::staff_space (me);
+
+  // Wont play nicely with weird staves where individual line positions  
are set...

+  Interval y_ext (-line_count * ss / 2.0, line_count * ss / 2.0);
+
+  Real amount = 0.0;
+
+  Grob *st = unsmob_grob (me->get_object ("stem"));
+  Grob *stem = st;
+  if (!stem)
+return ly_interval2scm (ext);
+  Grob *beam = unsmob_grob (stem->get_object ("beam"));
+  if (!beam
+  || !Beam::has_interface (beam)
+  || !Beam::normal_stem_count (beam))
+return ly_interval2scm (ext);
+
+  extract_grob_set (beam, "stems", stems);
+  vector my_stems;
+
+  for (vsize i = 0; i < stems.size (); i++)
+if (Stem::head_count (stems[i]) || stems[i] == stem)
+  my_stems.push_back (stems[i]);
+
+  vsize idx = -1;
+
+  for (vsize i = 0; i < my_stems.size (); i++)
+if (my_stems[i] == stem)
+  {
+idx = i;
+break;
+  }
+  Grob *left;
+  Grob *right;
+
+  if (idx == -1 || my_stems.size () == 1)
+return ly_interval2scm (ext);
+  else if (idx == 0)
+left = right = my_stems[1];
+  else if (idx == my_stems.size () - 1)
+left = right = my_stems[idx - 1];
+  else
+{
+  left = my_stems[idx - 1];
+  right = my_stems[idx + 1];
+}
+  Direction beamdir = get_grob_direction (beam);
+  amount = min (max (minmax (beamdir, Stem::head_positions  
(left)[beamdir], Stem::head_positions (right)[beamdir]) / 2.0,  
y_ext[DOWN]), y_ext[UP]);

+
+  return ly_interval2scm (ext + amount);
 }

 ADD_INTERFACE (Rest,



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

Re: Treats multi measure rest staff position like rest staff position. (issue4822046)

[reinhold . kainhofer]

LGTM. I wonder why we use get_positino in the first place, which uses
the "staff-position" property only as a fall-back...

http://codereview.appspot.com/4822046/

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

Re: Creates a glissando stem grob that uses stems' functionality. (issue4777044)

[mtsolo]

New patch set up that gets Y-offset right for glissando stem scripts.

Cheers,
MS

http://codereview.appspot.com/4777044/

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

Re: GOP-PROP 5: build system output (final)

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: 
Sent: Friday, August 05, 2011 4:32 AM
Subject: GOP-PROP 5: build system output (final)



Well, we can't pretend that there's unanimous support for this,
and of course there will always be concerns about specific
technical details... but I think we've got an ok set of guidelines
for future build system work, and it's time to start producing
patches.


[snip]

Well - on the upside of all this discussion, at least we've got rid of some 
compiler warnings :-)


--
Phil Holmes



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

Re: Better pure height approximations for beamed rests. (issue4860043)

[reinhold . kainhofer]

I haven't actually tested it, but from reading the code it LGTM in
general. Please observe the comments, though.


http://codereview.appspot.com/4860043/diff/1/lily/rest.cc
File lily/rest.cc (right):

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode239
lily/rest.cc:239: Interval y_ext (-line_count * ss / 2.0, line_count *
ss / 2.0);
Do you want to calculate the y-extents of the staff? Shouldn'tyou then
use (line_count-1)*ss, i.e. a staff with n lines only has n-1 staff
spaces...

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode244
lily/rest.cc:244: Grob *stem = st;
Why do you need that second line at all? Shouldn't
  Grob *stem = unsmob_grob (..);
work?

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode246
lily/rest.cc:246: return ly_interval2scm (ext);
Why don't you move that to the very top, before the variable definitions
of line_count, ss, y_ext and amount?

Then, everything needed for stemmed rests comes later and is placed
together in the source code.

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode283
lily/rest.cc:283: amount = min (max (minmax (beamdir,
Stem::head_positions (left)[beamdir], Stem::head_positions
(right)[beamdir]) / 2.0, y_ext[DOWN]), y_ext[UP]);
Can you add some comments how you calculate this?
And this min(max(minmax(...))) is extremely hard to read.

http://codereview.appspot.com/4860043/

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

Re: Better pure height approximations for beamed rests. (issue4860043)

[n . puttock]

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc
File lily/rest.cc (right):

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode238
lily/rest.cc:238: // Wont play nicely with weird staves where individual
line positions are set...
Don't use line_count then :)

(see Breathing_sign::offset_callback ())

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode239
lily/rest.cc:239: Interval y_ext (-line_count * ss / 2.0, line_count *
ss / 2.0);
this exaggerates the extent; is that deliberate?

Edit: Reinhold beat me to it :)

rename so it's clear this is the extent of the StaffSymbol

http://codereview.appspot.com/4860043/diff/1/lily/rest.cc#newcode249
lily/rest.cc:249: || !Beam::has_interface (beam)
is this possible?

http://codereview.appspot.com/4860043/

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

GOP-PROP 8: issue priorities (probable decision)

[Graham Percival]

I'm feeling pretty good about this one, with the exception of
whether we should have a Type-ignorance or not.

In case you're wondering: yes, I am serious proposing that we
elminiate priorities completely, and this is not a joke.  Nobody
has objected yet, but if you don't think this is a good idea,
please speak up.


http://lilypond.org/~graham/gop/gop_8.html

** Proposal summary

Let’s get rid of priorities. We will simply describe bugs in
neutral terms; each contributor can search and interpret the
results as he or she sees fit.

We will make a “Type-Critical”; a new stable release will only
occur if there are 0 type-Critical issues.


** Rationale

There is wide disagreement on what “priorities” should mean, or
how they should be interpreted. Do they represent which
“milestone” we want a fix by? How bad are crashes? How important
are matters which hinder future development?

Assuming that “GOP-PROP 7: developers as resources” is resolved in
favor of “treat developers as independent volunteers” (which seems
extremely likely), the notion of an externally-imposed “priority”
seems a stretch.

The remaining question concerns Critical issues, and more
generally, “what does a release mean?”. Our source tree is open;
anybody can download and try any version. Our unstable development
releases are freely available. The only distinction between git
master and a “stable release” is our mark of approval. A new
stable release indicates that we think the software is usable, and
attracts more attention than an unstable release. In addition to
user attention, it also attracts the attention of potential
contributors, so we should avoid having any glaring problems which
would stop somebody from contributing and turn them away – we do
not want to put our “stamp of approval” on something which might
cost us potential contributors.


** Proposal details

We will delete “priority” altogether. The “type” system will be
tweaked.

Type-critical:

* a reproducible failure to build either make or make doc,
  from an empty build tree, in a first run, if configure does
  not report any errors.
* any program behaviour which is unintentionally worse than
  the previous stable version or the current development
  version. Developers may always use the “this is
  intentional”, or even the “this is an unavoidable effect of
  an improvement in another area”, reason to move this to a
  different type.
* anything which stops contributors from helping out (e.g.
  lily-git.tcl not working, source tree(s) not being
  available, lilydev being unable to compile git master,
  inaccurate instructions in the Contributor’s Guide 2 Quick
  start).

  To limit this scope of this point, we will assume that the
contributor is using the latest lilydev and has read the relevant
part(s) of the Contributor’s Guide. Problems in other chapters of
the CG are not sufficient to qualify as Type-Critical.


** More new/changed types

* Type-crash: any segfault, regardless of what the input file
  looks like or which options are given. Disclaimer: this
  might not be possible in some cases, for example certain
  guile programs (we certainly can’t predict if a piece of
  scheme will ever stop running, i.e. the halting problem), or
  if we rely on other programs (i.e. ghostscript). If there
  are any such cases that make segfault-prevention impossible,
  we will document those exceptions (and the issue will remain
  as a "crash" instead of "documentation" until the warning
  has been pushed).
* Type-maintainability: anything which makes it difficult for
  serious contributors to help out (e.g. difficult to find the
  relevant source tree(s), confusing policies, problems with
  automatic indentation tools, etc).
* Type-ugly: replaces Type-collision, and it will include
  things like bad slurs in addition to actual collision.
* Type-ignorance: (fixme name?) it is not clear what the
  correct output should look like. We need scans, references,
  examples, etc. 


** Shutting up users

We can remind users that they can “star” an issue to indicate that
they care about it. I could not possibly care less about what
users think, but if any contributors want to look at that info and
organize their work schedule according to that, they’re welcome to
do so. Also, the stars might serve as a placebo for users.


** Implementation notes

Yes, revising the current issue tracker will take a fair amount of
effort, but I have a plan for this. Don’t waste time pointing this
out. 


Cheers,
- Graham

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

Re: GOP-PROP 8: issue priorities (radical update)

[Graham Percival]

On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Wednesday, August 10, 2011 9:09 AM
> 
> >Using lily-git.tcl and being able to fix it are completely
> >different things.  IIRC the only people who have worked on
> >lily-git.tcl are the original author of it, Carl, and me -- none
> >of these people actually use lily-git.tcl.
> 
> I don't believe either you or Carl needs any coercion to fix
> lily-git.tc.

Think of a release as more of a "stamp of approval" and less of
"coercion".

> >Besides, lily-git.tcl is only a small fraction of the things which
> >may stop a contributor from helping out.  If savannah is down,
> >then nobody can push (or pull) anything.
> 
> Neither can a release be made anyway.

Technically I could still make a release using a local git repo.

> Don't get me wrong.  Whether we place these issues in a
> critical category or not is hardly a vital decision, but here
> we're talking about deciding Policy.  Policy decisions
> must be based on sound and justifiable arguments, not
> opinion or expediency.  So my concern is that we are not
> following a sufficiently sound approach here.

Completely agreed!  I've taken a stab at this with the "stamp of
approval" concept of a release -- please take a look at the
updated GOP-PROP 8...(probable decision) and let me know what you
think.

Cheers,
- Graham

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

Re: Lilypond-book: Implement musicxml support in lilypond-book (issue1659041)

[reinhold . kainhofer]

On 2011/07/26 21:38:00, J_lowe wrote:

A few minor syntax and doc policy issues


I have now also changed the documentation and uploaded a new patch.

http://codereview.appspot.com/1659041/

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

Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)

[n . puttock]

LGTM.


http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly
File input/regression/quote-during-subvoice.ly (right):

http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly#newcode1
input/regression/quote-during-subvoice.ly:1: \version "2.15.6"
2.15.9

http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly#newcode18
input/regression/quote-during-subvoice.ly:18: \addQuote quoteMe \quoteMe
"quoteMe"

http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly#newcode26
input/regression/quote-during-subvoice.ly:26: \addQuote quoteMeI
\quoteMeI
"quoteMeI"

http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly#newcode34
input/regression/quote-during-subvoice.ly:34: \addQuote quoteMeII
\quoteMeII
"quoteMeII"

http://codereview.appspot.com/4816044/diff/15001/input/regression/quote-during-subvoice.ly#newcode42
input/regression/quote-during-subvoice.ly:42: \addQuote quoteMeIII
\quoteMeIII
"quoteMeIII"

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm
File scm/part-combiner.scm (right):

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode574
scm/part-combiner.scm:574: (voicename (get-next-unique-voice-name))
indent

(most of the following lines are also out by at least a space)

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode578
scm/part-combiner.scm:578: (ly:parser-lookup parser
'partCombineListener
indent

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode582
scm/part-combiner.scm:582: ;; If the context-specced quoted music does
not contain anything, try to
indent

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode586
scm/part-combiner.scm:586: (let find-non-empty ((current-tail (member
raw-voice context-list)))
indent

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode589
scm/part-combiner.scm:589: ((null? current-tail) #f)
indent

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode592
scm/part-combiner.scm:592: (set! quote-contents (cdar current-tail)))
indent

http://codereview.appspot.com/4816044/diff/15001/scm/part-combiner.scm#newcode597
scm/part-combiner.scm:597: (ly:music-message mus (ly:format (_ "quoted
music `~a' is empty") name) 
name)

http://codereview.appspot.com/4816044/

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

Re: GOP-PROP 9: behavior of make doc

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Keith OHara" ; 
Sent: Wednesday, August 10, 2011 4:25 PM
Subject: Re: GOP-PROP 9: behavior of make doc



On Wed, Aug 10, 2011 at 03:51:15PM +0100, Phil Holmes wrote:

So I nuked build, started again, and make doc
failed.  I've just nuked build, pulled and am running make.  I'll
let you know...


If that happens again, please keep it and report any error
messages you can find -- although we're still discussing the
"issues priorities" GOP question, there doesn't seem to be any
disagreement that failing to build from a clean build tree should
be a Critical issue.

Cheers,
- Graham



It happened again ... BUT ...

I think it was my fault for having a file named learning.texi in my 
git/Documentation directory - I think it was one of my experiments.  Just 
deleted it and continuing make doc.


This does raise 2 issues: 1) nuking build and abort changes and pull isn't 
guaranteed to get a clean system.  To be properly clean, you'd have to nuke 
git as well.  2) The error message isn't too helpful:


cd ./out-www; texi2pdf -I ./out-www -I 
/home/phil/lilypond-git/build/Documentation/out -I 
/home/phil/lilypond-git/Documentation -I 
/home/phil/lilypond-git/Documentation --quiet  learning.texi

/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make[2]: *** [out-www/learning.pdf] Error 1
rm out-www/weblinks.itexi
make[2]: Leaving directory `/home/phil/lilypond-git/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/phil/lilypond-git/build'
make: *** [doc-stage-1] Error 2

This is because of the --quiet option in texi2pdf (not my doing, I think). 
My tip from this.  texi2pdf also produces a logfile, so to find what it's 
complained about, open learning.log and see what it says.


--
Phil Holmes



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

Re: GOP-PROP 8: issue priorities (radical update)

[Trevor Daniels]

Graham, you wrote Wednesday, August 10, 2011 5:48 PM



On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote:


Don't get me wrong.  Whether we place these issues in a
critical category or not is hardly a vital decision, but here
we're talking about deciding Policy.  Policy decisions
must be based on sound and justifiable arguments, not
opinion or expediency.  So my concern is that we are not
following a sufficiently sound approach here.


Completely agreed!  I've taken a stab at this with the "stamp of
approval" concept of a release -- please take a look at the
updated GOP-PROP 8...(probable decision) and let me know what you
think.


Well, OK, it's a better point, if a little 
contrived :)  I can live with it, though.

Let's move on.  The key point is dropping
the priority field and replacing it with
the stars, and I like that.

Trevor
 



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11


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

Re: Adds a glyph for tied lyrics. (issue4808074)

[bordage . bertrand]

Secondly, it does not follow the policy for syllable separator, which
is '[space]--[space]', not '-[space]'.


I already fixed it in this patch (for every language).


Finally, 2nd and 3rd stanzas look _very_ improbable to me in that it
has three syllables on a single note, which requires two lyric ties.
o~y is a synalepha and it could be a in-word diphthong, y~ho is
another synalepha, but o~y~ho is not a triphthong and can not be a
three-vowel synalepha.



If nobody finds a real example in literature, I suggest to remove the
problematic case, it is too artificial.


I agree, I never saw such a case.


http://codereview.appspot.com/4808074/

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

Re: GOP-PROP 8: issue priorities (radical update)

[Graham Percival]

On Wed, Aug 10, 2011 at 06:44:51PM +0100, Trevor Daniels wrote:
> 
> Graham, you wrote Wednesday, August 10, 2011 5:48 PM
> 
> >Completely agreed!  I've taken a stab at this with the "stamp of
> >approval" concept of a release -- please take a look at the
> >updated GOP-PROP 8...(probable decision) and let me know what you
> >think.
> 
> Well, OK, it's a better point, if a little contrived :)  I can live
> with it, though.
> Let's move on.

Well, it's not /entirely/ contrived.  I mean, Janek wants us to
use fontforge 20110222 or higher; I want to say "no way until
lilydev has that version of fontforged installed".  And if we ever
did push such a change without lilydev being updated, I certainly
wouldn't want to make a new stable release before fixing that!

We haven't had many build-dependency updates in the past few
years, but before that we used to require really cutting-edge
libraries.  I'm not opposed to requiring new libraries, and I
don't care if it's something that no linux distro includes -- as
long as we have a customized, downloadable, lilydev iso image
available.
(I could argue that anything less would be a "regression", i.e. "I
used to be able to contribute to development, but because of
changes to git master I can no longer do so".  However, I'd rather
make this particular case of "regression" explicit.)

Cheers,
- Graham

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

New German PO file for 'lilypond' (version 2.15.9)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'lilypond' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/lilypond/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/lilypond/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/lilypond.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.



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

Re: Better pure height approximations for beamed rests. (issue4860043)

[mtsolo]

All comments have been addressed and a new patchset's uploaded.

Cheers,
MS

http://codereview.appspot.com/4860043/

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

Re: GOP-PROP 8: issue priorities (probable decision)

[Carl Sorensen]

On 8/10/11 10:46 AM, "Graham Percival"  wrote:

> I'm feeling pretty good about this one, with the exception of
> whether we should have a Type-ignorance or not.
> 
> In case you're wondering: yes, I am serious proposing that we
> elminiate priorities completely, and this is not a joke.  Nobody
> has objected yet, but if you don't think this is a good idea,
> please speak up.
> 
> 
> http://lilypond.org/~graham/gop/gop_8.html
> 
> ** Proposal summary
> 
> Let¹s get rid of priorities. We will simply describe bugs in
> neutral terms; each contributor can search and interpret the
> results as he or she sees fit.
> 
> We will make a ³Type-Critical²; a new stable release will only
> occur if there are 0 type-Critical issues.

It might be less work to only have 2 priorities:

Critical
Ordinary

Then we could continue to use the system as it exists now.

But I don't feel strongly enough about it to prevent prop 8 from passing.

Thanks,

Carl


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

Re: Better pure height approximations for beamed rests. (issue4860043)

[n . puttock]

http://codereview.appspot.com/4860043/diff/4002/lily/rest.cc
File lily/rest.cc (right):

http://codereview.appspot.com/4860043/diff/4002/lily/rest.cc#newcode251
lily/rest.cc:251: Interval rest_max_pos = Staff_symbol::line_span
(Staff_symbol_referencer::get_staff_symbol (me));
unsafe with \stopStaff or no Staff_symbol_engraver

http://codereview.appspot.com/4860043/

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Reinhold Kainhofer]

Am Mittwoch, 10. August 2011, 19:54:52 schrieb bordage.bertr...@gmail.com:
> > Finally, 2nd and 3rd stanzas look _very_ improbable to me in that it
> > has three syllables on a single note, which requires two lyric ties.
> > o~y is a synalepha and it could be a in-word diphthong, y~ho is
> > another synalepha, but o~y~ho is not a triphthong and can not be a
> > three-vowel synalepha.
> > 
> > If nobody finds a real example in literature, I suggest to remove the
> > problematic case, it is too artificial.
> 
> I agree, I never saw such a case.

I can't find it now, but I definitely remember having seen three syllables in 
a soprano aria (I think it was Italian). It was something like "-- to e in".

Unfortunately, I really can't find it any more. I thought it was in Rossini's 
Stabat Mater, but that was wrong.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: Does better polynomial calculations for avoid objects. (issue4860042)

[pkx166h]

Passes Make and there are some reg test differences - see

http://code.google.com/p/lilypond/issues/detail?id=1328#c2

http://codereview.appspot.com/4860042/

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

Re: Better pure height approximations for beamed rests. (issue4860043)

[pkx166h]

Passes make and reg tests

http://codereview.appspot.com/4860043/

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

Re: Get rid of some compiler warnings (issue4854049)

[pkx166h]

Passes make but there are some reg test differences

see

http://code.google.com/p/lilypond/issues/detail?id=804#c6

http://codereview.appspot.com/4854049/

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Werner LEMBERG]

> I can't find it now, but I definitely remember having seen three
> syllables in a soprano aria (I think it was Italian). It was
> something like "-- to e in".

An example is the second aria of Susanna in Mozart's `Le Nozze di
Figaro', bar 16:

   f2 f8  e8   g8c8

  fin -- chè l'a -- "ria è an" -- cor

Almost all singers I've met during my work as a coach have problems if
they sing it the first time :-)

However, I've *never* seen lyric ties in any edition of Mozart, be it
Urtext or something else.


Werner

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Werner LEMBERG]

> An example is the second aria of Susanna in Mozart's `Le Nozze di
> Figaro', bar 16:
> 
>f2 f8  e8   g8c8
> 
>   fin -- chè l'a -- "ria è an" -- cor

BTW, the next bar is

  a8[ d8] f8 g,8[ b8] d8

  bru --  "na, e il" mon --   do

:-)


 Werner

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

Re: Lets auto numbering of footnotes kick in from commands alone. (issue4837047)

[reinhold . kainhofer]

That's exactly as I envisioned it. Numbering works fine, except in staff
systems. the example that I sent a while ago still has some apparently
random order of the numbering.


http://codereview.appspot.com/4837047/diff/1017/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):

http://codereview.appspot.com/4837047/diff/1017/lily/page-layout-problem.cc#newcode127
lily/page-layout-problem.cc:127: programming_error ("Your numbering
function needs to return a stencil.");
Is there any chance to use the functions of the Input class? They would
provide some code location and tell the user which footnote this message
is about

http://codereview.appspot.com/4837047/diff/1017/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/4837047/diff/1017/scm/define-grob-properties.scm#newcode62
scm/define-grob-properties.scm:62: numbered?")
Should this really be a public property? I would move it down to the
internal properties.

http://codereview.appspot.com/4837047/

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

Re: Lilypond-book: Implement musicxml support in lilypond-book (issue1659041)

[pkx166h]

minor stuff.


http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):

http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely#newcode225
Documentation/usage/lilypond-book.itely:225: In the input file, music is
specified with any of the following commands
Minor nitpick, I just noticed this needs a comma after the word
'command'. We don't 'run into' the example any more. CG 5.3.7.

http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely#newcode439
Documentation/usage/lilypond-book.itely:439: In the input file, music is
specified with any of the following commands
again a comma needed at the end of this phrase.

http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely#newcode516
Documentation/usage/lilypond-book.itely:516: In the input file, music is
specified with any of the following commands
One more comma here too.

http://codereview.appspot.com/1659041/

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

Re: Doc: NR Warning added to para for cueduring (issue4850051)

[pkx166h]

Reviewers: Trevor Daniels,

Message:
Second draft,

James


http://codereview.appspot.com/4850051/diff/1/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):

http://codereview.appspot.com/4850051/diff/1/Documentation/notation/staff.itely#newcode1304
Documentation/notation/staff.itely:1304: @warning{In this example, the
@code{Voice} context must be explicitly
On 2011/08/09 23:08:15, Trevor Daniels wrote:

@warning{When a @code{Voice} starts with @code{\cueDuring}, as in the

following

example, ... }


Done.

Description:
Doc: NR Warning added to para for cueduring

As per Tracker 1811.

Added @warning{ } around pararaph in cueDuring to alert users to
create explicit contexts in certain cases.

Please review this at http://codereview.appspot.com/4850051/

Affected files:
  M Documentation/notation/staff.itely


Index: Documentation/notation/staff.itely
diff --git a/Documentation/notation/staff.itely  
b/Documentation/notation/staff.itely
index  
b4e471f7b09233c22d62a24c6ffe5cfc72346e7f..06f6089d19cdfeeb2654d47e4a849d21a04c9e9f  
100644

--- a/Documentation/notation/staff.itely
+++ b/Documentation/notation/staff.itely
@@ -1301,9 +1301,10 @@ tie-event beam-event tuplet-span-event)}, which  
means that only

 notes, rests, ties, beams and tuplets are quoted, but not
 articulations, dynamic marks, markup etc.

-In this example, the @code{Voice} context must be
-explicitly declared, or else the entire music expression would
-belong to the @code{CueVoice} context.
+@warning{When a @code{Voice} starts with @code{\cueDuring}, as in the
+following example, the @code{Voice} context must be explicitly declared,
+or else the entire music expression would belong to the @code{CueVoice}
+context.}

 @lilypond[verbatim,quote]
 oboeNotes = \relative c'' {



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

Re: Lilypond-book: Implement musicxml support in lilypond-book (issue1659041)

[Carl . D . Sorensen]

LGTM.  Thanks!

Carl



http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):

http://codereview.appspot.com/1659041/diff/16001/Documentation/usage/lilypond-book.itely#newcode225
Documentation/usage/lilypond-book.itely:225: In the input file, music is
specified with any of the following commands
I think a colon is better than a comma in these situations.

http://codereview.appspot.com/1659041/

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

Bezier curves in the NR

[Trevor Daniels]

James

I've just noticed commit 854c9519c4d2aef9a2541c7a1684340b6c75d0f4 
which you pushed recently.  In it you changed my wording which 
describe how a Bezier curve is drawn.  Your changed version is 
wrong.  The curve does *not* go through the two intermediate control 
points.  Could you please restore my original wording.  Please only 
change things you understand.


Trevor




-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11


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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Francisco Vila]

2011/8/10 Werner LEMBERG :
>> I can't find it now, but I definitely remember having seen three
>> syllables in a soprano aria (I think it was Italian). It was
>> something like "-- to e in".
>
> An example is the second aria of Susanna in Mozart's `Le Nozze di
> Figaro', bar 16:
>
>   f2     f8  e8       g8        c8
>
>  fin -- chè l'a -- "ria è an" -- cor
>
> Almost all singers I've met during my work as a coach have problems if
> they sing it the first time :-)

That makes four vowels! i+a+e+a

Here http://cosinasdeleon.blogspot.com/2009/07/hinmo-leon.html are two
different instances of 'ioa' but they come from two words, not three.
First "-- gio~a" , then "Dio~a".

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Better pure height approximations for beamed rests. (issue4860043)

[n . puttock]

LGTM.


http://codereview.appspot.com/4860043/diff/11001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4860043/diff/11001/lily/beam.cc#newcode1736
lily/beam.cc:1736: Below, the prev_offset parameter is intentionally
unused. This is
comment it out then :)

http://codereview.appspot.com/4860043/diff/11001/lily/beam.cc#newcode1737
lily/beam.cc:1737: because the old offset is assummedly irrelevant once
the rest
assumedly

http://codereview.appspot.com/4860043/diff/11001/lily/beam.cc#newcode1743
lily/beam.cc:1743: Beam::pure_rest_collision_callback (SCM smob, SCM
prev_offset,
SCM /* prev_offset */,

http://codereview.appspot.com/4860043/

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Francisco Vila]

2011/8/10 Werner LEMBERG :
>> An example is the second aria of Susanna in Mozart's `Le Nozze di
>> Figaro', bar 16:
>>
>>    f2     f8  e8       g8        c8
>>
>>   fin -- chè l'a -- "ria è an" -- cor
>
> BTW, the next bar is
>
>  a8[ d8]     f8     g,8[ b8] d8
>
>  bru --  "na, e il" mon --   do
>
> :-)

Thanks. It is available on page 346 of

  
http://216.129.110.22/files/imglnks/usimg/6/66/IMSLP25315-PMLP03845-Mozart_Figaro_K.492_Act_4_IX--XI.pdf

redirected from

  http://imslp.org/wiki/Special:ImagefromIndex/25315

linked in

  http://imslp.org/wiki/Le_nozze_di_Figaro,_K.492_(Mozart,_Wolfgang_Amadeus)

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

RE: Bezier curves in the NR

[James Lowe]

commit  57bf28a9c6ba1059c368214171be8f4b571533d1

From: Trevor Daniels [t.dani...@treda.co.uk]
Sent: 10 August 2011 23:05
To: James Lowe
Cc: Lily-Devel List
Subject: Bezier curves in the NR

James

I've just noticed commit 854c9519c4d2aef9a2541c7a1684340b6c75d0f4
which you pushed recently.  In it you changed my wording which
describe how a Bezier curve is drawn.  Your changed version is
wrong.  The curve does *not* go through the two intermediate control
points.  Could you please restore my original wording.  Please only
change things you understand.

Trevor




-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11


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

Doc: NR remove 5.1.7 (issue4839061)

[tdanielsmusic]

James
My suggestion was to remove the *material* in 5.1.7 and replace it with
material from 5.4.3, removing 5.4.3 as a section.  The reference at the
end of the material from 5.4.3 will need to be removed.  Also, following
Neil's reminder, we need to expand the documentation of the use of
\accepts in 5.1.7 too, using his neat example.
Trevor


http://codereview.appspot.com/4839061/

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

Re: Bezier curves in the NR

[Trevor Daniels]

Thanks James - that's fine now.

Trevor

- Original Message - 
From: "James Lowe" 

To: "Trevor Daniels" 
Cc: "Lily-Devel List" 
Sent: Wednesday, August 10, 2011 11:28 PM
Subject: RE: Bezier curves in the NR


commit 57bf28a9c6ba1059c368214171be8f4b571533d1

From: Trevor Daniels [t.dani...@treda.co.uk]
Sent: 10 August 2011 23:05
To: James Lowe
Cc: Lily-Devel List
Subject: Bezier curves in the NR

James

I've just noticed commit 854c9519c4d2aef9a2541c7a1684340b6c75d0f4
which you pushed recently.  In it you changed my wording which
describe how a Bezier curve is drawn.  Your changed version is
wrong.  The curve does *not* go through the two intermediate control
points.  Could you please restore my original wording.  Please only
change things you understand.

Trevor




-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 
08/10/11





-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 
08/10/11





-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11


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

T1349 - Fix load order for running with Guile V2 (issue4849054)

[ianhulin44]

Reviewers: ,

Message:
This patch adjusts the load order to one which works for both Guile
V1.8.7 and Guile V2.0.

The markup syntax macros have been moved from markup.scm to a new file
markup-macros.scm, so these can be loaded before markup.scm. Attempting
to move markup.scm without doing this causes interactions with other
dependent .scm files in the list.

Make and regtests run with Guile V1.8.7, V2.0 system completes load
successfully but fails later in initialization owing to deprecation
warnings (see Tracker 1780).

Patch available for review on
http:://codereview/appspot.com/4849054

Ian Hulin


Ian Hulin

Description:
T1349 - Fix load order for running with Guile V2

1. Split load list into components (init-scheme-files-lib, *-used,
*-body
and *-tail, and append them together before doing load.
2. Split markup macros from markup.scm to new file markup-macros.scm

Please review this at http://codereview.appspot.com/4849054/

Affected files:
  M scm/lily.scm
  A scm/markup-macros.scm
  M scm/markup.scm



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

Re: T1349 - Fix load order for running with Guile V2 (issue4849054)

[Carl . D . Sorensen]

Thanks for tackling this.

Your tab to space conversion on lily.scm has lots of errors.  Please
either revert those changes or get them right.

markup.scm should continue to use interval-length, rather than car.

Thanks,

Carl


http://codereview.appspot.com/4849054/diff/1/scm/lily.scm
File scm/lily.scm (right):

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode229
scm/lily.scm:229: (ly:message
Indent is wrong here -- should align with test, not with if.

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode272
scm/lily.scm:272: (ly:get-option 'trace-memory-frequency)
Indentation needs to move in one parenthesis level on this line and
next.

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode294
scm/lily.scm:294: (ly:progress "[~A" file-name))
indent one more level

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode296
scm/lily.scm:296: (ly:error (_ "cannot find: ~A") x))
indent one more level

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode299
scm/lily.scm:299: (ly:progress "]\n"
indent one more level

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode303
scm/lily.scm:303: (vector-ref (uname) 0) char-set:letter+digit)))
needs to be indented beyond string-tokenize

http://codereview.appspot.com/4849054/diff/1/scm/lily.scm#newcode305
scm/lily.scm:305: (member (string-downcase (cadr platform)) '("95" "98"
"me")
Indent one more level

http://codereview.appspot.com/4849054/diff/1/scm/markup.scm
File scm/markup.scm (right):

http://codereview.appspot.com/4849054/diff/1/scm/markup.scm#newcode74
scm/markup.scm:74: (xoff (+ space (cdr (ly:stencil-extent head X)
Please keep this interval-length, because it isolates the function from
the data representation.

If we need to split lily-library.scm so we can load it earlier, we
should do so.

http://codereview.appspot.com/4849054/

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

Re: GOP-PROP 8: issue priorities (probable decision)

[Colin Campbell]

On 11-08-10 10:46 AM, Graham Percival wrote:

 * Type-ignorance: (fixme name?) it is not clear what the
   correct output should look like. We need scans, references,
   examples, etc.



Perhaps more diplomatically as "Type- ambiguous"?

Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



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

Re: GOP-PROP 8: issue priorities (probable decision)

[Keith OHara]

Graham Percival  percival-music.ca> writes:

> Type-critical:
> 
You might want to split this into two:
 regressions to the output of Lilypond, and
 critical impediments to development

> * Type-ignorance: (fixme name?) it is not clear what the
>   correct output should look like. 

In a classification of Types, I'd drop this.  It is not a type 
of problem but rather a status of problem, and not something we
will likely want to sort under.  We can look in the comments to
see if the desired behavior is clear before starting to program.



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

Re: GOP-PROP 8: issue priorities (probable decision)

[Graham Percival]

On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote:
> Graham Percival  percival-music.ca> writes:
> 
> > Type-critical:
> > 
> You might want to split this into two:
>  regressions to the output of Lilypond, and
>  critical impediments to development

Why bother splitting it?  I forsee an average weekly count of 2
Critical regressions, and 0.15 critical impediments to
development.  I really hope that both "sub-types" would be fixed
very quickly, and both will block a stable release.  Given that
every other type is likely to have between 20 and 400 issues, I
don't think that it's worth splitting them.

> > * Type-ignorance: (fixme name?) it is not clear what the
> >   correct output should look like. 
> 
> In a classification of Types, I'd drop this.  It is not a type 
> of problem but rather a status of problem, and not something we
> will likely want to sort under.  We can look in the comments to
> see if the desired behavior is clear before starting to program.

I'm fine with that.

Cheers,
- Graham

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

Re: Adds a glyph for tied lyrics. (issue4808074)

[Werner LEMBERG]

>> An example is the second aria of Susanna in Mozart's `Le Nozze di
>> Figaro', bar 16:
>>
>>   f2     f8  e8       g8        c8
>>
>>  fin -- chè l'a -- "ria è an" -- cor
>>
>> Almost all singers I've met during my work as a coach have problems
>> if they sing it the first time :-)
> 
> That makes four vowels! i+a+e+a

Yes :-) Since this is completely unexpected (and I don't know any
other work of Mozart with a similar situation), people are stumbling
there.

> Here http://cosinasdeleon.blogspot.com/2009/07/hinmo-leon.html are
> two different instances of 'ioa' but they come from two words, not
> three.  First "-- gio~a" , then "Dio~a".

No lyric ties either...


Werner

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