RE: Octave shifts in polyphonic setting

2018-09-25 Thread Mark Stephen Mrotek
Jogchum,

I encountered the same when setting multi-voiced fugues and using the 
<<{  }\\{   }\\{  }>> construct. Is that what you use?

My solution is to set each voice explicitly, e.g.,

\new Voice = "soprano"
 { \voiceOne \relative c'' {
  f4 f f f }
 }
 
 \new Voice = "alto"
 { \voiceTwo \relative c'' {
   
   aes4 aes aes aes }
 }  

More information here
http://lilypond.org/doc/v2.19/Documentation/learning/explicitly-instantiatin
g-voices

Mark


-Original Message-
From: lilypond-user
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
Jogchum Reitsma
Sent: Tuesday, September 25, 2018 12:13 PM
To: lilypond-user 
Subject: Octave shifts in polyphonic setting

Hi,

When entering a piece of music with some one-, some two- and some
three-voiced bars, quite often notes in previous bars go up or down an
octave, when entering new bars.
Restoring this from the first bars affected by adding or deleting
apostrophes or comma's, sometimes lead again to side effects. Rather
frustrating...

Is there a way to prevent this?

regards, Jogchum Reitsma



___
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: Octave shifts in polyphonic setting

2018-09-25 Thread Jogchum Reitsma

Hi David (and Matthew),

These are fast answers! Thanks a lot!

regards, Jogchum

Op 25-09-18 om 21:25 schreef David Kastrup:

Jogchum Reitsma  writes:


Hi,

When entering a piece of music with some one-, some two- and some
three-voiced bars, quite often notes in previous bars go up or down an
octave, when entering new bars.
Restoring this from the first bars affected by adding or deleting
apostrophes or comma's, sometimes lead again to side effects. Rather
frustrating...

Is there a way to prevent this?

Use \fixed note entry instead of \relative .  It stops the notes being
dependent on one another.




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


Re: Octave shifts in polyphonic setting

2018-09-25 Thread mskala
On Tue, 25 Sep 2018, Jogchum Reitsma wrote:
> Restoring this from the first bars affected by adding or deleting apostrophes
> or comma's, sometimes lead again to side effects. Rather frustrating...
>
> Is there a way to prevent this?

Are you using relative mode?  I only use absolute, myself; every pitch
specifies its octave and they don't change depending on the cutting and
pasting of other notes.  I find that the annoyance of having to debug this
kind of thing in relative mode outweighs the convenience of leaving out
octaves on some pitches.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

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


Re: Octave shifts in polyphonic setting

2018-09-25 Thread David Kastrup
Jogchum Reitsma  writes:

> Hi,
>
> When entering a piece of music with some one-, some two- and some
> three-voiced bars, quite often notes in previous bars go up or down an
> octave, when entering new bars.
> Restoring this from the first bars affected by adding or deleting
> apostrophes or comma's, sometimes lead again to side effects. Rather
> frustrating...
>
> Is there a way to prevent this?

Use \fixed note entry instead of \relative .  It stops the notes being
dependent on one another.

-- 
David Kastrup

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


Octave shifts in polyphonic setting

2018-09-25 Thread Jogchum Reitsma

Hi,

When entering a piece of music with some one-, some two- and some 
three-voiced bars, quite often notes in previous bars go up or down an 
octave, when entering new bars.
Restoring this from the first bars affected by adding or deleting 
apostrophes or comma's, sometimes lead again to side effects. Rather 
frustrating...


Is there a way to prevent this?

regards, Jogchum Reitsma



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


Re: tweak markup text

2018-09-25 Thread Aaron Hill

On 2018-09-25 7:38 am, Abraham Lee wrote:

Hi, Ryan!

On Tue, Sep 25, 2018 at 8:34 AM Ryan Michael 
wrote:


Hello

I am trying to offset my markup text above the staff by a horizontal
quantity. I can't seem to do so. I have tried


%
\version "2.18.2"

r8^\markup{\tweak #'X-offset #1.5\huge"tempo I"} r8 r2.

%

 but that results in a syntax error.



Try this instead:

\markup { \hspace #1.5 \huge “tempo I” }


Be aware that \hspace only changes the effective width of the markup, so 
whether it moves the text depends on the alignment with the notes.  When 
the text is centered, the text would move to the right but by half the 
amount you specify.  If the markup is right-aligned, then \hspace would 
have no effect on the placement of the text.


For more precise control, consider the following markup:


\markup \translate #'(1.5 0) \huge "tempo I"


Note that you need the offset to be relative to the font size, use 
\translate-scaled instead.



-- Aaron Hill

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


Re: tweak markup text

2018-09-25 Thread David Kastrup
Ryan Michael  writes:

> Hello
>
> I am trying to offset my markup text above the staff by a horizontal
> quantity. I can't seem to do so. I have tried
>
>
> %
> \version "2.18.2"
>
> r8^\markup{\tweak #'X-offset #1.5\huge"tempo I"} r8 r2.
>
> %
>
>  but that results in a syntax error.

# introduces Scheme expressions, and 1.5\huge is not a Scheme
expression.  \tweak can only tweak music expressions, and a markup and
its insides are not music expressions (and you are missing braces around
the overall expression as well, but that's an unrelated syntax error).

However, ^\markup ... is a music expression, so you can write

\tweak X-offset #1.5 ^\markup \huge "tempo I"

for getting a tweaked expression.  So that LilyPond knows that it has to
treat it as an addition to the expression before, you need to prefix it
with one of _ - ^ as well, resulting in

{ r8-\tweak X-offset #1.5 ^\markup \huge "tempo I" r8 r2. }

Whether you write ^\tweak ... -\markup or -\tweak ... ^\markup or even
^\tweak ... ^\markup is a matter of taste.

-- 
David Kastrup

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


Re: tweak markup text

2018-09-25 Thread Abraham Lee
Hi, Ryan!

On Tue, Sep 25, 2018 at 8:34 AM Ryan Michael 
wrote:

> Hello
>
> I am trying to offset my markup text above the staff by a horizontal
> quantity. I can't seem to do so. I have tried
>
>
> %
> \version "2.18.2"
>
> r8^\markup{\tweak #'X-offset #1.5\huge"tempo I"} r8 r2.
>
> %
>
>  but that results in a syntax error.
>

Try this instead:

\markup { \hspace #1.5 \huge “tempo I” }

HTH,
Abraham

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


Re: tweak markup text

2018-09-25 Thread Kieren MacMillan
Hi Ryan,

> I am trying to offset my markup text above the staff by a horizontal 
> quantity. I can't seem to do so. I have tried 

Perhaps you’re looking for this?

%%%
\version "2.18.2"
{ r8-\tweak #'X-offset #1.5 ^\markup { \huge "tempo I" } r8 r2. }
%%%

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


tweak markup text

2018-09-25 Thread Ryan Michael
Hello

I am trying to offset my markup text above the staff by a horizontal
quantity. I can't seem to do so. I have tried


%
\version "2.18.2"

r8^\markup{\tweak #'X-offset #1.5\huge"tempo I"} r8 r2.

%

 but that results in a syntax error.
-- 
ॐ नमः शिवाय
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Melisma line

2018-09-25 Thread Noeck
Hi Kaj,

Am 25.09.2018 um 14:34 schrieb 70147pers...@telia.com:
> Noeck: You suggested to print the stop character in white, the assumed
> paper colour. But what happens if you would print your score on a
> coloured paper, e.g. yellow.

Nothing happens, because a space has no colour. So that still works fine.

But that was just a fancy way of making the space so complex that it
doesn't get ignored. In case you like something like that, I'd suggest
to go with David W. and a non-breakable space:

> n = \lyricmode { \markup \char ##x00A0 }

Best,
Joram

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


Re: Re: Melisma line

2018-09-25 Thread 70147persson



On 2018-09-24 at 01:02, David Wright wrote:

On Sun 23 Sep 2018 at 14:35:59 (-0700), Aaron Hill wrote:

On 2018-09-23 1:43 pm, Noeck wrote:

Txt = \lyricmode { Ah Ah __ \repeat unfold 2 { \skip 1 } Ah Ah }


Try using "" or any invisible markup instead of the skips.

That did not work here. But this ugly hack does:

\lyricmode { Ah Ah __ \markup \with-color #white " " _ Ah Ah }

Actually, the color does not matter. But only an empty markup or a
space
is not enough.

My solution to this sort of thing is to make sure that only notes that
have lyrics assigned are in the voice in question when using
\addlyrics or \lyricsto.  The two "extra" notes would be put into
their own voice so nothing tries to bind to them.


\version "2.18.2"
A = \relative g' { g2 g( g g) << { s2 s } \\ { \oneVoice g2 g } >> g g }
Txt = \lyricmode { Ah Ah __ Ah Ah }
\score { \A \addlyrics { \Txt } \layout {} }


That's adds a lot of complexity. I prefer a simpler approach:

%%
\version "2.18.2"

A = \relative g' { g2 g( g g) g g g g }
n = \lyricmode { "" }

Txt = \lyricmode { Ah Ah __ \n _ Ah Ah }

\score { \A \addlyrics { \Txt } \layout {} }

nbsp = \markup \char ##x00A0 % safer alternative than the literal char (which 
does work)
n = \lyricmode { \nbsp }

Txt = \lyricmode { Ah Ah __ \n _ Ah Ah }

\score { \A \addlyrics { \Txt } \layout {} }
%%

The first method can emit warning messages so I use the second,
defined in a library \include.

You only need one melisma stopper, and I then use _ for subsequent notes as

   … a melisma __ \n
   \repeat unfold 83 _
   Next lyric …

is so tidy, and easily edited.

Cheers,
David.


Hello everybody, Simon, Noeck, Aaron and David, and thank you for your 
efforts in my embarrassment.


Simon: Well, I started with your suggestion, and it worked, so I was 
satisfied, almost. The printed score was what I wanted and I could see 
no influence on the MIDI file. But instead I got a bunch of warnings 
because of the empty string "". Well, it was warnings and not errors, so 
the compilation worked fine, and at that stage I was prepared to accept, 
even if I was not fully contented.


Noeck: You suggested to print the stop character in white, the assumed 
paper colour. But what happens if you would print your score on a 
coloured paper, e.g. yellow. Right now I cannot see any reason for this, 
but it might happen. Well, I have seen this suggestion in the manual NB, 
too, but think it's a second-hand solution.


Aaron: Yes, your solution works fine for this small example, but it has 
one (solvable and possibly affordable) disadvantage: Since you introduce 
two completely new voices, all settings you may have done for the 
original voice, e.g. \stemDown etc.., are lost for these two. Of course 
you can introduce them quit easily with a variable or something, but 
that is the consequence. So this method will not be my choice.


David: Already after testing Simon's method the thoughts started in my 
head, that I ought to search for a non printable control character, but 
then it dealt with the original ASCII characters (the interval hex 0x00 
to 0x1F). Indeed I was not aware of the special character you use. But 
it works perfect, and I have not noticed any unwanted side effects. So 
that is the way I will chose. The last lines in your message, starting 
with "You only need one melisma stopper" I do not fully understand, but 
the method you describe before that is crystal clear.



Thank you all for your help and your assistance. It has helped me a lot 
in an irritating situation.


Kaj


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


Re: Instructions to install lilypond onto Raspberry Pi

2018-09-25 Thread Peter Engelbert
That's right -- I had to add the repository from the earlier version of Debian 
to the apt sources list.  That was the only way I could get it to install.  
Compiling a large program such as lilypond from source was far too difficult 
for me (I'm a novice when it comes to building from source).

Another way would be to install Arch linux on your raspberry pi, and the arch 
repository has 2.19.82, though I can't confirm they have the ARM package.

Don't know if I have much more to add--I can't quite remember how to change the 
apt sources as I switched to arch a while ago.

Best,
Peter

On Tue, Sep 18, 2018 at 07:53:03AM -0500, Karlin High wrote:
> On 9/18/2018 7:05 AM, Vivyan wrote:
> > did they have any success building lilypond?
> 
> I don't know if this is the exact thread that Federico Bruni had in mind,
> but it should be close.
> 
> 
> 
> There, Peter Engelbert was trying to compile LilyPond from source. (Adding
> him to CC on this post.) He did report that adding the Debian 8 Jessie
> repository to his APT sources.list allowed a successful install of LilyPond
> 2.18.2 on Raspberry Pi. Newer Debian repositories were missing LilyPond due
> to a required-version conflict with the Guile package.
> -- 
> Karlin High
> Missouri, USA

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


"Generate PDF" works, but cmd doesn't

2018-09-25 Thread Pedro Pessoa
Hello!
I want to generate pdf from lilypond files via cmd, so I can run it with
AutoHotKey.
My test file works on Frescobaldi and with the Generate PDF context menu.
I'm using Windows 7 and running cmd with Admin privileges. The ">lilypond"
command returns the version and help context. When I execute ">lilypond
test.ly", it returns: 

"GNU LilyPond 2.18.2
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...terminate called after throwing an
instance of
 'std::bad_alloc'
  what():  std::bad_alloc

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information."

---

The test.ly contains nothing but:
"\version "2.18.2"

\relative c''{
  a16 a g g a4
  e'16 e b b e4
}"

Doesn't seem like a lilypond bug, since it can render the file with other
methods.
Any ideas?



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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