date:20170105

Re: Allow fixed spacing of symbols in church rests (issue 319910043 by david.nales...@gmail.com)

2017-01-05 Thread david . nalesnik


On 2016/12/30 16:59:55, Dan Eble wrote:

On 2016/12/29 17:47:46, david.nalesnik wrote:
> Please review.  Thanks!



I haven't reviewed the code, but the description makes me wonder, is

the current

behavior not a bug?  Gould says "In tradition engraving," which

appears to be

her term for the style using church rests, "a rest bar takes the space

the

graphic symbol needs ..." (Behind Bars, p.565).  Although she goes on

to

recommend against "tradition engraving," it seems that the bars should

be sized

to the rests, not the other way around.



Is it important to preserve the old algorithm at all?  If not, call it

a bug and

throw it out.  If it is important to preserve, could it be handled

with a

conversion rule so that your new algorithm can be the default?


I've had time to think about this, and I think my comments below will be
a more direct response
to your concerns!

Bars *are* sized to fit the rest, but this issue is complicated by
available space.

When ragged-right is #t, bars fit the rest, though an effort is made to
give extra space to rests
proportional to their duration (the property space-increment).  Gould is
in favor of this practice.  Setting
spacing-increment to 0 gives you measures with only enough space to
contain their rests:

{
  \override MultiMeasureRest.expand-limit = 101
  \override MultiMeasureRest.space-increment = 0
  \compressFullBarRests
  R1*3
  R1*5
  R1*7
  R1*9
  R1*101
}

But when the contents of the measure aren't the only factors in deciding
measure size, what happens
to the church rest?  The engraving examples I cited allow flexibility in
the spacing of church rest
symbols.  When the rest is too diffuse, however, it becomes harder to
take in.

So I believe that the bug here is that LilyPond does not limit the
stretchability of the
rest.  The third patch set addresses that.


https://codereview.appspot.com/319910043/

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

PATCHES - Countdown for January 5th

2017-01-05 Thread James


Hello,

Here is the current patch countdown list. The next countdown will be on
January 8th

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/



Push:


5023 converted font-size values from px and percentages to em values - 
Graham Percival

https://sourceforge.net/p/testlilyissues/issues/5023
http://codereview.appspot.com/315310043



Countdown:


5027 NR 1.2.1.d: Split note correctly - Simon Albrecht
https://sourceforge.net/p/testlilyissues/issues/5027
http://codereview.appspot.com/319940043


5025 Let the distance of strings and frets in fret-diagrams be settable 
- Thomas Morley

https://sourceforge.net/p/testlilyissues/issues/5025
http://codereview.appspot.com/319030043


5024 Rework the Preinit framework into something simpler - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5024
http://codereview.appspot.com/318200043


4983 \crossStaff only hides default-style flags - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/4983
http://codereview.appspot.com/315330043


Review:


4509 Enhancement: automatically engrave lyric extenders - Alexander Kobel
https://sourceforge.net/p/testlilyissues/issues/4509
http://codereview.appspot.com/313240043


New:


5028 Correct some typos german doc - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/5028
http://codereview.appspot.com/319060043


5022 Allow fixed spacing of symbols in church rests - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5022
http://codereview.appspot.com/319910043


Regards

James


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

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Simon Albrecht


On 04.01.2017 15:01, Hans Åberg wrote:

This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, "Elementary 
Training", p. 30. In other words, the note should not cross the 2nd and 4th metric 
accents, but it can cross the [3rd].


I’ve never heard of that and would assume it is a peculiarity in 
Hindemith. Can anyone cite Gould or similar on the topic?


Best, Simon

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

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Hans Åberg


> On 5 Jan 2017, at 23:16, Simon Albrecht  wrote:
> 
>>> On 04.01.2017 15:01, Hans Åberg wrote:
 This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
 "Elementary Training", p. 30. In other words, the note should not cross 
 the 2nd and 4th metric accents, but it can cross the [3rd].
> 
> I’ve never heard of that and would assume it is a peculiarity in Hindemith. 
> Can anyone cite Gould or similar on the topic?

My scores of J.S. Bach, Orchestral Suite No. 2 in B Minor, BWV 1067 has it in a 
number of places, i.e., a half note crossing the 3rd metric accent.



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

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Hans Aikema


> On 5 Jan 2017, at 23:55, Simon Albrecht  wrote:
> 
> On 05.01.2017 23:42, Hans Aikema wrote:
>>> On 5 Jan 2017, at 23:16, Simon Albrecht  wrote:
> On 04.01.2017 15:01, Hans Åberg wrote:
>> This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
>> "Elementary Training", p. 30. In other words, the note should not cross 
>> the 2nd and 4th metric accents, but it can cross the [3rd].
>>> I’ve never heard of that and would assume it is a peculiarity in Hindemith. 
>>> Can anyone cite Gould or similar on the topic?
>>> 
>>> Best, Simon
>> Have Gould at hand, but I think it depends on interpretation of Gould p171 
>> in the section on Syncopation
>> 
>> 
>> The following common patterns are exceptions and should always be written as 
>> follows
>> 
>> 
>> description of the image that follows for 4/4 time:
>> crotchet minim crotchet  and not crotchet crotchet tie crotchet crotchet
>> 
>> does that hold for ‘minim in the middle of the measure’ or just for an exact 
>> crotchet minim crotchet measure?
> 
> We are not talking about a simple syncopated rhythm like the one Gould lists 
> as an exception (!). Of course it’s perfectly normal to write 4 2 4 in 4/4 
> time.
> But if the note has to be split with a tie anyway, then it should be split 
> along the center of the measure first, unlike the NR hitherto did.
> 8 4.~ 4 4
> not
> 8 8~ 2 4
> 
> Best, Simon

How I read p171 is that those are common patterns that are NOT syncopated but 
appear to be, as it follows the following snippet of text on Syncopation:

Rhythms that should not be syncopated must divide note-values to expose the 
beats of the bar:

4/4 time 4. 4 8 4 | will be accentuated as 3 + 3+ 2 quavers : 8/8 4.-> 4-> 8 
4-> |

unless written 4/4 4. 8~8 8 4 |

The following common patterns……..
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Hans Åberg


> On 5 Jan 2017, at 23:55, Simon Albrecht  wrote:
> 
> On 05.01.2017 23:42, Hans Aikema wrote:
>>> On 5 Jan 2017, at 23:16, Simon Albrecht  wrote:
> On 04.01.2017 15:01, Hans Åberg wrote:
>> This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
>> "Elementary Training", p. 30. In other words, the note should not cross 
>> the 2nd and 4th metric accents, but it can cross the [3rd].
>>> I’ve never heard of that and would assume it is a peculiarity in Hindemith. 
>>> Can anyone cite Gould or similar on the topic?
>>> 
>>> Best, Simon
>> Have Gould at hand, but I think it depends on interpretation of Gould p171 
>> in the section on Syncopation
>> 
>> 
>> The following common patterns are exceptions and should always be written as 
>> follows
>> 
>> 
>> description of the image that follows for 4/4 time:
>> crotchet minim crotchet  and not crotchet crotchet tie crotchet crotchet
>> 
>> does that hold for ‘minim in the middle of the measure’ or just for an exact 
>> crotchet minim crotchet measure?
> 
> We are not talking about a simple syncopated rhythm like the one Gould lists 
> as an exception (!). Of course it’s perfectly normal to write 4 2 4 in 4/4 
> time.
> But if the note has to be split with a tie anyway, then it should be split 
> along the center of the measure first, unlike the NR hitherto did.
> 8 4.~ 4 4
> not
> 8 8~ 2 4

Hindemith has 8 8~ 2~ 8 8.




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

LiyDev 4.1 + GUB fails lilypond test on my system

2017-01-05 Thread Hans Aikema

I decided to first try and get an operational GUB build before further 
trialling to get the same running in a minimal docker container…. so off I went 
as per the website with LilyDev (version 4.1; decided to go conservative as 
AFAIK I would need the unstable branch of Lilypond for success with LilyDev 
5.0) , installed in a VMWare VM (4CPU, 8Gb memory, 40Gb disk space)

I tried to cook the proper recipe:
a git clone of https://github.com/gperciva/gub
a download of regtests tarball for 2.18.2 & touch of the regtests/ignore
a make bootstrap
a make lilypond
blend it all with a lot of patience….

then the logs started showing errors and the lilypond-test came to a grinding 
halt:

cd ./out-test && 
/home/aikebah/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/scripts/build/out/run-and-check
 "dblatex  suffix-lyxml.xml" "suffix-lyxml.dblatex.log"

Please check the logfile suffix-lyxml.dblatex.log for errors

make[2]: *** [out-test/suffix-lyxml.pdf] Error 1
make[2]: Leaving directory 
`/home/aikebah/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/lilypond-book'
make[1]: *** [local-test] Error 2
make[1]: Leaving directory 
`/home/aikebah/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/lilypond-book'
make: *** [test] Error 2
Command barfed: cd 
/home/aikebah/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master
 && ulimit -m 524288 && ulimit -d 524288 && ulimit -v 1048576 &&  
LILYPOND_EXTERNAL_BINARY=/home/aikebah/gub/target/linux-x86/root/usr/bin/lilypond
 
PATH=/home/aikebah/gub/target/tools/root/usr/bin:/home/aikebah/gub/target/linux-x86/root/usr/bin:$PATH
 MALLOC_CHECK_=2 
LD_LIBRARY_PATH=/home/aikebah/gub/target/tools/root/usr/lib:/home/aikebah/gub/target/linux-x86/root/usr/lib:${LD_LIBRARY_PATH-/foe}
 
GS_FONTPATH=/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/fonts:/home/aikebah/gub/target/linux-x86/root/usr/share/gs/fonts
 
GS_LIB=/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/Resource/Init:/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/Resource
  make -j8  CPU_COUNT=4   test
Traceback (most recent call last):
  File "bin/gub", line 233, in exceptional_build
build (settings, options, files)
  File "bin/gub", line 229, in build
b.build_source_packages (names)
  File "bin/../gub/buildrunner.py", line 334, in build_source_packages
self.spec_build (spec_name)
  File "bin/../gub/buildrunner.py", line 262, in spec_build
deferred_runner.execute_deferred_commands ()
  File "bin/../gub/runner.py", line 167, in execute_deferred_commands
cmd.execute (self.logger)
  File "bin/../gub/commands.py", line 75, in execute
ignore_errors=self.ignore_errors)
  File "bin/../gub/loggedos.py", line 93, in system
raise misc.SystemFailed (m)
SystemFailed: Command barfed: cd 
/home/aikebah/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master
 && ulimit -m 524288 && ulimit -d 524288 && ulimit -v 1048576 &&  
LILYPOND_EXTERNAL_BINARY=/home/aikebah/gub/target/linux-x86/root/usr/bin/lilypond
 
PATH=/home/aikebah/gub/target/tools/root/usr/bin:/home/aikebah/gub/target/linux-x86/root/usr/bin:$PATH
 MALLOC_CHECK_=2 
LD_LIBRARY_PATH=/home/aikebah/gub/target/tools/root/usr/lib:/home/aikebah/gub/target/linux-x86/root/usr/lib:${LD_LIBRARY_PATH-/foe}
 
GS_FONTPATH=/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/fonts:/home/aikebah/gub/target/linux-x86/root/usr/share/gs/fonts
 
GS_LIB=/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/Resource/Init:/home/aikebah/gub/target/linux-x86/root/usr/share/ghostscript/9.20/Resource
  make -j8  CPU_COUNT=4   test


with a suffix-lyxml.dblatex.log containing

/usr/bin/python: /home/aikebah/gub/target/tools/root/usr/lib/libz.so.1: no 
version information available (required by /usr/bin/python)
Traceback (most recent call last):
  File "/usr/bin/dblatex", line 5, in 
from dbtexmf.contrib.debian.errorhandler import DebianHandler
  File 
"/usr/lib/python2.7/dist-packages/dbtexmf/contrib/debian/errorhandler.py", line 
8, in 
import apt
  File "/usr/lib/python2.7/dist-packages/apt/__init__.py", line 23, in 
import apt_pkg
ImportError: /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12: symbol gzseek64, 
version ZLIB_1.2.3.3 not defined in file libz.so.1 with link time reference

Anyone a clue what the root-cause of this error can be? It would seem to me as 
a conflict between libz.so as compiled by GUB and the python on LilyDev….. but 
then I would expect LilyDev 4.1 itself to be broken as well and I did not see 
any signals that LilyDev 4.1 itself would not be able to properly build 
Lilypond master branch.

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

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Hans Aikema


> On 5 Jan 2017, at 23:16, Simon Albrecht  wrote:
> 
>>> On 04.01.2017 15:01, Hans Åberg wrote:
 This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
 "Elementary Training", p. 30. In other words, the note should not cross 
 the 2nd and 4th metric accents, but it can cross the [3rd].
> 
> I’ve never heard of that and would assume it is a peculiarity in Hindemith. 
> Can anyone cite Gould or similar on the topic?
> 
> Best, Simon
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
Have Gould at hand, but I think it depends on interpretation of Gould p171 in 
the section on Syncopation


The following common patterns are exceptions and should always be written as 
follows


description of the image that follows for 4/4 time:
crotchet minim crotchet  and not crotchet crotchet tie crotchet crotchet

does that hold for ‘minim in the middle of the measure’ or just for an exact 
crotchet minim crotchet measure?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Trevor Daniels

Simon Albrecht wrote Thursday, January 05, 2017 10:16 PM

>>> On 04.01.2017 15:01, Hans Åberg wrote:
 This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
 "Elementary Training", p. 30. In other words, the note should not cross 
 the 2nd and 4th metric accents, but it can cross the [3rd].
> 
> I’ve never heard of that and would assume it is a peculiarity in 
> Hindemith. Can anyone cite Gould or similar on the topic?

Well, Elaine Gould has several pages on the topic - 166-169.
That section starts:

"Note-values sustained across a beat or half-bar must expose
the beat structure of the bar:

[examples picked out are all in 4/4 time]

   8 4.~ 8 4 8 and not 8 2 4 8
   8 8 8 8~ 4. 8 and not 8 8 8 2 8

"Only very straightforward rhythms may be written across the beat
or half-bar:   4 2.  or   2 32  [are OK]"

"As the division of a bar becomes more complex, it is essential to
reveal more of the beats."

"When the rhythms are not part of a regular pattern, the long duration
may be divided to expose the beats or half-bar, to make the rhythm
easier to count.  In 4/4 it is the third (not the fourth) beat that should 
be exposed:

   2~ 4... 32  or even   2~ 4~ 8.. 32  "

So her essential message is reveal as many beats with ties as is
necessary to make the required rhythm clear.  There is no definite
rule.

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

Re: 5027: NR example with bad engraving practice

2017-01-05 Thread Simon Albrecht


On 05.01.2017 23:42, Hans Aikema wrote:

On 5 Jan 2017, at 23:16, Simon Albrecht  wrote:

On 04.01.2017 15:01, Hans Åberg wrote:

This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, "Elementary 
Training", p. 30. In other words, the note should not cross the 2nd and 4th metric 
accents, but it can cross the [3rd].

I’ve never heard of that and would assume it is a peculiarity in Hindemith. Can 
anyone cite Gould or similar on the topic?

Best, Simon

Have Gould at hand, but I think it depends on interpretation of Gould p171 in 
the section on Syncopation


The following common patterns are exceptions and should always be written as 
follows


description of the image that follows for 4/4 time:
crotchet minim crotchet  and not crotchet crotchet tie crotchet crotchet

does that hold for ‘minim in the middle of the measure’ or just for an exact 
crotchet minim crotchet measure?


We are not talking about a simple syncopated rhythm like the one Gould 
lists as an exception (!). Of course it’s perfectly normal to write 4 2 
4 in 4/4 time.
But if the note has to be split with a tie anyway, then it should be 
split along the center of the measure first, unlike the NR hitherto did.

8 4.~ 4 4
not
8 8~ 2 4

Best, Simon

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

New template for 'lilypond' made available

2017-01-05 Thread Translation Project Robot

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'lilypond' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/lilypond-2.19.54.pot

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.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.54.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

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: Allow fixed spacing of symbols in church rests (issue 319910043 by david.nales...@gmail.com)

PATCHES - Countdown for January 5th

Re: 5027: NR example with bad engraving practice

Re: 5027: NR example with bad engraving practice

Re: 5027: NR example with bad engraving practice

Re: 5027: NR example with bad engraving practice

LiyDev 4.1 + GUB fails lilypond test on my system

Re: 5027: NR example with bad engraving practice

Re: 5027: NR example with bad engraving practice

Re: 5027: NR example with bad engraving practice

New template for 'lilypond' made available

11 matches

Site Navigation

Mail list logo

Footer information