Re: Rotation.

[Marc Hohl]

Am 28.12.2015 um 08:44 schrieb Hwaen Ch'uqi:

Greetings All,

I see from the NR that there are ways of rotating individual objects
or text markups. Is there a way of rotating an entire score?


If you embed the score in a markup, this should work out of the box, IIRC.

Marc


Thank you for any help.

Hwaen Ch'uqi

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




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

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 12:05:22 +1100
> Andrew Bernard  wrote:
>
>> The name of a variable must have alphabetic characters only, no numbers,
>> underscores, or dashes.
>> 
>> Most lilypond users would write bellaMelodia, conventionally. In terms of
>> readability, it’s clearer to read than the string with quotes, I reckon.
>
> They would write bellaMelodia since there is (was) no alternative to
> separate "words" in a variable name. 2.19.33 seems to accept dashes and
> underscores as well. Maybe the NR needs updating?

The quote character syntax was issue 2931.  The change was for 2.18 but
not mentioned in the Changes file.  Single, in-word occurences of - and
_ were allowed for 2.16 already, issue 2702.  It was mentioned in
Changes at that time.  I think that some other documentation was changed
as well but am not sure how completely.

The quote syntax is a bit of an ugliness which was added for sort-of
consistency reasons.

-- 
David Kastrup

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

\transpose not work working inside define-music-function

[John Smith]

I'm trying to define a music function that transposes a chord and a melody multiple times.  But for some reason, the transposition is done only once.

 

Here's my attempt:

 

repeatpattern =
#(define-music-function (parser location chord pattern) (ly:music? 
ly:music?)
  #{
  <<
  \new ChordNames {
    \transpose c d { #chord }
    \transpose c e { #chord }
  }
  \new Staff {
    \transpose c d { #pattern }
    \transpose c e { #pattern }
  }
  >>
  #})

 

\score {
  \repeatpattern { c1 } { c'4 d' e' r }
}

 

Any ideas for why this is not working and how to fix it? (i.e., it 
should transpose "c d e" into "d e f#" and "e f# g#", not into "f# g# 
a#").

 


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

Re: \transpose not work working inside define-music-function

[Phil Holmes]

This was answered yesterday.  Please check the list.

--
Phil Holmes


  - Original Message - 
  From: John Smith 
  To: lilypond-user@gnu.org 
  Sent: Saturday, December 26, 2015 11:01 PM
  Subject: \transpose not work working inside define-music-function


  I'm trying to define a music function that transposes a chord and a melody 
multiple times.  But for some reason, the transposition is done only once.

  Here's my attempt:

  repeatpattern =
  #(define-music-function (parser location chord pattern) (ly:music? 
  ly:music?)
#{
<<
\new ChordNames {
  \transpose c d { #chord }
  \transpose c e { #chord }
}
\new Staff {
  \transpose c d { #pattern }
  \transpose c e { #pattern }
}
>>
#})

  \score {
\repeatpattern { c1 } { c'4 d' e' r }
  }

  Any ideas for why this is not working and how to fix it? (i.e., it 
  should transpose "c d e" into "d e f#" and "e f# g#", not into "f# g# 
  a#").



--


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

Re: \transpose not work working inside define-music-function

[David Kastrup]

Wols Lists  writes:

> On 27/12/15 16:32, J Smith wrote:
>> I'm trying to define a music function that transposes a chord and a 
>> melody multiple times.  But for some reason, the transposition is done 
>> only once.
>>  
>> Here's my attempt:
>>  
>> repeatpattern =
>> #(define-music-function (parser location chord pattern) (ly:music? 
>> ly:music?)
>>   #{
>>   % <<
>>   \new ChordNames {
>> \transpose c d { #chord }
>> \transpose c e { #chord }
>>   }
>>   \new Staff {
>> \transpose c d { #pattern }
>> \transpose c e { #pattern }
>>   }
>>   % >>
>>   #})
>>  
>> \score {
>>   \repeatpattern { c1 } { c'4 d' e' r }
>> }
>>  
>> (delete the %'s preceding << and >>; had to add them to pass Gmane's 
>> filter).
>> 
>> Any ideas for why this is not working and how to fix it? (i.e., it 
>> should transpose "c d e" into "d e f#" and "e f# g#", not into "f# g# 
>> a#").
>> 
> Just a guess, but \transpose is funny - I think of it as taking note
> NAMES. As soon as you've fed the names through anything (such as
> define-music-function) they've been converted to note PITCHES, and
> \transpose no longer works.

That's, uh, very imaginative.  It has nothing whatsoever to do with what
happens here, and pretty much nothing whatsoever to do with anything
else.  My guess is that your inspiration is the behavior of \transpose
inside of \relative (more accurately, the behavior of \relative
concerning included passages generated using \transpose).

> Short answer - \transpose is very temperamental and sensitive as to
> where it is used.

Not really.

> (And note, my understanding is almost certainly technically wrong,

As well as factually.

> I just find it helpful as a superficial guide to what's going on.)

I don't.

At any rate, the problem here is applying \transpose twice to the same
music.

The instances of #chord (analogously for #pattern) need to be replaced
by either $chord (which inherently copies, being a lexically scoped
variant of \chord) or #(ly:music-deep-copy chord) or equivalent.

This is the same for _any_ multiple use of a music function argument.
Otherwise they don't just experience trouble with \transpose, but also
\relative, \keepWithTag and a number of other constructs.

-- 
David Kastrup

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

Re: Strings as variable names

[Andrew Bernard]

Consistency with what actually?

And so the NR should in fact therefore be updated?

Andrew

On 28/12/2015, 20:17, "David Kastrup" 
 wrote:

The quote syntax is a bit of an ugliness which was added for sort-of
consistency reasons.


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

Re: \transpose not work working inside define-music-function

[David Kastrup]

"Phil Holmes"  writes:

> This was answered yesterday.  Please check the list.
>
> --
> Phil Holmes
>
>
>   - Original Message - 
>   From: John Smith 
>   To: lilypond-user@gnu.org 
>   Sent: Saturday, December 26, 2015 11:01 PM
>   Subject: \transpose not work working inside define-music-function

And this question was sent on Saturday, several hours _before_ the
question that got answered.  My guess is that he posted the question and
it landed in the moderation queue because of him not being a member of
the list.  Then he subscribed to the list, posted his question again
(without cancelling his original mail), and got an answer.

And now the list moderator has found the leisure to look at his original
first question and, considering it on-topic, permitted its delivery.

-- 
David Kastrup

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

Draw line across staves

[Andrew Bernard]

How does one go about drawing an arbitrary line across staves, as per the 
attached image?

Andrew




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

Re: Strings as variable names

[David Kastrup]

Andrew Bernard  writes:

>  d...@gnu.org> wrote:
>>
>> The quote syntax is a bit of an ugliness which was added for sort-of
>> consistency reasons.
>
> Consistency with what actually?

After

xxx = ...

you can refer to \xxx.  And

"xxx" = ...

has always been allowed for arbitrary strings.

> And so the NR should in fact therefore be updated?

It's not really making stuff more readable.

-- 
David Kastrup

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

Re: Draw line across staves

[Jacques Menu]

Hello Andrew,Someone proposed the attached example for diagonal lines, maybe that can help?JM

DiagonalStrokeAcrossBars.ly
Description: Binary data
Le 28 déc. 2015 à 12:49, Andrew Bernard  a écrit :How does one go about drawing an arbitrary line across staves, as per the attached image?Andrew
___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: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 12:51:51 +0100
David Kastrup  wrote:

> "xxx" = ...
> 
> has always been allowed for arbitrary strings.
> 
> > And so the NR should in fact therefore be updated?  
> 
> It's not really making stuff more readable.

Now if only this would work:

\version "2.19.33"

bella_melodia_cello = \relative c' {
   r4- ef\upbow(f) r g |
}

part = cello

\score {
  \"bella_melodia_\part"
}

I can think of some use cases for this.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Hello, all!

> the bug is a consequence of issue 2504 
> .
> To fix it, just change line 89 of your attached file into
> (stencil-whiteout new-sim-stil 'outline thickness 1)

Ah! Hoisted by my own petard, as they say…
(I personally sponsored that feature!)

Thanks for the quick fix!
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: frame engraver & box repeats: what's the current state-of-the-art?

[Kieren MacMillan]

Hi David,

Thanks for the quick help.

> The linked code with corrections should give you what you need.


This is actually going to work!
It’s like Christmas… Oh, wait: it *IS* Christmas!

Thanks,
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: Strings as variable names

[David Sumbler]

> > From: David Kastrup 
> > To: Andrew Bernard 
> > Cc: lilypond-user@gnu.org
> > Subject: Re: Strings as variable names
> > Date: Mon, 28 Dec 2015 12:51:51 +0100
> > 
> > Andrew Bernard  writes:
> > 
> > >  > > d...@gnu.org> wrote:
> > >>
> > >> The quote syntax is a bit of an ugliness which was added for sort-of
> > >> consistency reasons.
> > >
> > > Consistency with what actually?
> > 
> > After
> > 
> > xxx = ...
> > 
> > you can refer to \xxx.  And
> > 
> > "xxx" = ...
> > 
> > has always been allowed for arbitrary strings.
> > 
> > > And so the NR should in fact therefore be updated?
> > 
> > It's not really making stuff more readable.

I think it would be useful to have it added to the NR.

I have always been frustrated by the fact that I can't (or thought I
couldn't) use underscores in variable names, and also that numbers are
not allowed.

Using the syntax with quotes is rather ugly, I agree.  But it is
nonetheless potentially useful for two reasons:
(1) it enables us to use numbers etc. in variable names
(2) the quotes help to distinguish our own defined variables from
Lilypond's own.

David


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

Re: lilypond-devel on MacPorts

[Davide Liessi]

Hi.

> On 12/27/15 12:32 PM, "Jacques Menu"  wrote:
>>MacPorts as I understand it is meant to work on its own. Since it keeps
>>records of what has been installed, their dependencies and where they
>>have been installed, I don¹t think you can tamper with that easily.

Actually ports in MacPorts declare dependencies on TeX Live by path
instead of by port name, so you could actually edit the configuration
file (/opt/local/etc/macports/macports.conf) and prepend your TeX Live
installation to MacPorts' path, but this could be a source of problems
and is not officially supported (i.e. if you have problems you are on
your own).

2015-12-28 2:55 GMT+01:00 Carl Sorensen :
> So I moved to just using LilyDev
> for my development environment.  I do install development releases on my
> Mac and use them with Frescobaldi for my engraving work.

That's what I would advise, too.
I have a lot of software installed with MacPorts (including TeX Live,
by the way), but I install LilyPond manually downloading the app, so
that I can have multiple versions side by side (I rename them to
"LilyPond X.Y.Z.app").
When I tried installing lilypond-devel with MacPorts, it didn't build
on my machine.

Best wishes.
Davide

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

Re: Strings as variable names

[David Kastrup]

David Sumbler  writes:

>> > From: David Kastrup 
>> > To: Andrew Bernard 
>> > Cc: lilypond-user@gnu.org
>> > Subject: Re: Strings as variable names
>> > Date: Mon, 28 Dec 2015 12:51:51 +0100
>> > 
>> > Andrew Bernard  writes:
>> > 
>> > > > > > behalf of d...@gnu.org> wrote:
>> > >>
>> > >> The quote syntax is a bit of an ugliness which was added for sort-of
>> > >> consistency reasons.
>> > >
>> > > Consistency with what actually?
>> > 
>> > After
>> > 
>> > xxx = ...
>> > 
>> > you can refer to \xxx.  And
>> > 
>> > "xxx" = ...
>> > 
>> > has always been allowed for arbitrary strings.
>> > 
>> > > And so the NR should in fact therefore be updated?
>> > 
>> > It's not really making stuff more readable.
>
> I think it would be useful to have it added to the NR.
>
> I have always been frustrated by the fact that I can't (or thought I
> couldn't) use underscores in variable names,

Well, that is hopefully more or less documented though probably not
everywhere.

> and also that numbers are not allowed.

But really, \"violin1" is so much more ugly than \violinI or if you must
\violin_I.

> Using the syntax with quotes is rather ugly, I agree.  But it is
> nonetheless potentially useful for two reasons:
> (1) it enables us to use numbers etc. in variable names

Why would that be desirable?

> (2) the quotes help to distinguish our own defined variables from
> Lilypond's own.

Absolutely not.  The quote marks don't become part of the variables or
identifiers.  \bing is absolutely identical to \"bing".

Reading people's ideas about those things make them appear like
something we would be better without.  They only lead to confusion.

-- 
David Kastrup

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

Re: Strings as variable names

[Urs Liska]

Am 28.12.2015 um 18:49 schrieb David Kastrup:
>> Using the syntax with quotes is rather ugly, I agree.  But it is
>> > nonetheless potentially useful for two reasons:
>> > (1) it enables us to use numbers etc. in variable names
> Why would that be desirable?
> 

Whenever you have variables pointing to indexed parts or to consecutive
snippets you may want to use variables like

violin1 =
violin2 =

or

flute_phrase01 =
flute_phrase02 =

or similar.
This is expressive as LilyPond code per se, and would be accessible for
scripting, e.g. to generate stub files with empty varialbes.

The workaround using roman numbers is pretty cumbersome, and I think

violin_02_34 would be much more comprehensible to most users than
violinIIxxxiv

-- 
Urs Liska
www.openlilylib.org

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

Re: Strings as variable names

[Marc Hohl]

Am 28.12.2015 um 18:49 schrieb David Kastrup:

David Sumbler  writes:

[...]

Using the syntax with quotes is rather ugly, I agree.  But it is
nonetheless potentially useful for two reasons:
(1) it enables us to use numbers etc. in variable names


Why would that be desirable?


Well, speaking just for myself, I use roman numerals in \textI, \textII, 
... \textVII which is rather clumsy and error-prone

(IV versus VI etc.)

This is just a convenience factor, but \text1 ... \text7 would be
nice, but I see that this leads to major problems in terms of
durations vs. variable calls.

Just my 2 cents,

Marc


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

Re: Strings as variable names

[Urs Liska]

Am 28.12.2015 um 13:29 schrieb Johan Vromans:
> On Mon, 28 Dec 2015 12:51:51 +0100
> David Kastrup  wrote:
> 
>> "xxx" = ...
>>
>> has always been allowed for arbitrary strings.
>>
>>> And so the NR should in fact therefore be updated?  
>>
>> It's not really making stuff more readable.
> 
> Now if only this would work:
> 
> \version "2.19.33"
> 
> bella_melodia_cello = \relative c' {
>r4- ef\upbow(f) r g |
> }
> 
> part = cello
> 
> \score {
>   \"bella_melodia_\part"
> }
> 
> I can think of some use cases for this.

I think something like this should be achievable using a music function
with two string arguments. It could concatenate them in an arbitrary
fashion and find the appropriate variable through the parser commands.

Urs

> 
> -- Johan
>http://johan.vromans.org/seasons_greetings.html
> 
> ___
> 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: Strings as variable names

[David Kastrup]

Urs Liska  writes:

> Am 28.12.2015 um 18:49 schrieb David Kastrup:
>>> Using the syntax with quotes is rather ugly, I agree.  But it is
>>> > nonetheless potentially useful for two reasons:
>>> > (1) it enables us to use numbers etc. in variable names
>> Why would that be desirable?
>> 
>
> Whenever you have variables pointing to indexed parts or to consecutive
> snippets you may want to use variables like
>
> violin1 =
> violin2 =

What's wrong with violinI ?

> or
>
> flute_phrase01 =
> flute_phrase02 =
>
> or similar.

When would you ever want to do that?

> This is expressive as LilyPond code per se, and would be accessible
> for scripting, e.g. to generate stub files with empty varialbes.

Why would violinI not be accessible for scripting?

That's just (format #f "violin~@r" 1).

> The workaround using roman numbers is pretty cumbersome,

What's this with "workaround" anyway?  I have more scores using
"Violin I" and "Violin II" for their parts than otherwise.

Here are the instrument names of literally the first score I found on my
desktop:


> and I think
>
> violin_02_34 would be much more comprehensible to most users than
> violinIIxxxiv

34 separate second violins seem a bit excessive.

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

Re: Strings as variable names

[Kieren MacMillan]

Hi David,

> What's wrong with violinI ?

For one thing, arabic numerals sort more easily than roman numerals.

> When would you ever want to do that?

Unfortunately, I need to do it all the time: until Lilypond handles 
multi-instrumentalist parts better than it does (you may recall us discussing 
the many issues in the past?), I am forced to break up variables and then knit 
them back together later [transposed, or with a new key signature, or whatever].

> What's this with "workaround" anyway?  I have more scores using
> "Violin I" and "Violin II" for their parts than otherwise.

Instrument names [presentation] and variable names [content] are independent… 
or at least should be.

Best regards,
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: Strings as variable names

[Thomas Morley]

2015-12-28 18:49 GMT+01:00 David Kastrup :
[...]
>
> Reading people's ideas about those things make them appear like
> something we would be better without.  They only lead to confusion.
>
> --
> David Kastrup

I rarely use this possibility, but it's very nice to have numbers, etc
in identifiers for things like:

"des:7.5+.9+" =
\markup {
  \fret-diagram-verbose #`(
(mute 6)
(place-fret 5 7 ,#{ \markup \fontsize #-4 3 #})
(place-fret 4 8 ,#{ \markup \fontsize #-4 \with-flat 7 #})
(place-fret 3 8 ,#{ \markup \fontsize #-4 \with-sharp 9 #})
(place-fret 2 9 ,#{ \markup \fontsize #-4 \with-sharp 5 #})
(mute 1)
  )
}

\with-flat is a custom-markup-command outputting nice formatted "b7"

Wouldn't want to miss it.


Cheers,
  Harm

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

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 19:01:47 +0100
Urs Liska  wrote:

> > part = cello
> > 
> > \score {
> >   \"bella_melodia_\part"
> > }
> 
> I think something like this should be achievable using a music function
> with two string arguments.

Yes, but my suggestion was to have a mechanism for interpolation of
variables in strings, which is much more generic, flexible and powerful.
And most programming languages have it.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 17:42:03 +
David Sumbler  wrote:

> > > It's not really making stuff more readable.  
> 
> I think it would be useful to have it added to the NR.

If it's part of the language syntax, it should be documented.
If it's experimental, dangerous, or deprecated, it should be documented as
such.
If it is unwanted, it should be removed from the language syntax.

There's no point in having undocumented language features, because these
will only lead to errors and confusion.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: Strings as variable names

[Malte Meyn]

Am 28.12.2015 um 19:20 schrieb David Kastrup:
> What's wrong with violinI ?

lexicographical sorting (of file names) ≠ roman numeral sorting

>> flute_phrase01 =
>> flute_phrase02 =
>>
>> or similar.
> 
> When would you ever want to do that?

Variations (one score per variation):

fluteTheme = …
fluteVar1 = …
…
fluteVar14 = …

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

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 19:01:47 +0100
> Urs Liska  wrote:
>
>> > part = cello
>> > 
>> > \score {
>> >   \"bella_melodia_\part"
>> > }
>> 
>> I think something like this should be achievable using a music function
>> with two string arguments.
>
> Yes, but my suggestion was to have a mechanism for interpolation of
> variables in strings, which is much more generic, flexible and
> powerful.

The above is mainly confused.  Remember that \n in a string stands for
newline.

> And most programming languages have it.

Uh what?  Bourne shells can interpolate variables (written with $ rather
than \ by the way) into _double_-quoted strings.  Maybe some other
shells can.

But what _programming_ languages allow interpolating into quoted
strings?  The C preprocessor can expand #identifier into a string, and
juxtaposed with other double-quoted strings they combine into a larger
string I believe.  But that's only for preprocessor constants, and those
are not really part of the language proper.

The strings in Python's regular expression replacements can interpolate
variable values, but those are not part of the string syntax but of the
regexp replacement semantics.

And so on.

-- 
David Kastrup

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

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 18:49:30 +0100
David Kastrup  wrote:

> > I have always been frustrated by the fact that I can't (or thought I
> > couldn't) use underscores in variable names,  
> 
> Well, that is hopefully more or less documented though probably not
> everywhere.

NR refers to
http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
which does not mention the quoted syntax, and explicitly disallows dashes
and underscores.

=== Suggested replacement text ===

The name of a variable must consist of alphabetic characters, underscores
and dashes. Underscores and dashes must always follow and be followed by an
alphabetic character. Also, the name of a variable may not be one of
LilyPond's predefined keywords.

These are valid variable names:

pieceIV
myMusic
alternate-one
big_loud_part

Examples of invalid names:

piece4 (numbers not allowed)
-my-Music (leading dash)
alternate--one (more than one consecutive dash)
example_ (ends with underscore)

A variable name may be enclosed in double quotes, e.g. "pieceIV" is
the same as pieceIV. When using quotes, the name may consist of any
sequence of characters. For example "My New Music Piece 14²" is a valid
variable but there is no quote-less way to refer to it.

"My New Music Piece 14²" = \new Staff {
  \relative {
a'4 b c b
  }
}

{
  <<
\"My New Music Piece 14²"
  >>
}

=== end of suggestion ===

> But really, \"violin1" is so much more ugly than \violinI or if you must
> \violin_I.

Let's consider this a matter of taste...

BTW, you can use unicode characters including numerals ☺ .

bella_melódia-① = { ... }

-- Johan
   http://johan.vromans.org/seasons_greetings.html


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

Re: Strings as variable names

[David Kastrup]

Malte Meyn  writes:

> Am 28.12.2015 um 19:20 schrieb David Kastrup:
>> What's wrong with violinI ?
>
> lexicographical sorting (of file names) ≠ roman numeral sorting

File names are not variable names.

-- 
David Kastrup

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

Re: Beamed Tremolo + Fermata

[tisimst]

Ooooh! I really like this idea as it would solve the horizontally-centered
problem, but I just realized that it would inherit the unknown of the
fermata's vertical position that escapes collisions with other elements. I
don't know if it could still be treated like a Script object (to take care
of vertical positioning), but added to the beam stencil (to take care of
horizontal positioning). That would be a nice feature, though!

- Abraham

On Sunday, December 27, 2015, Kieren MacMillan [via Lilypond] <
ml-node+s1069038n185152...@n5.nabble.com> wrote:

> Hi Abraham,
>
> On Dec 24, 2015, at 5:52 PM, Abraham Lee <[hidden email]
> > wrote:
> > Any other nice ideas to center-align the fermata on the tremolo beams?
>
> Override [once] the Beam.stencil to add the [centred] fermata?
>
> Hope that helps,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: [hidden email]
> 
>
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Beamed-Tremolo-Fermata-tp185064p185152.html
> To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Beamed-Tremolo-Fermata-tp185064p185230.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: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 20:27:22 +0100
David Kastrup  wrote:

> The above is mainly confused.  Remember that \n in a string stands for
> newline.

So there's already some kind of processing done. \{varname} would be an
alternative.

But it is just a suggestion.

> But what _programming_ languages allow interpolating into quoted
> strings?

Most dynamic languages like Bash, Perl, JavaScript, ...

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: Strings as variable names

[Werner LEMBERG]

> Reading people's ideas about those things make them appear like
> something we would be better without.  They only lead to confusion.

+1


Werner

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

Re: Strings as variable names

[Simon Albrecht]

On 28.12.2015 20:28, Johan Vromans wrote:

NR refers to
http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
which does not mention the quoted syntax, and explicitly disallows dashes


Ugh, that’s bad.
Especially since it’s an important feature in interlocking Scheme and 
LilyPond code. Mind you, I’ve even think it might be better to use the 
scheme naming convention lowercase-with-dashes everywhere in LilyPond 
code. To be discussed when GLISS finally will get on the table again…


Yours, Simon

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

Re: Strings as variable names

[Malte Meyn]

Am 28.12.2015 um 20:30 schrieb David Kastrup:
> Malte Meyn  writes:
> 
>> Am 28.12.2015 um 19:20 schrieb David Kastrup:
>>> What's wrong with violinI ?
>>
>> lexicographical sorting (of file names) ≠ roman numeral sorting
> 
> File names are not variable names.
> 

That’s true. I just don’t like to have two different naming schemes
(horn4.pdf contains hornIV) where it’s not really necessary ...

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

Re: Strings as variable names

[Werner LEMBERG]

> Whenever you have variables pointing to indexed parts or to
> consecutive snippets you may want to use variables like
>
> violin1 =
> violin2 =
>
> or
>
> flute_phrase01 =
> flute_phrase02 =
>
> or similar.  This is expressive as LilyPond code per se, and would
> be accessible for scripting, e.g. to generate stub files with empty
> varialbes.
>
> The workaround using roman numbers is pretty cumbersome, and I think
>
> violin_02_34 would be much more comprehensible to most users than
> violinIIxxxiv

I suggest to use the m4 preprocessor
[https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,
say, `violin1' to `violinI'.  Add the line

  define(`violin1', `violinI')

at the very beginning of your input file, then run

  m4 < infile > outfile


 Werner

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

Re: Beamed Tremolo + Fermata

[Thomas Morley]

2015-12-28 20:33 GMT+01:00 tisimst :
> Ooooh! I really like this idea as it would solve the horizontally-centered
> problem, but I just realized that it would inherit the unknown of the
> fermata's vertical position that escapes collisions with other elements. I
> don't know if it could still be treated like a Script object (to take care
> of vertical positioning), but added to the beam stencil (to take care of
> horizontal positioning). That would be a nice feature, though!
>
> - Abraham

How about overriding TupletNumber?

\version "2.19.32"
%\paper { ragged-right = ##f }

fermataOverTremolo =
#(define-music-function (mus)(ly:music?)
#{
  \once \omit TupletBracket
  %% maybe add this?
  %\once \override TupletNumber.outside-staff-priority = 100
  \once \override TupletNumber.text =
  #(lambda (grob)
(let ((dir (ly:grob-property grob 'direction)))
  (markup
#:musicglyph (format #f "scripts.~afermata" (if (= dir 1) "u" "d")
  \times 1/1
  $mus
#})

\relative c,
{
  \voiceTwo
  \fermataOverTremolo \repeat tremolo 16 { a32 c }
}

Cheers,
  Harm

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

Re: Notation snippets

[Thomas Morley]

2015-12-27 23:10 GMT+01:00 Jayaratna :
> Thank you so much, Harm.
>
> Maybe I could/should draw the glyphs for petrucci style flags. They should
> not be too much work if I can start from a draft.
>
> Andy

Would be great. Patches are always welcome.
I can't help with this, though. I have no clue how to create
glyphs/fonts (but others on this list may help you), nor do I know how
petrucci-flags should look like.

Cheers,
  Harm

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2015-12-28 1:25 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> (1)
>> stencil-whiteout-box uses define*-public and optional arguments, I
>> thought it's broken in guilev2
>
> Only in connection with currying.  So
>
> (define*-public ((...
>
> is (possibly) going to cause trouble while
>
> (define*-public (...
>
> is ok.
>
Thanks for the hint.

Iiuc, than the following is a curried definition:
(define (curry-list-a a) b) c) d) e)
  (list a b c d e))

It could be rewritten as:
(define curry-list-b
  (lambda (a)
(lambda (b)
  (lambda (c)
(lambda (d)
  (lambda (e) (list a b c d e)))

guilev2 may have problems with:
(define*-public (curry-list-c a) b) c) d) e #:optional (f "x"))
  (list a b c d e f))

Though I'm not sure with the following one. May I ask: curried or not?
(define (foo a b)
  (let ((x2 (lambda (arg) (* 2 arg
(map x2 (list a b


Best,
  Harm

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

Re: Beamed Tremolo + Fermata

[Kieren MacMillan]

Harm,

> How about overriding TupletNumber?

#BOOM or #FTW or whatever the kids would say nowadays.  =)
Nicely done!

Although it’s a [tiny] pimple on the ‘Pond that these kind of [incredibly 
elegant] hacks must be done, it’s a [giant] shiny platinum crown on the ‘Pond 
that it’s so easy.

Best,
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: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 21:39:05 +0100 (CET)
Werner LEMBERG  wrote:

> I suggest to use the m4 preprocessor
> [https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,

Yikes. Speaking of overkill...

> say, `violin1' to `violinI'.  Add the line
> 
>   define(`violin1', `violinI')

This will happily change violin12 to violinI2, etc., probably not what you
want.

m4 is not for the faint of the heart.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: Strings as variable names

[David Kastrup]

Simon Albrecht  writes:

> On 28.12.2015 20:28, Johan Vromans wrote:
>> NR refers to
>> http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
>> which does not mention the quoted syntax, and explicitly disallows dashes
>
> Ugh, that’s bad.
> Especially since it’s an important feature in interlocking Scheme and
> LilyPond code. Mind you, I’ve even think it might be better to use the
> scheme naming convention lowercase-with-dashes everywhere in LilyPond
> code.

Nope.  Far too large collision potential with preexisting Scheme
identifiers.  Often the underlying Scheme functions for some music
function are named the same, just with dashes instead of CamelCase.

> To be discussed when GLISS finally will get on the table again…

To me, the main motivation for changes in syntax is making things work
better or more consistently.  Unifying LilyPond's idea of valid
identifier syntax across modes made a number of things work more
reliably and removed strange errors and quirks.  But that the
conventions are no longer brutally enforced by LilyPond does not render
them useless.

-- 
David Kastrup

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[David Kastrup]

Thomas Morley  writes:

> Though I'm not sure with the following one. May I ask: curried or not?
> (define (foo a b)
>   (let ((x2 (lambda (arg) (* 2 arg
> (map x2 (list a b

Why would that one be curried?  It's completely boring, returns a list,
and its internal function x2 is totally straightforward (not even a
closure) and is invisible to the caller.

Slightly more interesting is

(define (fie a)
  (lambda (x) (+ x a)))

which is equivalent to the curried definition

(define ((fie a) x) (+ x a))

However, the currying is not a feature of the semantics (the semantics
of returning a function or more often a closure, namely a function with
an environment in the form of variables imported into its scope) but of
the syntax.

So while the second definition of fie is a curried definition, the first
equivalent definition isn't.

-- 
David Kastrup

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

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 20:27:22 +0100
> David Kastrup  wrote:
>
>> The above is mainly confused.  Remember that \n in a string stands for
>> newline.
>
> So there's already some kind of processing done. \{varname} would be an
> alternative.
>
> But it is just a suggestion.
>
>> But what _programming_ languages allow interpolating into quoted
>> strings?
>
> Most dynamic languages like Bash, Perl, JavaScript, ...

You conveniently snipped shells so that you could mention them again.
Perl has gobbled up every syntax from all traditional UNIX utilities
anyway so that does not really count.

JavaScript does not appear to do variable interpolation into string
literals
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String>
as far as I can see.

That's a far cry from "most programming languages".  It's not even "most
dynamic languages".  It's shells and Perl.  Arguably Cpp though it's not
a programming language of its own.  Make knows $x but does not really
work with quoted strings.  Awk knows $x but not inside quoted strings.
M4 does not work with quoted strings but will expand recognizable
identifiers in at most one level of [...].  But it's not a programming
language.

Maybe Tcl?  Would seem consistent with its history but I don't know it.

-- 
David Kastrup

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

Re: Beamed Tremolo + Fermata

[Thomas Morley]

2015-12-28 22:41 GMT+01:00 Kieren MacMillan :
> Harm,
>
>> How about overriding TupletNumber?
>
> #BOOM or #FTW or whatever the kids would say nowadays.  =)
> Nicely done!
>
> Although it’s a [tiny] pimple on the ‘Pond that these kind of [incredibly 
> elegant] hacks must be done, it’s a [giant] shiny platinum crown on the ‘Pond 
> that it’s so easy.
>
> Best,
> Kieren.


Glad you like it.
Here a little more sophisticated code, with optional setting of
'outside-staff-priority

\version "2.19.32"

%\paper { ragged-right = ##f }

fermataOverTremolo =
#(define-music-function (outside-staff-priority? mus)((boolean? #t) ly:music?)
"Returns @code{fermata} over tremolo-beam.
If the optional @var{outside-staff-priority?} is set @code{#f}, the value of
@code{outside-staff-priority} is disregarded."
(if (eq? (ly:music-property mus 'name) 'TremoloRepeatedMusic)
#{
  \once \omit TupletBracket
  %% maybe add this?
  #(if outside-staff-priority?
   #{ \once \override TupletNumber.outside-staff-priority = 100 #})
  \once \override TupletNumber.text =
  #(lambda (grob)
(let ((dir (ly:grob-property grob 'direction)))
  (markup
#:musicglyph
(format #f "scripts.~afermata" (if (= dir 1) "u" "d")
  \times 1/1
  $mus
#}
mus))

\relative c''
{
  %\voiceOne
  %\voiceTwo
  \fermataOverTremolo
\repeat tremolo 16 { c32 a }
  \fermataOverTremolo ##f
\repeat tremolo 16 { c32 a }
}

Though, we don't do all nicely with tremolo. Look at the terrible output from:

\repeat tremolo 16 { c''32 ais' }

https://sourceforge.net/p/testlilyissues/issues/3143/

Cheers,
  Harm

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

Re: Beamed Tremolo + Fermata

[David Kastrup]

Thomas Morley  writes:

> 2015-12-28 20:33 GMT+01:00 tisimst :
>> Ooooh! I really like this idea as it would solve the horizontally-centered
>> problem, but I just realized that it would inherit the unknown of the
>> fermata's vertical position that escapes collisions with other elements. I
>> don't know if it could still be treated like a Script object (to take care
>> of vertical positioning), but added to the beam stencil (to take care of
>> horizontal positioning). That would be a nice feature, though!
>>
>> - Abraham
>
> How about overriding TupletNumber?
>
> \version "2.19.32"
> %\paper { ragged-right = ##f }
>
> fermataOverTremolo =
> #(define-music-function (mus)(ly:music?)
> #{
>   \once \omit TupletBracket
>   %% maybe add this?
>   %\once \override TupletNumber.outside-staff-priority = 100
>   \once \override TupletNumber.text =
>   #(lambda (grob)
> (let ((dir (ly:grob-property grob 'direction)))
 ^^ That one calls
 Tuplet_bracket::get_default_dir which references a
 whole lot of other callbacks and properties and then
 caches the resulting value.  I'm not sure this will
 always be correct.
>   (markup
> #:musicglyph (format #f "scripts.~afermata" (if (= dir 1) "u" "d")
>   \times 1/1
>   $mus
> #})
>
> \relative c,
> {
>   \voiceTwo
>   \fermataOverTremolo \repeat tremolo 16 { a32 c }
> }
>
> Cheers,
>   Harm

-- 
David Kastrup

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

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 21:39:05 +0100 (CET)
> Werner LEMBERG  wrote:
>
>> I suggest to use the m4 preprocessor
>> [https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,
>
> Yikes. Speaking of overkill...
>
>> say, `violin1' to `violinI'.  Add the line
>> 
>>   define(`violin1', `violinI')
>
> This will happily change violin12 to violinI2, etc., probably not what you
> want.

File: m4.info,  Node: Names,  Next: Quoted strings,  Up: Syntax

3.1 Macro names
===

A name is any sequence of letters, digits, and the character '_'
(underscore), where the first character is not a digit.  'm4' will use
the longest such sequence found in the input.

So, no.

> m4 is not for the faint of the heart.

It's not as bad as you want to paint it.  It would not be my choice of
tool here nevertheless.

-- 
David Kastrup

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2015-12-28 23:13 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> Though I'm not sure with the following one. May I ask: curried or not?
>> (define (foo a b)
>>   (let ((x2 (lambda (arg) (* 2 arg
>> (map x2 (list a b
>
> Why would that one be curried?  It's completely boring, returns a list,
> and its internal function x2 is totally straightforward (not even a
> closure) and is invisible to the caller.
>
> Slightly more interesting is
>
> (define (fie a)
>   (lambda (x) (+ x a)))
>
> which is equivalent to the curried definition
>
> (define ((fie a) x) (+ x a))
>
> However, the currying is not a feature of the semantics (the semantics
> of returning a function or more often a closure, namely a function with
> an environment in the form of variables imported into its scope) but of
> the syntax.
>
> So while the second definition of fie is a curried definition, the first
> equivalent definition isn't.
>
> --
> David Kastrup

Indeed interesting.

Thanks again,
  Harm

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

Re: Beamed Tremolo + Fermata

[Thomas Morley]

2015-12-28 23:47 GMT+01:00 David Kastrup :

>>   \once \override TupletNumber.text =
>>   #(lambda (grob)
>> (let ((dir (ly:grob-property grob 'direction)))
>  ^^ That one calls
>  Tuplet_bracket::get_default_dir which references a
>  whole lot of other callbacks and properties and then
>  caches the resulting value.  I'm not sure this will
>  always be correct.

Hmmm.
Up to now I found no problematic case, though would it be better to do
   (let ((dir (ly:grob-property (ly:grob-object grob 'bracket) 'direction)))
?

Cheers,
  Harm

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

Ragged right on last 2 bars.

[Peter Terpstra]

Dear People,
Is it possible to apply the ragged-right paper option in such a way that only 
the last 2 bars will be effected?

Thanks in advantage!

Example:
\version "2.18.2"
\paper {
  indent = 0
  ragged-last-bottom = ##t
  ragged-right = ##t
}
\score {
  \relative c' {
   \repeat unfold 12 {a'4 b c d}\break
r 2
   \bar "|."
  }
}

Peter


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

Re: Ragged right on last 2 bars.

[Thomas Morley]

2015-12-29 0:41 GMT+01:00 Peter Terpstra :
> Dear People,
> Is it possible to apply the ragged-right paper option in such a way that only 
> the last 2 bars will be effected?
>
> Thanks in advantage!
>
> Example:
> \version "2.18.2"
> \paper {
>   indent = 0
>   ragged-last-bottom = ##t
>   ragged-right = ##t

Use
ragged-last = ##t
instead

HTH,
  Harm

> }
> \score {
>   \relative c' {
>\repeat unfold 12 {a'4 b c d}\break
> r 2
>\bar "|."
>   }
> }
>
> Peter
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Ragged right on last 2 bars.

[Brian Barker]

At 15:41 28/12/2015 -0800, Peter Terpstra wrote:
Is it possible to apply the ragged-right paper option in such a way 
that only the last 2 bars will be affected?


Example:
\version "2.18.2"
\paper {
  indent = 0
  ragged-last-bottom = ##t
  ragged-right = ##t
}
\score {
  \relative c' {
   \repeat unfold 12 {a'4 b c d}\break
r 2
   \bar "|."
  }
}


ragged-last = ##t
(without ragged-right = ##t)
Note that ragged-last-bottom applies to vertical spacing, not horizontal.

I trust this helps.

Brian Barker


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

Re: Ragged right on last 2 bars.

[Peter Terpstra]

Thomas Morley wrote:

> Use
> ragged-last = ##t
> instead

Thank you kindly, so simple :)

Peter


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

Music running off page, yet passes bar line check

[Ryan Michael]

I have the following music :


\tempo 4=40
\time 4/4
\clef bass
\barNumberCheck #1
b,1\glissando


\barNumberCheck #2
\once \hide NoteHead bes4\glissando a2\glissando \once \hide NoteHead
a4\glissando


\barNumberCheck #3
\once \hide NoteHead a4\glissando b-\markup{"don't articulate b. stop gliss
exactly on 1"} r8 b8\glissando \once \hide NoteHead b16 a8.~


\barNumberCheck #4
a4\glissando \once \hide NoteHead bes4\glissando \once \hide NoteHead
bes\glissando b8\glissando c16\glissando [\once \hide NoteHead
b32\glissando a32]]

\barNumberCheck #5
r16 b8.\glissando
 \once \hide NoteHead a4\glissando
\once \hide NoteHead gis8\glissando g8-\markup{\italic "crescendo"}
g16\glissando-\markup{\italic "decrescendo"} \once \hide NoteHead
a8.\glissando


\barNumberCheck #6
\once \hide NoteHead ais4\glissando \once \hide NoteHead b16 b8. r4

gis4\glissando\p\<



\barNumberCheck #7
\once \hide NoteHead gis4\glissando feh\glissando\mp\>\! \once \hide
NoteHead g4\glissando \once \hide NoteHead a4\glissando



\barNumberCheck #8
gis4\!\p r4 gis4\glissando a\glissando


\barNumberCheck #9
b\glissando a\glissando b8\glissando a16.\glissando b32 r8 b8\glissando


\barNumberCheck #10
\once \hide NoteHead bes8 a\glissando \once \hide NoteHead
 bes8 \tuplet 3/2{ b\glissando a\glissando b\glissando} a8
r8
r16 b\glissando

\barNumberCheck #11
\once \hide NoteHead a4\glissando \once \hide NoteHead aes8.\glissando
g16\glissando
\once \hide NoteHead gis4\glissando \once \hide NoteHead a4\glissando


\barNumberCheck #12
\once \hide NoteHead ais4\glissando bes8-\markup{\italic "decrescendo
molto"}\glissando b16 r16 r4 r4



And all the bars are right, and yet the second line is cramped and runs off.



-- 
ॐ नमः शिवाय
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Music running off page, yet passes bar line check

[Brian Barker]

At 18:05 28/12/2015 -0800, Ryan Michael wrote:

I have the following music :

\tempo 4=40
\time 4/4
\clef bass
\barNumberCheck #1
b,1\glissando
\barNumberCheck #2
\once \hide NoteHead bes4\glissando a2\glissando 
\once \hide NoteHead a4\glissando

\barNumberCheck #3
\once \hide NoteHead a4\glissando 
b-\markup{"don't articulate b. stop gliss 
exactly on 1"} r8 b8\glissando \once \hide NoteHead b16 a8.~

\barNumberCheck #4
a4\glissando \once \hide NoteHead bes4\glissando 
\once \hide NoteHead bes\glissando b8\glissando 
c16\glissando [\once \hide NoteHead b32\glissando a32]

\barNumberCheck #5
r16 b8.\glissando
 \once \hide NoteHead a4\glissando
\once \hide NoteHead gis8\glissando 
g8-\markup{\italic "crescendo"} 
g16\glissando-\markup{\italic "decrescendo"} \once \hide NoteHead a8.\glissando

\barNumberCheck #6
\once \hide NoteHead ais4\glissando \once \hide NoteHead b16 b8. r4
gis4\glissando\p\<
\barNumberCheck #7
\once \hide NoteHead gis4\glissando 
feh\glissando\mp\>\! \once \hide NoteHead 
g4\glissando \once \hide NoteHead a4\glissando

\barNumberCheck #8
gis4\!\p r4 gis4\glissando a\glissando
\barNumberCheck #9
b\glissando a\glissando b8\glissando a16.\glissando b32 r8 b8\glissando
\barNumberCheck #10
\once \hide NoteHead bes8 a\glissando \once \hide NoteHead
 bes8 \tuplet 3/2{ b\glissando a\glissando b\glissando} a8
r8
r16 b\glissando
\barNumberCheck #11
\once \hide NoteHead a4\glissando \once \hide 
NoteHead aes8.\glissando g16\glissando

\once \hide NoteHead gis4\glissando \once \hide NoteHead a4\glissando
\barNumberCheck #12
\once \hide NoteHead ais4\glissando 
bes8-\markup{\italic "decrescendo molto"}\glissando b16 r16 r4 r4


And all the bars are right, and yet the second line is cramped and runs off.


It seems that systems will not break where there 
is a glissando across the bar line (in 2.18.2). 
The break that occurs after bar 4 is the last bar 
line that isn't spanned by a glissando: hence the 
cramped nature of the second system, as no 
further breaks are possible. In addition, your 
articulation "decrescendo molto" is too long to 
fit on the second system, even if there is (just) 
room for the music. If you shorten this or stack 
the words using \column, you will just see the 
final bar line, though displaced into the margin 
- or at least I do with my default settings. If 
you drop one of the glissandi, you can see three sensibly spaced systems.


I trust this helps.

Brian Barker


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

Re: Music running off page, yet passes bar line check

[Kieren MacMillan]

Hi all,

> If you drop one of the glissandi

Or use

\override Glissando.breakable = ##t

(For more information, see 
.)

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: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 23:04:37 +0100
David Kastrup  wrote:

> You conveniently snipped shells so that you could mention them again.

You can find a lot more on
https://en.wikipedia.org/wiki/String_interpolation

But does it really matter?

The point is, is it something we would want (i.e., is useful) in LilyPond?

-- Johan
   http://johan.vromans.org/seasons_greetings.html

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

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 23:52:27 +0100
David Kastrup  wrote:

> So, no.

I stand corrected.
It's a very long since ago that I stopped using m4.

> It would not be my choice of tool here nevertheless.

Preprocessors in general add the disadvantage of having unmaintainable
sources (you cannot edit the unprocessed source with e.g. frescobaldi
without trickery) and hard to find errors (line/column numbers may change).

For the purpose discussed here (using something better than violinI) it is
definitely not the best tool.

-- Johan

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