Re: Variable systems-per-page only on last page?

[David F.]

That doesn’t work for me.  (Lilypond 2.19.58)  I’ve got 3 bars at the end of a 
piece that would comfortably fit on a single line, but they are stretched to 
fill two lines.

David

On Sep 9, 2017, at 7:38 PM, Kieren MacMillan  wrote:

> Hi David,
> 
>> Is there a way to tell Lilypond to put 2 systems per page on all pages 
>> except the last—the last page can have one or two systems, depending on 
>> whichever fits best?
> 
> 1. It would be great if there was some consistent way to tell Lilypond to 
> consider the first and last page separately from the rest of the score, for 
> layout purposes — as far as I know, there's no such thing.
> 
> 2. If you use ragged-last-bottom = ##t, then systems-per-page = 2 should do 
> what you want. Does that not work for you?
> 
> Cheers,
> Kieren.
> 
> 
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 


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

Re: Variable systems-per-page only on last page?

[Kieren MacMillan]

Hi David,

> Is there a way to tell Lilypond to put 2 systems per page on all pages except 
> the last—the last page can have one or two systems, depending on whichever 
> fits best?

1. It would be great if there was some consistent way to tell Lilypond to 
consider the first and last page separately from the rest of the score, for 
layout purposes — as far as I know, there's no such thing.

2. If you use ragged-last-bottom = ##t, then systems-per-page = 2 should do 
what you want. Does that not work for you?

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Variable systems-per-page only on last page?

[David F.]

Is there a way to tell Lilypond to put 2 systems per page on all pages except 
the last—the last page can have one or two systems, depending on whichever fits 
best?

Thanks,
David


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

Re: notes regex expression

[Simon Albrecht]

On 09.09.2017 16:17, David Kastrup wrote:

David Wright  writes:


Would it be worth looking at how ly (in Python I believe) parses
LilyPond code?

What is ly ?


The command line tool aka python-ly that has been made available 
separately from Frescobaldi.


Best, Simon

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

Re: Is there a way to circle around tab numbers?

[Devin Ulibarri]

Stephen MacNeil:
> you could just change it to tab

Thanks, this is helpful.

If possible, I would like some more information about how to tweak the
output.

* Is it possible to make the space within the circle opaque, but without
hiding the number (just hiding the tab line)? If so, how is this done?

(I could do this in Inkscape, but would rather automate it if possible)

Thanks!
Devin

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

Re: notes regex expression

[David Kastrup]

David Wright  writes:

> On Fri 01 Sep 2017 at 14:44:53 (+0200), Gianmaria Lari wrote:
>> Salut Jacques!
>> 
>> I don’t have any experience with C# programming, but maybe the Flex and
>> > Bison specifications that are part of the LilyPond  source code could be
>> > integrated within a C# application?
>> > This would provide a full and usable scanner and parser.
>> >
>> 
>> This would open interesting possibilities but I had a look online and
>> for what I understood recycling Flex/Bison specification to generate c#
>> code would not be trivial.
>> At the moment I prefer doing something simpler but I will check better in
>> the future.
>
> Would it be worth looking at how ly (in Python I believe) parses
> LilyPond code?

What is ly ?

-- 
David Kastrup

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

Re: Understanding how \tag works in \relative pitched music

[David Kastrup]

David Wright  writes:

[...]

>> >> Now make-relative is a convenient but quite heavy-handed macro.
>> >> There are situations where it fails, and then it does so
>> >> spectacularly.
>> >> 
>> >> The reason is that it allows creating a more natural "user
>> >> experience" by a totally unnatural and complex actual inner
>> >> operation that has to be defined individually for each music
>> >> function written by the programmer.
>> >
>> > Hey, programming's hard. Glad I'm retired.
>> 
>> It's not that programming is hard but that the concept of \relative
>> does not map well to music functions or other forms of rearranging
>> input since the user expectation with regard to \relative is focused
>> on input order rather than music expression internal order.
>> 
>> In fact, the mess \relative creates was such that issue 2240
>> (changing the music expression internals, various followup issues)
>> was necessary for fixing chord repetition in \relative mode, in order
>> to have issue 2263 for fixing the long-standing issue 1110.
>> 
>> Issue 2240 and all of the followup work took several months of work,
>> and \relative has intervened for additional work several times.  The
>> "Hey, programming is hard.  Glad I'm retired." attitude coupled with
>> the expectation that some sucker is going to do it because you won't
>> is actually pretty offensive considering on how little money I had
>> and have to get by for making such actually inherent problems mostly
>> go away.  What kind of retirement entitles you to have me and other
>> programmers make LilyPond work according to your expectations?
>
> I honestly hadn't realised that, when considering the design and
> documentation of a language construction, one should take into
> consideration the finances of a person who has decided to implement
> it.

[...]

> Now I'm retired, I'm happy to be a user of other people's software,
> and the programming I do is limited pretty much to scripting in bash
> and python on linux, for convenience rather than necessity. The
> pressure's off for me; what's wrong with that? I don't see why you
> should try to make me feel any shame in being retired.

You could stop the gloating.  I don't think you would like to get by
with the kind of payment I get for my programming, so expressing your
opinion that it's time for others to do the programming because you made
enough doing so to be able to retire is not exactly enjoyable to hear.

>> We have warnings in the manual exactly because users in general find
>> the interaction of \relative and the \tag-related commands
>> surprising.  If you lecture users on the same questions year after
>> year after, at some point you ask yourself where the point in being
>> right is when it is so much trouble.
>
> So much trouble for whom?

For the ones having to hand out the same information time and again.

>> So what do you think
>> 
>> \fixed a'' { c d e f g a b c' }
>> 
>> should map to?
>
> Could, not should.
>
> \absolute { c'' d''' e''' f''' g''' a'' b'' c''' }

Where does the discontinuity between c'' and d''' come from?  You
probably mean

\absolute { c''' d''' e''' f''' g''' a'' b'' c }

>> Maybe
>> 
>> \absolute { c' d' e' f' g' a'' b'' c'' }
>> 
>> ?  So as the argument to \fixed rises, the result gets lower until the
>> octave jumps and then it gets higher?  That's sort-of discontinuous.
>> The continuous result would be
>> 
>> \absolute { c'' d'' e''' f''' g''' a''' b''' c''' }
>> 
>> but you can't really make anybody cheer for that as a user interface
>> even though it would be logical.  So you are likely rooting for the
>> discontinuous approach.

I have no idea actually how either proposal of mine is supposed to make
any sense, so it seems like a concept rather hard to get right.  But
then neither does yours.

> Under a definition I described earlier, \fixed a'' { c d e f g a b c' }
> wouldn't be an octave scale, because the point in a written scale
> where a prime or comma needs to added or removed would be the
> transition between g-a, not b-c. So a scale on c'' would be written
>
> \fixed a'' { c d e f g a' b' c' }

That would be a scale on c''' since it would contain a''' .  See how
_confusing_ this scheme is?

You haven't managed to get a single example consistent/right, and
neither have I on first try.

That's what makes it a bad idea.

> (I've added the x here in case anyone were to read this paragraph later,
> in isolation from the above discussion.)
>
> \fixedx c'' { f, g, a, b, c   d   e   f   g   a   b   c'   d'   e'   f' }
> \absolute {   f' g' a' b' c'' d'' e'' f'' g'' a'' b'' c''' d''' e''' f''' }
>   ↑
>
> \fixedx a' { b, c, d, e, f, g, a  b  c   d   e   f   g   a'  b'  c'   d' }
> \absolute {  b  c' d' e' f' g' a' b' c'' d'' e'' f'' g'' a'' b'' c''' d''' }
>↑
>
> \fixedx fis' { b, c, d, e, f  g  a  b  c   d   e   f'  g'  a'  b'  c'   d' }
> \absolute {b  c' d' e' f' g' 

Re: notes regex expression

[David Wright]

On Fri 01 Sep 2017 at 14:44:53 (+0200), Gianmaria Lari wrote:
> Salut Jacques!
> 
> I don’t have any experience with C# programming, but maybe the Flex and
> > Bison specifications that are part of the LilyPond  source code could be
> > integrated within a C# application?
> > This would provide a full and usable scanner and parser.
> >
> 
> This would open interesting possibilities but I had a look online and
> for what I understood recycling Flex/Bison specification to generate c#
> code would not be trivial.
> At the moment I prefer doing something simpler but I will check better in
> the future.

Would it be worth looking at how ly (in Python I believe) parses
LilyPond code?

Cheers,
David.

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

Re: Understanding how \tag works in \relative pitched music

[David Wright]

On Mon 07 Aug 2017 at 22:33:12 (+0200), David Kastrup wrote:
> David Wright  writes:
> 
> > Neither do I. But the post I was commenting on was constructing an
> > Aunt Sally argument, "the unpredictability of \relative with \tag"
> > as a reason to make the change.
> 
> Maybe "unpredictability" was not the best expression.  It's clear that
> Kieren was referring not to non-deterministic but surprising behavior.
> 
> The truth is that \relative does not interact with \tag at all.  But
> that means that you get different results for
> 
> \relative \keepWithTag ...
> 
> and
> 
> \keepWithTag ... \relative
> 
> because then \relative gets to work with different material.

Whether that's a useful distinction, I wouldn't know. I can
see the point of having \tags mixed in with \relative sections
as in the OP's example. I can't see the point in mixing
\relative with \score and \staff constructions, particularly
when they contain commands such as \keepWithTag, except as
an exercise in regression testing or, possibly, obfuscation.

But in any case, if someone is surprised by the behaviour of a
particular construction, one that they are determined to use, then it
behoves them to find out in more depth how it behaves and/or examine
their expectations and whether they are justified.

The flexibility of LP's syntax certainly allows one to obscure
what the final interpretation will be. But it's hardly unique
in that respect.

> > Well, that's what I tried to do by removing the parts of the code
> > that had no bearing on \relative's behaviour but (a) were obscuring
> > the simple relation of the note pitches being input and (b) were
> > believed erroneously by the OP to have some influence on the pitches
> > of those notes.
> 
> At some point of time we have to acknowledge that people and humans are
> wired differently.  The difference might not be all that large when
> looking at me but then you would likely not want to reduce composers to
> that kind of crop.  So it's important to be able to cater to people with
> differing capability of in-depth understanding of mathematical and/or
> programming logic.
> 
> >> So he has
> >> all the necessary information for considering and/or trying and/or
> >> rejecting such a switch.
> >
> > Oh come on. There are contributors here whose words carry far more
> > weight than many of us, and with good reason. Their posts get pasted
> > into archives and consulted later, so their accuracy is all the more
> > important.
> 
> "Accuracy" is not the same as "agrees with David", actually for any
> value of David.

I'm not sure why you focus on "David"s.

> >> \fixed is also pretty good at minimizing fly-shit.  It becomes worse
> >> in that regard for stuff with widely navigated ranges,
> >
> > Agreed. And I was just expressing how it might have been better,
> > in my opinion. As it is, I gain nothing over \relative so I
> > haven't used it.
> 
> That's fine, and you are free to express this opinion just as Kieren is
> free to express his.

Thank you.

> And you have harped over it a lot longer than he
> has.

Both of us are good at splitting a paragraph and commenting on each
part, just as I've done here.

> > But I'm not trying to dissuade anyone from using \absolute and, now,
> > \fixed. In fact, I was contradicted when I expressed an opinion that
> > it would be difficult to _compose_ directly into anything other than
> > \absolute because of all the cutting and pasting involved.
> 
> It's a contrarian list and it doesn't help that I am an active
> participant.

Evidently.

> >> >> It doesn't do that impressively when communicating with other
> >> >> programs, so its main incentive is communication with humans.
> >> >> When humans are confused about what it does, it fails on one of
> >> >> the core tenets of its justification.
> >> >
> >> > That argument fails because not all humans are the same.
> 
> All humans are the same as themselves, and most LilyPond users are
> themselves the most relevant human reader of the LilyPond source they
> write.
> 
> Of course humans are capable of learning to navigate any amount of
> complexity with enough determination, like they can learn to play bad
> instruments well.  But if you find in the long run that fighting your
> instrument is becoming a major drain of your focus and thus is taking
> resources better invested elsewhere, improving or changing your
> instrument might be smarter than trying to become smarter.

I can't see a connection between this and the decision whether to
employ \relative, \fixed or \absolute to define some notes in LP.

> > I didn't say that. I said that you haven't shown it fails on one of
> > the core tenets of its justification merely because some humans have
> > difficulty learning/understanding/retaining the concept.
> 
> It fails for them.  Whether fixing that makes sense is up to them.
> 
> >> Now make-relative is a convenient but quite heavy-handed macro.
> >> There are 

Re: Slur position

[Mario Moles]

UH!

Great!

Thank you so match!


Il 09/09/2017 10:06, David Kastrup ha scritto:

Mario Moles  writes:


Do you know how to make this slur?

Well, the input looks like a smiley parade, but it sort-of works:



What is irritating, though, is that replacing "^-" with "--" will result
in a complete messup.

Basically, you can tell LilyPond what you want it to do but its
execution leaves something to be desired: it shows that this feature was
implemented by a frontend guy with no backend guy fixing up the results.



--

oiram/bin/selom

Da ognuno secondo le proprie capacità ad ognuno secondo i propri bisogni.

MIB-kernellinux-tester

Linux 

MIB Lilypond 
Frescobaldi 
Rosegarden 


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

Re: Slur position

[David Kastrup]

Mario Moles  writes:

> Do you know how to make this slur?

Well, the input looks like a smiley parade, but it sort-of works:

\version "2.19.60"
\fixed c'
{
  \time 6/8
  8^-\arpeggio
  b a)
}

What is irritating, though, is that replacing "^-" with "--" will result
in a complete messup.

Basically, you can tell LilyPond what you want it to do but its
execution leaves something to be desired: it shows that this feature was
implemented by a frontend guy with no backend guy fixing up the results.

-- 
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Slur position

[Mario Moles]

Hi lilyponders!

Do you know how to make this slur?

Thanks!

--

oiram/bin/selom

Da ognuno secondo le proprie capacità ad ognuno secondo i propri bisogni.

MIB-kernellinux-tester

Linux 

MIB Lilypond 
Frescobaldi 
Rosegarden 


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