Re: LilyPond MIDI and sustain pedal

[Andrew Bernard]

Hi All,

It transpires that I have been using FL Studio 20, and I am a new user
of that amazing DAW. FL Studio is immensely sophisticated and the
technique is that you import the MIDI CC and automation data to the
channel in question (e.g. 64) with the event editor, a separate
operation. That's why I was not seeing it in the plain MIDI file
import. Having learned that, it's really great! I note that Presonus
Studio One Five imports the sustain along with the rest of the MIDI
data, but I only found that out afterwards.

Thanks all for your always amazing help. I have been using LilyPond
daily in my engraving work for years and I still feel like a raw
beginner.

Andrew


On Wed, 21 Oct 2020 at 01:37, Jean Abou Samra  wrote:
>
> Le 20/10/2020 à 16:32, Andrew Bernard a écrit :
>
> > Hi Jean,
> >
> > This is totally great. I never heard of this tool. How would a user
> > know it exists - as far as I can see there is nothing in the NR (I may
> > be wrong)? It never occurred to me as a user to look at the programs
> > in  the usr/bin areas as I thought everything was installed in
> > $HOME/bin.
> >
> > Andrew
> Hello,
>
> It is undocumented for a long time. Have a look at
>
> https://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00612.html
>
> Go ahead if you want to fix this :-)
>
> Jean
>

Re: Vertical spacing inside the music

[Thomas Morley]

Am Di., 20. Okt. 2020 um 14:06 Uhr schrieb Павел :
>
> Hello. I'm looking for the "right" way to control vertical spacing
> within music. The example below doesn't work. Now I know only explicit
> vertical spacing via NonMusicalPaperColumn, and dirty hacks like a very
> low invisible note.
>
> <<
>  \new Staff {
>  c' c' c' c'
>  \override
> Score.VerticalAxisGroup.staff-staff-spacing.basic-distance = #20
>  c' c' c' c'
>  }
>  \new Staff { c' c' c' c' c' c' c' c' }
>  >>
>
>

What's wrong with NonMusicalPaperColumn?
You may use it for one-time changes together with overriding
VerticalAxisGroup in \layout for general settings as Jean
demonstrated.

\layout {
   \context {
 \Staff
 \override VerticalAxisGroup.staff-staff-spacing.basic-distance = #20
   }
}

<<
  \new Staff {
\repeat unfold 4 c'4
\break
\overrideProperty Score.NonMusicalPaperColumn.line-break-system-details
  #'((alignment-distances . (40)))
\repeat unfold 4 c'4
\break
\repeat unfold 4 c'4
  }
  \new Staff \repeat unfold 12  c'4
>>

Cheers,
  Harm

Re: Some wild considerations and a question

[Jonas Hahnfeld]

Am Dienstag, den 20.10.2020, 19:26 +0200 schrieb David Kastrup:
> Jonas Hahnfeld  writes:
> 
> > Am Dienstag, den 20.10.2020, 18:26 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld  writes:
> > > 
> > > > I don't want to digress into this topic right now (P.S. the reply got
> > > > longer than I initially anticipated), but the scripts have a much
> > > > narrower focus: they mostly compile native binaries (except for
> > > > Windows via mingw) instead of cross-compiling for all targets. In my
> > > > experience from helping with GUB in the past year, that's the main
> > > > source of complexity for usage and maintenance. Moreover, this choice
> > > > also outright prevents 64-bit executables for macOS because of Apple's
> > > > restrictions with regard to their toolchain.
> > > > 
> > > > I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
> > > > just too much (a package manager for building arbitrary packages for
> > > > various targets; where we only do LilyPond to a handful) by using a
> > > > too powerful language and architecture (Python 2 with dynamic
> > > > dependency resolution and generic interfaces to various build
> > > > systems). I think we should learn from that and choose a design that
> > > > avoids the pitfalls.
> > > 
> > > To be fair, GUB could have become a significant part of the GNU compiler
> > > toolchain which would have vindicated its complexity, and at one point
> > > of time it was more or less intended for that.
> > > 
> > > I have not pushed it in that direction since I never was able to get
> > > dependable information about the legal status of our MacOSX port's
> > > toolkit.  While it was clear that the conditions of the 64bit toolkit
> > > precluded its use, the respective conditions for the 32bit kit we used
> > > just were no longer to be found and it was not overly clear just what
> > > version was involved here.  If this would have been replaced by some
> > > OpenDarwin components (but we had nobody to work on that, partly a
> > > hen-and-egg problem), this might have been different.
> > > 
> > > And with the basic "let's not look too closely here" status of the
> > > MacOSX toolkit, extending its reach would have been asking others to
> > > embrace the potential trouble that we were in ourselves.
> > 
> > For my own reading pleasure, do you have links where this was
> > discussed? I mean, I don't see your name in the GUB repo so I'm not
> > sure what "I have not pushed it" means.
> 
> That would not be in the GUB repo but in GNU's internal discussion
> lists.

Are there public archives of that?

> There were a few sort-of discussions/attempts on the
> lilypond-devel list to clear things up without conclusive results.

Do you have pointers to them or roughly know the time frame when they
happened? Most posts in the recent years are from Phil about some
failure or last year's threads about fixing them.


signature.asc
Description: This is a digitally signed message part

Re: Some wild considerations and a question

[Karlin High]

On 10/20/2020 12:26 PM, David Kastrup wrote:

Jonas Hahnfeld  writes:
For my own reading pleasure, do you have links where this was
discussed?



That would not be in the GUB repo but in GNU's internal discussion
lists.  There were a few sort-of discussions/attempts on the
lilypond-devel list to clear things up without conclusive results.


This thread is the one I best remember:



Folks in the Apple world said there was a stand-alone OSX 10.4 SDK that 
would not have had hardware restrictions. Hopefully that's the one 
LilyPond has been using.

--
Karlin High
Missouri, USA

Re: Some wild considerations and a question

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 20.10.2020, 18:26 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld  writes:
>> 
>> > I don't want to digress into this topic right now (P.S. the reply got
>> > longer than I initially anticipated), but the scripts have a much
>> > narrower focus: they mostly compile native binaries (except for
>> > Windows via mingw) instead of cross-compiling for all targets. In my
>> > experience from helping with GUB in the past year, that's the main
>> > source of complexity for usage and maintenance. Moreover, this choice
>> > also outright prevents 64-bit executables for macOS because of Apple's
>> > restrictions with regard to their toolchain.
>> > 
>> > I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
>> > just too much (a package manager for building arbitrary packages for
>> > various targets; where we only do LilyPond to a handful) by using a
>> > too powerful language and architecture (Python 2 with dynamic
>> > dependency resolution and generic interfaces to various build
>> > systems). I think we should learn from that and choose a design that
>> > avoids the pitfalls.
>> 
>> To be fair, GUB could have become a significant part of the GNU compiler
>> toolchain which would have vindicated its complexity, and at one point
>> of time it was more or less intended for that.
>> 
>> I have not pushed it in that direction since I never was able to get
>> dependable information about the legal status of our MacOSX port's
>> toolkit.  While it was clear that the conditions of the 64bit toolkit
>> precluded its use, the respective conditions for the 32bit kit we used
>> just were no longer to be found and it was not overly clear just what
>> version was involved here.  If this would have been replaced by some
>> OpenDarwin components (but we had nobody to work on that, partly a
>> hen-and-egg problem), this might have been different.
>> 
>> And with the basic "let's not look too closely here" status of the
>> MacOSX toolkit, extending its reach would have been asking others to
>> embrace the potential trouble that we were in ourselves.
>
> For my own reading pleasure, do you have links where this was
> discussed? I mean, I don't see your name in the GUB repo so I'm not
> sure what "I have not pushed it" means.

That would not be in the GUB repo but in GNU's internal discussion
lists.  There were a few sort-of discussions/attempts on the
lilypond-devel list to clear things up without conclusive results.

-- 
David Kastrup

Re: Some wild considerations and a question

[Jonas Hahnfeld]

Am Dienstag, den 20.10.2020, 18:26 +0200 schrieb David Kastrup:
> Jonas Hahnfeld  writes:
> 
> > I don't want to digress into this topic right now (P.S. the reply got
> > longer than I initially anticipated), but the scripts have a much
> > narrower focus: they mostly compile native binaries (except for
> > Windows via mingw) instead of cross-compiling for all targets. In my
> > experience from helping with GUB in the past year, that's the main
> > source of complexity for usage and maintenance. Moreover, this choice
> > also outright prevents 64-bit executables for macOS because of Apple's
> > restrictions with regard to their toolchain.
> > 
> > I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
> > just too much (a package manager for building arbitrary packages for
> > various targets; where we only do LilyPond to a handful) by using a
> > too powerful language and architecture (Python 2 with dynamic
> > dependency resolution and generic interfaces to various build
> > systems). I think we should learn from that and choose a design that
> > avoids the pitfalls.
> 
> To be fair, GUB could have become a significant part of the GNU compiler
> toolchain which would have vindicated its complexity, and at one point
> of time it was more or less intended for that.
> 
> I have not pushed it in that direction since I never was able to get
> dependable information about the legal status of our MacOSX port's
> toolkit.  While it was clear that the conditions of the 64bit toolkit
> precluded its use, the respective conditions for the 32bit kit we used
> just were no longer to be found and it was not overly clear just what
> version was involved here.  If this would have been replaced by some
> OpenDarwin components (but we had nobody to work on that, partly a
> hen-and-egg problem), this might have been different.
> 
> And with the basic "let's not look too closely here" status of the
> MacOSX toolkit, extending its reach would have been asking others to
> embrace the potential trouble that we were in ourselves.

For my own reading pleasure, do you have links where this was
discussed? I mean, I don't see your name in the GUB repo so I'm not
sure what "I have not pushed it" means.


signature.asc
Description: This is a digitally signed message part

Re: Vertical spacing inside the music

[Kieren MacMillan]

Dobrij dehn, Павел!

> how to control vertical spacing inside music? For example, I want to have #10 
> basic-distance at start of a piece and #15 basic-distance since 12-th measure.

I use the edition-engraver for this kind of spacing — I find the best result 
usually comes from a combination of setting the basic-distance to an 
appropriate amount at the beginning of the piece, and then tweaking the 
extra-offset (or sometimes Y-offset) of individual systems as needed.

Hope that helps!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Some wild considerations and a question

[David Kastrup]

Jonas Hahnfeld  writes:

> I don't want to digress into this topic right now (P.S. the reply got
> longer than I initially anticipated), but the scripts have a much
> narrower focus: they mostly compile native binaries (except for
> Windows via mingw) instead of cross-compiling for all targets. In my
> experience from helping with GUB in the past year, that's the main
> source of complexity for usage and maintenance. Moreover, this choice
> also outright prevents 64-bit executables for macOS because of Apple's
> restrictions with regard to their toolchain.
>
> I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
> just too much (a package manager for building arbitrary packages for
> various targets; where we only do LilyPond to a handful) by using a
> too powerful language and architecture (Python 2 with dynamic
> dependency resolution and generic interfaces to various build
> systems). I think we should learn from that and choose a design that
> avoids the pitfalls.

To be fair, GUB could have become a significant part of the GNU compiler
toolchain which would have vindicated its complexity, and at one point
of time it was more or less intended for that.

I have not pushed it in that direction since I never was able to get
dependable information about the legal status of our MacOSX port's
toolkit.  While it was clear that the conditions of the 64bit toolkit
precluded its use, the respective conditions for the 32bit kit we used
just were no longer to be found and it was not overly clear just what
version was involved here.  If this would have been replaced by some
OpenDarwin components (but we had nobody to work on that, partly a
hen-and-egg problem), this might have been different.

And with the basic "let's not look too closely here" status of the
MacOSX toolkit, extending its reach would have been asking others to
embrace the potential trouble that we were in ourselves.

> Closing words: In general, a replacement for GUB is not something to
> be discussed in length on -user. This must happen in a proper thread
> on the -devel list, and hopefully with more technical content than
> just the statement of "we need something better".

-- 
David Kastrup

trying to install microlily

[Stefan Thomas]

Dear community,
I've recently tried to install microlily with the command

>  lyp install microlily
>
Unfortunately I've got the message:

> Cloning https://github.com/lyp-packages/microlily.git...
> Installing microlily@0.1.0
> Could not find include file reference join-path specified in
> /home/stefan/.lyp/packages/microlily@0.1.0/package.ly:3:
>
>   "athenian"= \pincludeOnce #(lyp:join-path microlily-dir "athenian.ly
> ")
>
Can someone give me a hint, what I could do?
Thanks,
Stefan

Re: LilyPond MIDI and sustain pedal

[Jean Abou Samra]

Le 20/10/2020 à 16:32, Andrew Bernard a écrit :


Hi Jean,

This is totally great. I never heard of this tool. How would a user
know it exists - as far as I can see there is nothing in the NR (I may
be wrong)? It never occurred to me as a user to look at the programs
in  the usr/bin areas as I thought everything was installed in
$HOME/bin.

Andrew

Hello,

It is undocumented for a long time. Have a look at

https://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00612.html

Go ahead if you want to fix this :-)

Jean

Re: LilyPond MIDI and sustain pedal

[Andrew Bernard]

Hi Jean,

This is totally great. I never heard of this tool. How would a user
know it exists - as far as I can see there is nothing in the NR (I may
be wrong)? It never occurred to me as a user to look at the programs
in  the usr/bin areas as I thought everything was installed in
$HOME/bin.

Andrew

On Sun, 18 Oct 2020 at 19:33, Jean Abou Samra  wrote:
>
> On the output of this file, `lilymidi --pretty` indeed gives: ...

Re: Vertical spacing inside the music

[Павел]

Thanks, Jean, I think so too. Coming back to my question, how to control 
vertical spacing inside music? For example, I want to have #10 
basic-distance at start of a piece and #15 basic-distance since 12-th 
measure.


20.10.2020 15:14, Jean Abou Samra пишет:


Le 20/10/2020 à 14:06, Павел a écrit :
Hello. I'm looking for the "right" way to control vertical spacing 
within music. The example below doesn't work. Now I know only 
explicit vertical spacing via NonMusicalPaperColumn, and dirty hacks 
like a very low invisible note.


<<
    \new Staff {
    c' c' c' c'
    \override 
Score.VerticalAxisGroup.staff-staff-spacing.basic-distance = #20

        c' c' c' c'
    }
    \new Staff { c' c' c' c' c' c' c' c' }
>>



Hello,

VerticalAxisGroup is a special object, which (I believe) is only
created once per score. Therefore, you need to set its properties
globally.

\layout {
  \context {
    \Staff
    \override VerticalAxisGroup.staff-staff-spacing.basic-distance = #20
  }
}

<<
  \new Staff { c' c' c' c' c' c' c' c' }
  \new Staff { c' c' c' c' c' c' c' c' }
>>

Best regards,
Jean

Re: showLastLength/Score.skipTypesetting

[Martín Rincón Botero]

Hi Jean,

thank you for your idea with the paper block. Indeed having a separate
paper and header block for these pages is the way to go. I can also add
first-page-number = #myPage and that way it's virtually possible to make a
decent-looking pdf out of individual pages before applying a "refresh all"
Lilypond command if desired. However, if I remove the tempo and time
signature engravers for the page I want, I can't print any tempo or time
signature changes anymore. It would be fine for many pages in many pieces
but not for pieces with tempo and time signature changes. Perhaps it would
be good to know, when using showLastLength/Score.skipTypesetting for
measures other than the first measure, why does Lilypond have to
incorrectly make indentation, print a header, tempo and time signature?
Maybe a simple condition could be added to
showLastLength/Score.skipTypesetting for measure numbers higher than 1? If
yes, I would like to make this a feature request :-).

> PS: There is also a trick to speed up compilation for large scores:
>
> \paper {
>   page-breaking = #ly:minimal-breaking
> }
>
Thanks for the trick. I haven't used that mode yet. Good to know this
speeds up compilation!

Am Di., 20. Okt. 2020 um 14:08 Uhr schrieb Jean Abou Samra <
j...@abou-samra.fr>:

>
> Le 19/10/2020 à 22:44, Martín Rincón Botero a écrit :
>
> Hello Jean,
>
> thank you for your answer. It’s not a critical thing, but since I moved
> all my workflow to Python to be able to use its automating capabilities for
> producing Lilypond files, today I started using OLL’s partial compilation
> together with a couple of subprocesses that are run at the end of the
> Python file (the ones that actually write my Lilypond file), so that with
> the help of partial compilation and a pdf utility, it produces a separate
> partially compiled pdf of only one page (the page I’m working on), then the
> script merges that headerless, indentless pdf with a “memory pdf” (say, the
> first page), so that I can see a single merged pdf with all the music at
> all times, and I only need to compile one page at a time: whenever I need a
> new page I just tell the partial compilation the measure the next page
> begins with and write the page number I want compiled. This pdf “grows” out
> of compiling page by page. This has exponentially increased the efficiency
> of my workflow, since Lilypond’s compilation times get only larger with
> more information, whereas compiling only one page gets done quickly.
> Certainly this pdf is not gonna be the final pdf. When I’m finished, I’ll
> run a full compilation. But it seems to me that to get things done quickly,
> the actual Lilypond command should only be used as a sort of “refresh all
> layout” command. This approach works very well, except for unexisting page
> numbers (basically unimportant for a temporary pdf, although from a user
> perspective you might wonder why partial compilation doesn’t just put the
> page number I manually gave it...), and a tempo and time signature marking
> at the beginning of every page. It’s not the end of the world, because this
> is not a final pdf, but it would be nice if I didn’t have those markings at
> all (to be honest, I don’t like them either when using “plain”
> showLastLength et al. without my Python pipeline, and can’t see any reason
> why they show by default anyways unless the first measure shown has an
> explicit tempo or time signature change).
>
> Other than my way of working with Python, I can see this method as having
> potential for a sort of page by page compilation mode in Frescobaldi, but
> that would need said Lilypond commands to not give extra information to the
> user unless explicitely told to do so.
>
>
> Hello,
>
> This is an interesting workflow; I'll have to think of it.
>
> As mentioned before, you could use the header from this example:
>
> \version "2.23.0"
>
> \paper {
>   print-first-page-number = ##t
> }
>
> \layout {
>   \context {
> \Staff
> \remove Time_signature_engraver
>   }
>   \context {
> \Score
> \remove Metronome_mark_engraver
>   }
> }
>
> {
>   \tempo "Vivace"
>   \time 3/4
>   \key cis \major
>   c'2.\break
>   c'2.
> }
>
> I'd just comment out the header block, reintroducing it later when the
> work is done.
>
> Best,
> Jean
>
> PS: There is also a trick to speed up compilation for large scores:
>
> \paper {
>   page-breaking = #ly:minimal-breaking
> }
>
>
> www.martinrinconbotero.com
> On 19. Oct 2020, 22:11 +0200, Jean Abou Samra 
> , wrote:
>
> Le 19/10/2020 à 17:32, Martín Rincón Botero a écrit :
>
> Hello,
>
> I wanted to ask if there's a way to prevent
> showLastLength/Score.skipTypesetting from showing tempo and time signature
> (and header information if possible).
>
> Regards,
> Martín.
>
> Hi,
>
> I don't know an obvious way to do this, though you could
> remove the appropriate engravers. The question is, why do you
> want this? showLastLength and Score.skipTypesetting
> are for faster development, so you 

Re: Vertical spacing inside the music

[Jean Abou Samra]

Le 20/10/2020 à 14:06, Павел a écrit :
Hello. I'm looking for the "right" way to control vertical spacing 
within music. The example below doesn't work. Now I know only explicit 
vertical spacing via NonMusicalPaperColumn, and dirty hacks like a 
very low invisible note.


<<
    \new Staff {
    c' c' c' c'
    \override 
Score.VerticalAxisGroup.staff-staff-spacing.basic-distance = #20

        c' c' c' c'
    }
    \new Staff { c' c' c' c' c' c' c' c' }
>>



Hello,

VerticalAxisGroup is a special object, which (I believe) is only
created once per score. Therefore, you need to set its properties
globally.

\layout {
  \context {
    \Staff
    \override VerticalAxisGroup.staff-staff-spacing.basic-distance = #20
  }
}

<<
  \new Staff { c' c' c' c' c' c' c' c' }
  \new Staff { c' c' c' c' c' c' c' c' }
>>

Best regards,
Jean

Re: showLastLength/Score.skipTypesetting

[Jean Abou Samra]

Le 19/10/2020 à 22:44, Martín Rincón Botero a écrit :

Hello Jean,

thank you for your answer. It’s not a critical thing, but since I 
moved all my workflow to Python to be able to use its automating 
capabilities for producing Lilypond files, today I started using OLL’s 
partial compilation together with a couple of subprocesses that are 
run at the end of the Python file (the ones that actually write my 
Lilypond file), so that with the help of partial compilation and a pdf 
utility, it produces a separate partially compiled pdf of only one 
page (the page I’m working on), then the script merges that 
headerless, indentless pdf with a “memory pdf” (say, the first page), 
so that I can see a single merged pdf with all the music at all times, 
and I only need to compile one page at a time: whenever I need a new 
page I just tell the partial compilation the measure the next page 
begins with and write the page number I want compiled. This pdf 
“grows” out of compiling page by page. This has exponentially 
increased the efficiency of my workflow, since Lilypond’s compilation 
times get only larger with more information, whereas compiling only 
one page gets done quickly. Certainly this pdf is not gonna be the 
final pdf. When I’m finished, I’ll run a full compilation. But it 
seems to me that to get things done quickly, the actual Lilypond 
command should only be used as a sort of “refresh all layout” command. 
This approach works very well, except for unexisting page numbers 
(basically unimportant for a temporary pdf, although from a user 
perspective you might wonder why partial compilation doesn’t just put 
the page number I manually gave it...), and a tempo and time signature 
marking at the beginning of every page. It’s not the end of the world, 
because this is not a final pdf, but it would be nice if I didn’t have 
those markings at all (to be honest, I don’t like them either when 
using “plain” showLastLength et al. without my Python pipeline, and 
can’t see any reason why they show by default anyways unless the first 
measure shown has an explicit tempo or time signature change).


Other than my way of working with Python, I can see this method as 
having potential for a sort of page by page compilation mode in 
Frescobaldi, but that would need said Lilypond commands to not give 
extra information to the user unless explicitely told to do so.




Hello,

This is an interesting workflow; I'll have to think of it.

As mentioned before, you could use the header from this example:

\version "2.23.0"

\paper {
  print-first-page-number = ##t
}

\layout {
  \context {
    \Staff
    \remove Time_signature_engraver
  }
  \context {
    \Score
    \remove Metronome_mark_engraver
  }
}

{
  \tempo "Vivace"
  \time 3/4
  \key cis \major
  c'2.\break
  c'2.
}

I'd just comment out the header block, reintroducing it later when the 
work is done.


Best,
Jean

PS: There is also a trick to speed up compilation for large scores:

\paper {
  page-breaking = #ly:minimal-breaking
}



www.martinrinconbotero.com
On 19. Oct 2020, 22:11 +0200, Jean Abou Samra , wrote:


Le 19/10/2020 à 17:32, Martín Rincón Botero a écrit :


Hello,

I wanted to ask if there's a way to prevent 
showLastLength/Score.skipTypesetting from showing tempo and time 
signature (and header information if possible).


Regards,
Martín.


Hi,

I don't know an obvious way to do this, though you could
remove the appropriate engravers. The question is, why do you
want this? showLastLength and Score.skipTypesetting
are for faster development, so you usually don't much care
about the look of the output. This sounds like there could
be better tools to achieve your objectives.

Best,
Jean

Vertical spacing inside the music

[Павел]

Hello. I'm looking for the "right" way to control vertical spacing 
within music. The example below doesn't work. Now I know only explicit 
vertical spacing via NonMusicalPaperColumn, and dirty hacks like a very 
low invisible note.


<<
    \new Staff {
    c' c' c' c'
    \override 
Score.VerticalAxisGroup.staff-staff-spacing.basic-distance = #20

        c' c' c' c'
    }
    \new Staff { c' c' c' c' c' c' c' c' }
>>

Re: A Beam and a Slur in a Bracketed Tuplet

[Marc Shepherd]

Many thanks! Your manual shape override did the trick. I am new to LP and
honestly amazed how often it makes "pretty good" or great decisions.
Problems like this stand out for their rarity.

On Tue, Oct 20, 2020 at 3:59 AM Jean Abou Samra  wrote:

>
> Le 20/10/2020 à 01:08, Marc Shepherd a écrit :
>
> The reason the tuplet is up, is that — in the actual music, there is a
> lower voice, so the tuplet *has to be* up. I left out the lower voice in
> my example, because it is not relevant to the behavior I am asking about.
>
> In the real score, I have not overridden the tuplet and slur direction.
> With the lower voice present, LP automatically puts the slur and tuplet
> bracket "up", with the "crashing" behavior I showed.
>
> Hello,
>
> I just discovered that this is a known issue:
>
> https://gitlab.com/lilypond/lilypond/-/issues/1642
>
> Best regards,
> Jean
>


-- 
Marc Shepherd

Re: Some wild considerations and a question

[Jonas Hahnfeld]

Let me address the points about GUB:

Am Dienstag, den 20.10.2020, 11:03 +0200 schrieb Jean Abou Samra:
> > > - rely only on C++, flex, bison and the extension language.
> > >    Eliminating the need for GUB and Python would greatly simplify
> > >    porting LilyPond to various environments, including web sites,
> > >    phones and tablets.

I don't see how eliminating GUB simplifies porting to "various
environments". As others have said, it's only used to produce the
official binaries distributed for user convenience. This process is
complex and needs some form of automation, which is the reason why GUB
was created. Now even if moving to something else, it will still only
support a limited set of targets.

> > GUB will be history soon, thanks to the work mainly of Jonas.

Your mileage may vary, but I don't see this happening "soon", as in the
next few months. Right now it's more of a proof-of-concept that native
binaries for a number of architectures could be produced with a set of
generic scripts.

> Is this true, Jonas? I've heard of scripts you wanted to replace
> GUB with, but the last time I read about them, Han-Wen was skeptical
> of this idea because GUB had precisely been created to replace the
> scripts that were used before and were a nightmare to maintain.

I don't want to digress into this topic right now (P.S. the reply got
longer than I initially anticipated), but the scripts have a much
narrower focus: they mostly compile native binaries (except for Windows
via mingw) instead of cross-compiling for all targets. In my experience
from helping with GUB in the past year, that's the main source of
complexity for usage and maintenance. Moreover, this choice also
outright prevents 64-bit executables for macOS because of Apple's
restrictions with regard to their toolchain.

I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
just too much (a package manager for building arbitrary packages for
various targets; where we only do LilyPond to a handful) by using a too
powerful language and architecture (Python 2 with dynamic dependency
resolution and generic interfaces to various build systems). I think we
should learn from that and choose a design that avoids the pitfalls.

But again, that's nothing I'm expecting to happen "soon". Also because
an eventual transition to Guile 2 plays an important role here: I don't
want to plug that into GUB, but Guile 1.x is fundamentally incompatible
with 64-bit binaries for Windows.

Closing words: In general, a replacement for GUB is not something to be
discussed in length on -user. This must happen in a proper thread on
the -devel list, and hopefully with more technical content than just
the statement of "we need something better".

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Scheme expressions on lilypond command line (-e)

[Dave Seidel]

This is excellent, Aaron, thanks very much. Learning by example suits me
well, and I'm enjoying getting into Scheme. I use Python + Java all day
long on the job (in fact used Python to generate all of the music parts of
the score I'm working on -- it's originally a Csound piece that was written
using Python in the first place), and it's good for the brain to get
stretched into a different paradigm.

- Dave

On Mon, Oct 19, 2020 at 11:26 PM Aaron Hill 
wrote:

> On 2020-10-19 7:51 pm, Dave Seidel wrote:
> > More succinct:
> >
> > #(begin
> >   (use-modules (guile-user))
> >
> >   (if (not(defined? 'part))
> > (define partName "")
> > (define partName (string-append "S" (number->string part)))
> >   )
> > )
>
> To be even more succinct, observe the following:
>
> 
> Avoid negated predicates by swapping the consequent and alternate.
> 
> (if (defined? 'part)
>  (define partName (string-append "S" (number->string part)))
>  (define partName ""))
> 
>
> 
> Extract common logic from consequent and alternate.
> 
> (define partName
>(if (defined? 'part)
>(string-append "S" (number->string part))
>""))
> 
>
> 
> Use formatted output instead of manual string conversion/concatenation.
> 
> (define partName
>(if (defined? 'part)
>(format #f "S~d" part)
>""))
> 
>
>
> -- Aaron Hill
>
>

Re: Some wild considerations and a question

[Jean Abou Samra]

Greetings everybody,



- rely only on C++, flex, bison and the extension language.
   Eliminating the need for GUB and Python would greatly simplify
   porting LilyPond to various environments, including web sites,
   phones and tablets.


GUB will be history soon, thanks to the work mainly of Jonas.



Is this true, Jonas? I've heard of scripts you wanted to replace
GUB with, but the last time I read about them, Han-Wen was skeptical
of this idea because GUB had precisely been created to replace the
scripts that were used before and were a nightmare to maintain.

Le 19/10/2020 à 23:57, David Kastrup a écrit :

Jacques Menu  writes:


Hello folks,

Sorry, this message is rather long…


I’ve been wondering what design decisions would be made, should
someone start a project like LilyPond today, with the years-long
experience we have behind us in this field.

LilyPond can be characterized the following way, please excuse any
important omission or error:
- its native syntax is TeX inspired;

Wrong.  Its earliest implementations used TeX as a backend and continued
where MPP, a preprocessor for a TeX-based music system let off.  As a
consequence, early accent input in lyrics was TeX-based (it isn't
anymore), there is % as a line comment character and \ for introducing a
control sequence/word.  That's about it.  Very few lexical similarities
that actually remain these days.  You cannot change syntax on the fly
(as with TeX), the input is structured and nested and has a grammar.


Well, to me there is still a vague (yes, vague) family resemblance in 
things like


\paper {
  indent = 5\mm
}

I agree that it's become loose over the time.


Jacques, let me add one thing to the list: LilyPond was created with its
own fonts. It also has involved spacing algorithms as well as a workflow
relyingon complex relationship networks between objects.To me that is
the best part of LilyPond (since this is how it manages to produce beautiful
outuput). The less enthusing part is the difficulty to get your head 
around it.



Half of the wish list makes little sense in relation with what LilyPond
currently does.  Of course that may mean that what LilyPond currently
does is not transparent and accessible in sufficient degree to a typical
user.  Changing that is certainly a worthwhile and partly an ongoing
project.  I've actually invested a whole lot of work to make the
programmatic side of LilyPond match the user side of LilyPond better and
more naturally and get rid of strange things concerning the mapping of
music expressions to Scheme expressions.


Let me emphasize the point that already surfaced twice in this
thread: the lack of documentation of LilyPond's inner workings.
Learning how to extend LilyPond is, in my experience, a painful
process. To give just an example, Scheme engravers are documented
nowhere. This is in contrast with the otherwise extensive documentation
of every possible type of notation in the Notation Reference.

When/if I get sufficient time for this, I'd very much like to start
mailing list threads to ask questions about the internals of LilyPond,
in order to understand myself first, and have documentation come out of
that. This would benefit both users and the development team, I believe.


Cheers,
Jean

Re: A Beam and a Slur in a Bracketed Tuplet

[Jean Abou Samra]

Le 20/10/2020 à 01:08, Marc Shepherd a écrit :
The reason the tuplet is up, is that — in the actual music, there is a 
lower voice, so the tuplet /has to be/ up. I left out the lower voice 
in my example, because it is not relevant to the behavior I am asking 
about.


In the real score, I have not overridden the tuplet and slur 
direction. With the lower voice present, LP automatically puts the 
slur and tuplet bracket "up", with the "crashing" behavior I showed.



Hello,

I just discovered that this is a known issue:

https://gitlab.com/lilypond/lilypond/-/issues/1642

Best regards,
Jean