Re: MagnifyStaff Bug?

2016-05-16 Thread Carl-Henrik Buschmann
Hi Simon,

> it’s a known issue that alignment of barlines can be difficult in such cases. 
> I think we have a tracker issue, and it’s a non-trivial question how such 
> barlines should be aligned by default.

So it is a know issue, that it is all i needed to know. Harm did find something 
in the LSR that probably can help, Carl provided much the same solution. For 
that i am grateful. There is much good to say about the amount of knowledge 
people have on this list! 

I find it strange though why it is not mentioned in the manual 
 
that \magnifyStaff causes the lines to «misbehave» that way. But, if it is hard 
coded, as Harm implied, then perhaps there is some convention i dont know 
about. It does not look ugly, just unexpected. As a sidenote, cues sized staffs 
should not require this much mocking about to work. 

> If you had only asked ‘Do you agree that this looks bad?’, then this would be 
> a valid point. But, naturally, you also asked if somebody knew a way to do it 
> better. And unless I know the answer straightaway and can just type some code 
> in my reply (which doesn’t happen most of the time), I need to go to 
> Frescobaldi and fiddle around with the code, in order to check out some 
> approaches. I tried, and at first compilation got numerous errors due to 
> undefined variables.
> So I’d have had to clean it up and code an example myself, which is something 
> you could just as well have done as a courtesy to the volunteers who like to 
> help you on this list. There is a reason why we have this policy of posting 
> compilable, tiny examples.
>  
> Best, Simon

All that talk about hating to guess and not understanding what «this» is 
unnecessary sour mouth stuff when the problem is very clear. I wanted to know 
from the people that did know \magnifyStaff caused this to reply. Nothing more. 
I have no problem handling people that woke up on the wrong foot. But outbursts 
like that happens all the time and while i understand the need to teach new 
users how this list should function (a simple email when signing onto the list 
should do the trick and save you all from repeating ad infinitum) i won’t stand 
for it for a small thing like this.

While i agree that I could have stated the problem clearer in text there should 
to be a certain amount of leeway when talking about a subject amongst people 
that study the same subject. The picture is _very_ telling and should leave 
little doubt what the problem was. With that little snippet i wanted to give a 
context to \magnifyStaff so that people could see if there was a simple syntax 
error. No need to post the whole code (which is far to big and making a MWE nor 
helps you nor did not solve the problem) wasting time when it could be stated 
with a simple «aha, just do it like so». And indeed it was: \magnifyStaff 
behaves oddly and it is know. 

Seeing that the manual is a far cry from a user manual, at least not capable 
teaching non-scheme wizards anything but the simplest stuff, this list is the 
only place to get a working knowledge of Lilypond. While «losing» me hardly 
matters  (at least till i cool off in a couple of months) i cannot say i will 
advertise the use of Lilypond at its current state. Which is a pity since i’m a 
high school music teacher that desperately _wants_ this to be an option for 
myself and my students. One day it might be. 

So long, and thanks for all the fish.


Carl-Henrik Buschmann___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


How's the #'id property used

2016-05-16 Thread Ewald Liska
Hi all,

may I ask how the 'id property defined in grob-interface is actually used?

I can assign it a value using

{
  c'
  \once \override NoteHead.id = "Hi, I'm an ID"
  d' e'
}

and it will show up properly in the resulting SVF file. But is that
property actually used somewhere already or it is just provided in order
to be set by users?

Urs


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


Page Break in Lilypond-book

2016-05-16 Thread Alberto Simões

Hi

It seems that \pageBreak is not honored by Lilypond.
I found an old post [1] that seems to state that it is needed to enclose 
each portion in a different \book block (?).


Can anybody confirm? Or explain the better way to force page break from 
within a .ly file, to happen in the lilypond-book tex file?


Thank you
Alberto

[1] https://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00105.html

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


Re: "unroll code"

2016-05-16 Thread Urs Liska


Am 15. Mai 2016 17:18:10 GMT+01:00, schrieb Paul :
>On 05/15/2016 09:01 AM, David Wright wrote:
>> On Sun 15 May 2016 at 13:07:31 (+0200), imj-muz...@bluewin.ch wrote:
>>> Would such manipulations be easy in Scheme, using DisplayMusic to
>output the result ?
>Maybe \displayLilyMusic would be useful?
>
>\version "2.18.2"
>
>ab = { c d e f }
>cd = { g a b c }
>
>\displayLilyMusic {
>   \ab
>   \cd
>}
>
>% prints:
>% { { c d e f } { g a b c } }
>

No, because there's still the "repeat" info in the expression.

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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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


Re: making TextSpanner.style a very bold and large period

2016-05-16 Thread Carl Sorensen


On 5/15/16 4:24 PM, "Ryan Michael"  wrote:

>please confer with this Schoenberg op 30 engraving, where the "rit ...
>Tempo" are designed in the way I am trying to achieve.
>https://www.youtube.com/watch?v=AidU-4YF03Y

It looks to me like all they have done in that engraving is make the
TextSpanner font larger, and that's how the dots get bigger.

I've sent another email that shows how you will soon be able to get large
dots for the TextSpanner -- once it has made it into LilyPond.

Thanks,

Carl


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


Re: Ledger Lines and Tremolos

2016-05-16 Thread Noeck
Hi Dave,

>> For example: a1:32 would give 4 ledger lines but it's hard to tell
>> that there are 4 ledger lines because the tremolo covers it.

> And make them lighter.

The a has one octave more ledger lines. You can try this and adjust
the values:

{
  \override StemTremolo.Y-offset = 3  % vertical position
  \override StemTremolo.beam-thickness = 0.3  % thickness
  a'''1:32
}

Btw, I would consider the default rather legible.
And one more note: Frescobaldi shows all available properties if you type
\override StemTremolo.
and then Ctrl+Space.

Cheers,
Joram

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


Re: Page Break in Lilypond-book

2016-05-16 Thread Phil Holmes
- Original Message - 
From: "Alberto Simões" 

To: "lilypond" 
Sent: Saturday, May 14, 2016 3:34 PM
Subject: Page Break in Lilypond-book



Hi

It seems that \pageBreak is not honored by Lilypond.
I found an old post [1] that seems to state that it is needed to enclose 
each portion in a different \book block (?).


Can anybody confirm? Or explain the better way to force page break from 
within a .ly file, to happen in the lilypond-book tex file?


Thank you
Alberto

[1] 
https://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00105.html


In non lilypond-book mode, you can force Lily so that she only obeys manual 
breaks with:


\override NonMusicalPaperColumn #'page-break-permission = ##f

(this probably works with the newer dot syntax, but it's like this in my 
source).


I believe lilypond-book effectively produces a number of single system 
images, so it's not Lily herself that established page breaks in this case.


--
Phil Holmes




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


Re: Page Break in Lilypond-book

2016-05-16 Thread David Wright
On Sat 14 May 2016 at 15:34:30 (+0100), Alberto Simões wrote:
> It seems that \pageBreak is not honored by Lilypond.
> I found an old post [1] that seems to state that it is needed to
> enclose each portion in a different \book block (?).
> 
> Can anybody confirm? Or explain the better way to force page break
> from within a .ly file, to happen in the lilypond-book tex file?

I'm not experienced with lilypond-book, but is it as simple as
using \bookpart to make the page breaks? Or are you trying to
make \pageBreaks within a \score? I think you might need to give
more context, ie an example of the structure of your file with
the \book \bookpart \score commands, and indicating where the
page breaks are that you want to force.

Cheers,
David.

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


Can not reach the list

2016-05-16 Thread Joram
Hi,

my mails do not reach lilypond-user. Does that only happen to me or is it a
general problem? I have written 4 mails in the last week an none appeared on
the list. Is there something I can do?

Best,
Joram


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


Re: making TextSpanner.style a very bold and large period

2016-05-16 Thread Carl Sorensen


On 5/15/16 7:12 PM, "Ryan Michael"  wrote:

>great! Thanks Carl. Question, you have dots, I have the dashed line. When
>I try: 
>%
>\override TextSpanner.style = #'dotted-line
> \override TextSpanner.dash-fraction = 0
>\override TextSpanner.dash-period = 5
>\override TextSpanner.thickness = 5
>
>
>
>c\startTextSpan d e f g g g a  g f a g f a g  b,  b\stopTextSpan
>%

You won't get dots until I get the patch pushed into a distribution.  It
will take a couple of weeks before you can get the dots.  I had to change
some C++ code in order to make a dash of dash-fraction zero become a dot.

So unfortunately, you will need to wait a couple of weeks before it gets
into a release.

Thanks,

Carl


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


Re: Can not reach the list

2016-05-16 Thread Brian Barker

At 21:03 15/05/2016 +, Joram Noname wrote:

my mails do not reach lilypond-user. Does that only happen to me ...


No, it's often happened to me too.


... or is it a general problem? Is there something I can do?


There ought to be - but sadly it seems no-one is prepared to investigate.

I wonder if this message will make it ...

Brian Barker  



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


Re: Can not reach the list

2016-05-16 Thread Alberto Simões

Just wait. I sent one on 14th, and got it delivered today :)

On 15/05/16 22:03, Joram wrote:

Hi,

my mails do not reach lilypond-user. Does that only happen to me or is it a
general problem? I have written 4 mails in the last week an none appeared on
the list. Is there something I can do?

Best,
Joram


___
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: making TextSpanner.style a very bold and large period

2016-05-16 Thread Carl Sorensen


On 5/15/16 4:18 PM, "Ryan Michael"  wrote:

>Hello I am trying to go for a classic textSpan look, by using essentially
>a period '.' quite large and bold.
>as the in lieu of the 'dashed-line, line style. Is there a way I can do
>this?


Ryan,

I can find no way of doing it with the current LilyPond.  Setting the
dash-fraction to zero is supposed to make dots instead of dashes, but
doesn't work properly.

I've made some changes in the source code, and got the dots to work
properly.  I will propose this as a patch to LilyPond, and I expect that
it will be accepted in about two weeks.  So you should be able to do this
soon.


Here's the code that produced the attached output:

\version "2.19.42"

\score {
  \relative {
\override TextSpanner.dash-fraction = 0
\override TextSpanner.dash-period = 5
\override TextSpanner.thickness = 5
\override TextSpanner.bound-details.left.text = "rit "
\override TextSpanner.bound-details.right.text = "a Tempo"
c'4\startTextSpan d e f |
g4 a b c |
d4 e f e\stopTextSpan
  }
}


I hope this will help eventually.

Carl




dot-spanner-test.pdf
Description: dot-spanner-test.pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Page Break in Lilypond-book

2016-05-16 Thread Alberto Simões



On 16/05/16 18:50, David Wright wrote:

On Sat 14 May 2016 at 15:34:30 (+0100), Alberto Simões wrote:

> It seems that \pageBreak is not honored by Lilypond.
> I found an old post [1] that seems to state that it is needed to
> enclose each portion in a different \book block (?).
>
> Can anybody confirm? Or explain the better way to force page break
> from within a .ly file, to happen in the lilypond-book tex file?

I'm not experienced with lilypond-book, but is it as simple as
using \bookpart to make the page breaks? Or are you trying to
make \pageBreaks within a \score? I think you might need to give
more context, ie an example of the structure of your file with
the \book \bookpart \score commands, and indicating where the
page breaks are that you want to force.


I am trying to break inside a score.
In fact, my "main document" is only:

\score{
\new PianoStaff <<
\new Staff = "up"   \up
\new Dynamics = "dynamics" \dynamics
\new Staff = "down" \down
>>
}

and I am using \break to break lines, inside the \up markup.

I just wanted to say that some of those are page breaks. And those 
breaks need to be "shared" with lilypond-book, as it is it who lays out 
each line image in the sheet.


Thanks
Alberto

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


Single-note tremolos

2016-05-16 Thread Carl Sorensen
Dave Higgins noted that for notes outside of the staff, tremolo
indications collided with ledger lines.

In reviewing Gould (p. 222), I found several defaults in LilyPond that go
against Gould's recommendations.

1) The tremolo lines are too wide (they should be only as wide as a
crotchet note head).

2) The tremolo lines are too thick (they should be thinner than beams, but
in LilyPond they are the same thickness).

3) The tremolo lines collide with ledger lines (they should lie entirely
within the staff).

4) For notes on a staff line, the tremolo line closest to the heads
centered on a staff space.  This is allowed in Gould, but not recommended.
The recommendation is that single tremolo strokes should center on a staff
line.  The closest stroke and the single stroke are in the same position
in LilyPond, so I think it is best to move them to a staff line.

I have created changes to the semibreve single-note tremolo spacing code
to fix all of these issues. I've attached pdf output from the current code
as well as the improved code, along with my test file.

Please review the changes and let me know if you think this is worth
committing to LilyPond.

Thanks,

Carl



tremolo-test.pdf
Description: tremolo-test.pdf


tremolo-test.ly
Description: tremolo-test.ly


tremolo-test-improved.pdf
Description: tremolo-test-improved.pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Ledger Lines and Tremolos

2016-05-16 Thread Noeck
>> For example: a1:32 would give 4 ledger lines but it's hard to tell
>> that there are 4 ledger lines because the tremolo covers it.
>>
>> What's the syntax to lower the tremolo?
> 
>   \override Beam.positions = #'(0 . 1)
> 
> Change the 0 and 1 to suit
> 
> Trevor

Only if you are talking about \repeat tremolos with two notes. For the
example above (one note, stem tremolo), StemTremolo is the right object.

Cheers,
Joram

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


Single-note tremolos

2016-05-16 Thread Carl Sorensen
Dave Higgins noted that for notes outside of the staff, tremolo
indications collided with ledger lines.

In reviewing Gould (p. 222), I found several defaults in LilyPond that go
against Gould's recommendations.

1) The tremolo lines are too wide (they should be only as wide as a
crotchet note head).

2) The tremolo lines are too thick (they should be thinner than beams, but
in LilyPond they are the same thickness).

3) The tremolo lines collide with ledger lines (they should lie entirely
within the staff).

4) For notes on a staff line, the tremolo line closest to the heads
centered on a staff space.  This is allowed in Gould, but not recommended.
The recommendation is that single tremolo strokes should center on a staff
line.  The closest stroke and the single stroke are in the same position
in LilyPond, so I think it is best to move them to a staff line.

I have created changes to the semibreve single-note tremolo spacing code
to fix all of these issues. I've attached pdf output from the current code
as well as the improved code, along with my test file.

Please review the changes and let me know if you think this is worth
committing to LilyPond.

Thanks,

Carl




tremolo-test.pdf
Description: tremolo-test.pdf


tremolo-test.ly
Description: tremolo-test.ly


tremolo-test-improved.pdf
Description: tremolo-test-improved.pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: MagnifyStaff Bug?

2016-05-16 Thread Carl Sorensen


On 5/15/16 1:20 PM, "Carl-Henrik Buschmann"  wrote:

>Those lines at the end of the system should be perfect in line with
>the ends of the staff, should they not? I have not seen it in print
>before, 
>have anybody else?
>PS. 
>After 
>that speech about not giving a compatible example -which is not at all
>relevant in regard to this question, it is a simple see and confirm my
>suspicions or not- I think it is quite a arrogant way to address the
>problem. More and more of the way communication traverses on this list
>leaves me with a bad taste in my mouth and it is a
>shame. 

I'm sorry that you are getting a bad taste when people ask you to provide
a working example so they can better help you.  In my mind, this is just a
way to be able to do the best to help.

I have made smaller staffs in the past using a different means than
MagnifyStaff.  Because I don't have your code, I don't know if my code
would have the same problem as yours.  I have made up some music to go
into your variables to make things compile, and it looks good on my
example.  But I don't know if it would work with yours or not.

So here is another way to do things; I don't know if it meets your needs.

melody = \relative {
  c''4 d e f |
  c4 d e f |
}

violinDynamics = {
}

repeatBars = {
}

pianoNotesRight = \relative {
  c'4 d e f |
  c4 d e f |
}

pianoDynamics = {
}

pianoNotesLeft = \relative {
  c4 d e f |
  c4 d e f |
}

\score {
<<
  \new Staff \with {
 fontSize = #-2
\override StaffSymbol #'staff-space = #(magstep -2)
instrumentName = #"Violin "
shortInstrumentName = #"Vln. "
  }
  {
<<\melody \violinDynamics \repeatBars>>
  }

  \new PianoStaff  \with {
instrumentName = #"Piano "
shortInstrumentName = #"Pno. "
  }
  <<
\new Staff = "Right" <<\pianoNotesRight \repeatBars>>
\new Dynamics = "Dynamics" \pianoDynamics
\new Staff = "Left" <<\clef bass \pianoNotesLeft \repeatBars>>
  >>
>>
  }



Hope this helps,

Carl


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


Re: making TextSpanner.style a very bold and large period

2016-05-16 Thread Carl Sorensen


On 5/15/16 8:50 PM, "Andrew Bernard"  wrote:

>Hi Ryan,
>
>Yes, at 2.19.41 specifying dotted-line style for text spanners just uses
>tiny dashes that look a bit like dots, and you can¹t make them larger.

Actually, you can make them larger with the TextSpanner.thickness
parameter, but they'll still be dashes, not dots.

But by 2.19.42 or 2.19.43, it should work properly.

Carl


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


Re: Single-note tremolos

2016-05-16 Thread Malte Meyn


Am 16.05.2016 um 01:23 schrieb Carl Sorensen:

2) The tremolo lines are too thick (they should be thinner than beams, but
in LilyPond they are the same thickness).


IMO your variant isn’t much better: The tremolo beams look *very* slim 
now. Two ideas:

1. Does Gould say something about *how much* thinner they should be?
2. Shouldn’t the space between the beams be reduced at the same or at 
least similar amount?



4) For notes on a staff line, the tremolo line closest to the heads
centered on a staff space.  This is allowed in Gould, but not recommended.
The recommendation is that single tremolo strokes should center on a staff
line.  The closest stroke and the single stroke are in the same position
in LilyPond, so I think it is best to move them to a staff line.


This thread from August 2015 might be related:
https://lists.gnu.org/archive/html/lilypond-user/2015-08/msg00175.html
I posted a bug and an imperfect workaround there. I also reported the 
bug here:

https://lists.gnu.org/archive/html/bug-lilypond/2015-07/msg00067.html
But I don’t think it’s been added to the tracker yet (IMO it’s different 
from issue 3143, explanation see this thread).


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


Re: MagnifyStaff Bug?

2016-05-16 Thread Carl-Henrik Buschmann
Hi Simon,

> it’s a known issue that alignment of barlines can be difficult in such cases. 
> I think we have a tracker issue, and it’s a non-trivial question how such 
> barlines should be aligned by default.

So it is a know issue, that it is all i needed to know. Harm did find something 
in the LSR that probably can help, Carl provided much the same solution. For 
that i am grateful. There is much good to say about the amount of knowledge 
people have on this list! 

I find it strange though why it is not mentioned in the manual 
 
that \magnifyStaff causes the lines to «misbehave» that way. But, if it is hard 
coded, as Harm implied, then perhaps there is some convention i dont know 
about. It does not look ugly, just unexpected. As a sidenote, cues sized staffs 
should not require this much mocking about to work. 

> If you had only asked ‘Do you agree that this looks bad?’, then this would be 
> a valid point. But, naturally, you also asked if somebody knew a way to do it 
> better. And unless I know the answer straightaway and can just type some code 
> in my reply (which doesn’t happen most of the time), I need to go to 
> Frescobaldi and fiddle around with the code, in order to check out some 
> approaches. I tried, and at first compilation got numerous errors due to 
> undefined variables.
> So I’d have had to clean it up and code an example myself, which is something 
> you could just as well have done as a courtesy to the volunteers who like to 
> help you on this list. There is a reason why we have this policy of posting 
> compilable, tiny examples.
>  
> Best, Simon

All that talk about hating to guess and not understanding what «this» is 
unnecessary sour mouth stuff when the problem is very clear. I wanted to know 
from the people that did know \magnifyStaff caused this to reply. Nothing more. 
I have no problem handling people that woke up on the wrong foot. But outbursts 
like that happens all the time and while i understand the need to teach new 
users how this list should function (a simple email when signing onto the list 
should do the trick and save you all from repeating ad infinitum) i won’t stand 
for it for a small thing like this.

While i agree that I could have been stated the problem clearer in text there 
should to be a certain amount of leeway when talking about a subject amongst 
people that study the same subject. The picture is _very_ telling and should 
leave little doubt what the problem was. With that little snippet i wanted to 
give a context to \magnifyStaff so that people could see if there was a simple 
syntax error. No need to post the whole code (which is far to big and making a 
MWE nor helps you nor did not solve the problem) wasting time when it could be 
stated with a simple «aha, just do it like so». And indeed it was: 
\magnifyStaff behaves oddly and it is know. 

Seeing that the manual is far from complete, at least not capable teaching 
non-scheme wizards anything but the simplest stuff, this list is the only place 
to get a working knowledge of Lilypond. While «losing» me hardly matters  (at 
least till i cool off in a couple of months) i cannot say i will advertise the 
use of Lilypond at its current state. Which is a pity since i’m a high school 
music teacher that desperately _wants_ this to be an option for myself and my 
students. One day it might be. 

So long, and thanks for all the fish.


Carl-Henrik Buschmann

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


Re: Single-note tremolos

2016-05-16 Thread Malte Meyn



Am 16.05.2016 um 21:20 schrieb Malte Meyn:

IMO your variant isn’t much better:


I should have first thanked you to work on this topic at all (and your 
changes 1 and 3 are indeed worth to be included into LilyPond; 2 with 
some further changes, I have no opinion on 4 but these thoughts let me 
think of the other thread I mentioned).


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


magnifyStaff bug?

2016-05-16 Thread Carl-Henrik Buschmann
I’m trying to typeset a very simple piano and violin arrangement and while 
doing the piano part I wanted to have the violin staff «cue sized» as a 
reference to the pianist. I used \magnifyStaff and while it works wonders, it 
gives me this at the end of each system:

http://i.imgur.com/6UNkJkA.png 

This is weird. Any idea why this happens? Is there perhaps a better way of 
doing this?


\score {
<<
  \new Staff \with {
\magnifyStaff #5/7
instrumentName = #"Violin "
shortInstrumentName = #"Vln. "
  }
  {
<<\melody \violinDynamics \repeatBars>>
  }

  \new PianoStaff  \with {
instrumentName = #"Piano "
shortInstrumentName = #"Pno. "
  }
  <<
\new Staff = "Right" <<\pianoNotesRight \repeatBars>>
\new Dynamics = "Dynamics" \pianoDynamics
\new Staff = "Left" <<\pianoNotesLeft \repeatBars>>
  >>
>>
  }___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: MagnifyStaff Bug?

2016-05-16 Thread Noeck
Hi,

I was also wondering where the problem is in the given example. Precise
questions help to get answers.

Am 15.05.2016 um 21:20 schrieb Carl-Henrik Buschmann:
> Those lines at the end of the system should be perfect in line with the
> ends of the staff, should they not? I have not seen it in print before,
> have anybody else?

Now it's clearer. I would call it a bug. I don't see why the bar lines
should not be aligned with the end of the staff.

My guess would be that the double bar line is left aligned with the
normal-size bar lines, but as it is smaller is has a smaller width and
ends further left. That could be a technical reason for it. Still a bug
from what I can say.

Cheers,
Joram

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


What is the correct way(TM) to set a Rezitationston?

2016-05-16 Thread Lilypond-User Mailing List
Hi all,

I need to set a document containing one or more Rezitationstöne[1] (I
don't know if there is a correct english translation). The score looks
like my hand drawn score at [2]. I came up with the following file to
set this kind of music:

\version "2.19.37"
\score{
  {
\key g \major
\relative c''{
  \makeClusters{a8~a a4 a8~a}
  fis4 g fis(e)
  \makeClusters{e8~e e4} fis4~ fis
}
  }
  \addlyrics {
The _ quick brown _ fox jumps over the _ lazy dog
  }

  \layout{
 \context {
  \Score
  \override BarLine.transparent = ##t
}
\context {
  \Staff
  \override TimeSignature.stencil = ##f
  \override Stem.transparent = ##t
}
}
}

While this works, it feels like a dirty hack, so I want to know if there
is a better way to work with this kind of notes. Especially I would like
to expand the bars until the end of the syllable (I got this for the
start by splitting the starting note and added a _ to the text). The
vertical bars at the start and end would be nice, but are not that much
important.

Bye,
Rudi.

[1] https://de.wikipedia.org/wiki/Kirchentonart#Rezitationston
[2] https://qzzq.de/rezitation.jpg

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


Re: Single-note tremolos

2016-05-16 Thread Werner LEMBERG

> In reviewing Gould (p. 222), I found several defaults in LilyPond
> that go against Gould's recommendations.
> 
> 1) The tremolo lines are too wide (they should be only as wide as a
>crotchet note head).

This is a matter of taste, it seems.  I have seen scores where the
width of tremolos is wider, especially at small sizes.

> 2) The tremolo lines are too thick (they should be thinner than
>beams, but in LilyPond they are the same thickness).

The same.  For my taste, your new settings are too thin.

> 3) The tremolo lines collide with ledger lines (they should lie
>entirely within the staff).

This looks OK.

Have you done some real world comparisons?


Werner

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


Re: Single-note tremolos

2016-05-16 Thread Carl Sorensen


On 5/16/16 1:20 PM, "Malte Meyn"  wrote:

>
>Am 16.05.2016 um 01:23 schrieb Carl Sorensen:
>> 2) The tremolo lines are too thick (they should be thinner than beams,
>>but
>> in LilyPond they are the same thickness).
>
>IMO your variant isn¹t much better: The tremolo beams look *very* slim
>now. Two ideas:
>1. Does Gould say something about *how much* thinner they should be?
>2. Shouldn¹t the space between the beams be reduced at the same or at
>least similar amount?

Lilypond beams are 0.48 staff spaces by default, which is half of the
space between staff lines.

In the code I produced I reduced the thickness by about 25%, to 0.4 staff
spaces.  Harm had suggested even thinner lines, at 0.35 staff spaces.

Gould is explicit that the separation for the tremolo lines is the same as
the separation for beams, with one possible exception -- she suggests that
when there are two tremolo lines, they should both be centered on adjacent
staff lines.  Beams should be hanging from the top, and centered on the
bottom.  At any rate, her explicit recommendation is that the spacing
should *not* be reduced, and the reduction in line thickness increases the
amount of white space between the lines.

>
>> 4) For notes on a staff line, the tremolo line closest to the heads
>> centered on a staff space.  This is allowed in Gould, but not
>>recommended.
>> The recommendation is that single tremolo strokes should center on a
>>staff
>> line.  The closest stroke and the single stroke are in the same position
>> in LilyPond, so I think it is best to move them to a staff line.
>
>This thread from August 2015 might be related:
>https://lists.gnu.org/archive/html/lilypond-user/2015-08/msg00175.html
>I posted a bug and an imperfect workaround there. I also reported the
>bug here:
>https://lists.gnu.org/archive/html/bug-lilypond/2015-07/msg00067.html
>But I don¹t think it¹s been added to the tracker yet (IMO it¹s different
>from issue 3143, explanation see this thread).

I have not yet worked on the code to change the slash placement on stemmed
notes.  The problems with the stemmed note slashes are more severe than on
the whole note slashes.  But the code for the whole notes was easier to
work on for an initial patch.  My plan was to handle the whole-note
tremolos first, and make sure I got the spacing rules right, then figure
out how to apply the spacing rules properly to the stemmed-note tremolos.

Gould says that whole-note tremolos should be applied as if the note had a
stem, so I'm comfortable doing the initial work on whole notes, then
moving it to stemmed notes.

Thanks,

Carl


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


Re: Ledger Lines and Tremolos

2016-05-16 Thread Noeck


Am 12.05.2016 um 22:45 schrieb Dave Higgins:
> That doesn't appear to move the tremolo in any direction.  Tried (5 . 5).

My previous mail did not come through (yet?), so I try once again:

Only if you are talking about \repeat tremolos with two notes this
works. For the example above (one note, stem tremolo), StemTremolo is
the right object.

Cheers,
Joram


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


Re: Single-note tremolos

2016-05-16 Thread Noeck
Hi Carl,

bringing this up and already offering a solution is really nice. Thank
you for your work!

I can only tell what my gut feeling is:

1) I like the wider tremolos more for whole notes

2) Again, I like the thick lines more

3) The tremolos inside the staff look much cleaner/better.

4) Can/Should the lines be separated by exactly one staff space?
   Would that make sense or is it too wide?

Thanks again for taking care about such details!

Best,
Joram

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


Re: Single-note tremolos

2016-05-16 Thread Thomas Morley
2016-05-16 22:52 GMT+02:00 Carl Sorensen :
>
>
> On 5/16/16 1:20 PM, "Malte Meyn"  wrote:
>
>>
>>Am 16.05.2016 um 01:23 schrieb Carl Sorensen:
>>> 2) The tremolo lines are too thick (they should be thinner than beams,
>>>but
>>> in LilyPond they are the same thickness).
>>
>>IMO your variant isn¹t much better: The tremolo beams look *very* slim
>>now. Two ideas:
>>1. Does Gould say something about *how much* thinner they should be?
>>2. Shouldn¹t the space between the beams be reduced at the same or at
>>least similar amount?
>
> Lilypond beams are 0.48 staff spaces by default, which is half of the
> space between staff lines.
>
> In the code I produced I reduced the thickness by about 25%, to 0.4 staff
> spaces.  Harm had suggested even thinner lines, at 0.35 staff spaces.

Tbh, I took 0,35 to make it obvious to everyone (and added "change to
fit your needs" or something like that).

That said, I _do_ like your changes, although I think I've seen a
broad variety in printed editions.

Thanks for doing this,
  Harm

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


Re: \keepWithTag #'A {\keepWithTag #'B \music}

2016-05-16 Thread Flaming Hakama by Elaine
Copying to the list, from an off-list conversation.
Which I started since I wasn't sure I was saying anything useful.

On Sat, May 14, 2016 at 2:13 PM, Gianmaria Lari 
wrote:

> Ciao David, you wrote:
>
> > Great news!  I'll have to look into that since I'm not familiar with
> > groupTag.
>
> If you want to check how I fixed the issue with groupTag here they are
> a complete example. I attached the following files:
>
> - Basile - bambinette.ly: the music file
> - AccordionStandardBass.ly: the library I wrote (and you've already
> seen) adding accordion standard bass facilities
> - AddStaccato.ly: a function to add some articulation to a music expression
> - SetNotesDuration.ly: a function to change the duration if a music
> expression
>
> You should be able to compile all the code. Let me know if you've any
> problem.
> If you check this new version of AccordionStandardBass.ly you will see
> there is just a new line at the beginning of the file
>
> \tagGroup #'(screenOut midiOut)
>
> This is enough to fix all the issues :)
>
> > Since you have this solved to your satisfaction, I only really have a few
> > general comments.
> >
> > The code in your library file is about 10X longer than simply writing out
> > the music in the first place.
> > My approach would be to just do something like this (note that you don't
> > need to use #' any more when specifying tags):
> >
> > cbar = {
> > \tag screenOut {
> > c4 c'\majorChordLetter 4 4
> > }
> > \tag midiOut {
> > 4  4 4
> > }
> > }
>
> Yes, there is no advantage or small advantages in using this library
> just to write one (short) music score like that one I included. If I
> intend just to write a single piece of accordion music is better to
> avoid programming and use LP to write music.
>
> But generally at the moment you start recognize pattern of similar
> problem that you need to solve frequently it become interesting
> developing/adapting/extending the language you're using. The goal is
> having new structure to be able to simplify writing, be more synthetic
> and trough higher level functionality write neater script. I imagine
> you know all these.
>

I think the trick here is making sure you make good choices about what to
generalize.

I often find that if I get too happy trying to reuse code.  Then when I
need to make changes that are specific to an instrument, or a particular
iteration, I need to unwind the work I did.


> > What if, for example, you decide to add dynamics or articulations down
> the
> > road?  Where will you enter them?  At rootNoteExp?  Will you have then
> > several versions of rootNoteExp for different dynamics and articulations,
> > and then versions for all the intermediate variables?
>
> This specific problem has been solved using AddStaccato (that I
> attached to this email).
> I wanted this solution and I'm happy it exists! And I see no reason
> why we should not want to have the same for other articulation,
> dynamics etc.
>


> > My point is that, the further you get from using direct musical input
> > syntax, the more difficult it is to add these other elements that may
> vary
> > from instance to instance.
>
> Yes, in case of LP I think you're right. But I reached a good
> compromise with my small library. Now I can easily and neatly write
> accordion with Standard bass notation. At the moment for this specific
> class of problem it is a very nice facility.
>
> > If you've defined everything by a cascade of variables, you basically
> have
> > to start from scratch whenever you have a new variation of elements.
> With
> > the more literal approach I suggest, you just copy & paste to the
> variable
> > definition to one with the modification.
> >
> > cbarP = {
> > \tag screenOut {
> > c4\p c'\majorChordLetter 4 4
> > }
> > \tag midiOut {
> > 4\p  4
> > }
> > }
>
> Yes I use copy&paste without hesitation each time other approaches does
> not work
>
> > At some point, I think the approach you've started would better
> generalize
> > to using functions.   That way, you don't have to redefine every
> different
> > permutation.
>
> Yes, exactly. And it looks not too hard to implement a functional
> approach to other LP functionalities. So maybe they will be
> standardized in the future, or I will use some snippet like now.
>
>
> > Secondly, there should be no need to replicate everything per pitch.
> Just
> > say:
> >
> > dbar = \transpose c d { \cbar }
>
> You're definitely right What a mindless man I have been!
>
> I'll make some test and if they work as supposed I will simplify the
> code like you suggest.
>
> Thanks a lot!!!
> Best regards, G.
> P.S. If you want to continue this discussion I suggest continue it on
> the LP mailing list. I think these things can interest other people.



David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_haka