Re: Key list in lyricmode

[David Kastrup]

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.

-- 
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

[David Kastrup]

Noeck  writes:

> And I was not up-to-date in a previous mail: 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+.

-- 
David Kastrup

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

Guitar bend error

[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/

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
<0>: 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
<1>: 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.
___
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 1:38 PM, Paul Morris  wrote:
> 
>> On Apr 23, 2016, at 11:00 PM, Matt Hood > > wrote:
>> 
>> **So my second question is: How do I programmatically generate markup from 
>> information taken from a list, and then put it into a single markup 
>> variable?**
> 
> Hi again,  I’d suggest looking at snippets in the LSR, searching for "time 
> signature", if you haven’t yet, .  This one looks like it might be helpful:
> 
> http://lsr.di.unimi.it/LSR/Snippet?id=743 
> 
> 
> Cheers,
> -Paul

Thank you very much Paul, for this and your previous message. I think it’s 
going to be really helpful.

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?

[Paul Morris]

> On Apr 23, 2016, at 11:00 PM, Matt Hood  wrote:
> 
> **So my second question is: How do I programmatically generate markup from 
> information taken from a list, and then put it into a single markup 
> variable?**

Hi again,  I’d suggest looking at snippets in the LSR, searching for "time 
signature", if you haven’t yet, .  This one looks like it might be helpful:

http://lsr.di.unimi.it/LSR/Snippet?id=743

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

Re: ANN: Frescobaldi 2.19.0

[David Wright]

On Sat 23 Apr 2016 at 22:09:55 (+0200), Noeck wrote:
> Hi,
> 
> print 'foo' vs. print('foo') is usually the most frequent difference and
> writing code for a 'common subset' in most cases requires at least some
> from __future__ imports to ensure compatibility.

All my programs converted perfectly there, both the () and changing
from >> sys.stderr to ,file=sys.stderr).

OTOH I never really got comfortable with the python2 hacks for
handling UTF I/O, stuff like codecs.getwriter(u'utf-8')(sys.stdout).
Programs that handled both binary and UTF strings were a real pain
to maintain. 2to3 couldn't unpick all that, but at least the python3
replacement code was/is much cleaner and easier to write and maintain.

But the volume of my own code is now much smaller than in the past,
and a fraction of LP's.

Cheers,
David.

___
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?

[Paul Morris]

> On Apr 23, 2016, at 11:00 PM, Matt Hood  wrote:
> 
> does anyone know where can I find the source (scm or otherwise) for 
> \compoundMeter?


You’ll find it in ly/music-functions-init.ly  

Hope that helps,
-Paul___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

What is the proper way of programmatically generating markup?

[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), e.g. 4/4 = 4/crotchet, 9/8 = 
3/dotted-crotchet, 15/16+2/4 = 5/dotted-quaver + 2/crotchet. I’ve been able to 
implement the first two cases, i.e. no additive signatures,  but I’d like to 
make the third example work.

**My first question is: does anyone know where can I find the source (scm or 
otherwise) for \compoundMeter? I can’t find it in the ‘share/scm’ folder. I 
feel like it would be helpful to reference.**

My attempts to make this work have involved trying to generate the markup using 
foreach loops, that crawl through a list of lists that might look like:

(  (3 3 (ly:make-duration 3 1))   (4 (ly:make-duration 2))  )

which would be equal to: (9+9/16)+(4/4). All elements except for the last of 
each loop are numerators, while the last is the denominator.

-

This is the scheme code doing the work (not finished, but the basics should 
work?). The list-of-lists is referred to as ‘durs':

\version “2.18.2"
...
(markup
(#:line
  ( for-each
   (lambda (x) 
(markup "+")
( #:center-column 
 
 ;; Numerator Markup. The list supplied to the for-each loop doesn’t 
contain the duration. [“(cdr (reverse x))”]
 (#:line  
   (for-each 
(lambda (y) 
 (
  ( markup "+") 
  (#:number (number->string y) )
 )
)
(cdr (reverse x))
   )
 )

;; Denominator markup.
(#:note-by-number 
 (ly:duration-log (car (reverse x))) 
 (ly:duration-dot-count (car (reverse x))) 
 DOWN
)
   
   )
  )
  durs
 )
)
)

This haphazard collection of markup needs to somehow fit into:

\override Score.TimeSignature #'text =

which accepts ‘markup’, singular, only. 

This throws errors such as:
warning: type check for `stencil' failed; value `#' must 
be of type `stencil'

--

**So my second question is: How do I programmatically generate markup from 
information taken from a list, and then put it into a single markup variable?**

Any help at all would be greatly appreciated.
Cheers, Matt.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Wright]

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.

> 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?
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?

> 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 you barely remember.

> As Kieren said, this stuff is generic across all parts, so he and I want
> to store it in a generic variable that then gets merged with the notes.
> But there doesn't appear to be a syntax that isn't crucially dependent
> on the notes being merged, other than filling the generic variable with
> a whole bunch of special-case formatting tags, which totally misses the
> point of having a generic variable :-( (plus I haven't used tags yet,
> another learning curve ...)

Again, isn't that why people use scheme. Then you can see if a given
moment has a note or not, and choose your markup appropriately.
LP never looks very automatic to me. It doesn't even have an "if"
construction to make a decision.

Anyway, I made mr jones into a nonsensical "\tempo". The rehearsal
letter now appears above it of course. I stuck a note in before the
MMR for some reason though nothing is anchored to it; everything but
mr jones is a \mark. I'm just doodling—not sure why I bothered.

Cheers,
David.


markswap.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Key list in lyricmode

[Simon Albrecht]

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.

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

[Martin Tarenskeen]

On Sat, 23 Apr 2016, Noeck wrote:


And I was not up-to-date in a previous mail: Python 3 is already the
default in the latest Ubuntu release.


Fedora:

https://fedoraproject.org/wiki/Changes/Python_3_as_Default

--

MT

___
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 23/04/2016 12:23, Kieren MacMillan wrote:

Hi Wol,


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

\textLengthOff

?

Hope this helps,
Kieren.


BRILLIANT (but not the way you intended :-)

As far as I can tell, \textLengthOff is the default, but I looked it up 
in the manual, and found out how to attach a markup to a zero-length 
note! Just attach it to an empty chord!


So instead of doing "s4\markup s2. s1*7", I can simply do "<>\markup 
s1*8", and that stops my multi-measure-rests mucking up. (I think I'd 
found that before ages ago, but forgotten it ...)


I'll need to play a bit more, but that's another niggle fixed ... :-)

Cheers,
Wol

___
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]

And I was not up-to-date in a previous mail: Python 3 is already the
default in the latest Ubuntu release.

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

[Carlo Stemberger]

2016-04-23 15:19 GMT+02:00 Federico Bruni :

> I guess that in 4 years Linux distros will "have to" (?) migrate to
> python3.
>

Currently new Debian packages written in Python 2 should be refused:

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

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

Re: ANN: Frescobaldi 2.19.0

[Noeck]

Hi,

print 'foo' vs. print('foo') is usually the most frequent difference and
writing code for a 'common subset' in most cases requires at least some
from __future__ imports to ensure compatibility.

However, the 2to3 tool is handy and there are very sane and good
guidelines for porting python code:
https://docs.python.org/3/howto/pyporting.html and also for writing code
for both 2 and 3. The baseline is: Port your code to 2.7 before.

IMHO, there is no reason not to support Python 2.7. Python 2.4 is from
2004. What would people on this list say if such old LilyPond versions
were still in use and questions were appearing on lilypond-user!?

Ubuntu urges contributors that new code should be written in python 3.

So, I would say 2.7 is the conservative approach and should be well
supported. Most distributions are working towards python 3 and now or
quite soon it will be preferred over python 2.

Cheers,
Joram

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

Re: Scheme optional arguments, number-list

[David Kastrup]

Thomas Morley  writes:

> my-time =
> #(define-music-function (v1 v2)(scheme? scheme?)
>   #{ \time $v1 $v2 #})


> %% doesn't work
> {
>   %% \time redefined with comma-separated list
>   \my-time 2,2,1 5/8
>   g'8 8 8 8 8
>   %% or
>   \my-time 1,1,2,1 5/8
>   g'8 8 8 8 8
> }
>
> A problem with the function-macros?

A problem with the argument types.  If a number is accepted, a number is
parsed.  Number lists are only tried when a number as such does not
work.  Because otherwise a single-element list would be impossible to
specify.

-- 
David Kastrup

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

Re: Scheme optional arguments, number-list

[David Kastrup]

Mark Knoop  writes:

> In this instance single number lists are not relevant anyway. So I've
> tried this method:
>
> #(define (multi-number-list? x)
>   (and (list? x)
>(< 1 (length x))
>(every number? x)))
>
> testfn = #(define-void-function
>   (a) (multi-number-list?)
>   (print "\na=~s length=~s\n" a (length a)))
>
> {
>   % this works
>   \testfn #'(1 2 3)
>   % this doesn't - why?
>   \testfn 1,2,3
>   % this fails as expected
>   \testfn 1
> }
>
> ...and was surprised to see that the new list syntax doesn't work in
> this instance. It's not clear to me at what point lilypond/guile
> decides that something is a list or not.

LilyPond does not try for a list if a single-element list does not work.
Because that decision would result in lookahead which is something it
cannot do in the context of optional arguments.  It needs to make a
decision earlier than that.

So, uh, my advice was not particularly useful.

Sorry for that.

-- 
David Kastrup

___
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 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. 

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.

Is this (not detecting upgrades) intentional behaviour?

-- Johan

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

Re: Scheme optional arguments, number-list

[Thomas Morley]

2016-04-23 16:27 GMT+02:00 Mark Knoop :
> Thanks David,
>
> At 15:01 on 23 Apr 2016, David Kastrup wrote:
>>Mark Knoop  writes:
>>> On upgrading to 2.19.32, one of my regular functions no longer works.
>>> It seems that a single number as the first argument is now accepted
>>> as a number-list whereas before it was not and thus became the second
>>> argument.
>>>
>>> Whilst the new possibility to write lists as 1,2,3,4 is very nice, is
>>> there any way to alter my function definition to achieve the old
>>> behaviour?
>>>
>>> myFunction = #(define-void-function
>>>   (a b c d)
>>>   ((number-list? '()) number? (boolean? #t) fraction?)
>>>   (print "\na=~s b=~s c=~s d=~s\n" a b c d))
>>>
>>> {
>>>   % this works when all arguments are specified
>>>   \myFunction 1,2,3,4 4 ##t 4/4
>>>   % not specifying first argument no longer works
>>>   \myFunction 4 4/4
>>> }
>>
>>You can write your own predicate that will reject lists containing a
>>single number.  But it will then also reject an explicit #'(3).  I'm
>>afraid that you just created an interface that was too delicate to
>>survive further development.
>
> In this instance single number lists are not relevant anyway. So I've
> tried this method:
>
> #(define (multi-number-list? x)
>   (and (list? x)
>(< 1 (length x))
>(every number? x)))
>
> testfn = #(define-void-function
>   (a) (multi-number-list?)
>   (print "\na=~s length=~s\n" a (length a)))
>
> {
>   % this works
>   \testfn #'(1 2 3)
>   % this doesn't - why?
>   \testfn 1,2,3
>   % this fails as expected
>   \testfn 1
> }
>
> ...and was surprised to see that the new list syntax doesn't work in
> this instance. It's not clear to me at what point lilypond/guile
> decides that something is a list or not.

A probably related observation:

\version "2.19.40"

my-time =
#(define-music-function (v1 v2)(scheme? scheme?)
  #{ \time $v1 $v2 #})

%% works
{
  %% default with comma-separated list
  \time 2,2,1 5/8
  g'8 8 8 8 8
  %% or
  \time 1,1,2,1 5/8
  g'8 8 8 8 8
}

%% works
{
  %% \time redefined with common-list
  \my-time #'(2 2 1) 5/8
  g'8 8 8 8 8
  %% or
  \my-time #'(1 1 2 1) 5/8
  g'8 8 8 8 8
}

%% doesn't work
{
  %% \time redefined with comma-separated list
  \my-time 2,2,1 5/8
  g'8 8 8 8 8
  %% or
  \my-time 1,1,2,1 5/8
  g'8 8 8 8 8
}

A problem with the function-macros?


Cheers,
  Harm

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

Re: Scheme optional arguments, number-list

[Mark Knoop]

Thanks David,

At 15:01 on 23 Apr 2016, David Kastrup wrote:
>Mark Knoop  writes:
>> On upgrading to 2.19.32, one of my regular functions no longer works.
>> It seems that a single number as the first argument is now accepted
>> as a number-list whereas before it was not and thus became the second
>> argument.
>>
>> Whilst the new possibility to write lists as 1,2,3,4 is very nice, is
>> there any way to alter my function definition to achieve the old
>> behaviour?
>>
>> myFunction = #(define-void-function
>>   (a b c d)
>>   ((number-list? '()) number? (boolean? #t) fraction?)
>>   (print "\na=~s b=~s c=~s d=~s\n" a b c d))
>>
>> {
>>   % this works when all arguments are specified
>>   \myFunction 1,2,3,4 4 ##t 4/4
>>   % not specifying first argument no longer works
>>   \myFunction 4 4/4
>> }  
>
>You can write your own predicate that will reject lists containing a
>single number.  But it will then also reject an explicit #'(3).  I'm
>afraid that you just created an interface that was too delicate to
>survive further development.

In this instance single number lists are not relevant anyway. So I've
tried this method:

#(define (multi-number-list? x)
  (and (list? x)
   (< 1 (length x))
   (every number? x)))

testfn = #(define-void-function
  (a) (multi-number-list?)
  (print "\na=~s length=~s\n" a (length a)))

{
  % this works
  \testfn #'(1 2 3)
  % this doesn't - why?
  \testfn 1,2,3
  % this fails as expected
  \testfn 1
}

...and was surprised to see that the new list syntax doesn't work in
this instance. It's not clear to me at what point lilypond/guile
decides that something is a list or not.

So this method will work for my old scores which still use #'(1 2 3)
syntax, but can't take advantage of the new 1,2,3 syntax.

>Of course, you can always skip an optional argument using \default, but
>that's likely not what you would want to do.

Yes, still hoping to find a way to avoid that if possible.

-- 
Mark Knoop

___
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]

Federico Bruni  writes:

> On Sat, Apr 23, 2016 at 02:56:47PM +0200, David Kastrup wrote:
>> 
>> Upgrading to a newer version of GCC stopped our release process from
>> working for several months.  That's exactly the kind of "it should not
>> be a big deal" that you are talking about here.
>> 
>
> That's why the upgrades should be planned in advance before there's
> few time left.
>
> Python 2 will reach end of life in 2020 (no bugfix releases from that date).
> I guess that in 4 years Linux distros will "have to" (?) migrate to python3.
> We might find ourselves in a similar position as for guile1.8/guile2

Guile 1.8 is already the other way round: most distributions only still
support it because of LilyPond.  That's actually a quite more urgent
deal.

-- 
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 Sat, Apr 23, 2016 at 02:56:47PM +0200, David Kastrup wrote:
> 
> Upgrading to a newer version of GCC stopped our release process from
> working for several months.  That's exactly the kind of "it should not
> be a big deal" that you are talking about here.
> 

That's why the upgrades should be planned in advance before there's few time 
left.

Python 2 will reach end of life in 2020 (no bugfix releases from that date).
I guess that in 4 years Linux distros will "have to" (?) migrate to python3.
We might find ourselves in a similar position as for guile1.8/guile2

I would not discourage Andrew.
The task is difficult but it's worth the effort. I hope that he'll try
to tackle it and get support by this community.

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

Re: ANN: Frescobaldi 2.19.0

[Davide Liessi]

2016-04-22 7:55 GMT+02:00 Wilbert Berendsen :
> Frescobaldi 2.19.0 has been released into the wild.

Precompiled application for (Mac) OS X are now available.

Download: http://frescobaldi.org/download

Best wishes.
Davide

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

Re: Scheme optional arguments, number-list

[David Kastrup]

Mark Knoop  writes:

> On upgrading to 2.19.32, one of my regular functions no longer works.
> It seems that a single number as the first argument is now accepted as a
> number-list whereas before it was not and thus became the second
> argument.
>
> Whilst the new possibility to write lists as 1,2,3,4 is very nice, is
> there any way to alter my function definition to achieve the old
> behaviour?
>
> myFunction = #(define-void-function
>   (a b c d)
>   ((number-list? '()) number? (boolean? #t) fraction?)
>   (print "\na=~s b=~s c=~s d=~s\n" a b c d))
>
> {
>   % this works when all arguments are specified
>   \myFunction 1,2,3,4 4 ##t 4/4
>   % not specifying first argument no longer works
>   \myFunction 4 4/4
> }

You can write your own predicate that will reject lists containing a
single number.  But it will then also reject an explicit #'(3).  I'm
afraid that you just created an interface that was too delicate to
survive further development.

Of course, you can always skip an optional argument using \default, but
that's likely not what you would want to do.

-- 
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

[David Kastrup]

Andrew Bernard  writes:

> Hi David,
>
> But lilypond ships its own internal version of python in
> …lilypond/usr/bin.

Assuming that you install from our precompiled binary packages.
Obviously, that's not what the developers do since they need to run
LilyPond right after compiling it.  Also obviously that is not what the
packagers of distributions do since they compile a native version of
LilyPond and most certainly do not ship versions of Python crosscompiled
by us.

> I am aware the entire ecosystem has to be ported. I am offering to do
> the work.

Check out working on and with GUB for compiling various binaries first
in order to figure out how much work that's actually going to be.
That's a rather big hurdle, and it does not help overly with GNU/Linux
systems (and MacPorts and whatever else) packaging their own
compilations.  But the GUB hurdle of course is our personal showstopper.

> But I don’t understand why the system vesion of python matters. Why do
> we bundle it then?

We only bundle it for our installers, but LilyPond is obviously also
compilable natively.

> Also, python 2 and 3 stand happily side by side on my openSUSE
> systems, ny Ubuntu systems, my Fedora systems, and my Debian
> systems.

But they don't magically don't turn #!/usr/bin/python (or whatever else)
into #!/usr/bin/python3 and the latter will stop working with Python 4
anyway.

> I am having trouble seeing what the issue is. If there comes a
> dependcy on python 3, surely anybody who is capable of downloading and
> installing lilypond can also download and install python 3?

The "surely anybody who is capable of downloading and installing
LilyPond can also ..." argument is nonsense.  We are not trying to prove
mathematically that it is possible to install LilyPond, we are talking
about the kind of practical hurdle imposed here.

If you want to talk about theories, one could compile LilyPond natively
under Windows.  That's what Git also does, requiring the attention of
something like two developers and trailing half a year behind.
LilyPond's Windows version just falls out of our release process,
simultaneously with the rest.

Everything requiring constant effort and attention, even if you think
it's not a big deal, is something that is keeping people from using
LilyPond, or keeping developers from working on more important things.

Upgrading to a newer version of GCC stopped our release process from
working for several months.  That's exactly the kind of "it should not
be a big deal" that you are talking about here.

-- 
David Kastrup

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

Scheme optional arguments, number-list

[Mark Knoop]

On upgrading to 2.19.32, one of my regular functions no longer works.
It seems that a single number as the first argument is now accepted as a
number-list whereas before it was not and thus became the second
argument.

Whilst the new possibility to write lists as 1,2,3,4 is very nice, is
there any way to alter my function definition to achieve the old
behaviour?

myFunction = #(define-void-function
  (a b c d)
  ((number-list? '()) number? (boolean? #t) fraction?)
  (print "\na=~s b=~s c=~s d=~s\n" a b c d))

{
  % this works when all arguments are specified
  \myFunction 1,2,3,4 4 ##t 4/4
  % not specifying first argument no longer works
  \myFunction 4 4/4
}

I suspect this is related to commit
2a66e23f356503ef916d51efa3f00cae5958dc48 
Issue 4811/1: Allow property paths as scalars and in assignments

--
Mark Knoop

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

Re: partcombine and tag

[Gianmaria Lari]

Thank you David, that's clear!
g.

On Sat, Apr 23, 2016 at 11:08 AM, David Kastrup  wrote:

> Gianmaria Lari  writes:
>
> > What if I change this
> >
> > note = \partcombine {e'} {\tag #'pdfOut c' \tag #'midiOut c'}
> >
> >
> > in this:
> >
> > note = { \new Voice << {e'}  {\tag #'pdfOut c' \tag #'midiOut c'}>>}
> >
> >
> > Now it works, but should I expect any side effects? It is equivalent?
>
> It's not equivalent.  \partcombine is most useful for piano extracts: it
> will combine notes of same length into chords and keep notes of
> different length separated.
>
> << >> will combine even notes of different length into chords (and
> LilyPond cannot currently deal with them properly either), and << \\ >>
> will keep even notes of the same length in different voices (and
> consequently with different stems).  Which is often what you want in
> partiture in order to be able to tell different voices apart.
>
> --
> 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

[Andrew Bernard]

Hi David,

But lilypond ships its own internal version of python in …lilypond/usr/bin. Is 
this not to shield lilypond from system versions?

In my Ubuntu I have:

$ uname -a
Linux fivefold 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15 22:15:45 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

$ /usr/bin/python --version
Python 2.7.10

and in the lilypond install:



$ ./python
Python 2.4.5 (#1, Apr  5 2015, 13:45:28) 
[GCC 4.9.2] on linux

Clearly a considerably, and not entirely compatible, earlier version - as I 
know, having written a whole lot of python scripts for lilypond in 2.7 before 
realising we are on 2.4.


I am aware the entire ecosystem has to be ported. I am offering to do the work. 
It does not bother me that you think it is ‘unsexy’.

But I don’t understand why the system vesion of python matters. Why do we 
bundle it then?

Also, python 2 and 3 stand happily side by side on my openSUSE systems, ny 
Ubuntu systems, my Fedora systems, and my Debian systems. I am having trouble 
seeing what the issue is. If there comes a dependcy on python 3, surely anybody 
who is capable of downloading and installing lilypond can also download and 
install python 3?

Andrew




On 23/04/2016, 8:57 PM, "David Kastrup"  wrote:

>dak@lola:/usr/local/tmp/lilypond$ uname -a
>Linux lola 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 
>i686 i686 GNU/Linux
>dak@lola:/usr/local/tmp/lilypond$ python --version
>Python 2.7.11+
>dak@lola:/usr/local/tmp/lilypond$


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

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

[Kieren MacMillan]

Hi Wol,

> 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

\textLengthOff

?

Hope this helps,
Kieren.


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


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

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

[David Kastrup]

Andrew Bernard  writes:

>> 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.
>
> 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.

dak@lola:/usr/local/tmp/lilypond$ uname -a
Linux lola 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 
i686 i686 GNU/Linux
dak@lola:/usr/local/tmp/lilypond$ python --version
Python 2.7.11+
dak@lola:/usr/local/tmp/lilypond$ 

Without a really compelling reason, using a version of Python not
corresponding to the default version of Python for even the most
up-to-date version of the most common GNU/Linux distribution (which
LilyDev is based on) means that we buy into early adopter problems.  In
particular since we are talking about the whole cross-building
environment for all operating systems we are supporting.

So there is a whole wagonload of additional work and maintenance and
trouble involved with becoming incompatible to Python 2.

As I said: staying compatible with Python 2 while making sure we become
compatible to Python 3 is unsexy work.  It will pave the ground for a
later time where we may follow Ubuntu in making Python 3 the default,
and go there also with GUB.  And after a grace period _after_ that,
using pure Python 3 or later constructs will no longer come at
considerable cost to other people involved with the project.

There is a whole lot of weight to be lifted in connection with becoming
incompatible with Python 2.  Part of the weight will be gone once Ubuntu
itself moves there.  But without an actual plan and the resources for
actually pulling the weight here, it does not seem that declaring the
fallout "somebody else's problem" is going to be the least problematic
option.

-- 
David Kastrup

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

Re: Multi-measure rests and mark collisions

[Wols Lists]

On 23/04/16 01:52, Kieren MacMillan wrote:
> Hi David,
> 
>> It strikes me as conceptually problematic to try to put a fermata on a 
>> multi-measure rest.
>> Who does this, and what does it mean, musically?
>> In this example, you are actually placing a fermata on a single bar of rest.
>> In which case, this works fine:
>> { \compressFullBarRests f1->\fermata R1*3 r1\fermata }
> 
> Except r1\fermata and R1\fermataMarkup look and behave differently.
> And the difference gets even more obvious when you have a measure not in 4/4.
> =)
> 
And my mind is still stuck in the old days when neither of those worked,
but

\bar "||" \fermata

did :-) I think a load of my old code still has \markup #script.ufermata
or whatever it was all over the place trying to get them above notes ...

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 ...

[Wols Lists]

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 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 :-(

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. 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.

As Kieren said, this stuff is generic across all parts, so he and I want
to store it in a generic variable that then gets merged with the notes.
But there doesn't appear to be a syntax that isn't crucially dependent
on the notes being merged, other than filling the generic variable with
a whole bunch of special-case formatting tags, which totally misses the
point of having a generic variable :-( (plus I haven't used tags yet,
another learning curve ...)

Cheers,
Wol


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

Re: ANN: Frescobaldi 2.19.0

[Davide Liessi]

2016-04-22 7:55 GMT+02:00 Wilbert Berendsen :
> Frescobaldi 2.19.0 has been released into the wild.

Precompiled application for (Mac) OS X coming in a few hours.
Best wishes.
Davide

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

Re: ANN: Frescobaldi 2.19.0

[Davide Liessi]

2016-04-22 19:08 GMT+02:00 Steve Noland :
> When do you expect it to appear in MacPorts?

I'm updating the Portfiles right now. After I submit them, I expect
the usual 1-3 days for approval.

Best wishes.
Davide

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

Python 3, was Re: ANN: Frescobaldi 2.19.0

[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.


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

Re: partcombine and tag

[David Kastrup]

Gianmaria Lari  writes:

> What if I change this
>
> note = \partcombine {e'} {\tag #'pdfOut c' \tag #'midiOut c'}
>
>
> in this:
>
> note = { \new Voice << {e'}  {\tag #'pdfOut c' \tag #'midiOut c'}>>}
>
>
> Now it works, but should I expect any side effects? It is equivalent?

It's not equivalent.  \partcombine is most useful for piano extracts: it
will combine notes of same length into chords and keep notes of
different length separated.

<< >> will combine even notes of different length into chords (and
LilyPond cannot currently deal with them properly either), and << \\ >>
will keep even notes of the same length in different voices (and
consequently with different stems).  Which is often what you want in
partiture in order to be able to tell different voices apart.

-- 
David Kastrup

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

Re: partcombine and tag

[Gianmaria Lari]

What if I change this

note = \partcombine {e'} {\tag #'pdfOut c' \tag #'midiOut c'}


in this:

note = { \new Voice << {e'}  {\tag #'pdfOut c' \tag #'midiOut c'}>>}


Now it works, but should I expect any side effects? It is equivalent?

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

Re: partcombine and tag

[Gianmaria Lari]

Ciao David you wrote:

[...]
> \partcombine runs and creates a common score.  Since none of the tags is
> removed, the result contains both c4 and c'4.  This is stored in \note.
>

thank you for you explanation now it is perfectly clear what happens.


> I don't remember: doesn't partcombine complain when given parts of
> different length?


Apparently no :)

[...]

> Basically, you need to use the equivalent of \keepWithTag/\removeWithTag
> _before_ running \partcombine.  Afterwards, you only have a combined
> list of events without any tags left.
>

uhm... I don't think this will work for me. I mean, I could rewrite the
code so that \keepWithTag or \removeWithTag  runs before \partcombine but I
think for this I would be forced to create some multiple variable
containing the result of \keepWithTag etc. This is not very practical and
in case of many tags it will became difficult to handle, isn't it?


> It would be nice if \partcombine were rewritten to run just-in-time.
> The current implementation runs it when encountered, however.  Which
> means that it also has no access to context properties and other
> niceties.
>

Yes it would be!
Thanks, g.

On Fri, Apr 22, 2016 at 5:58 PM, Gianmaria Lari 
wrote:

> Ciao David you wrote:
>
> [...]
>> \partcombine runs and creates a common score.  Since none of the tags is
>> removed, the result contains both c4 and c'4.  This is stored in \note.
>>
>
> thank you for you explanation now it is perfectly clear what happens.
>
>
>> I don't remember: doesn't partcombine complain when given parts of
>> different length?
>
>
> Apparently no :)
>
> [...]
>
>> Basically, you need to use the equivalent of \keepWithTag/\removeWithTag
>> _before_ running \partcombine.  Afterwards, you only have a combined
>> list of events without any tags left.
>>
>
> uhm... I don't think this will work for me. I mean, I could rewrite the
> code so that \keepWithTag or \removeWithTag  runs before \partcombine but I
> think for this I would be forced to create some multiple variable
> containing the result of \keepWithTag etc. This is not very practical and
> in case of many tags it will became difficult to handle, isn't it?
>
>
>> It would be nice if \partcombine were rewritten to run just-in-time.
>> The current implementation runs it when encountered, however.  Which
>> means that it also has no access to context properties and other
>> niceties.
>>
>
> Yes it would be!
> Thanks, g.
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ANN: Frescobaldi 2.19.0

[David Kastrup]

Andrew Bernard  writes:

> Hi Martin,
>
> I have brought this topic up before, but it keeps getting knocked back
> by naysayers.
>
> I am volunteering to bring lilypond to Python 3. It would be helpful
> in many ways. Are there objections, folks?

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.

No naysayers to be expected for that, but it is likely an unsexy task to
work on then.

-- 
David Kastrup

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

Re: ANN: Frescobaldi 2.19.0

[Andrew Bernard]

Hi Martin,

I have brought this topic up before, but it keeps getting knocked back by 
naysayers.

I am volunteering to bring lilypond to Python 3. It would be helpful in many 
ways. Are there objections, folks?

Andrew




On 23/04/2016, 4:49 PM, "Martin Tarenskeen"  wrote:

>
>I know, the question is always: who will do the job ...


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

Re: ANN: Frescobaldi 2.19.0

[Federico Bruni]

Il giorno sab 23 apr 2016 alle 8:49, Martin Tarenskeen 
 ha scritto:
- Why isn't LilyPond bundled with at least Python 2.7? Are there any 
known

  issues with Python 2.7? It seems to work fine here on my Fedora box.

- If future versions of Frescobaldi will require Python3, wouldn't 
that be
  a good moment to port all python scripts in the LilyPond 
distribution

  also to Python3, or to make them compatible with both Python3 and
  Python2? Stepping up to Python 2.7 first would already make the gap
  smaller.


See these issues:

https://sourceforge.net/p/testlilyissues/issues/1895/ (GUB only has 
python 2.4)
https://sourceforge.net/p/testlilyissues/issues/1079/ (upgrade python 
in GUB)


BTW, should be marked as duplicates?




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

Re: tempo and different staves

[matpen3@gmail]

Solved. Sorry for the noise

m


> Il giorno 23 apr 2016, alle ore 08:03, matpen3@gmail  ha 
> scritto:
> 
> Hi David,
> 
> thanks.
> 
> I’d like to have tempos above the voice staff and above the piano part, so, 
> reading manuals and forums, it seems you have to remove them from score and 
> assign to single staves.
> 
> m
> 
> 
>> Il giorno 23 apr 2016, alle ore 07:58, David Kastrup  ha 
>> scritto:
>> 
>> "matpen3@gmail"  writes:
>> 
>>> Hi all,
>>> 
>>> is there a reason why tempos aren’t assigned to the staves, after
>>> removing them from score?
>> 
>> I'd ask the person who removed them from the score.
>> 
>> -- 
>> David Kastrup
> 


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

Re: Multi-measure rests and mark collisions

[Simon Albrecht]

On 23.04.2016 02:06, Flaming Hakama by Elaine wrote:
It strikes me as conceptually problematic to try to put a fermata on a 
multi-measure rest.

Who does this, and what does it mean, musically?


You must be kidding. While calling R1 a MultiMeasureRest may be slightly 
confusing in LilyPond terminology, honestly it’s not so difficult to 
grasp. And of course it’s totally standard notation to use R, not r, for 
full-bar rests.


Regards, Simon

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

Re: tempo and different staves

[Noeck]

Hi,

I don't know why that matters, but you can omit the line
  \consists "Metronome_mark_engraver"
in the pianostaff \with block and put it in the \with block of the upper
("right") Staff.

That works for me.

Cheers,
Joram

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

Re: ANN: Frescobaldi 2.19.0

[Martin Tarenskeen]

On Fri, 22 Apr 2016, Paul Morris wrote:

Um, so... 2.19 still uses Qt4.  In the future, version 3.0 will require 
Qt5 (and Python3).


So future Frescobaldi 3.x version will require Python3.

Python scripts in the LilyPond package currently need Python2. On Linux 
Fedora I'm running it with Python 2.7. On my Windows machine I'm using the 
LilyPond version for Windows with bundled Python 2.4.


- Why isn't LilyPond bundled with at least Python 2.7? Are there any known
  issues with Python 2.7? It seems to work fine here on my Fedora box.

- If future versions of Frescobaldi will require Python3, wouldn't that be
  a good moment to port all python scripts in the LilyPond distribution
  also to Python3, or to make them compatible with both Python3 and
  Python2? Stepping up to Python 2.7 first would already make the gap
  smaller.

I know, the question is always: who will do the job ...

--

MT




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

Re: ANN: Frescobaldi 2.19.0

[Federico Bruni]

Il giorno sab 23 apr 2016 alle 2:12, Andrew Bernard 
 ha scritto:
On Debian 8.4, the current git master builds after a long session 
struggling to manually solve dependenices, and then when run, simply 
unceremoniously dumps core. I have a pristine, newly installed Debian 
8.4 jessie system.


If you are building from master, you are using Frescobaldi 3.0, which 
needs python3 and qt5 (see my previous emails in this thread).





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

Re: tempo and different staves

[matpen3@gmail]

Hi David,

thanks.

I’d like to have tempos above the voice staff and above the piano part, so, 
reading manuals and forums, it seems you have to remove them from score and 
assign to single staves.

m


> Il giorno 23 apr 2016, alle ore 07:58, David Kastrup  ha 
> scritto:
> 
> "matpen3@gmail"  writes:
> 
>> Hi all,
>> 
>> is there a reason why tempos aren’t assigned to the staves, after
>> removing them from score?
> 
> I'd ask the person who removed them from the score.
> 
> -- 
> David Kastrup


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