gmane.comp.gnu.lilypond.general

Re: Beaming regression 2.15.39 compared to 2.14.2

Nick Payne — 2012-05-24T12:40:45

My search of the documentation regarding beaming didn't find much 
information on what the defaults are/are intended to be:

http://lilypond.org/doc/v2.15/Documentation/learning/automatic-and-manual-beams
http://lilypond.org/doc/v2.15/Documentation/notation/beams

I had a look in Gould - she merely says that in 3/4 time, any number of 
eighth notes can be beamed together. However, I would say that in 3/4 
time, if you're default is to beam six eighth notes together, then r8 c 
c c c c should be beamed as either r8 c[ c c c c] (i.e. 2.14 behaviour) 
or r8 c c[ c] c[ c], but not the current 2.15.39 default of r8 c c[ c c c].

Nick


_______________________________________________
lilypond-user mailing list
lilypond-user< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Grace Note Thickness

Thomas Morley — 2012-05-24T12:38:43

2012/5/24 Pierre Perol-Schneider <pierre.schneider.paris< at >gmail.com>:

Hi Pierre,

in the NR 1.2.6 Special rhythmic concerns, Known issues and warnings
you can read:
"The use of grace notes within voice contexts confuses the way the
voice is typeset. This can be overcome by inserting a rest or note
between the voice command and the grace note."

Seems that changing graceSettings is confused too.
I didn't manage to apply the shown workaround to your example.

But replacing \voiceOne, \voiceTwo with \stemUp, \stemDown works,
although this will lead to some other problems.

So I come up with the code below, containing three suggestions, I'd
prefer `Suggestion II'.
`Suggestion III' is needed only, if you want a complete new definition
of graceSettings.

\version "2.15.38"
\score {
  \new Staff
  <<
%%%% Suggestion I
   % $(add-grace-property 'Voice 'Beam 'beam-thickness '0.5)
   % \override Staff.Beam #'beam-thickness = #0.55
  \new Voice = "first"
    {
       \clef "treble_8"
       \time 3/8
       \stemUp
       e'4. | %2
       \appoggiatura { b'32 [ c'' b' ais' ] } b'8 [ c'' b'16
\glissando e'' ] | %2
    }
  \new Voice= "second"
    {  \stemDown a,8 a, a, }
  >>
%%%% Suggestion II
  \layout {
          \override Beam #'beam-thickness = #0.55
          $(add-grace-property 'Voice 'Beam 'beam-thickness '0.5)
  }
%%%% Suggestion III
%  \layout {
%          \override Beam #'beam-thickness = #0.55
%          \context {
%            \Voice
%            graceSettings = #`(
%                           (Voice Stem direction ,UP)
%                           (Voice Stem font-size -3)
%                           (Voice Flag font-size -3)
%                           (Voice NoteHead font-size -3)
%                           (Voice TabNoteHead font-size -4)
%                           (Voice Dots font-size -3)
%                           (Voice Stem length-fraction 0.8)
%                           (Voice Stem no-stem-extend #t)
%                           (Voice Beam beam-thickness 0.5)
%                           (Voice Beam length-fraction 0.8)
%                           (Voice Accidental font-size -4)
%                           (Voice AccidentalCautionary font-size -4)
%                           (Voice Slur direction ,DOWN)
%                           (Voice Script font-size -3)
%                           (Voice Fingering font-size -8)
%                           (Voice StringNumber font-size -8)
%                         )
%          }
%  }

}

HTH,
  Harm

Re: Grace Note Thickness

Thomas Morley — 2012-05-24T12:24:05

2012/5/24 Xavier Scheuer <x.scheuer< at >gmail.com>:

Hi Xavier,

sorry, I answered to all, not investigating the adresses. Will do in future.

-Harm

Re: Beaming regression 2.15.39 compared to 2.14.2

Urs Liska — 2012-05-24T12:17:15

Am 24.05.2012 14:14, schrieb Nick Payne:
Well, not having followed this too closely:
I have the impression that you experience an effect or side effect of 
the heavily changed beaming.

It this is the case, could you please check if this is documented? Maybe 
you overlooked something.
Or maybe there's need for a documentations suggestion?

Best
Urs

Re: Beaming regression 2.15.39 compared to 2.14.2

Nick Payne — 2012-05-24T12:14:21

Reverting to the previous behaviour is simply a matter of

\set beamExceptions = #'((end . (((1 . 8) . (6)))))

Nick

Re: Beaming regression 2.15.39 compared to 2.14.2

2012-05-24T11:19:29


Still a regression. Any change in behavior that is not fully accounted for in the change log and that you feel leads to worse behavior than a previous version is a regression.  People can then either report it as a change, at which point it is a feature, or they can fix it, at which point the old functionality is restored.

Cheers,
MS

Re: Video recording of LilyPond talk at Chemnitz

David Kastrup — 2012-05-24T11:17:21


Since I invested more half a year of fulltime work on my own savings
before even starting to seriously ask for donations, and since people
don't pay more than one or two months in advance, the only person really
losing money when I stop working on LilyPond is myself.  Everybody else
gets more developer time than they paid for, and it is not like it is
not a total bargain.  And it is not like I cash in donations at the
start of a month, and then tell people I'll quit right away.


Well, so far there is actually only one person on a variable plan.
Everybody else has either chosen an unconditional monthly payment (and
usually promised to keep it up for a certain period of time) or one-time
donations.  And since, of course, everybody is free to change his mind
at any time depending on the information I provide about ongoing
payments, it is not like there is much of a danger that I will go
stinking rich because of people "unnecessarily" paying the maximum
amount of money they can afford while on an unconditional payment plan.

You propose a system with a guarantee that I will not get any payment at
all unless a minimum is met, meaning that I have to finance the whole
month on my own.  This is not exactly going to extend the time I will be
able to work on LilyPond while tapping into my own non-replenishable
reserves.  I don't see that it would make sense for me to offer a plan
where people pay less in case more is needed.

Re: Ugly default note spacing in single staff polyphony

Thomas Morley — 2012-05-24T11:05:02

2012/5/24 Nick Payne <nick.payne< at >internode.on.net>:

Hi Nick,

\override NoteColumn #'force-hshift seems to need a note from another
voice as a substantial reference-point.
But if you try to insert such a (invisible) note the following
NoteColumn is moved, too. And the resulting code is worse:

\version "2.15.38"

\relative c'' {
   \time 3/4
<<
       { r8 c4 c c8 r c4 c4*1/2 \hideNotes c' \unHideNotes c,8 }
       \\
       { a,4 a' a' a,, a' \once \override NoteColumn #'force-hshift = #0.5 a' }
}

Trying to use 'X-offset instead seems to work:

\version "2.15.38"

\relative c'' {
   \time 3/4
<<
       { r8 c4 c c8 r c4 c4 c8 }
       \\
       { a,4 a' a' a,, a' \once \override NoteColumn #'X-offset = #0.5 a' }
}

HTH,
  Harm

David's hard work and funding

Christ van Willegen — 2012-05-24T11:01:26

Hi David,

thanks for your fantastic work for the Lilypond project!

On Thu, May 24, 2012 at 11:28 AM, David Kastrup <dak< at >gnu.org> wrote:

FWIW, I also intend to join Wilbert's 'Nieuwe Liedboek' project, and
donate whatever I get from that project to you.

Chirst van Willegen

Re: Video recording of LilyPond talk at Chemnitz (was: Slides fromLilyPond talk at Chemnitzer Linuxtage are up)

Jonas Olson — 2012-05-24T10:51:16

tor 2012-05-24 klockan 11:28 +0200 skrev David Kastrup:

When donating, is there any mechanism in place by which funds will be
donated only if some target level is reached by all donations together?
I'm speculating people might be more comfortable when they know that
they will lose money if and only if it is precisely what makes the
difference between you working and not working on LilyPond full time.

As far as I can tell, such a mechanism isn't described in the payment
plans you suggest. The plans are clever in themselves, though. For easy
access, I quote the payment plan proposals:

        The idea is to contribute a fixed minimum, and if a specified
        target is not reached by all contributions, you contribute
        proportionally up to a cap. Of course, you are free to pick all
        three numbers yourself, but here are a few models:
        
            • [Regular] €25 per month fixed, no cap. This is the payment
        plan to pick once everything is sailing smoothly and you don’t
        want to contribute unduly much or think about it unduly much.
            • [Lifesaver] Minimum €0, cap €250 per month, monthly target
        €800. That means that if the target (which basically allows me
        to postpone my decision to work elsewhere) is reached with
        everybody’s minimum already, you are not billed. This is the
        option to pick if you don’t want to support a single person as
        much as keep the LilyPond project from losing me. You do what is
        necessary to avoid my leaving, but nothing else. Yes, it will be
        annoying if it turns out you have to pay the cap more than once,
        but it will also be annoying for me not even to afford survival
        in spite of highly qualified work.
            • [Torchbearer] Minimum €50, cap €150 per month, monthly
        target €1200. This is a model aimed at being reasonably
        comfortable for you as well as for me if everything works out.

Jonas


_______________________________________________
lilypond-user mailing list
lilypond-user< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beaming regression 2.15.39 compared to 2.14.2

Urs Liska — 2012-05-24T10:04:58

Am 24.05.2012 11:57, schrieb Toine Schreurs:
Just one comment, a question that I had several times when reading such 
reports.
Don't know if this applies here, but:
A regression is something that doesn't work in a later version and that 
has _deliberately_ worked in a previous version. I.e. something that has 
once been fixed to work in that specific way.
If it just was correct and isn't anymore, it isn't considered a 
regression but just a newly introduced bug.
Best
Urs

Re: Source management tools for lilypond projects

Susan Dittmar — 2012-05-24T10:00:00

Count me in on the repository test. It's not urgent for me, so take your
time :-)

Susan

Re: Beaming regression 2.15.39 compared to 2.14.2

Toine Schreurs — 2012-05-24T09:57:36

It apparently is different from 2.14.2, but I would not call this a
regression.

In 3/4, I would like to have 6 eights beamed together, but if any
rests are involved, the beaming should be per quarter in order to
preserve the 3-beat character. In:

\relative c'' {
   \time 3/4
    r4 r8 c c c
 }

the default beaming in 2.14.2 gives an impression of a 2-beat, which should
be avoided.

Toine Schreurs

Re: Source management tools for lilypond projects

Urs Liska — 2012-05-24T09:37:37

Am 24.05.2012 10:57, schrieb Colin Hall:
Hi all,
I was just busy writing to express my gratitude for all this input.
By now I think I have acquired enough information to be contented. So 
while still being interested in reading anything more, I'd say nobody 
_needs_ to give more of his/her time.

I have for some time now being decided to go for working with git.
But I won't make any experiments with our current project. This project 
triggered my thinking about this subject - but as we're rapidly approach 
the publication date, and we're in this case only two people having to 
keep the integrity of the project, it will work the way we started. And 
it's way too late to try out fundamental changes ...

I have a project in mind which will become my first bigger experience 
with a git repository: an open library with many tools and concepts we 
developed during the project (including quite some very clever coding we 
profited from on this list and bug-lilypond). But I will only start to 
think of it when the current project is ready.

And now to your idea, Colin: I find this is a very good idea.
For me personally this would be an opportunity to make sure I'm already 
on the right track when starting the library project. And to get 
feedback and discussion on the way.
I would suggest documenting such an experiment, so it will become useful 
for others.
And I suggest to set the ground 'privately' (say: we four) and then open 
it up for others from the list so we have more contributors and thus 
more 'potential' of collisions.

I suggest that I will come back to you privately when our current 
edition is finished. I would then setup a free github account, and we 
would start thinking about what to do concretely.
If anyone wants to start right now, then of course: do. But I probably 
won't be very active until mid/end June.
And (I stated already, but maybe I should repeat this here: I don't have 
any practical experience with versioning systems (although I'm surely 
'techy' enough to get it quickly ...))

This experiment could well also serve as a pre-test for a larger idea 
that I have in mind (maybe for 2013): I would like to do a 'public 
experiment' on how fast and efficient we can collaboratively produce a 
large score - thanks to the text based approach. I'd like to do this as 
a proof-of-concept project to promote some of LilyPond's qualities to a 
wider target group ...
Imagine a large symponic movement (or possibly something oratoric) from 
the end of the 19th century (so it's in the public domain) of 10 
minutes. If we'd have 20 contributors, each dealing with one or two 
parts, it should grow very speedily, documented through daily builds. 
Maybe we could even find something that we can produce as a first 
edition, which would give us quite some attention in the scholarly world 
of music edition (furthermore: this _could_ generate money for the 
development of Lilypond - provided one agrees upon not to give the 
result to the public domain. One could for example make a score freely 
available but keep the performance rights (an editor of a first edition 
can hold the performance rights for 25 years, the royalties are similar 
to those of the copyright of a composer). But that's nothing do discuss 
already now ... ).

[
This is one of my goals on a grander scale: convince as many editors as 
possible of LilyPond's qualities and potential (therefore the mentioned 
library also stresses concepts in that direction (support of editorial 
annotations, in-source communication or -documentation. And I have some 
more ideas that can't be quickly hacked but might hopefully be realized 
in the future: Support for pdf layers, a script that extracts 'critical 
comments' from the sources ...)).
If responsible editors, say of Critical Editions start getting convinced 
of LilyPond, it may increase the pressure on the publishers to slowly 
tolerate the use of LilyPond. I won't say I have influence in this area, 
but I will definitely do some lobbying with a few important Complete 
Editions and also universities ...
]

Best
Urs

Re: Grace Note Thickness

Xavier Scheuer — 2012-05-24T09:30:10

On 24 May 2012 10:39, Pierre Perol-Schneider
<pierre.schneider.paris< at >gmail.com> wrote:

Hi Pierre, Thomas, dear LilyPond users,

Could you please make sure you do not cross-post your messages to the
French users mailing list (lilypond-user-fr)?

I think it's a fair policy to have only messages in French there and
keep the ones in English on the international mailing lists only.
If some French users want to know what's going on in the LilyPond
worldwide community they can (and usually do) subscribe to the
international mailing lists.

Pierre, if you have some nice tips you learned from the international
mailing lists and that you want to share with the French community,
please feel free to send it in French to lilypond-user-fr.

Thank you in advance.

Cheers,
Xavier

Video recording of LilyPond talk at Chemnitz (was: Slides fromLilyPond talk at Chemnitzer Linuxtage are up)

David Kastrup — 2012-05-24T09:28:26


And now the video recordings are online as well.  Same URL.

For those interested in the more hands-on details, I start talking about
some notational problems of the accordion at 16:00 (at which time
approximately I demolish the microphone with detrimental effects on the
sound quality of the talk), and there are a few measures of
semi-coordinated (usually I don't play this instrument standing up, and
not sight-reading from a laptop screen) playing and singing (old Bach,
avoiding copyright issues) at about 24:00.

I mention funding problems for my work at the end of the talk.  It turns
out that this month has dropped so far in one-time monetary
contributions compared to the rather slow uptake of regular
contributions that the minimal amount for being able to afford housing,
eating, and health insurance will likely be missed significantly.  So
I'll have to pitch in again from my private savings, and they are not
excessive.  If the situation does not rise to the level of at least bare
life support soonish, I will not be able to afford working on LilyPond
any more.  Read the gist of the story at
<URL:http://news.lilynet.net/?The-LilyPond-Report-24&lang=en#an_urgent_request_for_funding>
and successive LilyPond Report issues for my reports on the success of
my request.

Enjoy!

Re: Source management tools for lilypond projects

Colin Hall — 2012-05-24T08:57:15

On Thu, May 24, 2012 at 01:24:11PM +0800, James Harkins wrote:

Yes, it does, especially if there are clear boundaries between the
responsibilities of the contributors. This seems to be the case for
Urs, and probably a lot of lilypond projects, and my introduction of
the build token idea was not a useful contribution. Sorry for that.


Agreed.

How about Urs, Susan, you and I collaborating on a one-page score via github as a way of confirming our understanding, and demonstrating how it can be done? Even a few staves would be enough to confirm a suitable workflow.

Keep it very simple. Something that any of us could write in thirty minutes, say, on our own, but share the work via git.

Cheers,
Colin.

Re: Grace Note Thickness

Pierre Perol-Schneider — 2012-05-24T08:39:34

I just ment that I've change the beam-thickness in the graceSettings file.
Sorry for the missunderstanding and for my poor english. :S

Pierre

2012/5/23 Thomas Morley <thomasmorley65< at >googlemail.com>

_______________________________________________
lilypond-user mailing list
lilypond-user< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Ugly default note spacing in single staff polyphony

Nick Payne — 2012-05-24T07:48:10

In the following, to look correctly positioned, the final A in the bar 
needs to be moved slightly to the right relative to the notes in the 
other voice each side of it. I tried moving the note to the right using 
\override NoteColumn #'force-hshift, but that didn't move the note. What 
can I use? I think it needs to go about half a staff space to the right, 
without increasing the spacing between the C notes in the other voice.

\version "2.15.39"

\relative c'' {
     \time 3/4
<<
         { r8 c4 c c8 r c4 c c8 }
         \\
         { a,4 a' a' a,, a' \once \override NoteColumn #'force-hshift = 
#0.5 a' }
 >>
}

Nick
_______________________________________________
lilypond-user mailing list
lilypond-user< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Directed \tweak commands in 2.15.39

Janek Warchoł — 2012-05-24T07:06:57

Hm.  Maybe you are right.

--
Janek

_______________________________________________
lilypond-user mailing list
lilypond-user< at >gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Directed \tweak commands in 2.15.39

David Kastrup — 2012-05-24T07:00:58


And it would still be mostly trivial to adapt existing documentation.
If someone were to write a book about using LilyPond (and our docs are
not really anything but that), and then GLISS came along: you think he
would scrap the book and start fresh?  No, you'd get "Using LilyPond --
2nd edition".  Perhaps new chapters, and adjustments in some existing
chapters.

Using GLISS as an excuse for keeping the documentation in abysmal state
is far too cheap and it does not at all make sense.  In particular since
good and/or efficient documentation writers tend to be different people
than good and/or efficient programmers, and good documentation draws
both into participating with the project, making things progressively
smoother.