Changes: long english notenames switched from aflat to a-flat (issue 232330043 by d...@gnu.org)

[k-ohara5a5a]

This would be a good commit in which to also put something like
@code{s}/-@code{-sharp}
at Documentation/notation/pitches.itely

@item @code{english}
@tab -s/--sharp @tab -f/--flat
@tab -ss/-x/--sharpsharp
@tab -ff/--flatflat

The -- produces an em-dash, only slightly longer than a -, so in the
manuals it looks like the names of the pitch would be cs / csharp

https://codereview.appspot.com/232330043/

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

Re: Improving the Contributors Guide and LilyDev

[Janek Warchoł]

PS don't install Vagrant with apt-get, the version in official repositories
is *ancient* and probably won't work - install using files from the website.

2015-05-12 21:38 GMT-07:00 Janek Warchoł :

> Hello,
>
> I have an alpha version of LilyDev built with Vagrant and Ansible ready
> for demonstration.
>
> To try it, you need VirtualBox (https://www.virtualbox.org/) and Vagrant (
> https://www.vagrantup.com/) installed, and the LilyDev Vagrant box (which
> you can download here:
> https://www.dropbox.com/s/xzv9iog9klhexgm/lilydev4.a02.box?dl=0).
>
> Open terminal and in an empty directory run:
>
> vagrant init lilydev4 
> vagrant up
>
> LilyDev should setup itself completely automatically, and you should see a
> login screen; the username and password is `vagrant`.  Inside, you should
> be able to compile LilyPond according to the "Compiling with LilyDev"
> section of the CG.
>
> Of course, you can build the box yourself - there are instructions in
> README (the repository is on GitHub:
> https://github.com/janek-warchol/vagrant-powered-lilydev).  I hope that
> the code is commented well and will be self-explanatory.
>
> How do you like it?
> (keep in mind that this is just a proof of concept; many things mentioned
> in the discussion still have to be done.  I'm mainly interested in your
> opinion about how it works in general).
>
> best,
> Janek
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4205: Improve part combiner's rest analysis (issue 174610043 by nine.fierce.ball...@gmail.com)

[k-ohara5a5a]

I noticed the same bug with rests and skips.  I'm using the patch below
with success on my own music, but I haven't tried it on the regtest
suite yet.


https://codereview.appspot.com/174610043/diff/20001/scm/part-combiner.scm
File scm/part-combiner.scm (right):

https://codereview.appspot.com/174610043/diff/20001/scm/part-combiner.scm#newcode51
scm/part-combiner.scm:51: (filter f? (events vs)))
I suggest also sorting rests before skips, so that we compare the rest
to the rest if parts contain a mix

 (append (filter (lambda(x) (ly:in-event-class? x 'rest-event))
 (events vs))
 (filter (lambda(x) (ly:in-event-class? x 'skip-event))
 (events vs

https://codereview.appspot.com/174610043/diff/20001/scm/part-combiner.scm#newcode457
scm/part-combiner.scm:457: (= 1 (length rests2))
(< 0 (length rests1))
(< 0 (length rests2))

https://codereview.appspot.com/174610043/

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

Re: Improving the Contributors Guide and LilyDev

[Janek Warchoł]

Hello,

I have an alpha version of LilyDev built with Vagrant and Ansible ready for
demonstration.

To try it, you need VirtualBox (https://www.virtualbox.org/) and Vagrant (
https://www.vagrantup.com/) installed, and the LilyDev Vagrant box (which
you can download here:
https://www.dropbox.com/s/xzv9iog9klhexgm/lilydev4.a02.box?dl=0).

Open terminal and in an empty directory run:

vagrant init lilydev4 
vagrant up

LilyDev should setup itself completely automatically, and you should see a
login screen; the username and password is `vagrant`.  Inside, you should
be able to compile LilyPond according to the "Compiling with LilyDev"
section of the CG.

Of course, you can build the box yourself - there are instructions in
README (the repository is on GitHub:
https://github.com/janek-warchol/vagrant-powered-lilydev).  I hope that the
code is commented well and will be self-explanatory.

How do you like it?
(keep in mind that this is just a proof of concept; many things mentioned
in the discussion still have to be done.  I'm mainly interested in your
opinion about how it works in general).

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

Compile LilyPond for NaCl

[Trevor]

Could any useful part of LilyPond be compiled for NaCl
?
Is that at all within the realm of possibility?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Part_combine_iterator: simplify context substitution (issue 238070043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2015/05/11 05:04:15, Keith wrote:

This and the MMrest patch look sensible,
but it is a good idea to test them on some orchestral music from

mutopiaproject.

  I tried them on a piece I have and saw no output differences.


First I tried a score requiring 2.14 which would not compile after
running convert-ly.  Then I tried a few scores requiring 2.18 with horn,
bassoon, and string combining, and I did not notice any problems due to
these changes.  (I did find a problem caused by older changes which I
reported to the bug list and will address when I have time.)

https://codereview.appspot.com/238070043/

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

Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

Reviewers: ,

Description:
Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc.

Hide Smob_base<>::is_smob() to prevent the misleading situation of
D::is_smob(S) returning true when S represents an ancestor of D rather
than a D.  This issue was previously worked around by overriding
is_smob in several derived smob classes; that is no longer needed.

For derived smobs, is_derived_smob<>() is required and incorporates a
dynamic cast.  The same distinction applies to unsmob<>() and
derived_unsmob<>().

Smob_base<>::smob_p() is hidden because there doesn't seem to be a
need for it to be public.

Files in lily/include were edited by hand.  Files in lily itself were
processed with the following sed script.

s/\(Engraver\|Global_context\|Item\|Music\|Paper_score\|Performance\| 
Performer\|Spanner\|Stream_event\)::is_smob/is_derived_smob<\1>/g
s/\(Engraver\|Global_context\|Item\|Music\|Paper_score\|Performance\| 
Performer\|Spanner\|Stream_event\)::unsmob/derived_unsmob<\1>/g

s/LY_ASSERT_SMOB
(\(Engraver\|Global_context\|Item\|Music\|Paper_score\|Performance\| 
Performer\|Spanner\|Stream_event\),/LY_ASSERT_DERIVED_SMOB

(\1,/g
s/\([A-Za-z_]\+\)::is_smob/is_smob<\1>/g
s/\([A-Za-z_]\+\)::unsmob/unsmob<\1>/g
s/Input \*\([A-Za-z_]\+\) = unsmob /Input *\1 = unsmob /g

This is an evolution of the idea originally proposed in
https://codereview.appspot.com/236850043/

Please review this at https://codereview.appspot.com/231680043/

Affected files (+1535, -1560 lines):
  M lily/accidental.cc
  M lily/accidental-engraver.cc
  M lily/accidental-placement.cc
  M lily/align-interface.cc
  M lily/all-font-metrics.cc
  M lily/ambitus-engraver.cc
  M lily/arpeggio.cc
  M lily/articulations.cc
  M lily/auto-beam-engraver.cc
  M lily/auto-change-iterator.cc
  M lily/axis-group-engraver.cc
  M lily/axis-group-interface.cc
  M lily/axis-group-interface-scheme.cc
  M lily/balloon.cc
  M lily/balloon-engraver.cc
  M lily/bar-check-iterator.cc
  M lily/beam.cc
  M lily/beam-collision-engraver.cc
  M lily/beam-engraver.cc
  M lily/beam-quanting.cc
  M lily/bend-engraver.cc
  M lily/book.cc
  M lily/book-scheme.cc
  M lily/break-align-engraver.cc
  M lily/break-alignment-interface.cc
  M lily/break-substitution.cc
  M lily/breathing-sign.cc
  M lily/chord-name.cc
  M lily/chord-name-engraver.cc
  M lily/clef.cc
  M lily/clef-engraver.cc
  M lily/clef-modifier.cc
  M lily/cluster.cc
  M lily/cluster-engraver.cc
  M lily/coherent-ligature-engraver.cc
  M lily/completion-note-heads-engraver.cc
  M lily/completion-rest-engraver.cc
  M lily/constrained-breaking.cc
  M lily/context.cc
  M lily/context-def.cc
  M lily/context-mod-scheme.cc
  M lily/context-property.cc
  M lily/context-scheme.cc
  M lily/custos.cc
  M lily/custos-engraver.cc
  M lily/dispatcher.cc
  M lily/dispatcher-scheme.cc
  M lily/dot-column.cc
  M lily/dot-column-engraver.cc
  M lily/dots.cc
  M lily/dots-engraver.cc
  M lily/drum-note-performer.cc
  M lily/duration-scheme.cc
  M lily/dynamic-align-engraver.cc
  M lily/dynamic-engraver.cc
  M lily/enclosing-bracket.cc
  M lily/engraver.cc
  M lily/engraver-group.cc
  M lily/engraver-scheme.cc
  M lily/episema-engraver.cc
  M lily/event-chord-iterator.cc
  M lily/figured-bass-continuation.cc
  M lily/figured-bass-engraver.cc
  M lily/fingering-column.cc
  M lily/fingering-engraver.cc
  M lily/flag.cc
  M lily/font-interface.cc
  M lily/font-metric-scheme.cc
  M lily/font-select.cc
  M lily/footnote-engraver.cc
  M lily/forbid-break-engraver.cc
  M lily/function-documentation.cc
  M lily/global-context.cc
  M lily/global-context-scheme.cc
  M lily/grace-engraver.cc
  M lily/grace-music.cc
  M lily/grace-spacing-engraver.cc
  M lily/gregorian-ligature-engraver.cc
  M lily/grid-line-interface.cc
  M lily/grid-point-engraver.cc
  M lily/grob.cc
  M lily/grob-array.cc
  M lily/grob-array-scheme.cc
  M lily/grob-closure.cc
  M lily/grob-info.cc
  M lily/grob-pq-engraver.cc
  M lily/grob-property.cc
  M lily/grob-scheme.cc
  M lily/hairpin.cc
  M lily/hara-kiri-group-spanner.cc
  M lily/horizontal-bracket.cc
  M lily/include/engraver.hh
  M lily/include/global-context.hh
  M lily/include/item.hh
  M lily/include/lily-guile-macros.hh
  M lily/include/listener.hh
  M lily/include/music.hh
  M lily/include/paper-score.hh
  M lily/include/performance.hh
  M lily/include/performer.hh
  M lily/include/smobs.hh
  M lily/include/smobs.tcc
  M lily/include/spanner.hh
  M lily/include/stencil.hh
  M lily/include/stream-event.hh
  M lily/input-scheme.cc
  M lily/input-smob.cc
  M lily/instrument-name-engraver.cc
  M lily/item-scheme.cc
  M lily/keep-alive-together-engraver.cc
  M lily/key-signature-interface.cc
  M lily/kievan-ligature-engraver.cc
  M lily/laissez-vibrer-engraver.cc
  M lily/ledger-line-engraver.cc
  M lily/ledger-line-spanner.cc
  M lily/lexer.ll
  M lily/ligature-engraver.cc
  M lily/lily-guile.cc
  M lily/lily-lexer.cc
  M lily/lily-lexer-scheme.cc
  M lily/lily-parser.cc
  M lily/lily-parser-scheme.cc
  M lily/

Re: Compile LilyPond for NaCl

[tisimst]

Although I can't speak to the details of LilyPond's dependencies, it sure
seems possible based on the site's description. This would be really neat,
but you'd obviously need some good server-side support to make it smooth (I
think). This would be a great addition at making an embedded
editor/compiler in the docs so that people can try things out rather than
"just read" through the examples.

- Abraham

On Tue, May 12, 2015 at 4:50 PM, trevordixon [via Lilypond] <
ml-node+s1069038n176524...@n5.nabble.com> wrote:

> Could any useful part of LilyPond be compiled for NaCl
> ?
>
> Is that at all within the realm of possibility?
> ___
> lilypond-devel mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Compile-LilyPond-for-NaCl-tp176524.html
>  To start a new topic under Dev, email
> ml-node+s1069038n88644...@n5.nabble.com
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Compile-LilyPond-for-NaCl-tp176524p176525.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Compile LilyPond for NaCl

[Trevor]

Could any useful part of LilyPond be compiled for NaCl
?
Is that at all within the realm of possibility?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: musicxml2ly tremolo tag on notes shorter than quarter

[Martin Tarenskeen]

On Tue, 12 May 2015, pls wrote:


For example what happened with the Philomenos musixcml2ly-dev fork?



Yes, Philomelos is still alive and I’m about to update the musicxml2ly-dev 
Github repo.  Over at least three years I have written almost 100 bug
reports  and many test cases for Philomelos and I will try to publish them as 
well.  We have fixed quite a few of these bugs.  I just implemented
a solution to the tremolo bug reported here.


Sound promising!

Allow to me to do a drastic suggestion. Wouldn't it be much simpler to 
replace the current musicxml2ly from the official LilyPond development 
tree with the one from Philomenos entirely and allow the Philomenos guy(s) 
to continue the work there, if he/they wants to?


I never quite understood why this fork was needed. And if the Philomenos 
version is the only one that has been actively developed since a few years 
now I don't see why not everyone who installs the official LilyPond should 
not have the latest and greatest musicxml2ly tool without extra effort?


--

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

Re: Google Code shutting down

[Trevor Daniels]

James wrote Tuesday, May 12, 2015 1:46 PM
>
>> Trevor
> Do we even need a new git-cl?
> 
> I am no expert but wasn't that designed to get around the fact that we 
> had to upload to two different places (one place for actual review and 
> one for a note on the tracker). Does this new place come with it's own 
> workflow and so it would be a case of 'use their tools' and update the 
> CG with the instructions - at least as an interim solution.

Well, I'm totally unfamiliar with Allura's Review mechanism so I can't comment 
on that, but I think I'd favour making the minimal changes needed at this time, 
vis just moving the tracker.  Since, as you say, git-cl was designed to work 
with a tracker and review that are independent it should be fine with just 
moving the tracker.
  
> Patchy is a different kettle of fish. Although I wouldn't want that to 
> delay getting the conversion/move done, as while it may be a fiddle for 
> others to manually test things, I don't mind doing that - but as I have 
> said it would mean that most patch testing would take a few more extra 
> steps for me so it would make testing during a normal work day more 
> difficult.

That's good news!  So it looks like we have the makings of a complete solution, 
even if we can't figure out how Patchy works.  I'm sure we'll find some 
undesirable features of Allura when we get down to the details, but that's what 
the next few weeks will tell us.

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

Re: Google Code shutting down

[Trevor Daniels]

Carl, you wrote Tuesday, May 12, 2015 8:45 PM

> On 5/11/15 11:06 AM, "Trevor Daniels"  wrote:
>>The second, with 4369 issues, is
>>https://sourceforge.net/p/testlily/issues/  I've not done anything to
>>tailor this to our needs yet.  I intend to do that over the next few days
>>as I work through your requirements list.  Anyone can read, project
>>members can post, developers can update.
> 
> I went to this URL, and got 403 Read access required.
> 
> Can you give me permissions?  Username cds4byu, email
> carl.d.soren...@gmail.com.

Could you try again?  I've added you as an Administrator.

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

Re: Google Code shutting down

[Trevor Daniels]

Carl Sorensen wrote Tuesday, May 12, 2015 8:32 PM

>>On 11/05/15 23:04, Trevor Daniels wrote:
>>> Phil Holmes wrote Monday, May 11, 2015 6:21 PM
>>>
 Have you investigated the API for patch and git-cl?
>>> I've quickly looked at Allura's API.  It seems to contain all the
>>>features we would need.  I've also looked at git-cl, but unpicking that
>>>is someway outside my comfort zone.  It's built around code obtained
>>>from Google.  I don't plan to work on git-cl's conversion, so we need
>>>some other volunteer to do that.  Any takers?  I've not even looked at
>>>patchy.
> 
> I'm willing to take a stab at the git-cl stuff.  I've done a quick look;
> if we are going to continue to use Rietveld as our code review tool, the
> changes to git-cl are almost certainly very minor.  The main piece of the
> API we would need to use is to get the URL associated with a given issue
> number.  I believe that the Allura API has the call needed to get the URL
> (I expect it's part of the JSON representation), but I haven't yet tested
> it.

That's great Carl!  Let's use the testlily project at SourceForge as the 
test-bed:

https://sourceforge.net/projects/testlily/

If you let me have your SourceForge username I'll add you as an Administrator.  
That will give you access to everything you need.  I think there are some other 
hoops to jump through to get at the API but you'll soon find those.

>>Do we even need a new git-cl?
>>
>>I am no expert but wasn't that designed to get around the fact that we
>>had to upload to two different places (one place for actual review and
>>one for a note on the tracker). Does this new place come with it's own
>>workflow and so it would be a case of 'use their tools' and update the
>>CG with the instructions - at least as an interim solution.
> 
> I think this may be worth looking at as well.  But for right now, I really
> like the way Rietveld handles code reviews.  As you suggested,  git-cl
> ties the Rietveld review number to the LilyPond issue number.  Since we're
> not (currently) proposing to change the review hosting service, most of
> git-cl will continue to work unchanged, as I see it right now.

I agree.  Rietveld is fine, and keeping it minimises the necessary changes.

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

Re: Google Code shutting down

[Carl Sorensen]

On 5/11/15 11:06 AM, "Trevor Daniels"  wrote:
>The second, with 4369 issues, is
>https://sourceforge.net/p/testlily/issues/  I've not done anything to
>tailor this to our needs yet.  I intend to do that over the next few days
>as I work through your requirements list.  Anyone can read, project
>members can post, developers can update.

I went to this URL, and got 403 Read access required.

Can you give me permissions?  Username cds4byu, email
carl.d.soren...@gmail.com.

Thanks,

Carl


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

Re: Google Code shutting down

[Carl Sorensen]

On 5/12/15 6:46 AM, "James"  wrote:

>
>
>On 11/05/15 23:04, Trevor Daniels wrote:
>> Phil Holmes wrote Monday, May 11, 2015 6:21 PM
>>
>>> Have you investigated the API for patch and git-cl?
>> I've quickly looked at Allura's API.  It seems to contain all the
>>features we would need.  I've also looked at git-cl, but unpicking that
>>is someway outside my comfort zone.  It's built around code obtained
>>from Google.  I don't plan to work on git-cl's conversion, so we need
>>some other volunteer to do that.  Any takers?  I've not even looked at
>>patchy.

I'm willing to take a stab at the git-cl stuff.  I've done a quick look;
if we are going to continue to use Rietveld as our code review tool, the
changes to git-cl are almost certainly very minor.  The main piece of the
API we would need to use is to get the URL associated with a given issue
number.  I believe that the Allura API has the call needed to get the URL
(I expect it's part of the JSON representation), but I haven't yet tested
it.

>>
>> Trevor
>Do we even need a new git-cl?
>
>I am no expert but wasn't that designed to get around the fact that we
>had to upload to two different places (one place for actual review and
>one for a note on the tracker). Does this new place come with it's own
>workflow and so it would be a case of 'use their tools' and update the
>CG with the instructions - at least as an interim solution.

I think this may be worth looking at as well.  But for right now, I really
like the way Rietveld handles code reviews.  As you suggested,  git-cl
ties the Rietveld review number to the LilyPond issue number.  Since we're
not (currently) proposing to change the review hosting service, most of
git-cl will continue to work unchanged, as I see it right now.

Thanks,

Carl


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

Re: Issues to verify

[Carl Sorensen]

I've verified all of the issues except those marked for 2.19.21.

Thanks,

Carl


On 5/12/15 8:30 AM, "Phil Holmes"  wrote:

>I've cleared a lot of the issues to verify, but there are a number that
>I've marked fixed, and our protocol is that someone else should verify
>these.
>
>http://philholmes.net/lilypond/git/ can be used to help find commitishes.
>
>Please could someone have a go at some of the issues to verify?
>
>TIA
>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Issues to verify

[Phil Holmes]

I've cleared a lot of the issues to verify, but there are a number that 
I've marked fixed, and our protocol is that someone else should verify 
these.

http://philholmes.net/lilypond/git/ can be used to help find commitishes.

Please could someone have a go at some of the issues to verify?

TIA


___
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)

[Paul Morris]

> On May 7, 2015, at 9:16 PM, Dan Eble  wrote:
> 
> \octave sounds like it should be a function returning the octave of a note.  
> It does not sound like an entry mode.

Yes, after further thought it’s probably better to go with something that 
clearly sounds like an entry mode, like \fixed (or \absolute).

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

Re: Google Code shutting down

[James]

On 11/05/15 23:04, Trevor Daniels wrote:

Phil Holmes wrote Monday, May 11, 2015 6:21 PM
  

At some point we will need to freeze the Google version, copy them over and
move to the new version.  This is probably better done sooner than later,
once we're sure that the move is correct.  It will presumably also mean no
updates to issues during that period.

Yes.  I suggested the latest day for this should be 10 Aug 2015.  That's 2 
weeks before GoogleCode goes read-only.  If we are ready earlier so much the 
better, but that depends on how long it takes to re-develop git-cl and patchy.  
And before that can start we need agreement on where we are going.  AFAIK using 
Allura at SourceForge is currently the only viable option on the table.  I'm 
not investigating any other options.  Is any one else?


Have you investigated the API for patch and git-cl?

I've quickly looked at Allura's API.  It seems to contain all the features we 
would need.  I've also looked at git-cl, but unpicking that is someway outside 
my comfort zone.  It's built around code obtained from Google.  I don't plan to 
work on git-cl's conversion, so we need some other volunteer to do that.  Any 
takers?  I've not even looked at patchy.

Trevor

Do we even need a new git-cl?

I am no expert but wasn't that designed to get around the fact that we 
had to upload to two different places (one place for actual review and 
one for a note on the tracker). Does this new place come with it's own 
workflow and so it would be a case of 'use their tools' and update the 
CG with the instructions - at least as an interim solution.


Patchy is a different kettle of fish. Although I wouldn't want that to 
delay getting the conversion/move done, as while it may be a fiddle for 
others to manually test things, I don't mind doing that - but as I have 
said it would mean that most patch testing would take a few more extra 
steps for me so it would make testing during a normal work day more 
difficult.


James

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

PATCHES: Countdown for May 16th 2015

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on 
May 16th.


You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch




PUSH:

David Kastrup: Patch: Rewrite Protected_scm for static lifetime requirements
http://code.google.com/p/lilypond/issues/detail?id=4378

David Kastrup: Patch: Implement and use "derived_unsmob"
http://code.google.com/p/lilypond/issues/detail?id=4377

Keith OHara: zero-duration chords confuse repeat tremolo
http://code.google.com/p/lilypond/issues/detail?id=4367

David Kastrup: Patch: Redesign listeners using templates
http://code.google.com/p/lilypond/issues/detail?id=4357

Phil Holmes: Get our act together concerning snippets with incipits
http://code.google.com/p/lilypond/issues/detail?id=3981

David Kastrup: Use \relative without explicit starting pitch in the docs
http://code.google.com/p/lilypond/issues/detail?id=3229




COUNTDOWN:

Dan Eble: Patch: Part_combine_iterator: move mmrest handling outside the 
part-routing state machine

http://code.google.com/p/lilypond/issues/detail?id=4386

Dan Eble: Patch: Part_combine_iterator: remove residual code related to 
marks

http://code.google.com/p/lilypond/issues/detail?id=4385

David Kastrup: Patch: Some optimizations during dispatching
http://code.google.com/p/lilypond/issues/detail?id=4380

Dan Eble: Patch: Part_combine_iterator: simplify context substitution
http://code.google.com/p/lilypond/issues/detail?id=4379

David Kastrup: Patch: Add LY_ASSERT_DERIVED_SMOB macro
http://code.google.com/p/lilypond/issues/detail?id=4376

James Lowe: Patch: Use mkstemp for intermediate ps files
http://code.google.com/p/lilypond/issues/detail?id=4374

David Kastrup: convert-ly misses some bflat -> b-flat
http://code.google.com/p/lilypond/issues/detail?id=4372

James Lowe: Patch: Add stencil-flip function
http://code.google.com/p/lilypond/issues/detail?id=4370

Han-Wen Nienhuys: Decrease space between vertical beams by length-fraction.
http://code.google.com/p/lilypond/issues/detail?id=4329




REVIEW:

David Kastrup: Patch: Add aliases fflat et al for f-flat et al in bagpipe.ly
http://code.google.com/p/lilypond/issues/detail?id=4389

David Kastrup: Patch: Changes: long english notenames switched from 
aflat to a-flat

http://code.google.com/p/lilypond/issues/detail?id=4388

David Kastrup: Patch: Let \relative work on \transpose content as if it 
were untransposed

http://code.google.com/p/lilypond/issues/detail?id=4387

David Kastrup: Patch: Remove convert-ly rule \shiftOff -> \undo\shiftOn
http://code.google.com/p/lilypond/issues/detail?id=4384

Keith OHara: absolute entry mode with less typing
http://code.google.com/p/lilypond/issues/detail?id=4366

Carl Sorensen: Subdivision of beams is wrong
http://code.google.com/p/lilypond/issues/detail?id=4355

Valentin Villenave: Attach lilypond source in pdf
http://code.google.com/p/lilypond/issues/detail?id=2643




NEW:

Thomas Morley: Fretboards: markup strings in dot positions
http://code.google.com/p/lilypond/issues/detail?id=4120




WAITING:

Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures
http://code.google.com/p/lilypond/issues/detail?id=3918

Mike Solomon: Patch: Prevents vertical axis groups with empty skylines
http://code.google.com/p/lilypond/issues/detail?id=3156

Mike Solomon: Patch: Removes the translate_axis call from 
axis-group-interface outside-staff positioning.

http://code.google.com/p/lilypond/issues/detail?id=3134

David Kastrup: Patch: Implement music functions in Scheme rather than C++
http://code.google.com/p/lilypond/issues/detail?id=2716




Thank you,
James

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

Re: Decrease space between vertical beams by length-fraction. (issue 214250043 by hanw...@gmail.com)

[pkx166h]

Patch on countdown for May 16th

https://codereview.appspot.com/214250043/

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

Re: Add stencil-flip function (issue 235090043 by paulwmor...@gmail.com)

[pkx166h]

Patch on countdown for May 16th

https://codereview.appspot.com/235090043/

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

Next Patch Flush extended by another 24 hours

[James]

Hello,

As there seems to be a significant amount of patches in the queue at the 
moment, I have decided to add another 24 hours until the next patch 
flush (May 16th instead of 15th), so as to give everyone time to digest 
those patches currently in review/countdown.


I hope that is OK.

James

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

Re: Use mkstemp for intermediate ps files (issue 233230044 by truer...@gmail.com)

[pkx166h]

Patch on countdown for May 16th

https://codereview.appspot.com/233230044/

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

Re: Issue 3229: Make \relative { ... } interpret the first pitch as an absolute one (issue 235000043 by d...@gnu.org)

[dak]

Reviewers: Keith,


https://codereview.appspot.com/23543/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):

https://codereview.appspot.com/23543/diff/1/Documentation/notation/pitches.itely#newcode169
Documentation/notation/pitches.itely:169: like @code{\relative @{ gis'''
@dots{} @}}
On 2015/05/12 06:16:37, Keith wrote:

Probably you'll want to reverse the convert-ly to the text that talks

about the

option to use \relative c'''{}


Well, it was more or less understood that this conversion would require
a followup rewrite.  I've just taken a look at some other commit
messages and there is, for example,

commit 6e4e9c4eacb94d68c11fd6b9062da4f724114860
Author: David Kastrup 
Date:   Fri Oct 18 12:29:37 2013 +0200

Run scripts/auxiliar/update-with-convert-ly.sh

Actually, this is an understatement.  This is the result of

scripts/auxiliar/update-with-convert-ly.sh
git checkout HEAD ly/{engraver,music-functions,property}-init.ly
input/regression/display-lily-tests.ly
Documentation/{,*/}learning/*.itely

and then committing.

In a similar vein, it may be possible/feasible to exempt certain files
or directories here from the conversion if we figure out that we are
likely to cause more damage than good.

However, given the extensiveness of the patterns, it is likely less
effort to manually change passages back that are negatively affected.
More likely than not, in chapters talking explicitly about pitches.

https://codereview.appspot.com/23543/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/23543/diff/1/Documentation/notation/rhythms.itely#newcode450
Documentation/notation/rhythms.itely:450: >>> Run
scripts/auxiliar/update-with-convert-ly.sh
On 2015/05/12 06:16:37, Keith wrote:

A few merge-failure reports made it into this upload, somehow.


Yeah, bummer.  Since I'll be rerunning the conversion, they won't be in
the final version (if I don't repeat the rebase mistake I apparently
did), but it's unnerving that the affected files still had no problem
passing Patchy.

Description:
Issue 3229: Make \relative { ... } interpret the first pitch as an
absolute one

The previous default of \relative { ... } being \relative c' { ... }
made c' more special than warranted.  Having to write
\relative f { ... } for this functionality seems awkward since f
serves no musical function but just happens to be the middle of the
scale.  Iff the scale is the standard scale.  The new definition of
\relative takes care to determine the "middle of the scale" reference
point properly even in the case of non-standard scales.

The conversion rules catch the cases where
a) \relative was used without a pitch argument.  In this case the
   pitch gets turned into c'
b) \relative x''' { ... is being used, with x''' being an arbitrary
   pitch and ... is a number of patterns where convert-ly can detect
   the first actual note reliably.

If the file contains \include or \language with a non-c-using notename
language, everything is left in place.

However, this exception is disabled in this commit as it is not
required on the LilyPond code base itself.

Please review this at https://codereview.appspot.com/23543/

Affected files (+9737, -6736 lines):
  M Documentation/ca/learning/common-notation.itely
  M Documentation/ca/learning/fundamental.itely
  M Documentation/ca/learning/tutorial.itely
  M Documentation/ca/learning/tweaks.itely
  M Documentation/ca/usage/running.itely
  M Documentation/ca/usage/suggestions.itely
  M Documentation/cs/learning/common-notation.itely
  M Documentation/cs/learning/fundamental.itely
  M Documentation/cs/learning/tutorial.itely
  M Documentation/cs/learning/tweaks.itely
  M Documentation/cs/usage/lilypond-book.itely
  M Documentation/cs/usage/running.itely
  M Documentation/cs/usage/suggestions.itely
  M Documentation/de/essay/engraving.itely
  M Documentation/de/extending/programming-interface.itely
  M Documentation/de/extending/scheme-tutorial.itely
  M Documentation/de/learning/common-notation.itely
  M Documentation/de/learning/fundamental.itely
  M Documentation/de/learning/tutorial.itely
  M Documentation/de/learning/tweaks.itely
  M Documentation/de/notation/ancient.itely
  M Documentation/de/notation/changing-defaults.itely
  M Documentation/de/notation/chords.itely
  M Documentation/de/notation/editorial.itely
  M Documentation/de/notation/expressive.itely
  M Documentation/de/notation/fretted-strings.itely
  M Documentation/de/notation/input.itely
  M Documentation/de/notation/keyboards.itely
  M Documentation/de/notation/pitches.itely
  M Documentation/de/notation/repeats.itely
  M Documentation/de/notation/rhythms.itely
  M Documentation/de/notation/simultaneous.itely
  M Documentation/de/notation/spacing.itely
  M Documentation/de/notation/staff.itely
  M Documentation/de/notation/text.itely
  M Documentation/de/notation/vocal.itely