Re: Multi-measure rests and mark collisions ...

[David Wright]

On Sun 24 Apr 2016 at 19:18:01 (+0100), Anthonys Lists wrote:
> On 24/04/2016 03:13, David Wright wrote:
> >On Sat 23 Apr 2016 at 11:25:05 (+0100), Wols Lists wrote:
> >>On 22/04/16 19:36, David Wright wrote:
> >>>On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:
> On 22/04/2016 14:31, Kieren MacMillan wrote:
> >David K wrote:
> >>>Hm?  How could you even have a compressed multi-measure rest when there
> >>>is anything like an "8-bar phrase" in parallel?
> >>>That sounds like a problem that cannot occur.
> >I assume Wol (like me) has the problem where the compressed rest happens 
> >in the part, not in the full score — but one wants not to have to use 
> >multiple \tag constructs just to handle this issue.
> Exactly... I write my music with "voiceStaff" to contain all the
> score-level stuff eg tempi, tune names, rehearsal marks etc, and
> "voiceInstrument" to contain the stuff that varies by instrument, eg
> notes, dynamics, anything else like that ...
> 
> In the case example, the phrase is eight bars long, commencing with
> a two-bar rest. For another instrument, it won't have a rest. And I
> don't want the output to change dramatically depending on what's in
> the part.
> 
> So of course, because voiceStaff is not meant to contain notes, it
> uses "s" all the time. And I very rarely produce scores, this case
> is absolutely typical for me in that we only have a bass-clef part,
> and because while some players in our section can read both, we have
> some players who can only read bass or treble clef so transposing is
> a regular requirement. So I'll have three parts to do, 1st, 2nd and
> bass.
> >>>I haven't followed all that. Is this the sort of thing you want?
> >>>
> >>Pretty much. In your example it's exactly okay - the "poco allegretto"
> >>is to the right of the rehearsal mark, so the four marks take three
> >>lines to display. (Note I tend to use box-barnumber, so my rehearsal
> >>marks can get quite wide :-)
> >>
> >>Now, imagine the "poco allegretto" and "This is the army mr jones" were
> >>the other way round - the "This" would collide with the rehearsal mark,
> >>and it would take four lines.
> >I'm not quite sure why you'd do that. The tempo is part of the
> >music. The tune titles that you want to include are not. But you can
> >add spaces to the beginnings of strings to avoid collisions.
> 
> Ah - does that mean the rehearsal mark would happily overwrite the
> blank space at the start of the other markup string?

Typically, yes.

> But as for "why would I want to do that" - to serve as an example
> maybe. Let's change it then. Get rid of the tempo. The title would
> still collide with the rehearsal mark, and it would still take three
> lines - I wouldn't save a line. But shift the title a couple of mill
> to the right, and it would drop down and save us a line. SAVING
> VERTICAL SPACE is the point.
> >
> >>I want some semi-automatic way so I can push the other markup to the
> >>right of the rehearsal mark and make sure I only use three lines. Oh -
> >>and if I use "extra-spacing-width" (which iirc works fine with
> >>multi-measure-rests), as soon as I have another part which actually has
> >>some notes in the first bar of the MMR, that first bar will be the same
> >>width as the markup so that then looks awful :-(
> >A lot in there. Your OP didn't have automation specified. Most people
> >drop into scheme for that, don't they?
> 
> Most people? Most people probably give up and go back to Sibelius,
> or Finale, or whatever. My day job was programming, and I haven't
> managed to get to grips with Scheme (it was FORTRAN/C, so Scheme is
> a bit of a culture shock :-) because time to concentrate and learn
> is a luxury :-(

Fair enough. I was making the point that LP sometimes looks like a
programming language but isn't actually one.

But it never ceases to amaze me how, if you post a reasonably
well-defined problem here, someone often posts a scheme solution.
But you have to factorise your problem into chunks that people
will feel inclined to tackle.

> >Why not push the rehearsal mark left if you want loads of text to the right?
> >I don't get the bit about notes in a MMR. Isn't that a contradiction?
> 
> Not really. My modus operandi is
> 
> voiceStaff = ...
> voiceInstrument1 = ...
> voiceInstrument2 = ...
> 
> \score {
>   <<
> voiceStaff
> voiceInstrument1
>   >>
> }
> \score {
>   <<
> voiceStaff
> voiceInstrument2
>   >>
> }
> 
> The problem is that the contents of voiceInstrumentx has a *major*
> influence on the way the contents of voiceStaff is displayed :-(
> Instrument1 may have an MMR, Instrument2 may have notes, they affect
> the bar spacing in different ways, and I may get markup collisions
> in one part, and no collisions in the other. Basically, lily is
> setting the notes, and then fitting the markup over the notes. There
> are occasions when you 

Re: Guitar bend error

[Devon LePage]

Thanks to everyone who responded! I appreciate it.

I think I might have some followup questions - like, how come the graceBend
slurs are always facing down in the output when it says “up” in the
definitions file? - but I’ll see if I can get the openlilylib files to work
first.

Although I want this score to have a TabStaff, the main reason I was using
Stephen MacNeil’s code library is because in general I need bend slurs
without the TabStaff. Thanks for that, Stephen!

-Devon.

On Sun, Apr 24, 2016 at 3:18 PM Federico Bruni  wrote:

> On Sun, Apr 24, 2016 at 11:38:31PM +0200, Thomas Morley wrote:
> > 2016-04-24 17:13 GMT+02:00 Stephen MacNeil :
> > >
> > > It was written by Marc Hohl I just adapted it to have no tab since I
> don't
> > > use tab
> > >
> > >
> > > see
> > >
> > >
> https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/guitar-string-bending
> > >
>
> For the records, this is the new home:
> https://github.com/openlilylib/snippets/tree/master/ly/tablature
>
> (the file is the same as in the old one, but future updates will be
> pushed to the new location.. unless Urs wants to keep the old
> in sync)
>
> > > Line breaks over bending notes are not supported and they are currently
> > > disabled, because otherwise the file would not compile as soon as page
> > > formatting decisions create such a situation.
> >
> >
> >
> > Manual inserting \noBreak or \break will probably not enough, without
> > \layout { \autoLineBreaksOff }
> >
> > Opposed to what is claimed in the quote from openlilylib above,
> > disabling line-breaks do not work sufficiently.
>
> I can add this to the README on github.
>
> > See the out put from:
> > \include "definitions.ily"
> >
> > \displayLilyMusic
> > \relative c'' {
> > \bendOn
> > c1( d)
> > c1( d)
> > }
> >
> > It returns in terminal:
> >
> > { { \override Voice.Slur.stencil = #slur::draw-pointed-slur
> > \override TabVoice.Slur.stencil = #slur::draw-bend-arrow
> > c''1( \noBreak } d''1) c''1( d''1) }
> >
> > The overrides last until the end, but the \noBreak occurs only once!!
> >
>
> True. Better to avoid these (likely) errors and use manual breaks.
> Minimal example reworked in the new openlilylib style:
>
> \version "2.19.40"
> \include "openlilylib"
>
> \useLibrary Tablature
> % Workaround for issue #136 at
> % https://github.com/openlilylib/snippets/issues/136
> #(display "")
> \useModule tablature.bending
>
> % Hack needed until issue #136 is fixed:
> % https://github.com/openlilylib/openlilylib/issues/136
> #(ly:message "loaded")
>
>
> music = \relative c'' {
>   \displayLilyMusic
>   \bendOn
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
>   c1( d)
> }
>
> \new StaffGroup <<
>   \new Voice \music
>   \new TabVoice \music
> >>
> % comment this line and it won't compile
> \layout { \autoLineBreaksOff }
>
> ___
> 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

Files to include on a flash drive

[Ralph Palmer]

Greetings -

My wife and I traveled to Cuba for 2 weeks recently. On our trip, we met a
number of Cuban musicians. I described, through an interpreter (my Spanish
is not very good yet), LilyPond and what it can do. Some of the musicians
expressed an interest in LilyPond. I'm pretty sure I can get a flash drive
to each of them, and I *think* I know what should be included, but I'd like
your input, both as to what to include and how to organize the contents. I
don't know what operating system they will be using (plus, there's the
possibility that they will share the contents of the flash drive), so I
would like to include files for Windows, Apple, and Linux. Also, most of
them are not fluent in English, so I'd like as much Spanish language
information and instruction as possible.

I appreciate your time and attention,

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Weird key sig accumulation

[Thomas Morley]

2016-04-25 0:48 GMT+02:00 David Kastrup :
> Simon Albrecht  writes:
>
>> Hello everybody,
>>
>> I’ve built some music functions to handle a large, multi-section
>> piece, and ran into a strange problem, which I could boil down to the
>> attached example.
>> If the concat-part function is called on the \key expression multiple
>> times in parallel, the \key expressions are accumulated in a way I’ve
>> never seen before. Why would that be?
>
> Because you are not copying the expression and still using it multiple
> times.  A big no-no.  Consequently, \transpose works multiple times on
> the identical expression.
>
> If you use stuff multiple times, _copy_ it.  Because LilyPond will
> generally _change_ expressions it is working on.
>
> Multiple \transpose, multiple \relative, multiple other stuff: all that
> you want to avoid occuring on the identical expression several times.
>
>> \version "2.19.39"
>>
>> global.1 = { \key c \major }
>>
>> concat-part =
>> #(define-music-function (al) (list?)
>>(make-sequential-music (map cdr al)))
>> buildPart =
>> #(define-music-function () ()
>>#{
>>  \new Voice <<
>>\concat-part \global
>>{ c'1 }
>>  >>
>>#})
>>
>> \transpose c d <<
>>   \buildPart
>>   \buildPart

>
> --
> David Kastrup



David was faster...
Same problem as sometimes with #/$-signs.

Cheers,
  Harm

P.S.
David did not provide an improved code. Maybe because searching it,
may teach more.
Though, we're on the user list, so I attach it for follow readers.

\version "2.19.40"

global.1 = { \key c \major }

concat-part =
#(define-music-function (al) (list?)
   (ly:music-deep-copy (make-sequential-music (map cdr al
   
buildPart =
#(define-music-function () ()
   #{
 \new Voice <<
   \concat-part \global
   { c'1 }
 >>
   #})

\transpose c d <<
  \buildPart
  \buildPart
>>

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

Re: Weird key sig accumulation

[David Kastrup]

Simon Albrecht  writes:

> Hello everybody,
>
> I’ve built some music functions to handle a large, multi-section
> piece, and ran into a strange problem, which I could boil down to the
> attached example.
> If the concat-part function is called on the \key expression multiple
> times in parallel, the \key expressions are accumulated in a way I’ve
> never seen before. Why would that be?

Because you are not copying the expression and still using it multiple
times.  A big no-no.  Consequently, \transpose works multiple times on
the identical expression.

If you use stuff multiple times, _copy_ it.  Because LilyPond will
generally _change_ expressions it is working on.

Multiple \transpose, multiple \relative, multiple other stuff: all that
you want to avoid occuring on the identical expression several times.

> \version "2.19.39"
>
> global.1 = { \key c \major }
>
> concat-part =
> #(define-music-function (al) (list?)
>(make-sequential-music (map cdr al)))
> buildPart =
> #(define-music-function () ()
>#{
>  \new Voice <<
>\concat-part \global
>{ c'1 }
>  >>
>#})
>
> \transpose c d <<
>   \buildPart
>   \buildPart
>>>

-- 
David Kastrup

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

Weird key sig accumulation

[Simon Albrecht]

Hello everybody,

I’ve built some music functions to handle a large, multi-section piece, 
and ran into a strange problem, which I could boil down to the attached 
example.
If the concat-part function is called on the \key expression multiple 
times in parallel, the \key expressions are accumulated in a way I’ve 
never seen before. Why would that be?
The original piece is in five parts, and having A sharp major with ten 
sharps pop up on a score by di Lasso was somewhat funny :-)


Best, Simon
\version "2.19.39"

global.1 = { \key c \major }

concat-part =
#(define-music-function (al) (list?)
   (make-sequential-music (map cdr al)))
buildPart =
#(define-music-function () ()
   #{
 \new Voice <<
   \concat-part \global
   { c'1 }
 >>
   #})

\transpose c d <<
  \buildPart
  \buildPart
>>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Guitar bend error

[Federico Bruni]

On Sun, Apr 24, 2016 at 11:38:31PM +0200, Thomas Morley wrote:
> 2016-04-24 17:13 GMT+02:00 Stephen MacNeil :
> >
> > It was written by Marc Hohl I just adapted it to have no tab since I don't
> > use tab
> >
> >
> > see
> >
> > https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/guitar-string-bending
> >

For the records, this is the new home:
https://github.com/openlilylib/snippets/tree/master/ly/tablature

(the file is the same as in the old one, but future updates will be
pushed to the new location.. unless Urs wants to keep the old
in sync)

> > Line breaks over bending notes are not supported and they are currently
> > disabled, because otherwise the file would not compile as soon as page
> > formatting decisions create such a situation.
> 
> 
> 
> Manual inserting \noBreak or \break will probably not enough, without
> \layout { \autoLineBreaksOff }
> 
> Opposed to what is claimed in the quote from openlilylib above,
> disabling line-breaks do not work sufficiently.

I can add this to the README on github.

> See the out put from:
> \include "definitions.ily"
> 
> \displayLilyMusic
> \relative c'' {
> \bendOn
> c1( d)
> c1( d)
> }
> 
> It returns in terminal:
> 
> { { \override Voice.Slur.stencil = #slur::draw-pointed-slur
> \override TabVoice.Slur.stencil = #slur::draw-bend-arrow
> c''1( \noBreak } d''1) c''1( d''1) }
> 
> The overrides last until the end, but the \noBreak occurs only once!!
> 

True. Better to avoid these (likely) errors and use manual breaks.
Minimal example reworked in the new openlilylib style:

\version "2.19.40"
\include "openlilylib"

\useLibrary Tablature
% Workaround for issue #136 at
% https://github.com/openlilylib/snippets/issues/136
#(display "")
\useModule tablature.bending

% Hack needed until issue #136 is fixed:
% https://github.com/openlilylib/openlilylib/issues/136
#(ly:message "loaded")


music = \relative c'' {
  \displayLilyMusic
  \bendOn
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
  c1( d)
}

\new StaffGroup <<
  \new Voice \music
  \new TabVoice \music
>>
% comment this line and it won't compile
\layout { \autoLineBreaksOff }

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

Re: Absfontsize wrong font size in final PDF

[reetpetite]

Thanks for your responses. The mysterious different point sizes solved my
issue. Thanks once more.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Absfontsize-wrong-font-size-in-final-PDF-tp189745p189984.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Guitar bend error

[Thomas Morley]

2016-04-24 17:13 GMT+02:00 Stephen MacNeil :
> Add a line break before bar 25
>
> r4 r8 e' g2 | \break  % gradual bend on g2 towards a |
>
> % BAR 25
>
> \bendGrace g8( a2) g2( | % gradual bend on g2 towards a |
>
> \bendGrace g8 a4 g8) e g2( | % gradual bend on g2 towards a |
>
>
>
> HTH
> Stephen
>
> It was written by Marc Hohl I just adapted it to have no tab since I don't
> use tab
>
>
> see
>
> https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/guitar-string-bending
>
> Line breaks over bending notes are not supported and they are currently
> disabled, because otherwise the file would not compile as soon as page
> formatting decisions create such a situation.



Manual inserting \noBreak or \break will probably not enough, without
\layout { \autoLineBreaksOff }

Opposed to what is claimed in the quote from openlilylib above,
disabling line-breaks do not work sufficiently.
See the out put from:
\include "definitions.ily"

\displayLilyMusic
\relative c'' {
\bendOn
c1( d)
c1( d)
}

It returns in terminal:

{ { \override Voice.Slur.stencil = #slur::draw-pointed-slur
\override TabVoice.Slur.stencil = #slur::draw-bend-arrow
c''1( \noBreak } d''1) c''1( d''1) }

The overrides last until the end, but the \noBreak occurs only once!!

Cheers,
  Harm

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Wright]

On Sun 24 Apr 2016 at 10:55:39 (+0200), m.tarensk...@zonnet.nl wrote:

[-- Attachment #1 --]
[-- Type: text/html, Encoding: base64, Size: 4.7K --]

[-- text/html is unsupported (use 'v' to view this part) --]

Please configure your client to post a text equivalent of your HTML code.

Cheers,
David.

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Wright]

On Sun 24 Apr 2016 at 10:00:38 (+0200), Urs Liska wrote:
> Am 24.04.2016 um 09:56 schrieb David Kastrup:
> > Noeck  writes:
> >>> So how do you define "the default"
> >> As written before: What ships with the default installation.
> > 
> > So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
> > (what happens when Python 4 gets created), and we need to either support
> > Python2 and Python3 in parallel (including from GUB) _or_ make a hard
> > switch where we change _every_ script to use Python3 _and_ change GUB
> > from one version to the next.
> > 
> > _And_ Wols insists that he does _not_ want to use a common subset of
> > Python2 and Python3 even temporarily but do this right away using
> > Python3-only features.
> > 
> > Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
> > make testing half-way reliable.  But in reality, the LilyPond code base
> > does not contain #!/usr/bin/python to any sizable degree (there is a
> > single script which might be an oversight) but instead #!@TARGET_PYTHON@
> > so again, there does not seem to be much of an alternative for an
> > all-or-nothing approach, and trying to mix this with making use of new
> > language features at the same time seems like a logistic nightmare.
> > 
> OK, but what happens when we face the situation that some distros have
> #!/usr/bin/python to Python 2 and other to Python 3?
> This is something we can't control at all, so at latest *then* we'd be
> in that situation, with the difference that *now* we have at least a
> chance to control the transition.

Has this not already happened? The rationale for PEP394 was
"This recommendation is needed as, even though the majority of
distributions still alias the python command to Python 2, some now
alias it to Python 3 ( [5] ). As some of the former distributions did
not provide a python2 command by default, there was previously no way
for Python 2 code (or any code that invokes the Python 2 interpreter
directly rather than via sys.executable ) to reliably run on all
Unix-like systems without modification, as the python command would
invoke the wrong interpreter version on some systems, and the python2
command would fail completely on others."

...which refers to https://www.archlinux.org/news/python-is-now-python-3/

>From https://wiki.archlinux.org/index.php/python of 7 April:
"Any program requiring Python 2 needs to point to /usr/bin/python2,
instead of /usr/bin/python, which points to Python 3. To do so, open
the program or script in a text editor and change the first line. The
line will show one of the following:
#!/usr/bin/env python or #!/usr/bin/python
In both cases, just change python to python2 and the program will then
use Python 2 instead of Python 3."

Jumping the gun a bit...

Cheers,
David.

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

make many icons

[Jim Tisdall]

I want to create about a hundred icons that contain short (2- 5-note) rhythms
or melodic shapes, without staff lines.  They will have no staff (which I see 
how
to do).  Ideally I could write them all in one file and invoke lilypond to 
create
the hundred or so svg files.  (My current solution is to create individual files
and compile, with perl script.)

Any advice about svg settings, lilypond input format, etc., to create many 
icons of short phrases?

Thanks,
Jim

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

Re: Guitar bend error

[Anthonys Lists]

On 24/04/2016 16:13, Stephen MacNeil wrote:

Add a line break before bar 25

r4 r8 e' g2 | \break  % gradual bend on g2 towards a |

% BAR 25

\bendGrace g8( a2) g2( | % gradual bend on g2 towards a |

\bendGrace g8 a4 g8) e g2( | % gradual bend on g2 towards a |



Or, if it's a longer piece and you want lily to choose the line breaks 
to look nice, you could put a \noBreak after bars 25 and 25?


r4 r8 e' g2 | % gradual bend on g2 towards a |

% BAR 25

\bendGrace g8( a2) g2( \noBreak | % gradual bend on g2 towards a |

\bendGrace g8 a4 g8) e g2( \noBreak | % gradual bend on g2 towards a |


(not tested, but that was my immediate reaction on reading this thread - 
disallow breaks where they're going to cause a problem)


Cheers,
Wol

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

Re: Multi-measure rests and mark collisions ...

[Anthonys Lists]

On 24/04/2016 03:13, David Wright wrote:

On Sat 23 Apr 2016 at 11:25:05 (+0100), Wols Lists wrote:

On 22/04/16 19:36, David Wright wrote:

On Fri 22 Apr 2016 at 15:47:59 (+0100), Anthonys Lists wrote:

On 22/04/2016 14:31, Kieren MacMillan wrote:

David K wrote:

Hm?  How could you even have a compressed multi-measure rest when there
is anything like an "8-bar phrase" in parallel?
That sounds like a problem that cannot occur.

I assume Wol (like me) has the problem where the compressed rest happens in the 
part, not in the full score — but one wants not to have to use multiple \tag 
constructs just to handle this issue.

Exactly... I write my music with "voiceStaff" to contain all the
score-level stuff eg tempi, tune names, rehearsal marks etc, and
"voiceInstrument" to contain the stuff that varies by instrument, eg
notes, dynamics, anything else like that ...

In the case example, the phrase is eight bars long, commencing with
a two-bar rest. For another instrument, it won't have a rest. And I
don't want the output to change dramatically depending on what's in
the part.

So of course, because voiceStaff is not meant to contain notes, it
uses "s" all the time. And I very rarely produce scores, this case
is absolutely typical for me in that we only have a bass-clef part,
and because while some players in our section can read both, we have
some players who can only read bass or treble clef so transposing is
a regular requirement. So I'll have three parts to do, 1st, 2nd and
bass.

I haven't followed all that. Is this the sort of thing you want?


Pretty much. In your example it's exactly okay - the "poco allegretto"
is to the right of the rehearsal mark, so the four marks take three
lines to display. (Note I tend to use box-barnumber, so my rehearsal
marks can get quite wide :-)

Now, imagine the "poco allegretto" and "This is the army mr jones" were
the other way round - the "This" would collide with the rehearsal mark,
and it would take four lines.

I'm not quite sure why you'd do that. The tempo is part of the
music. The tune titles that you want to include are not. But you can
add spaces to the beginnings of strings to avoid collisions.


Ah - does that mean the rehearsal mark would happily overwrite the blank 
space at the start of the other markup string?


But as for "why would I want to do that" - to serve as an example maybe. 
Let's change it then. Get rid of the tempo. The title would still 
collide with the rehearsal mark, and it would still take three lines - I 
wouldn't save a line. But shift the title a couple of mill to the right, 
and it would drop down and save us a line. SAVING VERTICAL SPACE is the 
point.



I want some semi-automatic way so I can push the other markup to the
right of the rehearsal mark and make sure I only use three lines. Oh -
and if I use "extra-spacing-width" (which iirc works fine with
multi-measure-rests), as soon as I have another part which actually has
some notes in the first bar of the MMR, that first bar will be the same
width as the markup so that then looks awful :-(

A lot in there. Your OP didn't have automation specified. Most people
drop into scheme for that, don't they?


Most people? Most people probably give up and go back to Sibelius, or 
Finale, or whatever. My day job was programming, and I haven't managed 
to get to grips with Scheme (it was FORTRAN/C, so Scheme is a bit of a 
culture shock :-) because time to concentrate and learn is a luxury :-(



Why not push the rehearsal mark left if you want loads of text to the right?
I don't get the bit about notes in a MMR. Isn't that a contradiction?


Not really. My modus operandi is

voiceStaff = ...
voiceInstrument1 = ...
voiceInstrument2 = ...

\score {
  <<
voiceStaff
voiceInstrument1
  >>
}
\score {
  <<
voiceStaff
voiceInstrument2
  >>
}

The problem is that the contents of voiceInstrumentx has a *major* 
influence on the way the contents of voiceStaff is displayed :-( 
Instrument1 may have an MMR, Instrument2 may have notes, they affect the 
bar spacing in different ways, and I may get markup collisions in one 
part, and no collisions in the other. Basically, lily is setting the 
notes, and then fitting the markup over the notes. There are occasions 
when you want to set the markup and then fit the notes under it.





The problem really is, all I want to do is stick multiple marks on a
barline (which doesn't work, lily doesn't do multiple \mark's :-(, and I
want to be able to move those markups to the right so they don't collide
with the rehearsal mark. \tempo *partly* solves my problem.

Well, that's a relief. BTW you can have multiple marks. My example had
one \tempo and the rest were marks.


The trouble
is, all the tweaks I've come up with (like for example "s1 s1*11") all
have side effects that don't matter in certain cases, and matter
enormously in others.

I haven't yet seen an example of what you want, not anything that
you've produced in the dim and distant past that 

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 


No disagreement here.  At the very least it would be verification that
the ones responsible for doing the GUB part of the transition are
comfortable with the basic necessities.



I think the only person likely to be able to upgrade GUB to python 2.7 2 
would be Masamichi.


--
Phil Holmes 



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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Paul Morris  writes:

>> On Apr 24, 2016, at 11:15 AM, David Kastrup  wrote:
>> 
>> Paul Morris  writes:
>> 
>>> IIUC, wouldn’t the first step be, in any case, to get LilyPond’s
>>> python scripts working on python 2.7?
>> 
>> Which ones _aren't_ working with Python 2.7?  I run a number of them
>> routinely, and I just converted some file with midi2ly as well.
>
> Sorry, my words weren’t very precise.  I don’t know of any scripts
> that aren’t working with 2.7.
>
> I jus wanted to make the point that since the LilyPond binaries ship
> with an earlier python version and that GUB still uses 2.4 (as
> mentioned earlier in the thread) that getting those things
> successfully upgraded to python 2.7 would be the first step to take
> (regardless of how we handle the transition to python 3).

No disagreement here.  At the very least it would be verification that
the ones responsible for doing the GUB part of the transition are
comfortable with the basic necessities.

> (Of course, you’re right that the transition to guile 2 is a much
> higher priority, but it seems we could use any help we can get
> wherever we can get it.)

I don't see that those tasks are competing for the same developers.

-- 
David Kastrup

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Paul Morris]

> On Apr 24, 2016, at 11:15 AM, David Kastrup  wrote:
> 
> Paul Morris  writes:
> 
>> IIUC, wouldn’t the first step be, in any case, to get LilyPond’s
>> python scripts working on python 2.7?
> 
> Which ones _aren't_ working with Python 2.7?  I run a number of them
> routinely, and I just converted some file with midi2ly as well.

Sorry, my words weren’t very precise.  I don’t know of any scripts that aren’t 
working with 2.7.

I jus wanted to make the point that since the LilyPond binaries ship with an 
earlier python version and that GUB still uses 2.4 (as mentioned earlier in the 
thread) that getting those things successfully upgraded to python 2.7 would be 
the first step to take (regardless of how we handle the transition to python 3).

(Of course, you’re right that the transition to guile 2 is a much higher 
priority, but it seems we could use any help we can get wherever we can get it.)

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

Re: Guitar bend error

[Stephen MacNeil]

>The code Stephan hosts is a nightmare, because all indentation has
>gone.

This is true :) but I actually read it better... not sure why. and not
being able to type fast it just works for me

cheers

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Paul Morris  writes:

> IIUC, wouldn’t the first step be, in any case, to get LilyPond’s
> python scripts working on python 2.7?

Which ones _aren't_ working with Python 2.7?  I run a number of them
routinely, and I just converted some file with midi2ly as well.

-- 
David Kastrup

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

Guitar bend error

[Stephen MacNeil]

Add a line break before bar 25

r4 r8 e' g2 | \break  % gradual bend on g2 towards a |

% BAR 25

\bendGrace g8( a2) g2( | % gradual bend on g2 towards a |

\bendGrace g8 a4 g8) e g2( | % gradual bend on g2 towards a |



HTH
Stephen

It was written by Marc Hohl I just adapted it to have no tab since I don't
use tab


see

https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/guitar-string-bending

Line breaks over bending notes are not supported and they are currently
disabled, because otherwise the file would not compile as soon as page
formatting decisions create such a situation.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Paul Morris]

IIUC, wouldn’t the first step be, in any case, to get LilyPond’s python scripts 
working on python 2.7?  Then at that point we could discuss and decide about 
whether it’s better to switch to python 3 or to support both 2.7 and 3.

Searching the LilyPond source code for files with extension “.py” turns up 
about 73 files, if anyone’s interested in a rough estimate of the scope.

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Davide Liessi]

2016-04-24 13:46 GMT+02:00 m.tarensk...@zonnet.nl :
> [...] Many python
> syntax can be compatible with both Python2 and Python3 without much effort.
> There are in practice only a few things that are a bit harder. For example
> strings/unicode/binary datatypes. If it's only a limited amount of old code
> that requires some effort to make it compatible with both Py2 and Py3 than
> that might be worth considering. Writing new code using a common subset
> isn't that difficult. That's where the six library can help.

Indeed, Frescobaldi 2 (just to mention the one I know best) has been
supporting both Python 2 and 3 for some months (Frescobaldi 3 however
will require Python 3).

Best wishes.
Davide

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Davide Liessi]

2016-04-23 13:59 GMT+02:00 Andrew Bernard :
> But lilypond ships its own internal version of python in …lilypond/usr/bin. 
> Is this not to shield lilypond from system versions?

In my experience, the Python interpreter bundled with LilyPond on Mac
is pretty unusable, also for running Python scripts bundled with
LilyPond.
In Frescobaldi we use the system-provided Python for them.

Best wishes.
Davide

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Federico Bruni]

On Sun, Apr 24, 2016 at 02:02:19PM +0200, Noeck wrote:
> > I will add a comment to the first of these two issues (and mark the second 
> > as duplicate):
> > https://sourceforge.net/p/testlilyissues/issues/1895/
> > https://sourceforge.net/p/testlilyissues/issues/1895/
> 
> Which two? They are the same. Probably just a copy-and-paste mistake.
> For completeness, it would still be good to have the two links here on
> the list.
> 

Sorry, I meant this:
https://sourceforge.net/p/testlilyissues/issues/1079/


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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Noeck]

> I will add a comment to the first of these two issues (and mark the second as 
> duplicate):
> https://sourceforge.net/p/testlilyissues/issues/1895/
> https://sourceforge.net/p/testlilyissues/issues/1895/

Which two? They are the same. Probably just a copy-and-paste mistake.
For completeness, it would still be good to have the two links here on
the list.

Best,
Joram

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[m.tarensk...@zonnet.nl]

How much python code are we talking about within the complete LilyPond project? The discussion until now seems to be a discussion about Python2/3 transitions in general. But maybe the situation isn't that bad. Many python syntax can be compatible with both Python2 and Python3 without much effort. There are in practice only a few things that are a bit harder. For example strings/unicode/binary datatypes. If it's only a limited amount of old code that requires some effort to make it compatible with both Py2 and Py3 than that might be worth considering. Writing new code using a common subset isn't that difficult. That's where the six library can help.MT Oorspronkelijk bericht Onderwerp: Re: Python 3, was Re: ANN: Frescobaldi 2.19.0Van: David Kastrup Aan: Werner LEMBERG Cc: lilypond-user@gnu.orgWerner LEMBERG  writes:>> So far we only have an offer for a hard and incompatible transition>> to Python3-only>> Actually, I dislike this.  Similar to you, I don't see a convincing> reason to not write python code that is compatible with both version 2> and version 3.Well, #!/usr/bin/guile can mean either Guile-1 and Guile-2 whereas#!/usr/bin/python is more or less guaranteed to mean Python-2 for quitea bit of time, even while there may be only Python-3 available at somepoint of time.So it does look like we are in for a hard change with regard todistributed LilyPond versions anyway.  However, the configure processvery well could substitute #!@TARGET_PYTHON@ (most installed scripts) aswell as #!@PYTHON@ (the build scripts) with either a Python-2 or aPython-3 hashbang, depending on availability/configuration of eitheroption.So we definitely have a use case for supporting both: then a choice canbe made by scripts or user at configure time.-- David Kastrup___lilypond-user mailing listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Werner LEMBERG  writes:

>> So far we only have an offer for a hard and incompatible transition
>> to Python3-only
>
> Actually, I dislike this.  Similar to you, I don't see a convincing
> reason to not write python code that is compatible with both version 2
> and version 3.

Well, #!/usr/bin/guile can mean either Guile-1 and Guile-2 whereas
#!/usr/bin/python is more or less guaranteed to mean Python-2 for quite
a bit of time, even while there may be only Python-3 available at some
point of time.

So it does look like we are in for a hard change with regard to
distributed LilyPond versions anyway.  However, the configure process
very well could substitute #!@TARGET_PYTHON@ (most installed scripts) as
well as #!@PYTHON@ (the build scripts) with either a Python-2 or a
Python-3 hashbang, depending on availability/configuration of either
option.

So we definitely have a use case for supporting both: then a choice can
be made by scripts or user at configure time.

-- 
David Kastrup

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

Re: error: can't allocate region - layout block?

[Thomas Morley]

2016-04-22 17:20 GMT+02:00 Carl Sorensen :
> On 4/22/16 7:11 AM, "matpen3@gmail"  wrote:
>
>>Hi all,
>>
>>I¹m again plagued by a memory error:
>>
>>lilypond(27883,0xa2db5000) malloc: *** mach_vm_map(size=106917888) failed
>>(error code=3)
>>*** error: can't allocate region
>>*** set a breakpoint in malloc_error_break to debug
>
> I can confirm this problem on OSX 10.8.5.
>
> I don't know how to solve it, but I have noticed that there is a
> programming error that occurs earlier in the output, probably due to some
> removed empty staves.  If this were my file, I would try to track down
> that programming error.  I think it may be related.
>
> Fitting music on 79 or 80 pages...
> Drawing systems...
> programming error: could not find this grob's vertical axis group in the
> vertical alignment
> continuing, cross fingers
> programming error: could not find this grob's vertical axis group in the
> vertical alignment
> continuing, cross fingers
>
>
> Note that this error mentions a missing vertical axis group, which is a
> container that holds staves.  Perhaps some grob is trying to be generated
> that is tied to a staff that has been removed.
>
> I have also noticed that the maximum memory used by LilyPond at the time
> the malloc error was thrown was about 2.45 GB.
>
> And I have confirmed that if I leave the layout block in, but comment out
> the RemoveAllEmptyStaves, there is no malloc error.  So the problem is
> clearly with removing the staves.  I believe that if you can track down
> the source of the programming error it will fix your malloc problem.
>
> But I don't have the time to go through your enormous score and track down
> the source of the programming error.  There are some suggestions in the
> documentation:
>
> http://lilypond.org/doc/v2.19/Documentation/usage/troubleshooting
>
>
> Good luck!
>
> Carl



@Carl
The problem occured in a previous version of matteos's code as well.
I boiled it down already, see my bug-report at
http://lilypond.1069038.n5.nabble.com/error-and-bad-output-with-VoltaBrackets-ossia-staffs-RemoveEmptyStaves-repeats-td189504.html

Not triage up to now, though.
And I've no clue how to circumvent it other than changing the whole
structure of matteo's coding.

@matteo
Your code is a nightmare to maintain and for tracking down problems.
I'd do:
(1) split it into parts. You repeatedly set currentBarNumber to 1.
Wouldn't there a new part be resonable?
(2) your Staffs don't compile on it's own, without loads of errors and
warnings, because information like the used time-signature, etc is not
everywhere implemented and available.
I'd use a global-variable for that.
(3) I've the suspicion the memory problem is still caused by the
numerous ossia staffs.
Not always creating new ones, but sending stuff only to the same
ossia-staves brought you some steps further.
But you use always the syntax like in my bug-report (simultaneous-music).
Maybe, but I can't warrant, it would be better to fill those ossias
directly not from the main-staves.
Though, even while using \start/stopStaff some problems needs to be
solved, among them instrumentNames, KeySignatures, Clefs,
TimeSignatures, TupletBrackets displayed where you don't want them.

See the output of the changed bug-reports-coding:

\paper { indent = 20 short-indent = 20 }

\layout {
  \context {
\Score
\override VerticalAxisGroup #'remove-first = ##t
  }
  \context {
\Staff
\RemoveEmptyStaves
  }
}


mI = {
  c1
  \break
  \repeat volta 2 { d }
  \alternative { { e } { eis } }
  \repeat volta 2 { f }
}

mII = {
  c1 d e eis f
}

ossiaI = {
  \stopStaff
  s1*4
  \startStaff
  fis
  \stopStaff
}

ossiaII = {
  \stopStaff
  s1*4
  \startStaff
  gis
  \stopStaff
}


<<
  \new Staff = "up-ossia"
\with { instrumentName = "up-ossia " shortInstrumentName = "up-ossia " }
\ossiaI
  \new Staff
\with { instrumentName = "up " shortInstrumentName = "up" }
\mI
  \new Staff
\with { instrumentName = "down" shortInstrumentName = "down" }
\mII
  \new Staff = "down-ossia"
\with { instrumentName = "down-ossia " shortInstrumentName = "down-ossia" }
\ossiaII
>>

Cheers,
  Harm

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Werner LEMBERG]

> So far we only have an offer for a hard and incompatible transition
> to Python3-only

Actually, I dislike this.  Similar to you, I don't see a convincing
reason to not write python code that is compatible with both version 2
and version 3.


Werner

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

Re: Guitar bend error

[Thomas Morley]

2016-04-24 7:50 GMT+02:00 Devon LePage :
> I’m transcribing a rock guitar solo, and to engrave the many string bends
> I’m using Stephen MacNeil’s LilyPond code library, available here:
>
> http://mglessons.com/lilypond/

The code Stephan hosts is a nightmare, because all indentation has
gone. For further testing I used my own version of the bend-files
which should be pretty much the same as hosted at openlilylib.

> If I use the “definitions_No-Tab.ly” file, LilyPond engraves the file with
> no hiccups. However, if I use the “definitions.ily” for notation and TAB, I
> get the following error:
>
> Drawing
> systems.../Users/devon/Downloads/lilypond-archive/guitar_functions/definitions.ily:180:14:
> In procedure ly:event-property in expression (ly:event-property (event-cause
> right-bound) (quote pitch)):
>
> /Users/devon/Downloads/lilypond-archive/guitar_functions/definitions.ily:180:14:
> Wrong type argument in position 1 (expecting Prob): #f
>
> Exited with return code 1.
>
>
> Learning Scheme is still on my to-do list, so I don’t quite understand
> what’s going on here. Frustratingly, I can’t seem to localize the error -
> I’ve tried compiling the file with different sections commented out, but the
> error isn’t consistently generated. A few times it happened at bar 13, but
> then it happened at bar 31, and then a few more times at places in between.
> It reliably compiles for the first 12 bars, but that’s it.
>
>
> I’ve put the LilyPond code in a Gist here:
>
>
> https://gist.github.com/devonlepage/624c66513538ad6b42de0f665857ade7
>
>
> This is the first third of the transcription. I’m hoping it will be enough
> that someone might be able to diagnose the problem. I’ve taken out all
> extraneous formatting code, which didn’t seem to effect the error.
>
>
> I’m using Frescobaldi 2.19 with LilyPond 2.19.40. It also happens in 2.18. I
> would prefer to use 2.19 so that I can use an alternative music font in the
> final document.
>
>
> I hope someone can help me figure out what’s going on.
>
>
> Thanks!
>
>
> -Devon LePage.

The problem is line-breaking. The bending-code doesn't support it.
Honestly, I've no clue how it should look at line-break.
To proof whether it's a line-break-issue include:

\paper { page-breaking = #ly:one-line-breaking }

You'll see the error vanished.

A minimal breaking example:

\include "definitions.ily"
\new TabVoice \relative c'' { \bendOn c1( \break d) }


Though, what to do?
Currently breaks are disabled at the end of \bendOn, which sometimes
is not enough.
It is likely possible to disallow line-breaks at all while \bendOn
works. But is surely not what you want, while applying \bendOn to a
larger piece of music.

Best I can think of is to disallow breaks at all, inserting them all manually.
For that you could use:

\layout { \autoLineBreaksOff }


HTH,
  Harm

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

Re: Key list in lyricmode

[Simon Albrecht]

On 24.04.2016 07:53, David Kastrup wrote:

Simon Albrecht  writes:


Hello everybody, (well, to be honest, hello David :-) )

I’m sorry, but I still need some enlightenment on the new alist
variable feature. What’s the problem with the following snippet?

%%%
\version "2.19.39"

cantus.1 = { e' }
cantus.lyr.1 = \lyricmode { Mi }

<<
   { \cantus.1 }
   \addlyrics { \cantus.lyr.1 }
%%%

I get

debug.ly:8:24: error: not a key
   \addlyrics { \cantus.
lyr.1 }

and so a non-music expression is getting ignored.
Basic testing didn’t quite show what the limitation is.

lyr.1 is a lyrics syllable "lyr." with a duration of 1 (whole note).
You'll likely need to space this out.

\cantus . lyr . 1

so that the dots do not become word parts.  You could probably write

\cantus.lyr .1

but that's a bit more ugly.  There is trickery in lyricsmode that will
accept long words like Lyrics.TextScript.color and split them up into a
list, but lyr.1 is not a long word but a word followed by a duration,
and lyr. alone cannot be split into parts while it is still a valid
syllable.


OK, thanks. That works (luckily all 101 instances could be fixed by a 
simple search: ".lyr." => " . lyr . " :-) )


Best, Simon

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[BB]

If anybody likes to check the difference between 2-3 here are just two links
https://docs.python.org/3/whatsnew/3.0.html
http://www.cs.carleton.edu/faculty/jgoldfea/cs201/spring11/Python2vs3.pdf

There are many more docs on internet dealing with the version 
differences ...



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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

"m.tarensk...@zonnet.nl"  writes:

> Has anyone considered using the six library? Six has helped me a lot
> in my own Python projects to write code that is compatible with both
> python2 and python3.

Well, as long as we have no one considering doing a gradual
python2/python3 transition, there is not much of a point in considering
a library facilitating it, is there?

So far we only have an offer for a hard and incompatible transition to
Python3-only (and the point of my contributions to that discussion was
just to make it clear how much work that might actually mean), and it is
my completely uninformed guess that a library supposed to help with
maintaining two-way compatible code would not help much for that.

-- 
David Kastrup

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[m.tarensk...@zonnet.nl]

Has anyone considered using the six library? Six has helped me a lot in my own Python projects to write code that is compatible with both python2 and python3. MT Oorspronkelijk bericht Onderwerp: Re: Python 3, was Re: ANN: Frescobaldi 2.19.0Van: David Kastrup Aan: Urs Liska Cc: lilypond-user@gnu.orgUrs Liska  writes:> Am 24.04.2016 um 09:56 schrieb David Kastrup:>> Noeck  writes:>>  So how do you define "the default">> As written before: What ships with the default installation.>> >> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts>> (what happens when Python 4 gets created), and we need to either support>> Python2 and Python3 in parallel (including from GUB) _or_ make a hard>> switch where we change _every_ script to use Python3 _and_ change GUB>> from one version to the next.>> >> _And_ Wols insists that he does _not_ want to use a common subset of>> Python2 and Python3 even temporarily but do this right away using>> Python3-only features.>> >> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to>> make testing half-way reliable.  But in reality, the LilyPond code base>> does not contain #!/usr/bin/python to any sizable degree (there is a>> single script which might be an oversight) but instead #!@TARGET_PYTHON@>> so again, there does not seem to be much of an alternative for an>> all-or-nothing approach, and trying to mix this with making use of new>> language features at the same time seems like a logistic nightmare.>> >> OK, but what happens when we face the situation that some distros have> #!/usr/bin/python to Python 2 and other to Python 3?> This is something we can't control at all, so at latest *then* we'd be> in that situation, with the difference that *now* we have at least a> chance to control the transition.>> I think this is about what Federico meant with this Guile 1.8/2> comparison - he didn't mean to say that we are in that situation *now*> but that we might run into it when the decisions of the distros are taken.Our scripts run with either Guile-1.8 or Guile-2.0 as far as I can tell.Which is sort-of a soft transition.  It's just core LilyPond which hasnot yet been ported over to the Guile-2 kernel and linkable libraries.But we have statements here to the effect that those interested in theporting are not interested in using a common subset for the Python3effort (which we won't likely be able to put off forever).  I ampointing out the consequences of such an approach.  It will cause awhole lot of work and fallout, and it's not at all clear to me that thebulk of those consequences will rest on the shoulders of those who wantto have it done in that manner.And I haven't seen _any_ compelling argument yet _why_ there is nouseful common ground between Python2 and Python3 that could do the jobwithout major rewrites of the current code base.-- David Kastrup___lilypond-user mailing listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Urs Liska  writes:

> Am 24.04.2016 um 09:56 schrieb David Kastrup:
>> Noeck  writes:
>> 
 So how do you define "the default"
>>>
>>> As written before: What ships with the default installation.
>> 
>> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
>> (what happens when Python 4 gets created), and we need to either support
>> Python2 and Python3 in parallel (including from GUB) _or_ make a hard
>> switch where we change _every_ script to use Python3 _and_ change GUB
>> from one version to the next.
>> 
>> _And_ Wols insists that he does _not_ want to use a common subset of
>> Python2 and Python3 even temporarily but do this right away using
>> Python3-only features.
>> 
>> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
>> make testing half-way reliable.  But in reality, the LilyPond code base
>> does not contain #!/usr/bin/python to any sizable degree (there is a
>> single script which might be an oversight) but instead #!@TARGET_PYTHON@
>> so again, there does not seem to be much of an alternative for an
>> all-or-nothing approach, and trying to mix this with making use of new
>> language features at the same time seems like a logistic nightmare.
>> 
>
> OK, but what happens when we face the situation that some distros have
> #!/usr/bin/python to Python 2 and other to Python 3?
> This is something we can't control at all, so at latest *then* we'd be
> in that situation, with the difference that *now* we have at least a
> chance to control the transition.
>
> I think this is about what Federico meant with this Guile 1.8/2
> comparison - he didn't mean to say that we are in that situation *now*
> but that we might run into it when the decisions of the distros are taken.

Our scripts run with either Guile-1.8 or Guile-2.0 as far as I can tell.
Which is sort-of a soft transition.  It's just core LilyPond which has
not yet been ported over to the Guile-2 kernel and linkable libraries.

But we have statements here to the effect that those interested in the
porting are not interested in using a common subset for the Python3
effort (which we won't likely be able to put off forever).  I am
pointing out the consequences of such an approach.  It will cause a
whole lot of work and fallout, and it's not at all clear to me that the
bulk of those consequences will rest on the shoulders of those who want
to have it done in that manner.

And I haven't seen _any_ compelling argument yet _why_ there is no
useful common ground between Python2 and Python3 that could do the job
without major rewrites of the current code base.

-- 
David Kastrup

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Federico Bruni]

On Sun, Apr 24, 2016 at 09:44:33AM +0200, Thomas Morley wrote:
> 
> As a side-note, midi2ly needs our shipped python-version. It stopps
> working even with my system-python, i.e. 2.7.9.
> Not sure, whether this requires a bugreport, because there is no bug
> with lily's python...
> 

I will add a comment to the first of these two issues (and mark the second as 
duplicate):
https://sourceforge.net/p/testlilyissues/issues/1895/
https://sourceforge.net/p/testlilyissues/issues/1895/


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

Re: ANN: Frescobaldi 2.19.0

[Johan Vromans]

On Sun, 24 Apr 2016 09:54:05 +0200
Urs Liska  wrote:

> If you install LilyPond through your (Linux) OS's package manager this
> will detect any updates to the OS's packages (of course) and will
> therefore update automatically whenever you run your package manager's
> update procedure (e.g. apt-get update && upat-get upgrade).
> If you have downloaded LilyPond as a binary release this will of course
> *not* detect the availability of any newer releases.

Much simpler: Frescobaldi seems to use the timestamp of the binary to detect
updates.

My lilypond binary is ~/bin/lilypond, which basically
execs /usr/bin/lilypond with some additional --include paths.

When /usr/bin/lilypond is updated to a newer version, this is not detected 
since the timestamp of ~/bin/lilypond doesn't change.

As remarked by Villum: detecting newer versions is efectively
"circumvented somehow in the setup". 

> So *now* Frescobaldi does detect updates on the
> LilyPond side, that is, when you have updated LilyPond outside of
> Frescobaldi.

*now* being > 2.19.0 ?

-- Johan

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Thomas Morley  writes:

> 2016-04-23 11:35 GMT+02:00 Andrew Bernard :
>> Pardon my ignorance but why do you want to support a common subset?
>> For what purpose? The whole point of Python 3 is that it breaks 2 in
>> order to become a superior and more consistent langauge. It’s been
>> out since 2008, an eternity in IT terms. Please help me understand.
>>
>> Andrew
>>
>>
>>
>>
>>
>> On 23/04/2016, 6:33 PM, "David Kastrup"  wrote:
>>
>>>Well, unless there are really compelling reasons otherwise, sticking
>>>with a common subset (namely making it work with Python 3 while keeping
>>>it working with Python 2) would seem like the sanest option.
>
>
> As a side-note, midi2ly needs our shipped python-version. It stopps
> working even with my system-python, i.e. 2.7.9.
> Not sure, whether this requires a bugreport, because there is no bug
> with lily's python...

In my opinion it does.  At least unless the problem consists in missing
libraries.  Then it may need mentioning in the dependencies (unless
already listed there), and it may be worth checking that system
packagings of LilyPond also have the requisite dependencies.

But if there is a bona-fide language version problem with midi2ly, of
course it's a bug.  Our prepackaged binaries are a service and
convenience for LilyPond users, but "the" LilyPond is just the source
code.

-- 
David Kastrup

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Urs Liska]

Am 24.04.2016 um 09:56 schrieb David Kastrup:
> Noeck  writes:
> 
>>> So how do you define "the default"
>>
>> As written before: What ships with the default installation.
> 
> So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
> (what happens when Python 4 gets created), and we need to either support
> Python2 and Python3 in parallel (including from GUB) _or_ make a hard
> switch where we change _every_ script to use Python3 _and_ change GUB
> from one version to the next.
> 
> _And_ Wols insists that he does _not_ want to use a common subset of
> Python2 and Python3 even temporarily but do this right away using
> Python3-only features.
> 
> Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
> make testing half-way reliable.  But in reality, the LilyPond code base
> does not contain #!/usr/bin/python to any sizable degree (there is a
> single script which might be an oversight) but instead #!@TARGET_PYTHON@
> so again, there does not seem to be much of an alternative for an
> all-or-nothing approach, and trying to mix this with making use of new
> language features at the same time seems like a logistic nightmare.
> 

OK, but what happens when we face the situation that some distros have
#!/usr/bin/python to Python 2 and other to Python 3?
This is something we can't control at all, so at latest *then* we'd be
in that situation, with the difference that *now* we have at least a
chance to control the transition.

I think this is about what Federico meant with this Guile 1.8/2
comparison - he didn't mean to say that we are in that situation *now*
but that we might run into it when the decisions of the distros are taken.

Urs

-- 
Urs Liska
www.openlilylib.org

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Noeck  writes:

>> So how do you define "the default"
>
> As written before: What ships with the default installation.

So python3 needs to be invoked using #!/usr/bin/python3 in the scripts
(what happens when Python 4 gets created), and we need to either support
Python2 and Python3 in parallel (including from GUB) _or_ make a hard
switch where we change _every_ script to use Python3 _and_ change GUB
from one version to the next.

_And_ Wols insists that he does _not_ want to use a common subset of
Python2 and Python3 even temporarily but do this right away using
Python3-only features.

Now having a separate prescribed #!/usr/bin/python3 shebang may seem to
make testing half-way reliable.  But in reality, the LilyPond code base
does not contain #!/usr/bin/python to any sizable degree (there is a
single script which might be an oversight) but instead #!@TARGET_PYTHON@
so again, there does not seem to be much of an alternative for an
all-or-nothing approach, and trying to mix this with making use of new
language features at the same time seems like a logistic nightmare.

-- 
David Kastrup

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

Re: ANN: Frescobaldi 2.19.0

[Urs Liska]

Am 24.04.2016 um 09:39 schrieb Villum Sejersen:
>> On Fri, 22 Apr 2016 10:22:23 +0200
>> Urs Liska  wrote:
> 
>> >/Am 22.04.2016 um 10:19 schrieb Johan Vromans:/
>> >/>> Frescobaldi 2.19.0 has been released into the wild. /
>> >/> Good job! Thanks!/
>> >/> /
>> >/>> - The new LilyPond feature to embed source code files in the PDF/
>> >/>> (LilyPond >= 2.19.39) can be used in publish mode and the custom/
>> >/>> engrave dialog (#813) /
>> >/> I must have missed this in the discussions... What can I do with this? /
>> >//
>> >/You can ensure that anyone who gets the PDF also has access to the/
/source files./
> 
>> While trying to find out why this didn't work I noticed that Frescobaldi
>> registers the version of the lilypond binary when that binary is added
>> (Preferences > Lilypond preferences). It doesn't notice that a binary has
>> been updated. 
> 
> That's not my experience. It might be something in your setup(s)? ;)
> 
>> In my case, the /usr/bin/lilypond was upgraded to 2.19.39 but Frescobaldi
>> still considered it to be 2.19.22, disabling the embed files feature. 
> 
> My installation (on a debian testing, not ubuntu, nor mint) found and updated 
> Lilypond to 2.19.41 (and as before 2.18.2) automatically, but don't ask me 
> why. 
> I run frescobaldi as a symlink from /usr/local/bin/ where lilypond and 
> fontforge binaries compiled fro git sources are situated too. 
> Contrarily, the lilypond version(s) possibly entered in in /usr/local/share 
> must be updated manually.
> 
>> Is this (not detecting upgrades) intentional behaviour? 
> 
> As said this may be circumvented somehow in the setup. Whether lilypond or 
> frescobaldi setup I don't know.
> 

I think there is some clarification needed here:

A) LilyPond
If you install LilyPond through your (Linux) OS's package manager this
will detect any updates to the OS's packages (of course) and will
therefore update automatically whenever you run your package manager's
update procedure (e.g. apt-get update && upat-get upgrade).
If you have downloaded LilyPond as a binary release this will of course
*not* detect the availability of any newer releases.

B) Frescobaldi
When you add or edit a LilyPond version in Frescobaldi's Preferences it
will run LilyPond to retrieve the version and will then know the version
of that LilyPond.

If I'm not completely mistaken (and would need clarification too) it is
a pretty recent feature that Frescobaldi runs LilyPond on startup to
detect the version of either the default registered LilyPond or all
registered ones. So *now* Frescobaldi does detect updates on the
LilyPond side, that is, when you have updated LilyPond outside of
Frescobaldi.

HTH
Urs

> 
>> -- Johan
> 
> -- 
> yours,
> Villum Sejersen
> Nørregade  1 A
> DK-4500  Nykøbing Sjælland
> mobil   +45   30 34  03 44
> 
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


-- 
Urs Liska
www.openlilylib.org

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Thomas Morley]

2016-04-23 11:35 GMT+02:00 Andrew Bernard :
> Pardon my ignorance but why do you want to support a common subset? For what 
> purpose? The whole point of Python 3 is that it breaks 2 in order to become a 
> superior and more consistent langauge. It’s been out since 2008, an eternity 
> in IT terms. Please help me understand.
>
> Andrew
>
>
>
>
>
> On 23/04/2016, 6:33 PM, "David Kastrup"  wrote:
>
>>Well, unless there are really compelling reasons otherwise, sticking
>>with a common subset (namely making it work with Python 3 while keeping
>>it working with Python 2) would seem like the sanest option.


As a side-note, midi2ly needs our shipped python-version. It stopps
working even with my system-python, i.e. 2.7.9.
Not sure, whether this requires a bugreport, because there is no bug
with lily's python...

Cheers,
  Harm

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Noeck]

> So how do you define "the default"

As written before: What ships with the default installation.

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

Re: ANN: Frescobaldi 2.19.0

[Villum Sejersen]

On Fri, 22 Apr 2016 10:22:23 +0200
Urs Liska  wrote:



>/Am 22.04.2016 um 10:19 schrieb Johan Vromans:/
>/ >> Frescobaldi 2.19.0 has been released into the wild. /
>/ > Good job! Thanks!/
>/ > /
>/ >> - The new LilyPond feature to embed source code files in the PDF/
>/ >> (LilyPond >= 2.19.39) can be used in publish mode and the custom/
>/ >> engrave dialog (#813) /
>/ > I must have missed this in the discussions... What can I do with this? /
>//
>/You can ensure that anyone who gets the PDF also has access to the/

/source files./



While trying to find out why this didn't work I noticed that Frescobaldi
registers the version of the lilypond binary when that binary is added
(Preferences > Lilypond preferences). It doesn't notice that a binary has
been updated.


That's not my experience. It might be something in your setup(s)? ;)


In my case, the /usr/bin/lilypond was upgraded to 2.19.39 but Frescobaldi
still considered it to be 2.19.22, disabling the embed files feature.


My installation (on a debian testing, not ubuntu, nor mint) found and updated 
Lilypond to 2.19.41 (and as before 2.18.2) automatically, but don't ask me why.
I run frescobaldi as a symlink from /usr/local/bin/ where lilypond and 
fontforge binaries compiled fro git sources are situated too.
Contrarily, the lilypond version(s) possibly entered in in /usr/local/share 
must be updated manually.


Is this (not detecting upgrades) intentional behaviour?


As said this may be circumvented somehow in the setup. Whether lilypond or 
frescobaldi setup I don't know.



-- Johan


--
yours,
Villum Sejersen
Nørregade  1 A
DK-4500  Nykøbing Sjælland
mobil   +45   30 34  03 44

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

Re: What is the proper way of programmatically generating markup?

[Matt Hood]

> On 24 Apr 2016, at 5:28 PM, Thomas Morley  wrote:
> 
> 2016-04-24 5:00 GMT+02:00 Matt Hood :
>> Hi everyone,
>> 
>> So I’m writing a function that reimplements the ‘\compoundMeter’ command
>> with an Orff-style time signature, whereby the denominator of the signature
>> is a note head (as opposed to a number),
> 
> I've done this some month ago in the german forum
> http://www.lilypondforum.de/index.php?topic=2127.msg11763#msg11763
> Without account you'll not able to see the image, so I attached it
> below, but the code should be available.
> 
> I was too tired to write documentation about it and didn't return to
> it, maybe I should put it in LSR.
> Note the beat-structure is hard-coded to '() for now. If this gives
> problems, please shout.
> 
> HTH,
>  Harm
> 

Wow, I really like this solution. I’ve been sitting the signatures in the 
normal location, but this is far more clear. Thanks!

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

Re: What is the proper way of programmatically generating markup?

[Thomas Morley]

2016-04-24 5:00 GMT+02:00 Matt Hood :
> Hi everyone,
>
> So I’m writing a function that reimplements the ‘\compoundMeter’ command
> with an Orff-style time signature, whereby the denominator of the signature
> is a note head (as opposed to a number),

I've done this some month ago in the german forum
http://www.lilypondforum.de/index.php?topic=2127.msg11763#msg11763
Without account you'll not able to see the image, so I attached it
below, but the code should be available.

I was too tired to write documentation about it and didn't return to
it, maybe I should put it in LSR.
Note the beat-structure is hard-coded to '() for now. If this gives
problems, please shout.

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Noeck  writes:

>>> Python 3 is already the default in the latest Ubuntu release.
>> 
>> How do you figure that?  I have an up-to-date Ubuntu and calling "python
>> --version" gives 2.7.11+.
>
> By default, I mean what is installed by default/ships with the default
> installation [1]. /usr/bin/python will point to python2 for some longer
> time as PEP394 [2] requests. And Ubuntu plans to follow that
> recommendation [3].

So how do you define "the default" when /usr/bin/python is Python2?  And
when the package "python" lists as

dak@lola:/usr/local/tmp/lilypond$ dpkg -l python
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version 
ArchitectureDescription
+++-=-===-===-===
ii  python2.7.11-1
i386interactive high-level object-oriented language 
(default version)

-- 
David Kastrup

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

Re: Python 3, was Re: ANN: Frescobaldi 2.19.0

[Noeck]

>> Python 3 is already the default in the latest Ubuntu release.
> 
> How do you figure that?  I have an up-to-date Ubuntu and calling "python
> --version" gives 2.7.11+.

By default, I mean what is installed by default/ships with the default
installation [1]. /usr/bin/python will point to python2 for some longer
time as PEP394 [2] requests. And Ubuntu plans to follow that
recommendation [3].

[1]: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3
[2]: http://legacy.python.org/dev/peps/pep-0394/
[3]: https://wiki.ubuntu.com/Python/3

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