Re: Piping contents of SVG directly to stdout

[William]

Hope you won’t mind me hopping in here a little late because this sounds 
similar to a project that I was using lilypond for. My workaround is, as you 
know, spinning up a temporary directory for the output and all the extra eps 
files, run lilypond, read the output file into program memory, delete the 
temporary directory, then serve over http via the buffer in memory. 

So to answer your question, there is no way to pipe output from lilypond, but 
the IO overhead even if you’re using something like a cloud provider HDD is 
very minimal compared to how long lilypond takes to render the output (more 
time would be saved by utilizing virtual host caching for the results, for 
example)

Felix, I’m curious what you mean by cropping the file. Sounds to me like you 
are trying to just write a small snippet of music, maybe a few measures, and 
not have the output flooded by whitespace all around the size of an A4 paper? 
This is also similar to what I was using lilypond for and there are ways to do 
this without any external apps. 

Thanks,
-William

Sent from my iPhone

> On Jul 15, 2022, at 15:17, DoubleFelix  wrote:
> 
> 
> Hello,
> 
> I'm using lilypond to programmatically generate sheet music. I already have a 
> system in place to crop the SVGs, but now I need to load them in my software. 
> I could use the default behavior of letting lilypond write to some file, and 
> then reading it, but file I/O tends to be pretty expensive, especially when 
> you're doing it in bulk like I am, so I'd like to avoid that.
> 
> My question is this: Is there a way to get lilypond to write the output to 
> stdout to save on performance, or do I need to use a file as a middleman? For 
> reference, my current command is:
> "lilypond --svg --loglevel=none file.ly"
> 
> Thanks,
> Felix

Re: Piping contents of SVG directly to stdout

[Andrew Bernard]

I'd avoid WSL like the plague. It's still half hearted, terribly slow 
with various filesystems and offers no advantages that I have seen so 
far over simply putting in Virtualbox and running full blown Linux of 
your choice. This is not merely my own opinion - there are dozens of 
websites mentioning the same thing. No need to detain the list further 
with all the gory details. Microsoft is in no way committed to Linux and 
sadly it is not a glorious new era.


Andrew


On 18/07/2022 1:12 pm, DoubleFelix wrote:

So

You could also use the Windows Subsystem for Linux, which is
easy to install as far as I could hear (yes, Microsoft officially
provides an option to install Linux these days, which speaks
volumes...)

Re: Piping contents of SVG directly to stdout

[DoubleFelix]

Sorry. I think this should reply to all now. As for the example I sent,
that's the barebones type. The ones I need to generate dynamically will
have random notes and key signatures and what not. I'll try WSL though. I
didn't even think of using that. I'll give it a go and respond here if
something comes up.

On Sun, Jul 17, 2022 at 4:32 PM Jean Abou Samra  wrote:

> Again, please keep the list in the recipients. In your mail client,
> click "Reply to all", not "Reply".
>
> Le 17/07/2022 à 23:19, DoubleFelix a écrit :
> > Oh I see. I looked at compiling LilyPond, but I'm windows and it seems
> > like a pain (I have to set up some VM for a custom OS is what I got
> > from the docs).
>
>
> You could also use the Windows Subsystem for Linux, which is
> easy to install as far as I could hear (yes, Microsoft officially
> provides an option to install Linux these days, which speaks
> volumes...)
>
>
> > As for my input, it's pretty barebones:
> >
> > \version"2.22.2"
> > \language"english"
> > \header{
> > tagline = ""
> > }
> > {
> > \omitScore.TimeSignature
> > \omitScore.Rest
> > \keya \major
> > r4
> > }
>
>
> So you just want to show an image of a key signature?
>
> How about generating those images for all 15 possible
> key signatures once and for all, and never calling LilyPond
> afterwards?
>
> Jean
>
>

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

> Le 18/07/2022 à 00:44, David Kastrup a écrit :
>> Jean Abou Samra  writes:
>>
>> [Harm:]
>>
>> You are aware that you are not talking to a C++ programmer?  Not exactly
>> a motivating message under the circumstances...
>
>
>
> I learnt C++ (like many things) by pretending I was a
> C++ programmer while I wasn't, and trying to get along.

Harm is not a C programmer either.  Scheme is his only language and he
learnt it because of LilyPond.  So he has no exposure to the low-level
nature of C++, nor to the basics of imperative programming languages
that are sort of a required firm footing before you dive into the
syntactic shitshow that C++ is.

I certainly hope that he isn't as miffed at your dismissive attitude as
I am since he is one of the most important contributors coming from the
user side of LilyPond.

>> Would something like this be a reasonable patch?
>
>
> Yes, in my opinion. I actually tried to display
> the original name some time ago
> 
> but abandoned it (one of my projects for this summer
> is to introduce "grob definitions" akin to context
> definitions, which would make this possible and simple).

Ok, I'll try that.

-- 
David Kastrup

Re: Tempo arguments

[David Kastrup]

Jean Abou Samra  writes:

> Le 18/07/2022 à 00:35, David F. a écrit :
>> \tempo 4 = 90
>>
>> How is tempo able to take ‘4 = 90’ as an argument?  Is this
>> hardwired into the language or can any function take ‘x = y’ as an
>> argument?
>
> It is hardwired. Music functions cannot take arguments with '='.

Similar with \override and \set .  It would be nice to turn them into
some kind of music function, but so far I've come up short with ideas
for sensible implementation semantics.

\tempo has the additional complication that both

\tempo "Allegro"

and

\tempo "Allegro" 4 = 90

are valid commands.

-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 18/07/2022 à 00:44, David Kastrup a écrit :

Jean Abou Samra  writes:

[Harm:]

You are aware that you are not talking to a C++ programmer?  Not exactly
a motivating message under the circumstances...




I learnt C++ (like many things) by pretending I was a
C++ programmer while I wasn't, and trying to get along.




Would something like this be a reasonable patch?



Yes, in my opinion. I actually tried to display
the original name some time ago

but abandoned it (one of my projects for this summer
is to introduce "grob definitions" akin to context
definitions, which would make this possible and simple).

Jean

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

[Harm:]

>> After some further hours of work, following a different idea, it now
>> displays # (as it should).
>>
>> I'm not able to say what happened, I'm not able to debug because of
>> that unhelpful (oh, I'm very polite this evening) guile messages, see
>> the other thread.
>>
>> I'm overtired like hell, close to trashing the whole project, and
>> close to advertising everyone to not use LilyPond for huge custom
>> codings.
>
>
> Well, how about rolling up your sleeves and working
> on that issue with unhelpful messages? See also my recent
> message to lilypond-devel about the need for help to
> fix regressions.

You are aware that you are not talking to a C++ programmer?  Not exactly
a motivating message under the circumstances...

Would something like this be a reasonable patch?

>From 7e4ff15a40158db8fc065623fbb0f0549ba75f0c Mon Sep 17 00:00:00 2001
From: David Kastrup 
Date: Mon, 18 Jul 2022 00:38:54 +0200
Subject: [PATCH] Include "dead" in name of grobs without reflection

Nothing to do with (undead) vampires: reflection means containing a
type description, and `ly:grob-suicide!` removes that.
---
 lily/grob.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lily/grob.cc b/lily/grob.cc
index 009c4de206..e014e0dc84 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -788,7 +788,9 @@ Grob::name () const
   SCM meta = get_property (this, "meta");
   SCM nm = scm_assq (ly_symbol2scm ("name"), meta);
   nm = (scm_is_pair (nm)) ? scm_cdr (nm) : SCM_EOL;
-  return scm_is_symbol (nm) ? ly_symbol2string (nm) : class_name ();
+  return scm_is_symbol (nm)
+? ly_symbol2string (nm)
+: string ("dead ").append (class_name ());
 }
 
 ADD_INTERFACE (Grob,
-- 
2.34.1




-- 
David Kastrup

Re: Tempo arguments

[Jean Abou Samra]

Le 18/07/2022 à 00:35, David F. a écrit :

\tempo 4 = 90

How is tempo able to take ‘4 = 90’ as an argument?  Is this hardwired into the 
language or can any function take ‘x = y’ as an argument?


It is hardwired. Music functions cannot take arguments with '='.

Jean

Tempo arguments

[David F.]

\tempo 4 = 90

How is tempo able to take ‘4 = 90’ as an argument?  Is this hardwired into the 
language or can any function take ‘x = y’ as an argument?

David F.

Re: Questions about ragged-right and margins

[Andrew Bernard]

Not sure if this is helpful to your use case, but you may want to take a 
look at how to centre psalms on a page in LSR snippet 708.


https://lsr.di.unimi.it/LSR/Item?id=708

Andrew

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

I tried to use ly.grob-original, though, in the real code it first
returned #.




Namely a dead grob, on which ly:grob-suicide! was called,
and on which grob::is-live? will return #f.

That's the sort of thing that can happen if your callback
gets called after line breaking, at a point where the original
has been killed due to break-visibility. Observe:

\version "2.23.10"

#(define (debug grob)
   (ly:message "~s ~s"
   (ly:item-break-dir grob)
   (ly:grob-original grob)))

{
  \override Staff.BarLine.before-line-breaking = #debug
  \override Staff.BarLine.after-line-breaking = #debug
  c'1
}




After some further hours of work, following a different idea, it now
displays # (as it should).

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.



Well, how about rolling up your sleeves and working
on that issue with unhelpful messages? See also my recent
message to lilypond-devel about the need for help to
fix regressions.

Best,
Jean

Re: lilypond-book texinfo and a two-book-ly-file

[Thomas Morley]

Am Sa., 9. Juli 2022 um 13:41 Uhr schrieb Thomas Morley
:

> (2) One of the books is in portrait the other in landscape format
> Is there any texinfo option to get the landscape one rotated?
> That landscape thingy is needed and I can't change it, it may be an
> option to drop the portrait-book, though.
> Even dropping that one I'd need to get the landscape output rotated, though.

I found a way to support portrait _and_ landscape, at least this
problem is solved.

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am So., 17. Juli 2022 um 09:26 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 17/07/2022 à 01:25, Thomas Morley a écrit :
> > Thanks for your explanations, right now I had only a quick glance over
> > them.
> > I'll hopefully have some time soon to dive into it...
> > Nevertheless, before I posted the problem I searched for an
> > 'original'-BarLine-grob, as we have for broken spanners.
> > For (maybe broken) spanners I sometimes switch to that
> > 'original'-grob, would it improve the situation if we had some
> > 'original' for items as well?
>
>
>
> D'oh, why didn't think about that? It does solve the problem too
> (and more elegantly):
>
>
> \version "2.23.11"
>
> tst =
> #(lambda (ctx)
>(let ((nhd #f)
>  (previous-nhd #f)
>  (bar #f))
>(make-engraver
>  (acknowledgers
>((bar-line-interface engraver grob source-engraver)
>  (set! bar grob))
>((note-head-interface engraver grob source-engraver)
>  (set! nhd grob)))
>  ((stop-translation-timestep engraver)
>   (when (and bar previous-nhd)
> ;; for debugging
> (ly:grob-set-property! previous-nhd 'color red)
> (ly:grob-set-object! bar 'element previous-nhd)
> (set! (ly:grob-property bar 'details)
>   (acons 'previous-note-head
>  previous-nhd
>  (ly:grob-property bar 'details
> (when nhd
> ;; Move the next line out of (when ...) if you only want the
> ;; note head from the time step right before, and not the last
> ;; note head seen before the bar line.
> (set! previous-nhd nhd)
> (set! nhd #f))
>   (set! bar #f)
>
> moveBarLineToPrevHead = {
>\override Staff.BarLine.Y-offset =
>  #(lambda (grob)
>(let* ((prev-head (ly:grob-object (ly:grob-original grob)
>  'element
>  #f))
>   (staff-pos (and prev-head (ly:grob-property prev-head
> 'staff-position
> (/ (or staff-pos 0) 2)))
> }
>
> \layout {
>\context {
>\Staff
>\consists \tst
>\moveBarLineToPrevHead
>}
> }
>
> \new Staff { s4 s \bar "." b s c' d' e' f' g' a' b' c'' \bar "|." }
>
>
>
> Not sure why it didn't work when you tried?
>
>
>
> Jean

I tried to use ly.grob-original, though, in the real code it first
returned #.
After some further hours of work, following a different idea, it now
displays # (as it should).

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.

Re: error handling

[Thomas Morley]

Am Mi., 6. Juli 2022 um 19:07 Uhr schrieb Jean Abou Samra :
>
>
>
> On 7/5/22 01:10, Thomas Morley wrote:
> > Am Di., 5. Juli 2022 um 00:34 Uhr schrieb Jean Abou Samra 
> > :
> >
> > I just detected I can't compile my code with 2.22. any more, due to
> > the internal changes in \repeat volta.
> > Ofcourse it could have been any other change as well.
> > Should I code for both lily-versions, just to get helpful error
> > messages? Well, no, thanks.
> >
> >> We have a real problem here.
> > You are a master of understatement.
> >
> > Does it help to use master, not byte-compiled?
> > Could check myself, to tired now, though.
> >
> > Cheers,
> >Harm
>
>
> By the way: as a workaround, you can put your code in a .scm file
> and load it with ly:load. Then run LilyPond with GUILE_AUTO_COMPILE=1.
>

Sorry for the delayed reply!
I now tried to make some steps for scm-files/ly:load/autocompile.

Though, as far as I can tell ly:load doesn't work with relative pathes.

I'm attempting to code an extension to plain LilyPond. It needs a huge
amount of scheme-coding.
And ofcourse I will not know where the end-user may store it (once it
is finished)

Therefore ly:load is unusable.
Thus debugging such huge code is a pain, it drains energy and motivation.

Ok, I can use it for private coding, though that's not the goal.

Cheers,
  Harm

Re: Piping contents of SVG directly to stdout

[Jean Abou Samra]

Again, please keep the list in the recipients. In your mail client, 
click "Reply to all", not "Reply".


Le 17/07/2022 à 23:19, DoubleFelix a écrit :
Oh I see. I looked at compiling LilyPond, but I'm windows and it seems 
like a pain (I have to set up some VM for a custom OS is what I got 
from the docs).



You could also use the Windows Subsystem for Linux, which is
easy to install as far as I could hear (yes, Microsoft officially
provides an option to install Linux these days, which speaks
volumes...)



As for my input, it's pretty barebones:

\version"2.22.2"
\language"english"
\header{
    tagline = ""
}
{
\omitScore.TimeSignature
\omitScore.Rest
\keya \major
r4
}



So you just want to show an image of a key signature?

How about generating those images for all 15 possible
key signatures once and for all, and never calling LilyPond
afterwards?

Jean

Re: Piping contents of SVG directly to stdout

[Jean Abou Samra]

Hi,

Please keep the list posted, which allows everyone to comment and
benefit from the answers.


Le 17/07/2022 à 22:11, DoubleFelix a écrit :
Oh I see. Thank you! While we're here, do you have any tips for 
speeding up lilypond generation times?



If you're using the SVG backend, it is likely that most of the time
is spent generating the SVG. The current SVG backend is very slow;
this is a known issue. It is being improved upon currently, with
a new SVG backend based on the Cairo library, but Cairo support
isn't yet in the official binaries.

If you can avoid SVG and want speed, better avoid it.

If you can't, and you're comfortable with using the command line,
you can try building LilyPond yourself. The procedure is
explained thoroughly in
https://lilypond.org/doc/v2.23/Documentation/contributor/compiling,
but basically it's just "./autogen.sh --noconfigure; ./configure; make",
after you have installed all dependencies. To build LilyPond with
Cairo support, you need to run configure with --enable-cairo-backend.
Then compile your LilyPond files with out/bin/lilypond --svg -dbackend=cairo
(the flags must be in that order).

Apart from that, it's hard to tell what you can to to speed up
compilation without seeing the input you're giving to LilyPond.

Best,
Jean

Re: grace note arpeggio tied to chord

[Jim Cline]

ah, newbie mistake!

thanks Jean!

(actually I had searched the documentation but obviously not thoroughly 
enough)


On Sun, 17 Jul 2022, Jean Abou Samra wrote:




Le 17/07/2022 à 20:00, Jim Cline a écrit :
Hello, sorry if I missed it, but I did not find it by searching the 
archives.  I would like to have a grace note arpeggio where each note is 
tied to the chord that follows:


\grace{g16~ c~ e~}4

I only get the tie between the e's, not the other notes.

This is similar to a rolled chord, but I want it more articulated, hence 
the grace notes.  regards, Jim






Before searching the archives, search the documentation :-)

There is an example on this page:

https://lilypond.org/doc/v2.22/Documentation/notation/writing-rhythms.html#ties

(the snippet "Using ties with arpeggios").

Best,
Jean

Re: grace note arpeggio tied to chord

[Jean Abou Samra]

Le 17/07/2022 à 20:00, Jim Cline a écrit :
Hello, sorry if I missed it, but I did not find it by searching the 
archives.  I would like to have a grace note arpeggio where each note 
is tied to the chord that follows:


\grace{g16~ c~ e~}4

I only get the tie between the e's, not the other notes.

This is similar to a rolled chord, but I want it more articulated, 
hence the grace notes.  regards, Jim






Before searching the archives, search the documentation :-)

There is an example on this page:

https://lilypond.org/doc/v2.22/Documentation/notation/writing-rhythms.html#ties

(the snippet "Using ties with arpeggios").

Best,
Jean

grace note arpeggio tied to chord

[Jim Cline]

Hello, sorry if I missed it, but I did not find it by searching the 
archives.  I would like to have a grace note arpeggio where each note is 
tied to the chord that follows:


\grace{g16~ c~ e~}4

I only get the tie between the e's, not the other notes.

This is similar to a rolled chord, but I want it more articulated, hence 
the grace notes.  regards, Jim

Re: subito PP

[Xavier Scheuer]

On Sun, 17 Jul 2022 at 10:12, Benjamin Tordoff  wrote:
>
> Hi all,
>
> I'm typesetting a score that uses "subito p" and "subito pp" in a couple
of places. I've found snippets explaining how to get this to look right
(subito in normal italics, the "p" or "pp" in dynamic font), and another
snippet showing how to create a custom dynamic that correctly sets the midi
volume, but not one that does both. What is the best way to add a text
prefix to a dynamic whilst also retaining the dynamic's effect on MIDI
output?
>

Hello,

You could adapt Graham's "make-dynamic-extra" into a  "make-extra-dynamic".
https://lists.gnu.org/archive/html/lilypond-user/2011-06/msg00335.html

IIRC the alignment was correct (dynamic part was aligned on note head ) and
it was correctly recognized for MIDI generation.
https://lists.gnu.org/archive/html/lilypond-user/2017-08/msg00381.html

Cheers,
Xavier

-- 
Xavier Scheuer 

Re: subito PP

[David Kastrup]

Jean Abou Samra  writes:

> Le 17/07/2022 à 19:14, Benjamin Tordoff a écrit :
>> Thanks David & Jean, both approaches work well and look good. The
>> original indications were left aligned to the note so the alignment
>> adjustment isn't needed in this case. I have no idea if one of these
>> is technically superior to the other, although I suspect the fact I
>> need both sub.P and sub.PP means less code with David's approach.
>>
>> I wonder if this could be added to the snippet examples about
>> defining new dynamics? I don't think I would have stood any chance
>> of finding either solution without your help, and I suspect I'm not
>> the only one who might need this.
>
>
> Well, I don't like documenting stuff that I would like to see improved
> in the first place. It would make a lot more sense to carry the volume
> in the event so you could implement a function used like
>
> subPP = \dynamic #0.5 \markup { sub. \dynamic pp }

Agreed.  Incidentally, my approach doesn't care just how the MIDI volume
is derived and would continue to work even after such a change of
implementation.

-- 
David Kastrup

Re: subito PP

[Jean Abou Samra]

Le 17/07/2022 à 19:14, Benjamin Tordoff a écrit :
Thanks David & Jean, both approaches work well and look good. The 
original indications were left aligned to the note so the alignment 
adjustment isn't needed in this case. I have no idea if one of these 
is technically superior to the other, although I suspect the fact I 
need both sub.P and sub.PP means less code with David's approach.


I wonder if this could be added to the snippet examples about defining 
new dynamics? I don't think I would have stood any chance of finding 
either solution without your help, and I suspect I'm not the only one 
who might need this.



Well, I don't like documenting stuff that I would like to see improved 
in the first place. It would make a lot more sense to carry the volume 
in the event so you could implement a function used like


subPP = \dynamic #0.5 \markup { sub. \dynamic pp }

Jean

Re: subito PP

[Benjamin Tordoff]

Thanks David & Jean, both approaches work well and look good. The original 
indications were left aligned to the note so the alignment adjustment isn't 
needed in this case. I have no idea if one of these is technically superior to 
the other, although I suspect the fact I need both sub.P and sub.PP means less 
code with David's approach.

I wonder if this could be added to the snippet examples about defining new 
dynamics? I don't think I would have stood any chance of finding either 
solution without your help, and I suspect I'm not the only one who might need 
this.

Thanks

Ben

> On 17 Jul 2022, at 18:06, David Kastrup  wrote:
> 
> Jean Abou Samra mailto:j...@abou-samra.fr>> writes:
> 
>> Le 17/07/2022 à 10:11, Benjamin Tordoff a écrit :
>>> Hi all,
>>> 
>>> I'm typesetting a score that uses "subito p" and "subito pp" in a couple of 
>>> places. I've found snippets explaining how to get this to look right 
>>> (subito in normal italics, the "p" or "pp" in dynamic font), and another 
>>> snippet showing how to create a custom dynamic that correctly sets the midi 
>>> volume, but not one that does both. What is the best way to add a text 
>>> prefix to a dynamic whilst also retaining the dynamic's effect on MIDI 
>>> output?
>>> 
>>> \version "2.23.10"
>>> subPP = \markup{ \italic{sub.} \dynamic pp }
>>> 
>>> \score {
>>>   {
>>> c'2-\ff c'2-\subPP % Volume should be pp but is still ff
>>>   }
>>>   \layout {}
>>>   \midi {}
>>> }
>> 
>> 
>> How about something like this:
>> 
>> \version "2.22.2"
>> 
>> subPPMarkup = \markup { \normal-text \italic { sub. } pp }
>> subPP = #(make-dynamic-script subPPMarkup)
>> 
>> \midi {
>>   \context {
>> \Score
>> dynamicAbsoluteVolumeFunction =
>>   #(lambda (dyn)
>>  (if (equal? dyn subPPMarkup)
>>  0.3
>>  (default-dynamic-absolute-volume dyn)))
>>   }
>> }
> 
> It may be more convenient to just tamper with the visuals of a command,
> like
> 
> \version "2.22.2"
> 
> subx = #(define-event-function (fun) (ly:event?)
>#{ -\tweak stencil #(lambda (g)
>  (grob-interpret-markup g
>   #{ \markup \concat { \with-dimensions #'(0 . 0) 
> #'(0 . 0)
> \right-align
>\normal-text \italic "sub. 
> "
>#(ly:grob-property g 
> 'text) }
>   #}))
>   #fun #})
> 
> subPP = \subx \pp
> 
> \score {
>  {
>c'8\\< d'8 e'8 f'8 g'8 a'8 b'8 c''8 |
>c''8\f b'8 a'8 g'8 f'8\subPP e'8 d'8 c'8 }
>  \layout { }
>  \midi { }
> }
> 
> Note that I put in some effort to stop "sub." from changing the
> alignment.  If that's undesired, removing
> 
>\with-dimension #'(0 . 0) #'(0 . 0)
> 
> should do the trick.
> 
> -- 
> David Kastrup

Re: subito PP

[David Kastrup]

David Kastrup  writes:

> Jean Abou Samra  writes:
>
>> Le 17/07/2022 à 10:11, Benjamin Tordoff a écrit :
>>> Hi all,
>>>
>>> I'm typesetting a score that uses "subito p" and "subito pp" in a couple of 
>>> places. I've found snippets explaining how to get this to look right 
>>> (subito in normal italics, the "p" or "pp" in dynamic font), and another 
>>> snippet showing how to create a custom dynamic that correctly sets the midi 
>>> volume, but not one that does both. What is the best way to add a text 
>>> prefix to a dynamic whilst also retaining the dynamic's effect on MIDI 
>>> output?
>>>
>>> \version "2.23.10"
>>> subPP = \markup{ \italic{sub.} \dynamic pp }
>>>
>>> \score {
>>>{
>>>  c'2-\ff c'2-\subPP % Volume should be pp but is still ff
>>>}
>>>\layout {}
>>>\midi {}
>>> }
>>
>>
>> How about something like this:
>>
>> \version "2.22.2"
>>
>> subPPMarkup = \markup { \normal-text \italic { sub. } pp }
>> subPP = #(make-dynamic-script subPPMarkup)
>>
>> \midi {
>>   \context {
>>     \Score
>>     dynamicAbsoluteVolumeFunction =
>>   #(lambda (dyn)
>>  (if (equal? dyn subPPMarkup)
>>  0.3
>>  (default-dynamic-absolute-volume dyn)))
>>   }
>> }
>
> It may be more convenient to just tamper with the visuals of a command,
> like
>
> \version "2.22.2"
>
> subx = #(define-event-function (fun) (ly:event?)
>#{ -\tweak stencil #(lambda (g)
>  (grob-interpret-markup g
>   #{ \markup \concat { \with-dimensions #'(0 . 0) 
> #'(0 . 0)
>  \right-align
>\normal-text \italic "sub. 
> "
>#(ly:grob-property g 
> 'text) }
>   #}))
>   #fun #})
>
> subPP = \subx \pp
>
> \score {
>   {
> c'8\\< d'8 e'8 f'8 g'8 a'8 b'8 c''8 |
> c''8\f b'8 a'8 g'8 f'8\subPP e'8 d'8 c'8 }
>   \layout { }
>   \midi { }
> }
>
>
> Note that I put in some effort to stop "sub." from changing the
> alignment.  If that's undesired, removing
>
> \with-dimension #'(0 . 0) #'(0 . 0)
>
> should do the trick.

Actually it might make more sense to name this \subito rather than \subx
as you can perfectly well just write \subito \pp in the score without
defining an extra command for it.

-- 
David Kastrup

Re: subito PP

[David Kastrup]

Jean Abou Samra  writes:

> Le 17/07/2022 à 10:11, Benjamin Tordoff a écrit :
>> Hi all,
>>
>> I'm typesetting a score that uses "subito p" and "subito pp" in a couple of 
>> places. I've found snippets explaining how to get this to look right (subito 
>> in normal italics, the "p" or "pp" in dynamic font), and another snippet 
>> showing how to create a custom dynamic that correctly sets the midi volume, 
>> but not one that does both. What is the best way to add a text prefix to a 
>> dynamic whilst also retaining the dynamic's effect on MIDI output?
>>
>> \version "2.23.10"
>> subPP = \markup{ \italic{sub.} \dynamic pp }
>>
>> \score {
>>{
>>  c'2-\ff c'2-\subPP % Volume should be pp but is still ff
>>}
>>\layout {}
>>\midi {}
>> }
>
>
> How about something like this:
>
> \version "2.22.2"
>
> subPPMarkup = \markup { \normal-text \italic { sub. } pp }
> subPP = #(make-dynamic-script subPPMarkup)
>
> \midi {
>   \context {
>     \Score
>     dynamicAbsoluteVolumeFunction =
>   #(lambda (dyn)
>  (if (equal? dyn subPPMarkup)
>  0.3
>  (default-dynamic-absolute-volume dyn)))
>   }
> }

It may be more convenient to just tamper with the visuals of a command,
like

\version "2.22.2"

subx = #(define-event-function (fun) (ly:event?)
	 #{ -\tweak stencil #(lambda (g)
			   (grob-interpret-markup g
#{ \markup \concat { \with-dimensions #'(0 . 0) #'(0 . 0)
 \right-align
		 \normal-text \italic "sub. "
		 #(ly:grob-property g 'text) }
#}))
	#fun #})

subPP = \subx \pp

\score {
  {
c'8\\< d'8 e'8 f'8 g'8 a'8 b'8 c''8 |
c''8\f b'8 a'8 g'8 f'8\subPP e'8 d'8 c'8 }
  \layout { }
  \midi { }
}

Note that I put in some effort to stop "sub." from changing the
alignment.  If that's undesired, removing

\with-dimension #'(0 . 0) #'(0 . 0)

should do the trick.

-- 
David Kastrup

Re: subito PP

[Jean Abou Samra]

Le 17/07/2022 à 10:11, Benjamin Tordoff a écrit :

Hi all,

I'm typesetting a score that uses "subito p" and "subito pp" in a couple of places. I've found 
snippets explaining how to get this to look right (subito in normal italics, the "p" or "pp" in 
dynamic font), and another snippet showing how to create a custom dynamic that correctly sets the midi volume, but not 
one that does both. What is the best way to add a text prefix to a dynamic whilst also retaining the dynamic's effect 
on MIDI output?

\version "2.23.10"
subPP = \markup{ \italic{sub.} \dynamic pp }

\score {
   {
 c'2-\ff c'2-\subPP % Volume should be pp but is still ff
   }
   \layout {}
   \midi {}
}



How about something like this:

\version "2.22.2"

subPPMarkup = \markup { \normal-text \italic { sub. } pp }
subPP = #(make-dynamic-script subPPMarkup)

\midi {
  \context {
    \Score
    dynamicAbsoluteVolumeFunction =
  #(lambda (dyn)
 (if (equal? dyn subPPMarkup)
 0.3
 (default-dynamic-absolute-volume dyn)))
  }
}

\score {
  {
    c'8\\< d'8 e'8 f'8 g'8 a'8 b'8 c''8 |
    c''8\f b'8 a'8 g'8 f'8\subPP e'8 d'8 c'8 }
  \layout { }
  \midi { }
}


See also the snippet"Creating custom dynamics in MIDI output"
at

https://lilypond.org/doc/v2.22/Documentation/notation/controlling-midi-dynamics.html

Best,
Jean

Re: Piping contents of SVG directly to stdout

[Jean Abou Samra]

Le 15/07/2022 à 21:15, DoubleFelix a écrit :

Hello,

I'm using lilypond to programmatically generate sheet music. I already 
have a system in place to crop the SVGs, but now I need to load them 
in my software. I could use the default behavior of letting lilypond 
write to some file, and then reading it, but file I/O tends to be 
pretty expensive, especially when you're doing it in bulk like I am, 
so I'd like to avoid that.


My question is this: Is there a way to get lilypond to write the 
output to stdout to save on performance, or do I need to use a file as 
a middleman? For reference, my current command is:

"lilypond --svg --loglevel=none file.ly "



I don't think this exists. On the other hand, I strongly
doubt that file I/O can prove expensive compared to the
time required to process the LilyPond file. For example,
with Python,

$ time lily -s --svg input/regression/parenthesize.ly

real    0m0,719s
user    0m0,637s
sys    0m0,061s

$ python
Python 3.10.5 (main, Jun  9 2022, 00:00:00) [GCC 12.1.1 20220507 (Red 
Hat 12.1.1-1)] on linux

Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> from timeit import timeit
>>> timeit("Path('parenthesize.svg').read_bytes()", number=1000, 
globals=globals())

0.01524080800284


As you can see, the time taken to read the output SVG
file was 2% of the time to compile the file in this example.

Best,
Jean

Re: subito PP

[Benjamin Tordoff]

Thanks for the suggestion. Unless I'm doing something wrong this still seems to 
leave the volume unchanged (I put a normal \pp in the subsequent bar to check 
and playing the midi back in GarageBand I only hear the volume change on the 
\pp not the \subPP).

Any further suggestions? Is there a way to manually insert a volume change as a 
workaround (i.e. do an invisible \pp)?

Thanks

Ben

> On 17 Jul 2022, at 14:43, Eef Weenink  wrote:
> 
> try this; 
> 
> \version "2.23.10"
> 
> subPP =
> #(make-dynamic-script
>   (markup #:line
>   (#:normal-text
>#:italic "sub."
>#:dynamic "pp")))
> 
> \score {
>  {
>c'2-\ff c'2-\subPP % Volume should be pp but is still ff
>  }
>  \layout {}
>  \midi {}
> }
> 
> 
> 
> 
>> Op 17 jul. 2022, om 10:11 heeft Benjamin Tordoff > > het volgende geschreven:
>> 
>> \version "2.23.10"
>> subPP = \markup{ \italic{sub.} \dynamic pp }
>> 
>> \score {
>>  {
>>c'2-\ff c'2-\subPP % Volume should be pp but is still ff
>>  }
>>  \layout {}
>>  \midi {}
>> }
> 

Re: Generating a spiccato

[Ralph Palmer]

On Sat, Jul 16, 2022 at 10:35 PM Jacques Menu  wrote:

> Hello Werner,
>
> Thanks for the clarification!
>
> JM
>
> > Le 13 juil. 2022 à 16:40, Werner LEMBERG  a écrit :
> >
> >
> >>> In MusixXML, this sign is  (The  element |
> >>> MusicXML 4.0 (w3.org)
> >>> <
> https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/spiccato/
> >),
> >>> the same sign is named \staccatissimo in Lilypond.
> >>> In MusixXML,  looks like this:  (The 
> >>> element | MusicXML 4.0 (w3.org)
> >>> <
> https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/staccatissimo/
> >),
> >>> but it seems there is no corresponding articulation in Lilypond and no
> >>> glyph in the Emmentaler font.
> >>>
> >>> So the question is: is there interest among the LilyPond community to
> >>> add the latter glyph in some way?
> >
> > I consider the distinction between these two glyphs completely
> > arbitrary.  At normal size, the difference between a concave and a
> > convex top is not really visible.
> >
> > If you look at
> >
> >  https://w3c.github.io/smufl/latest/tables/articulation.html
> >
> > you can see that both glyph shapes in question are defined as variants
> > of 'staccatissimo' – for spiccato, there doesn't exist a symbol.  And
> > rightly so: I've never seen a symbol for spiccato except an ordinary
> > staccato point with the word 'spicc.' (if at all).
> >
> >
> > Werner
>
>
>
My apologies - I haven't been paying attention, and I don't know where my
head was at. I think it's important that spiccato is a bowing technique,
and staccato is an articulation (a quality of sound) which can be
accomplished through spiccato (and, depending on the circumstances, other
bowing techniques). Also, I would imagine that staccato is possible on
instruments on which spiccato is impossible : flute, guitar, maybe piano?

All the best,

Ralph

-- 
Ralph Palmer
Seattle
USA
(he, him, his)
palmer.r.vio...@gmail.com

Re: Installing Lilypond 2.23.10

[David Sumbler]

On Fri, 2022-07-15 at 02:56 +0200, Jean Abou Samra wrote:
> 
> > A more serious problem (for me) is that Emacs could no longer find 
> > Lilypond mode.  So I moved the new Lilypond to 
> > /usr/local/lilypond/usr/.  Emacs can now uses Lilypond mode, but
> > can't 
> > compile a file - it produces reams of messages (after much
> > processing 
> > time), mostly of the
> > 
> > ;;; note: source file 
> > /usr/local/lilypond/usr/share/lilypond/2.23.10/scm/lily/display-
> > lily.scm
> > ;;; newer than compiled 
> > /usr/local/lilypond/usr/lib/lilypond/2.23.10/ccache/lily/display-
> > lily.go
> > 
> > kind, and then exits with
> > 
> > ERROR: In procedure apply-smob/1:
> > Wrong number of arguments to #
> > 
> > Compilation exited abnormally with code 1 at Thu Jul 14 17:21:52
> > 
> > I have spent some hours experimenting, but so far I haven't managed
> > to 
> > get things working.

On Fri, 2022-07-15 at 02:57 +0200, Jean Abou Samra wrote:
> Le 15/07/2022 à 02:56, Jean Abou Samra a écrit :
> 
> > > Hm. Does this help?
> > > 
> > > sudo find /usr/local/lilypond/usr/lib/lilypond/2.23.10/ -name
> > > "*.go" 
> > > -exec touch {} \;
> > > 
> Wait, rather try
> 
> sudo find /usr/local/lilypond/ -name "*.go" -exec touch {} \;

Yes, this worked - thank you.

I am used to a new installation of Lilypond taking some considerable
time to compile the first time - presumably because it needs to do some
general compilation and housekeeping to get itself organized.
 Subsequently it then takes a relatively short time, depending on the
complexity of the Lilypond source it is compiling.

At the moment I am testing it on a short file - in fact, your "grow-in-
up-direction" example from the Extending Lilypond document.  Compiling
it is taking over 80 seconds each time; after the first time, I would
expect a file like this to take only 3 or 4 seconds.  This is very
unsatisfactory.

On Thu, 2022-07-14 at 23:13 -0500, David Wright wrote:
> 
> Those paths look odd. /usr/local should only contain the directories
> bin  etc  games  include  lib  man  sbin  share  src
> and /usr/local/bin/ is typically placed at the start of your $PATH
> for you by your distribution. I don't know where
> /usr/local/lilypond/usr/
> came from, but the rest of the path, share/lilypond/2.23.10/…, does
> look like something unpacked from the .tar.gz file.

> If your response is that it used to work, then I would wonder
> whether you used to have a distribution-supplied version of
> lilypond installed, and emacs was relying on that. In other
> words, it was relying on lilypond*.el files in locations like
> /etc/emacs/site-start.d/ and /usr/share/emacs/site-lisp/
> (or similar names), instead of those from any of the downloaded
> versions you've installed/unpacked in the past.

No, I have never used a distro version of Lilypond.  Until this time, I
have always used a script downloaded from the Lilypond website.  I
install Lilypond globally (although I am the only user of this
computer), and the script chooses to put things where they now are.  I
always thought /usr/local/lilypond/usr/share/lilypond/ was an odd place
to put it, but that wasn't my choice.

When I moved 2.23.10 from my home folder, I intentionally put it in the
same place as previous versions have been on my previous Ubuntu
installations, hoping this would increase the chances of it actually
working.  On this current OS version, I have not actually had any
previous versions of Lilypond, which is why I needed to install it
again now.

In my .emacs file I have:

;;for Lilypond mode
(setq load-path (append (list (expand-file-name
"/usr/local/lilypond/usr/share/emacs/site-lisp")) load-path))
(autoload 'LilyPond-mode "lilypond-mode" "LilyPond Editing Mode" t)
(add-to-list 'auto-mode-alist '("\\.ly$" . LilyPond-mode))
(add-to-list 'auto-mode-alist '("\\.ily$" . LilyPond-mode))

So yes, clearly Lilypond mode is working now because I have installed
Lilypond where the .sh script would have put it.  I can also see that I
can easily work round this by editing my .emacs file, if I decide to
put Lilypond somewhere else (e.g. my home folder).

Is it the intention that the next "stable" version of Lilypond will be
packaged in this new way?  Will the shell script be done away with
there too?

Even if not, what are the perceived advantages of this change for the
development versions, at least?

David

Re: Openlilylib

[Mark Knoop]

Hi Andrew and other OLL users,

At 18:24 on 27 May 2022, Andrew Bernard wrote:

The upshot of that is that I suppose I should revive the OLL work. I'll
recreate the dedicated server I set up, recreate the Discourse forum for
discussion, and work on the git repository, then people can
collaboratively work together again and I can take pull requests and so
on.


Just a note to say that I have forks of some of the OLL repositories on Github 
as follows.

https://github.com/markk/oll-core
https://github.com/markk/edition-engraver
https://github.com/markk/partial-compilation
https://github.com/markk/breaks

Some of these have some minor updates to make them compatible with current 
LilyPond and Guile 2.2.

Andrew, I'm happy for you to host an alternative repository if you prefer, but 
it would be good to avoid multiple forks and duplicated effort.

I note a bug with the edition-engraver which can no longer address the first 
moment of the score. This needs further investigation (unless somebody else has 
already solved this?).

--
Mark Knoop

Re: subito PP

[Eef Weenink]

try this;

\version "2.23.10"

subPP =
#(make-dynamic-script
  (markup #:line
  (#:normal-text
   #:italic "sub."
   #:dynamic "pp")))

\score {
 {
   c'2-\ff c'2-\subPP % Volume should be pp but is still ff
 }
 \layout {}
 \midi {}
}




Op 17 jul. 2022, om 10:11 heeft Benjamin Tordoff 
mailto:ben.tord...@me.com>> het volgende geschreven:

\version "2.23.10"
subPP = \markup{ \italic{sub.} \dynamic pp }

\score {
 {
   c'2-\ff c'2-\subPP % Volume should be pp but is still ff
 }
 \layout {}
 \midi {}
}

Questions about ragged-right and margins

[Carl Peterson]

Hello All,

I have two questions related to ragged-right.

#1: Is it possible to change the behavior of ragged-right so that rather
than a system being an arbitrary length, the length snaps to certain
intervals? The out-of-the-box behavior of ragged-right = ##t can result in
systems that are minutely different lengths, which isn't particularly
attractive. Instead, it would be nice to snap to, say increments of 10% of
the maximum line length. I recognize that it's still possible to have two
similar-length lines that snap in opposite directions.

#2: Given #1 above, is it possible to set the margins of the score
dynamically so that the longest system is centered on the page, and all
other systems are left-aligned with it? Ideally, everything outside the
score would take the full margin/line length defined in the \paper block.

I'm typesetting a psalter with tune pairings. We want to generally match
the layout of a previously published hymnal that was done in Finale with
some of the above layout decisions. We're doing this project in LP because
the scope of the project (195 psalm paraphrases, each paired and notated
with multiple common tunes, prepared in multiple slide and print formats)
would be infeasible without the ability to automate the work using LP and a
language like Python.

Thanks in advance,
Carl Peterson

subito PP

[Benjamin Tordoff]

Hi all,

I'm typesetting a score that uses "subito p" and "subito pp" in a couple of 
places. I've found snippets explaining how to get this to look right (subito in 
normal italics, the "p" or "pp" in dynamic font), and another snippet showing 
how to create a custom dynamic that correctly sets the midi volume, but not one 
that does both. What is the best way to add a text prefix to a dynamic whilst 
also retaining the dynamic's effect on MIDI output?

\version "2.23.10"
subPP = \markup{ \italic{sub.} \dynamic pp }

\score {
  {
c'2-\ff c'2-\subPP % Volume should be pp but is still ff
  }
  \layout {}
  \midi {}
}

Thanks

Ben

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am So., 17. Juli 2022 um 09:26 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 17/07/2022 à 01:25, Thomas Morley a écrit :
> > Thanks for your explanations, right now I had only a quick glance over
> > them.
> > I'll hopefully have some time soon to dive into it...
> > Nevertheless, before I posted the problem I searched for an
> > 'original'-BarLine-grob, as we have for broken spanners.
> > For (maybe broken) spanners I sometimes switch to that
> > 'original'-grob, would it improve the situation if we had some
> > 'original' for items as well?
>
>
>
> D'oh, why didn't think about that? It does solve the problem too
> (and more elegantly):

[...]

> Not sure why it didn't work when you tried?

Well, actually I searched for a _function_ returning the unbroken
_item_, because I was under the impression ly:grob-original was fpr
spanners only.
Thus I didn't try it out, my bad.

After a night full sleep, I reseached ly:grob-original in our code base.

I found only one instance where ly:grob-original is used for grobs
which may not be spanners: `offsetter' in music-functions.scm.
Though IR says:
Function: ly:grob-original grob
  Return the unbroken original grob of grob.
Coming from
Return the unbroken original grob of @var{grob}.
in grob-scheme.cc

I think it would be more clear to do
Return the unbroken original grob of @var{grob}, @var{grob} may be an
item or spanner.

If you agree I'd put up a patch.


Cheers,
  Harm

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 17/07/2022 à 01:25, Thomas Morley a écrit :
Thanks for your explanations, right now I had only a quick glance over 
them.

I'll hopefully have some time soon to dive into it...
Nevertheless, before I posted the problem I searched for an
'original'-BarLine-grob, as we have for broken spanners.
For (maybe broken) spanners I sometimes switch to that
'original'-grob, would it improve the situation if we had some
'original' for items as well?




D'oh, why didn't think about that? It does solve the problem too
(and more elegantly):


\version "2.23.11"

tst =
#(lambda (ctx)
  (let ((nhd #f)
    (previous-nhd #f)
    (bar #f))
  (make-engraver
    (acknowledgers
  ((bar-line-interface engraver grob source-engraver)
    (set! bar grob))
  ((note-head-interface engraver grob source-engraver)
    (set! nhd grob)))
    ((stop-translation-timestep engraver)
 (when (and bar previous-nhd)
   ;; for debugging
   (ly:grob-set-property! previous-nhd 'color red)
   (ly:grob-set-object! bar 'element previous-nhd)
   (set! (ly:grob-property bar 'details)
 (acons 'previous-note-head
    previous-nhd
    (ly:grob-property bar 'details
   (when nhd
   ;; Move the next line out of (when ...) if you only want the
   ;; note head from the time step right before, and not the last
   ;; note head seen before the bar line.
   (set! previous-nhd nhd)
   (set! nhd #f))
 (set! bar #f)

moveBarLineToPrevHead = {
  \override Staff.BarLine.Y-offset =
    #(lambda (grob)
  (let* ((prev-head (ly:grob-object (ly:grob-original grob)
    'element
    #f))
 (staff-pos (and prev-head (ly:grob-property prev-head 
'staff-position

   (/ (or staff-pos 0) 2)))
}

\layout {
  \context {
  \Staff
  \consists \tst
  \moveBarLineToPrevHead
  }
}

\new Staff { s4 s \bar "." b s c' d' e' f' g' a' b' c'' \bar "|." }



Not sure why it didn't work when you tried?



Jean