Re: simple scheme in lilypond

2018-11-27 Thread Gianmaria Lari
Thank you Jan, very clear.
g.

On Tue, 27 Nov 2018 at 11:48, Jan-Peter Voigt  wrote:

> Hello,
>
> the $ sign has a special meaning of "instant scheme-expression". An
> instant scheme expression is evaluated instantly *and* the result is
> observed so that lilypond can decide what to do with it. When lily
> receives something that can be treated as a markup from an instant
> scheme expression it is handled like \markup {}. But a pure string is
> not a core lily-expression like music or markup. Thats the reason (3)
> fails with an error. The result of a plain scheme-exression introduced
> with # is simply ignored in root context.
>
> HTH
> Jan-Peter
>
>
> Am 27.11.18 um 09:14 schrieb Gianmaria Lari:
> > Probably these are very trivial things. Sorry to ask them but would like
> > to understand.
> >
> > If I write (1):
> >
> >
> > \version "2.19.82"
> > $(object->string (+ 3 2))
> >
> >
> > Lilypond is happy and compile to a pdf file showing "5".
> >
> > Even this simpler code works... (2)
> >
> > \version "2.19.82"
> > $"Hello"
> >
> >
> > and generate a pdf file showing "Hello".
> >
> > It is clear to me that $ introduce a scheme expression that is
> > evaluated. And in the previous two examples the scheme code is evaluated
> > to strings. But I don't understand why lilypond outputs them. If I write
> > (3):
> >
> > \version "2.19.82"
> > "Test"
> >
> >
> > this does not compile. So I would think that the "correct" code to
> > output evaluated expression in the pdf file should be (4)
> >
> >
> > \version "2.19.82"
> > \markup $(object->string (+ 3 2))
> >
> >
> > or this (5)
> >
> > \version "2.19.82"
> > \markup $"Hello"
> >
> >
> > Why the behaviour of (1) and (2) ?
> >
> > * * *
> >
> > I tried to rewrite (1) and (2) with the hash mark instead of dollar (6):
> >
> > \version "2.19.82"
> > #(object->string (+ 3 2))
> >
> >
> > and (7):
> >
> > \version "2.19.82"
> > #"Hello"
> >
> >
> > This time, there is no output in the pdf file. Why this difference?
> >
> > Thank you, g.
> >
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> >
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Protecting against page breaks in markup

2018-11-27 Thread Flaming Hakama by Elaine
> -- Forwarded message --
> From: Richard Shann 
> To: lilypond-user 
> Cc:
> Bcc:
> Date: Tue, 27 Nov 2018 15:20:04 +
> Subject: Protecting against page breaks in markup
> I'm creating an index to my scores, in the form of a sequence of
> LilyPond markups (for title, composer, first few bars etc).
> It is working well apart from page breaking which can occur mid-entry.
> Is there a way of turning page breaks off and back on around each
> entry?
>
> Richard Shann


When pagination gets hairy, I use \autoPageBreaksOff, and then manually put
in all page breaks using \pageBreak


HTH,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: No lyric extenders for RhythmicStaff if music comes from a variable

2018-11-27 Thread Werner LEMBERG


> Well, to summarize:
> 
> In less than an hour after posting a question / potential bug
> report, there is
> 
> - a quick & easy solution provided by an experienced fellow user,
> 
> - an explanation and some perspective from the main developer
>   working on that part of the code.
> 
> Unbeatable.  And on top of this, the excellent quality that LilyPond
> produces (which is often remarked upon by students & colleagues that
> see my worksheets containing lots of Lilypond music examples).  It's
> simply wonderful to work with this program - thanks so much!

Hear, hear!  And yes, great kudos to all the helpful guys on this
list!


Werner

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


Re: No lyric extenders for RhythmicStaff if music comes from a variable

2018-11-27 Thread Lukas-Fabian Moser




Some curly braces seem to help:


\new RhythmicStaff { \Melodie \addlyrics { Once there was a way __ } }


Using \displayMusic shows that use of the variable versus the explicit
\relative produces a different S-expression, but I am not sure where
the fault lies.

I never managed to get the parser to group \addlyrics just with the
desired expressions.  Operator priorities for shift/reduce conflict
resolution are hard to get right, and this is the major case where I did
not manage even though there are several issues and patches trying to
fix it.


Well, to summarize:

In less than an hour after posting a question / potential bug report, 
there is


- a quick & easy solution provided by an experienced fellow user,

- an explanation and some perspective from the main developer working on 
that part of the code.


Unbeatable. And on top of this, the excellent quality that LilyPond 
produces (which is often remarked upon by students & colleagues that see 
my worksheets containing lots of Lilypond music examples). It's simply 
wonderful to work with this program - thanks so much!


Best
Lukas



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


Re: No lyric extenders for RhythmicStaff if music comes from a variable

2018-11-27 Thread David Kastrup
Aaron Hill  writes:

> On 2018-11-27 1:22 pm, Lukas-Fabian Moser wrote:
>
>> \version "2.19.80"
>>
>> Melodie = \relative g' {
>>     g8 16 16 16 8.~  4 r
>> }
>>
>> \new Staff \Melodie \addlyrics { Once there was a way __ }
>>
>> \new RhythmicStaff \Melodie \addlyrics { Once there was a way __ }
>>
>> \new Staff \relative g' { g8 16 16 16 8.~  4 r }  \addlyrics { Once
>> there was a way __ }
>>
>> \new RhythmicStaff \relative g' { g8 16 16 16 8.~  4 r } \addlyrics {
>> Once there was a way __ }
>>
>> As can be seen, the second example does not contain the Lyric
>> extender. Why is this so, and how can I get it back? (True for 2.19.80
>> as well as not-so-current master from a few weeks/months ago.)
>
> Some curly braces seem to help:
>
> 
> \new RhythmicStaff { \Melodie \addlyrics { Once there was a way __ } }
> 
>
> Using \displayMusic shows that use of the variable versus the explicit
> \relative produces a different S-expression, but I am not sure where
> the fault lies.

I never managed to get the parser to group \addlyrics just with the
desired expressions.  Operator priorities for shift/reduce conflict
resolution are hard to get right, and this is the major case where I did
not manage even though there are several issues and patches trying to
fix it.

-- 
David Kastrup

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


Re: No lyric extenders for RhythmicStaff if music comes from a variable

2018-11-27 Thread Aaron Hill

On 2018-11-27 1:22 pm, Lukas-Fabian Moser wrote:

Dear list,

consider:

\version "2.19.80"

Melodie = \relative g' {
    g8 16 16 16 8.~  4 r
}

\new Staff \Melodie \addlyrics { Once there was a way __ }

\new RhythmicStaff \Melodie \addlyrics { Once there was a way __ }

\new Staff \relative g' { g8 16 16 16 8.~  4 r }  \addlyrics { Once
there was a way __ }

\new RhythmicStaff \relative g' { g8 16 16 16 8.~  4 r } \addlyrics {
Once there was a way __ }

As can be seen, the second example does not contain the Lyric
extender. Why is this so, and how can I get it back? (True for 2.19.80
as well as not-so-current master from a few weeks/months ago.)


Some curly braces seem to help:


\new RhythmicStaff { \Melodie \addlyrics { Once there was a way __ } }


Using \displayMusic shows that use of the variable versus the explicit 
\relative produces a different S-expression, but I am not sure where the 
fault lies.


-- Aaron Hill

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


No lyric extenders for RhythmicStaff if music comes from a variable

2018-11-27 Thread Lukas-Fabian Moser

Dear list,

consider:

\version "2.19.80"

Melodie = \relative g' {
    g8 16 16 16 8.~  4 r
}

\new Staff \Melodie \addlyrics { Once there was a way __ }

\new RhythmicStaff \Melodie \addlyrics { Once there was a way __ }

\new Staff \relative g' { g8 16 16 16 8.~  4 r }  \addlyrics { Once 
there was a way __ }


\new RhythmicStaff \relative g' { g8 16 16 16 8.~  4 r } \addlyrics { 
Once there was a way __ }


As can be seen, the second example does not contain the Lyric extender. 
Why is this so, and how can I get it back? (True for 2.19.80 as well as 
not-so-current master from a few weeks/months ago.)


Best
Lukas

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


Re: Protecting against page breaks in markup

2018-11-27 Thread Thomas Morley
Am Di., 27. Nov. 2018 um 16:22 Uhr schrieb Richard Shann
:
>
> I'm creating an index to my scores, in the form of a sequence of
> LilyPond markups (for title, composer, first few bars etc).

What exactly are you doing? An example would be nice.

> It is working well apart from page breaking which can occur mid-entry.
> Is there a way of turning page breaks off and back on around each
> entry?

Well, of course you know about \noPageBreak and \pageBreak.

Probably you can wrap a \column around all the single markups. At
least page-break can then only happen before or after the whole
thingy.
Depends on what you actually (want to) do.

Cheers,
  Harm

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


Re:v2.19.82 documentation unusable? (Aaron Hill)

2018-11-27 Thread Cynthia Karl
> On Nov 24, 2018, at 9:51 AM,Aaron Hill  wrote:
> 
> 
> Message: 1
> Date: Fri, 23 Nov 2018 10:34:39 -0800
> From: Aaron Hill 
> To: lilypond-user@gnu.org
> Subject: Re: v2.19.82 documentation unusable?
> Message-ID: <3cf7a16e59434b69a91678193e225...@hillvisions.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> On 2018-11-23 7:30 am, David Kastrup wrote:
>> Patrick Karl  writes:
>> 
>>> I thank everyone for the replies.  I?ll just wait till it?s fixed.
>>> 
>>> I tried to find a version of Emmentaler-20 I could install on my mac,
>>> but had no luck.  Is that a way out?  I have to admit that fonts are
>>> pretty much a black hole for me.
>> 
>> PDF files should embed every font they contain.  If you have to install
>> external fonts for viewing them, something is broken.  Try using the
>> documentation files of 2.19.81 instead.
> 
> Since the issue is that fonts are not embedded, I wondered if the 
> solution is as simple as embedding them after the fact.  The important 
> missing fonts in question are shipped with LilyPond, so then it was 
> matter of looking online for a little bit of GhostScript:
> 
> gs -o path-to-fixed.pdf \
>   -sDEVICE=pdfwrite -dEmbedAllFonts=true \
>   -sFONTPATH="path-to-fonts" \
>   path-to-broken.pdf
> 
> On my system, "path-to-fonts" would be:
> 
> /usr/local/lilypond/usr/share/lilypond/current/fonts/otf/
> 
> Running the command against all of the 2.19.82 PDFs from the web site, 
> the results are a significant improvement.  There were only a few 
> substitutions due to additional missing fonts, but those are largely 
> irrelevant (i.e. "LuxiMono" used as an example of overriding the 
> typewriter font).
> 
> Something for folks to consider to tide us over until the next release.
> 
> -- Aaron Hill
> 
On my mac I had to do:

GS_LIB=/Applications/LilyPond.app/Contents/Resources/share/ghostscript/9.21/Resource/Init
 
export GS_LIB

or gs would not execute due not being able to find gs_init.ps.  I tried to use 
“-x” with the above path but gs didn’t recognize the “-x”. Also, 
“path-to-fonts” on my system was:

/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/fonts/otf

I have run your command on changes.pdf, and it seems to have fixed the problem.

Thanks to all for their comments.  I wonder if there might be some new users 
(or old) that tried v2.19.82 and ran into this problem and got frustrated.  
Maybe it would be helpful to delete the English versions of the v2.19.82 
manuals from the lilypond.org site, possibly with a note to use the v2.19.81 
versions, at least until a new version of lilypond without this problem comes 
out.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Enabling Frescobaldi to load external extensions

2018-11-27 Thread Urs Liska
I have (finally) started to work towards making it possible to extend 
Frescobaldi with extensions. I have opened a Pull Request at 
https://github.com/wbsoft/frescobaldi/pull/1129 and invite anyone 
interested in looking at and discussing it. Probably this is mostly 
accessible for people who can look at the Python, but there may also be 
some usability aspects that would benefit from general, user-perspective 
discussion. A heavily commented sample extension can be found at 
https://github.com/frescobaldi-extensions/sample-extension, and at some 
point there will be a tutorial on that repository's Wiki pages.


If my basic approach is accepted by the other developers this will allow 
the creation of very simple Python packages that can be loaded as 
extensions in Frescobaldi. They will have access to the whole 
functionality that is available within Frescobaldi, but of course using 
this will require the knowledge, so it won't be trivial for everybody to 
create their own extensions (but it'll be a simpler task than it is now 
to find *someone* to create extensions, e.g. as a commission). What I've 
found so far (which was one of the motivations to actually do something) 
is that Frescobaldi is a perfect environment to place some project 
management GUIs into, which the extension API will make much simpler.


Urs


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


Protecting against page breaks in markup

2018-11-27 Thread Richard Shann
I'm creating an index to my scores, in the form of a sequence of
LilyPond markups (for title, composer, first few bars etc).
It is working well apart from page breaking which can occur mid-entry.
Is there a way of turning page breaks off and back on around each
entry?

Richard Shann


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


Re: simple scheme in lilypond

2018-11-27 Thread David Kastrup
Gianmaria Lari  writes:

> Probably these are very trivial things. Sorry to ask them but would like to
> understand.
>
> If I write (1):
>
>
> \version "2.19.82"
> $(object->string (+ 3 2))
>
>
> Lilypond is happy and compile to a pdf file showing "5".
>
> Even this simpler code works... (2)
>
> \version "2.19.82"
> $"Hello"
>
>
> and generate a pdf file showing "Hello".
>
> It is clear to me that $ introduce a scheme expression that is evaluated.
> And in the previous two examples the scheme code is evaluated to strings.
> But I don't understand why lilypond outputs them. If I write (3):
>
> \version "2.19.82"
> "Test"

blabla = "Test"
##f
\blabla

will compile again (sorry for the ##f : it is necessary to defeat
lookahead).  It is indistinguishable from

blabla = \markup "Test"
##f
\blabla

in output and in its effect on the variable.  Basically, $x and \x are
the same (apart from the characters allowed in and after x).  The
logical thing would be to permit "Test" on its own but it appears rather
error-prone.  This is similar to

blabla = c4
##f
\blabla

compiling and producing a result while

c4

on its own doesn't.

> I tried to rewrite (1) and (2) with the hash mark instead of dollar (6):
>
> \version "2.19.82"
> #(object->string (+ 3 2))
>
>
> and (7):
>
> \version "2.19.82"
> #"Hello"
>
>
> This time, there is no output in the pdf file. Why this difference?

At the top level of the file, assignments and assignment-like statements
may be executed.  The return value of an assignment in Scheme is
unspecified.  There are things like

#(set! (hashq-ref x y) z)

that somewhat inscrutably return an actual value other than
*unspecified*.  For that reason, # expressions in contexts where
assignments are allowed are evaluated and ignored.  Use $ if you want
them to be heeded.

-- 
David Kastrup

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


Re: simple scheme in lilypond

2018-11-27 Thread Jan-Peter Voigt
Hello,

the $ sign has a special meaning of "instant scheme-expression". An
instant scheme expression is evaluated instantly *and* the result is
observed so that lilypond can decide what to do with it. When lily
receives something that can be treated as a markup from an instant
scheme expression it is handled like \markup {}. But a pure string is
not a core lily-expression like music or markup. Thats the reason (3)
fails with an error. The result of a plain scheme-exression introduced
with # is simply ignored in root context.

HTH
Jan-Peter


Am 27.11.18 um 09:14 schrieb Gianmaria Lari:
> Probably these are very trivial things. Sorry to ask them but would like
> to understand.
> 
> If I write (1):
> 
> 
> \version "2.19.82"
> $(object->string (+ 3 2))
> 
> 
> Lilypond is happy and compile to a pdf file showing "5".
> 
> Even this simpler code works... (2)
> 
> \version "2.19.82"
> $"Hello"
> 
> 
> and generate a pdf file showing "Hello".
> 
> It is clear to me that $ introduce a scheme expression that is
> evaluated. And in the previous two examples the scheme code is evaluated
> to strings. But I don't understand why lilypond outputs them. If I write
> (3):
> 
> \version "2.19.82"  
> "Test"
> 
> 
> this does not compile. So I would think that the "correct" code to
> output evaluated expression in the pdf file should be (4)
> 
> 
> \version "2.19.82"
> \markup $(object->string (+ 3 2))
> 
> 
> or this (5)
> 
> \version "2.19.82"
> \markup $"Hello"
> 
> 
> Why the behaviour of (1) and (2) ?
> 
> * * *
> 
> I tried to rewrite (1) and (2) with the hash mark instead of dollar (6):
> 
> \version "2.19.82"
> #(object->string (+ 3 2))
> 
> 
> and (7):
> 
> \version "2.19.82"
> #"Hello"
> 
> 
> This time, there is no output in the pdf file. Why this difference?
> 
> Thank you, g.
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


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


simple scheme in lilypond

2018-11-27 Thread Gianmaria Lari
Probably these are very trivial things. Sorry to ask them but would like to
understand.

If I write (1):


\version "2.19.82"
$(object->string (+ 3 2))


Lilypond is happy and compile to a pdf file showing "5".

Even this simpler code works... (2)

\version "2.19.82"
$"Hello"


and generate a pdf file showing "Hello".

It is clear to me that $ introduce a scheme expression that is evaluated.
And in the previous two examples the scheme code is evaluated to strings.
But I don't understand why lilypond outputs them. If I write (3):

\version "2.19.82"
"Test"


this does not compile. So I would think that the "correct" code to output
evaluated expression in the pdf file should be (4)


\version "2.19.82"
\markup $(object->string (+ 3 2))


or this (5)

\version "2.19.82"
\markup $"Hello"


Why the behaviour of (1) and (2) ?

* * *

I tried to rewrite (1) and (2) with the hash mark instead of dollar (6):

\version "2.19.82"
#(object->string (+ 3 2))


and (7):

\version "2.19.82"
#"Hello"


This time, there is no output in the pdf file. Why this difference?

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