Re: Follow-up question to alternate music fonts

[Urs Liska]

Am 11.07.2014 07:00, schrieb David Kastrup:

tisimst  writes:


All,

Is there anyone who is VERY against distributing music fonts in binary form
(i.e., as otf, svg, etc.files)? I just don't see how we can make other music
fonts available by forcing them to have a metafont source file. I guess that
could be nice, but it seems like so much work to do that. I have about 4 or
5 alternate music fonts that people could use and I certainly don't want to
convert them to metafont. They are currently designed and built with
fontforge.

What do you think?


Spirit of the GPL is delivering source code, defined as "preferred form
of modification, including all scripts etc".  Now fonts are reasonably
separate anyway, but that's what we should stick with.  METAFONT is just
one possibility here.

If the fonts are derived from some upstream source, automating the
derivation as much as possible makes sense in order to facilitate
integrating future improvements from upstream.



IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to the 
usable form. If that should be a completely automated process and would 
for example make it possible to update the Profondo font automatically 
if a new version of Bravura comes out that would be quite good. Bravura 
itself is *not* delivered as source code, for example.


Urs

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

Re: Question for all LilyPond users (especially power users)

[David Kastrup]

Urs Liska  writes:

> I think the "cleanest" way with the least hassles (and maybe
> discussion) would be to integrate into LilyPond the _possibility_ to
> switch fonts (e.g. Abraham's functions) and provide the fonts
> independently.

I think the salient point is to provide the infrastructure where you can
install a font by dropping a number of files in directories, and then
have a standard way of accessing them.

The "drop a number of files in directories" part can ultimately be done
by using GUILEv2 functionality for downloading content via HTTP.  As
long as that is not in place, just unarchiving a font tar or zip file in
the right place would work, possibly helped with some scripts based on
wget or similar.

-- 
David Kastrup

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

Re: Question for all LilyPond users (especially power users)

[Urs Liska]

Am 11.07.2014 09:10, schrieb David Kastrup:

Urs Liska  writes:


I think the "cleanest" way with the least hassles (and maybe
discussion) would be to integrate into LilyPond the _possibility_ to
switch fonts (e.g. Abraham's functions) and provide the fonts
independently.


I think the salient point is to provide the infrastructure where you can
install a font by dropping a number of files in directories, and then
have a standard way of accessing them.

The "drop a number of files in directories" part can ultimately be done
by using GUILEv2 functionality for downloading content via HTTP.  As
long as that is not in place, just unarchiving a font tar or zip file in
the right place would work, possibly helped with some scripts based on
wget or similar.



I'm not really sure what you mean.
Does that mean you suggest incorporating that in the LilyPond installer?

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

Re: Question for all LilyPond users (especially power users)

[David Kastrup]

Urs Liska  writes:

> Am 11.07.2014 09:10, schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> I think the "cleanest" way with the least hassles (and maybe
>>> discussion) would be to integrate into LilyPond the _possibility_ to
>>> switch fonts (e.g. Abraham's functions) and provide the fonts
>>> independently.
>>
>> I think the salient point is to provide the infrastructure where you can
>> install a font by dropping a number of files in directories, and then
>> have a standard way of accessing them.
>>
>> The "drop a number of files in directories" part can ultimately be done
>> by using GUILEv2 functionality for downloading content via HTTP.  As
>> long as that is not in place, just unarchiving a font tar or zip file in
>> the right place would work, possibly helped with some scripts based on
>> wget or similar.
>>
>
> I'm not really sure what you mean.
> Does that mean you suggest incorporating that in the LilyPond installer?

No.

-- 
David Kastrup

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

Re: [SPAM] Re: Question for all LilyPond users (especially power users)

[Urs Liska]

Am 11.07.2014 09:20, schrieb David Kastrup:

Urs Liska  writes:


Am 11.07.2014 09:10, schrieb David Kastrup:

Urs Liska  writes:


I think the "cleanest" way with the least hassles (and maybe
discussion) would be to integrate into LilyPond the _possibility_ to
switch fonts (e.g. Abraham's functions) and provide the fonts
independently.


I think the salient point is to provide the infrastructure where you can
install a font by dropping a number of files in directories, and then
have a standard way of accessing them.

The "drop a number of files in directories" part can ultimately be done
by using GUILEv2 functionality for downloading content via HTTP.  As
long as that is not in place, just unarchiving a font tar or zip file in
the right place would work, possibly helped with some scripts based on
wget or similar.



I'm not really sure what you mean.
Does that mean you suggest incorporating that in the LilyPond installer?


No.



I would have wondered...
But what are you implying then?

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

Re: [SPAM] Re: Question for all LilyPond users (especially power users)

[David Kastrup]

Urs Liska  writes:

> Am 11.07.2014 09:20, schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> Am 11.07.2014 09:10, schrieb David Kastrup:
 Urs Liska  writes:

> I think the "cleanest" way with the least hassles (and maybe
> discussion) would be to integrate into LilyPond the _possibility_ to
> switch fonts (e.g. Abraham's functions) and provide the fonts
> independently.

 I think the salient point is to provide the infrastructure where you can
 install a font by dropping a number of files in directories, and then
 have a standard way of accessing them.

 The "drop a number of files in directories" part can ultimately be done
 by using GUILEv2 functionality for downloading content via HTTP.  As
 long as that is not in place, just unarchiving a font tar or zip file in
 the right place would work, possibly helped with some scripts based on
 wget or similar.

>>>
>>> I'm not really sure what you mean.
>>> Does that mean you suggest incorporating that in the LilyPond installer?
>>
>> No.
>>
>
> I would have wondered...
> But what are you implying then?

I am not implying anything beyond what I wrote.  If you don't understand
some particular sentence I wrote, please point out what problem you have
interpreting it.  I don't see a point in rewriting my entire posting in
different ways until the problem magically goes away.

-- 
David Kastrup

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

Re: Question for all LilyPond users (especially power users)

[Urs Liska]

Am 11.07.2014 09:29, schrieb David Kastrup:

Urs Liska  writes:


Am 11.07.2014 09:20, schrieb David Kastrup:

Urs Liska  writes:


Am 11.07.2014 09:10, schrieb David Kastrup:

Urs Liska  writes:


I think the "cleanest" way with the least hassles (and maybe
discussion) would be to integrate into LilyPond the _possibility_ to
switch fonts (e.g. Abraham's functions) and provide the fonts
independently.


I think the salient point is to provide the infrastructure where you can
install a font by dropping a number of files in directories, and then
have a standard way of accessing them.

The "drop a number of files in directories" part can ultimately be done
by using GUILEv2 functionality for downloading content via HTTP.  As
long as that is not in place, just unarchiving a font tar or zip file in
the right place would work, possibly helped with some scripts based on
wget or similar.



I'm not really sure what you mean.
Does that mean you suggest incorporating that in the LilyPond installer?


No.



I would have wondered...
But what are you implying then?


I am not implying anything beyond what I wrote.  If you don't understand
some particular sentence I wrote, please point out what problem you have
interpreting it.  I don't see a point in rewriting my entire posting in
different ways until the problem magically goes away.



You make clear what would be necessary to provide a convenient way to 
get and install additional fonts to be used by LilyPond (provided 
Abraham's function has been integrated to LilyPond).
What I don't get is what your opinion is about to what extent this 
should actually be integrated into LilyPond's downloads/installation 
routines. I see several options (without claiming to have a complete list):

- let LilyPond try to download and install fonts on LilyPond installation
- provide a script in LilyPond's download that can do that on request
- add information on usage and installation of alternate fonts to 
LilyPond's documentation
- add information of usage and a reference to a to-be-decided location 
where additional fonts can be got from.


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

Re: Question for all LilyPond users (especially power users)

[David Kastrup]

Urs Liska  writes:

> Am 11.07.2014 09:29, schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> Am 11.07.2014 09:20, schrieb David Kastrup:
 Urs Liska  writes:

> Am 11.07.2014 09:10, schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> I think the "cleanest" way with the least hassles (and maybe
>>> discussion) would be to integrate into LilyPond the _possibility_ to
>>> switch fonts (e.g. Abraham's functions) and provide the fonts
>>> independently.
>>
>> I think the salient point is to provide the infrastructure where you can
>> install a font by dropping a number of files in directories, and then
>> have a standard way of accessing them.
>>
>> The "drop a number of files in directories" part can ultimately be done
>> by using GUILEv2 functionality for downloading content via HTTP.  As
>> long as that is not in place, just unarchiving a font tar or zip file in
>> the right place would work, possibly helped with some scripts based on
>> wget or similar.
>>
>
> I'm not really sure what you mean.
> Does that mean you suggest incorporating that in the LilyPond installer?

 No.
>>>
>>> I would have wondered...
>>> But what are you implying then?
>>
>> I am not implying anything beyond what I wrote.  If you don't understand
>> some particular sentence I wrote, please point out what problem you have
>> interpreting it.  I don't see a point in rewriting my entire posting in
>> different ways until the problem magically goes away.
>>
>
> You make clear what would be necessary to provide a convenient way to
> get and install additional fonts to be used by LilyPond (provided
> Abraham's function has been integrated to LilyPond).

Not at all.  A "convenient way" is a matter of user interface, but the
underlying mechanism can be arbitrarily complex.  But I was not talking
about user interfaces.  I _was_ rather talking about the design of the
underlying mechanism which should be so simple that putting a user
interface on it (even if that means leaving this to installing packages
for a distribution) is not requiring anything beyond creating said user
interface and/or packaging.

> What I don't get is what your opinion is about to what extent this
> should actually be integrated into LilyPond's downloads/installation
> routines.

I did not express such an opinion.  Once font installation consists only
of dropping files in a directory hierarchy, it is pretty much arbitrary
how one does it.  I pointed out that GUILEv2 would make it reasonably
easy to make some sort of automated process for it, to the degree where
fonts (or other resources) can conceivably be fetched and installed
on-demand during a LilyPond run.  But that does not mean that such an
interface is necessary.

The salient point is to create a situation where one can just drop fonts
as files into LilyPond's file hierarchy (the installed one and/or a
user-specific one) and have them accessible.

The mechanism with which those files are dropped can be later improved
or augmented from the basic "unpack an archive manually".

-- 
David Kastrup

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

Re: Follow-up question to alternate music fonts

[James]

On 11/07/14 08:01, Urs Liska wrote:
> Am 11.07.2014 07:00, schrieb David Kastrup:
>> tisimst  writes:
>>
>>> All,
>>>
>>> Is there anyone who is VERY against distributing music fonts in
>>> binary form
>>> (i.e., as otf, svg, etc.files)? I just don't see how we can make
>>> other music
>>> fonts available by forcing them to have a metafont source file. I
>>> guess that
>>> could be nice, but it seems like so much work to do that. I have
>>> about 4 or
>>> 5 alternate music fonts that people could use and I certainly don't
>>> want to
>>> convert them to metafont. They are currently designed and built with
>>> fontforge.
>>>
>>> What do you think?
>>
>> Spirit of the GPL is delivering source code, defined as "preferred form
>> of modification, including all scripts etc".  Now fonts are reasonably
>> separate anyway, but that's what we should stick with.  METAFONT is just
>> one possibility here.
>>
>> If the fonts are derived from some upstream source, automating the
>> derivation as much as possible makes sense in order to facilitate
>> integrating future improvements from upstream.
>>
>
> IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to
> the usable form. If that should be a completely automated process and
> would for example make it possible to update the Profondo font
> automatically if a new version of Bravura comes out that would be
> quite good. Bravura itself is *not* delivered as source code, for
> example.
>
> Urs
>

I guess I am missing something here.

Why do we need other fonts as part of LilyPond anyway? In that I can
already use (can I not?) any font that I have installed with the
appropriate markup command, I can see why emmentaler and feta were
included as that was what Han and Jan 'created' when they created
LilyPond and I can also understand why we have users that extend the
glyphs (all the weird and wonderful arrows and dots and shapes for
noteheads etc.), after all LilyPond needs at least one font to base its
code on.

So what is the point of including more *as part of the code base*?

This isn't meant as any kind of argument against or questioning of the
request to add another font, I just don't understand what the purpose
would be, other than 'because we can'.

My only concern is that we then need to include these new fonts (if
applicable) as part of the regression test suite surely? And make sure
that LilyPond's spacing calculations are not going to be compromised by
the addition of new fonts and that it isn't going to start to create
more exceptions because one font's dynamic 'f' happens to be wider or
fatter than LilyPond's (if you see what I am getting at).

Regards

James


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

Re: Follow-up question to alternate music fonts

[Urs Liska]

Am 11.07.2014 10:16, schrieb James:

On 11/07/14 08:01, Urs Liska wrote:

Am 11.07.2014 07:00, schrieb David Kastrup:

tisimst  writes:


All,

Is there anyone who is VERY against distributing music fonts in
binary form
(i.e., as otf, svg, etc.files)? I just don't see how we can make
other music
fonts available by forcing them to have a metafont source file. I
guess that
could be nice, but it seems like so much work to do that. I have
about 4 or
5 alternate music fonts that people could use and I certainly don't
want to
convert them to metafont. They are currently designed and built with
fontforge.

What do you think?


Spirit of the GPL is delivering source code, defined as "preferred form
of modification, including all scripts etc".  Now fonts are reasonably
separate anyway, but that's what we should stick with.  METAFONT is just
one possibility here.

If the fonts are derived from some upstream source, automating the
derivation as much as possible makes sense in order to facilitate
integrating future improvements from upstream.



IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to
the usable form. If that should be a completely automated process and
would for example make it possible to update the Profondo font
automatically if a new version of Bravura comes out that would be
quite good. Bravura itself is *not* delivered as source code, for
example.

Urs



I guess I am missing something here.

Why do we need other fonts as part of LilyPond anyway? In that I can
already use (can I not?) any font that I have installed with the
appropriate markup command, I can see why emmentaler and feta were
included as that was what Han and Jan 'created' when they created
LilyPond and I can also understand why we have users that extend the
glyphs (all the weird and wonderful arrows and dots and shapes for
noteheads etc.), after all LilyPond needs at least one font to base its
code on.

So what is the point of including more *as part of the code base*?

This isn't meant as any kind of argument against or questioning of the
request to add another font, I just don't understand what the purpose
would be, other than 'because we can'.

My only concern is that we then need to include these new fonts (if
applicable) as part of the regression test suite surely? And make sure
that LilyPond's spacing calculations are not going to be compromised by
the addition of new fonts and that it isn't going to start to create
more exceptions because one font's dynamic 'f' happens to be wider or
fatter than LilyPond's (if you see what I am getting at).

Regards

James


Actually that's what I mean.
I suggest to add the _ability_ to easily change the notation font 
through the make-pango-tree approach and let the user install additional 
fonts at will.
As said this is the same as with any other (notation or any other) 
program. Of course you expect your word processor to let you choose from 
arbitrary fonts, but you're completely OK with installing fonts yourself.


Urs

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

Changing how a font style is requested

[Alexander Kobel]

Dear all,

I like to use the Romande ADF font family [1] in one of my scores. I do 
the usual rule-of-three with


  \paper { ... (make-pango-font-tree
"Romande ADF No2 Std" "Romande ADF Std" "monospace"
(/ myStaffSize 20)) ... }

(If you wonder, No2 is condensed, and the non-condensed version, used in 
the headers, is mapped to sans for easy access.)


However, here's the catch: Romande does offer a bold variant, but it 
announces it as "DemiBold" instead of "Bold", according to fc-list. I 
know that I can switch to the different font each time I need bold, but 
that's an utter nuisance.
Is there any way to tell Lily how to choose a bold variant? Bonus points 
if it only applies to a specific, say, the serif font. Or, follow>, if it is possible to define a mapping similar to


  myserif = { regular: # default
   "Romande ADF No2 Std:style=Regular",
  bold:# choose way of selecting bold
   "Romande ADF No2 Std:style=DemiBold",
  italic:  # pretend I don't like Romande's italics
   # and need to scale some other font to match
   "Gentium:style=Italic:scaling=0.93",
  bold-italic: # use small caps family instead
   "Romande ADF Style Std:style=Regular" }
  ...
  \paper { #(define fonts (myserif mysans mymono (/ myStaffSize 20)) }

Obviously, that's not Lily's syntax, but you get the point...


Thanks in advance,
Alexander


[1] http://arkandis.tuxfamily.org/adffonts.html

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

Re: lilypondforum.nl

[Johan Vromans]

Federico Bruni  writes:

> We are talking about a forum in a language other than english, I don't
> see any overlap with this mailing list. If I understand what you
> mean...

I'm just afraid that interesting topics posted in one list will escapes
the others.

Well, let's see...

A final hint: Setting up a mailing list is much easier than setting up
and maintaining a forum.

-- Johan

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

Alternative partcombine strategy possible?

[Abel Cheung]

Does anybody have experience about overriding existing partcombine
methods? I have a score that behave like the one below:

- When both voices have identical rests, use partcombineUnisonoOnce
- Use partcombineApart for everything else

In the snippet below, the second line represents what I intended to
do, but manually overriding each rest for several hundred bars isn't
quite practical. Is there any possibility of using custom value for
PartCombineForceEvent forced-type property? Or there's any other
elegant method that helps saving note input time?

==
upper = \relative c' { c4 r8 d r4 e8 d c2 r2 }
lower = \relative c' { c4 r8 b c d e b c2 r2 }

upperClumsy = \relative c' {
\partcombineApart c4
\partcombineUnisonoOnce r8
d r4 e8 d c2
\partcombineUnisonoOnce r2
}

\partcombine { \partcombineApart \upper } \lower
\partcombine \upperClumsy \lower % <--- desired
==

-- 
Abel Cheung
New GPG Key fingerprint: F43B 7F88 3D7B 4B58 928E  0151 EC2B E414 3B03 A8AC
Old GPG Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF

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

Re: Question for all LilyPond users (especially power users)

[Noeck]

Hi Urs,

it seems like I missed something. How did you create those scores? Using
Abrahams proposed tools? Are they public? Or did you do that with your
own magic?
I would also be interested to test these features.

I have clear preferences when I look at the fonts you compared here. It
is also interesting how tiny differences in some glyphs affect the
overall impression.

What is the Cadence font?

Cheers,
Joram

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

Re: List defect?

[PMA]

Simon Albrecht wrote:

Hello,

now there definitely seems to be something wrong with mail delivery on the list.


Agreed.  I had reported similar trouble with other forums'
email, but now only LilyPond's hasn't returned to normal.

Pete

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

Re: Chord Symbols with inversions

[David Raleigh Arnold]

On Wed, 09 Jul 2014 12:52:13 +0100
Richard Shann  wrote:

> Hi list,
> 
> With notation like
> \version "2.18.0"
> \chordmode {
>   c/g
> }
> I can get chord names with /G at the end to indicate a G added
> below the root of the chord.
> With the notation
>  \new ChordNames 
>  {
>  1
>  }
> 
> I can get the chord symbol C typeset, but is there any way to
> get the C/G symbol

May I suggest C/g instead? I'm not the only one. Regards, Rale

-- 
Guitar teaching materials and original music for all styles and
levels. Site: http://www.openguitar.com (()) eMail:
d.raleigh.arn...@gmail.com Contact:
http://www.openguitar.com/contact.html



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

Re: Chord Symbols with inversions

[David Raleigh Arnold]

On Wed, 09 Jul 2014 12:52:13 +0100
Richard Shann  wrote:

> Hi list,
> 
> With notation like
> \version "2.18.0"
> \chordmode {
>   c/g
> }
> I can get chord names with /G at the end to indicate a G added
> below the root of the chord.
> With the notation
>  \new ChordNames 
>  {
>  1
>  }
> 
> I can get the chord symbol C typeset, but is there any way to
> get the C/G symbol

May I suggest C/g instead? I'm not the only one. Regards, Rale

-- 
For All Guitar Beginners: The pages of very easy solos missing
from all of the published guitar methods of others.
For All Guitarists: solos, duets, and peerless guitar exercises
David Raleigh Arnold   http://www.openguitar.com

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

Re: Alternative partcombine strategy possible?

[Janek Warchoł]

2014-07-11 13:56 GMT+02:00 Abel Cheung :
> Does anybody have experience about overriding existing partcombine
> methods? I have a score that behave like the one below:
>
> - When both voices have identical rests, use partcombineUnisonoOnce
> - Use partcombineApart for everything else
>
> In the snippet below, the second line represents what I intended to
> do, but manually overriding each rest for several hundred bars isn't
> quite practical. Is there any possibility of using custom value for
> PartCombineForceEvent forced-type property? Or there's any other
> elegant method that helps saving note input time?
>
> ==
> upper = \relative c' { c4 r8 d r4 e8 d c2 r2 }
> lower = \relative c' { c4 r8 b c d e b c2 r2 }
>
> upperClumsy = \relative c' {
> \partcombineApart c4
> \partcombineUnisonoOnce r8
> d r4 e8 d c2
> \partcombineUnisonoOnce r2
> }
>
> \partcombine { \partcombineApart \upper } \lower
> \partcombine \upperClumsy \lower % <--- desired
> ==


Maybe this will help you:
https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/merge-rests-engraver

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

Re: Optical spacing -- no more?

[David Nalesnik]

On Thu, Jul 10, 2014 at 5:09 AM, Abraham Lee  wrote:

> On Thu, Jul 10, 2014 at 3:39 AM, James Harkins 
> wrote:
>
> Something I've been wondering about for awhile... lilypond.org boasts of
> "optical spacing" for notes with alternating up and down stems, but it
> seems this feature has been lost somewhere (or disabled by default). In
> this example, it's quite plain to my eyes that the stems are not equally
> spaced within the bars. \version "2.18.2" \relative c'' { e4 c, f' d, g' e,
> a' f, } Which is correct -- the website, or LP's behavior? hjh
> ___ lilypond-user mailing list
> lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> James,
>
> I would have to disagree with you. I think the notes look very nicely
> spaced. I think you are misunderstanding what "optical spacing" implies. It
> doesn't mean that the stems will be placed equidistant from each other.
> That would look awful because of how far that would push the noteheads out
> of place!
>

Equally spaced stems do look nice with groupings that change staff
constantly, however.  I remember that SCORE had a feature that enabled
this.  I've often thought that LilyPond should have this option, but
haven't studied the problem enough to know how it could be implemented.

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

Re: Alternative partcombine strategy possible?

[Abel Cheung]

Yes, this is exactly what I needed, thanks a lot!

On Fri, Jul 11, 2014 at 9:08 PM, Janek Warchoł  wrote:
> 2014-07-11 13:56 GMT+02:00 Abel Cheung :
>> Does anybody have experience about overriding existing partcombine
>> methods? I have a score that behave like the one below:
>>
>> - When both voices have identical rests, use partcombineUnisonoOnce
>> - Use partcombineApart for everything else
>>
>> In the snippet below, the second line represents what I intended to
>> do, but manually overriding each rest for several hundred bars isn't
>> quite practical. Is there any possibility of using custom value for
>> PartCombineForceEvent forced-type property? Or there's any other
>> elegant method that helps saving note input time?
>>
>> ==
>> upper = \relative c' { c4 r8 d r4 e8 d c2 r2 }
>> lower = \relative c' { c4 r8 b c d e b c2 r2 }
>>
>> upperClumsy = \relative c' {
>> \partcombineApart c4
>> \partcombineUnisonoOnce r8
>> d r4 e8 d c2
>> \partcombineUnisonoOnce r2
>> }
>>
>> \partcombine { \partcombineApart \upper } \lower
>> \partcombine \upperClumsy \lower % <--- desired
>> ==
>
>
> Maybe this will help you:
> https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/merge-rests-engraver



-- 
Abel Cheung
New GPG Key fingerprint: F43B 7F88 3D7B 4B58 928E  0151 EC2B E414 3B03 A8AC
Old GPG Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF

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

Re: Optical spacing -- no more?

[Abraham Lee]

On Fri, Jul 11, 2014 at 7:09 AM, David Nalesnik 
 wrote:




On Thu, Jul 10, 2014 at 5:09 AM, Abraham Lee  
wrote:
On Thu, Jul 10, 2014 at 3:39 AM, James Harkins 
 wrote:
Something I've been wondering about for awhile... lilypond.org 
boasts of "optical spacing" for notes with alternating up and down 
stems, but it seems this feature has been lost somewhere (or 
disabled by default). In this example, it's quite plain to my eyes 
that the stems are not equally spaced within the bars.


\version "2.18.2"
\relative c'' { e4 c, f' d, g' e, a' f, }

Which is correct -- the website, or LP's behavior?

hjh

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


James,

I would have to disagree with you. I think the notes look very 
nicely spaced. I think you are misunderstanding what "optical 
spacing" implies. It doesn't mean that the stems will be placed 
equidistant from each other. That would look awful because of how 
far that would push the noteheads out of place!




Equally spaced stems do look nice with groupings that change staff 
constantly, however.  I remember that SCORE had a feature that 
enabled this.  I've often thought that LilyPond should have this 
option, but haven't studied the problem enough to know how it could 
be implemented. 


--David

That's fair. I can imagine what that looks like, but do you happen to 
have an example score that shows this? Not important if you don't.


-Abraham



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

Re: Alternative partcombine strategy possible?

[Xavier Scheuer]

On 11 July 2014 15:08, Janek Warchoł  wrote:
>
>
> Maybe this will help you:
>
https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/merge-rests-engraver

Hi Janek,

Could this definition of Merge Rests Engraver (latest by Jay Anderson)
be included directly in LilyPond?

AFAICS it is quite different from the first version by Wilbert Berendsen
and maybe the earliest comments that the way it was (firstly)
implemented made it unsuitable to be merged directly into LilyPond are
not valid anymore.

https://code.google.com/p/lilypond/issues/detail?id=1228

Cheers,
Xavier

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

Re: Optical spacing -- no more?

[David Kastrup]

Abraham Lee  writes:

>> Equally spaced stems do look nice with groupings that change staff
>> constantly, however.  I remember that SCORE had a feature that
>> enabled this.  I've often thought that LilyPond should have this
>> option, but haven't studied the problem enough to know how it could
>> be implemented. 
>>
>> --David
>>
> That's fair. I can imagine what that looks like, but do you happen to
> have an example score that shows this? Not important if you don't.

\version "2.18.2"
\relative c'' { \override NoteSpacing.stem-spacing-correction = #1.8 e4 c, f' d, g' e, a' f, }


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

Re: Optical spacing -- no more?

[Abraham Lee]

On Fri, Jul 11, 2014 at 8:00 AM, David Kastrup  wrote:

Abraham Lee  writes:


 Equally spaced stems do look nice with groupings that change staff
 constantly, however.  I remember that SCORE had a feature that
 enabled this.  I've often thought that LilyPond should have this
 option, but haven't studied the problem enough to know how it could
 be implemented. 


 --David


 That's fair. I can imagine what that looks like, but do you happen 
to

 have an example score that shows this? Not important if you don't.




--
David Kastrup


Hmmm...

Maybe just me, but I don't really like the look of that. I see the 
stems are equidistant, but, at least to me, I feel like it's not 
balanced and it makes the notehead spacing a little awkward... I'd 
still rather see the default behavior. But we all can have our 
preferences :) Not sure if either is "correct". Maybe to a professional 
musician that sight-reads music all the time (i.e., not me), it might 
make more sense. No problem with that!


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

Barline at beginning of lines of music.

[Richard Shann]

For chord charts a barline is wanted at the start of each line of music
- \bar "|" is, of course ignored in this position.
Can anyone suggest how to force printing a barline here (after the time
signature, if any).

Incidentally, the documentation is slightly misleading on this point:

http://www.lilypond.org/doc/v2.18/Documentation/notation/bars#index-bar-lines

says

"This and other special bar lines may be inserted manually at any point."

Richard
 


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

Re: Barline at beginning of lines of music.

[Richard Shann]

It is somewhat embarrassing to reply to one's own question but:

\defineBarLine "|" #'("|" "|" "|")

does the trick.

Richard


On Fri, 2014-07-11 at 17:49 +0100, Richard Shann wrote:
> For chord charts a barline is wanted at the start of each line of music
> - \bar "|" is, of course ignored in this position.
> Can anyone suggest how to force printing a barline here (after the time
> signature, if any).
> 
> Incidentally, the documentation is slightly misleading on this point:
> 
> http://www.lilypond.org/doc/v2.18/Documentation/notation/bars#index-bar-lines
> 
> says
> 
> "This and other special bar lines may be inserted manually at any point."
> 
> Richard
>  
> 
> 
> ___
> 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: Barline at beginning of lines of music.

[James]

On 11/07/14 18:00, Richard Shann wrote:

It is somewhat embarrassing to reply to one's own question but:

\defineBarLine "|" #'("|" "|" "|")

does the trick.

Richard

So do we need to improve the documentation?

If so, what do you suggest?

http://www.lilypond.org/doc/v2.19/Documentation/notation/bars#index-bar-lines


Thanks

James






On Fri, 2014-07-11 at 17:49 +0100, Richard Shann wrote:

For chord charts a barline is wanted at the start of each line of music
- \bar "|" is, of course ignored in this position.
Can anyone suggest how to force printing a barline here (after the time
signature, if any).

Incidentally, the documentation is slightly misleading on this point:

http://www.lilypond.org/doc/v2.18/Documentation/notation/bars#index-bar-lines

says

"This and other special bar lines may be inserted manually at any point."

Richard
  



___
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



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

Re: Optical spacing -- no more?

[Brian Barker]

At 16:07 11/07/2014 +0006, Abraham Lee wrote:
Maybe just me, but I don't really like the look of that. I see the 
stems are equidistant, but, at least to me, I feel like it's not 
balanced and it makes the notehead spacing a little awkward... I'd 
still rather see the default behavior. But we all can have our 
preferences :) Not sure if either is "correct".


For what it's worth, Elaine Gould agrees, saying (on p. 41);
In certain cases, spacing should be adjusted to create an illusion 
of evenness. Adjacent stems 'back to back' can otherwise look too 
close together. Notes with stems away from each other can look too far apart.


Brian Barker 



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

Re: Question for all LilyPond users (especially power users)

[tisimst]

Noeck wrote
> Hi Urs,
> 
> it seems like I missed something. How did you create those scores? Using
> Abrahams proposed tools? Are they public? Or did you do that with your
> own magic?
> I would also be interested to test these features.
> 
> I have clear preferences when I look at the fonts you compared here. It
> is also interesting how tiny differences in some glyphs affect the
> overall impression.
> 
> What is the Cadence font?
> 
> Cheers,
> Joram

Joram,

I can answer for Urs. I started another topic to the Dev list a few months
ago asking for some help with  customizing the default music font

 
. Towards the end of that series of messages, I passed some of my files to
Urs because he wanted to test them out for himself. That's how the Haydn
score with the different fonts came to be. 

The Cadence font was the first result of that effort. I felt like some
features were not quite right with Emmentaler, so I made some adjustments in
FontForge, did a bunch of research to figure out everything that goes into a
compatible font, then got that working. I then had a hayday with getting
other music fonts to work (LilyJAZZ, Profondo, etc.). At that point, I
realized that there is no way that a single music font will please
EVERYBODY, so making more available would be a good thing! As a result of
this whole process, developing a font creation/build process, making custom
fonts doesn't take me that much effort (i.e., if someone wants to compile
the glyphs they like using FontForge and send them to me, I'd happily create
a LilyPond compatible font for them :)

I'm not sure if all the hyperlinks to files still work in the above thread
(sorry, you'll have to go through quite a few messages to find them), but
anyone is welcome to try them out! On the other hand, some of the fonts have
matured a bit since then (like making SVG versions, adding glyphs, adjusting
positions, etc.), so it may be preferable to wait for the time being until
we get a solid set of files to distribute just to make sure the frustration
is kept to a minimum and the enjoyment is maximized!

Regards,
Abraham





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-for-all-LilyPond-users-especially-power-users-tp164178p164343.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: Barline at beginning of lines of music.

[Richard Shann]

On Fri, 2014-07-11 at 18:11 +0100, James wrote:
> On 11/07/14 18:00, Richard Shann wrote:
> > It is somewhat embarrassing to reply to one's own question but:
> >
> > \defineBarLine "|" #'("|" "|" "|")
> >
> > does the trick.
> >
> > Richard
> So do we need to improve the documentation?
> 
> If so, what do you suggest?

Well, clearly

"This and other special bar lines may be inserted manually at any point
where they make good sense in terms of good music typesetting practice."

would be an truer.
Or did you mean, should that override be documented? I can't answer that
because I don't know if it is a stable feature - I just guessed. In fact
I have further problems of a similar nature. The chord chart requires
double bars to be printed despite a start-repeat bar following on the
next line - even writing

\defineBarLine "||" #'("||" "||" "||")

does not cause the double bar to appear at the line end. There is surely
a lack of detail about what the list elements (end begin span) actually
mean.

Richard

> 
> http://www.lilypond.org/doc/v2.19/Documentation/notation/bars#index-bar-lines
> 
> 
> Thanks
> 
> James
> 
> 
> 
> >
> >
> > On Fri, 2014-07-11 at 17:49 +0100, Richard Shann wrote:
> >> For chord charts a barline is wanted at the start of each line of music
> >> - \bar "|" is, of course ignored in this position.
> >> Can anyone suggest how to force printing a barline here (after the time
> >> signature, if any).
> >>
> >> Incidentally, the documentation is slightly misleading on this point:
> >>
> >> http://www.lilypond.org/doc/v2.18/Documentation/notation/bars#index-bar-lines
> >>
> >> says
> >>
> >> "This and other special bar lines may be inserted manually at any point."
> >>
> >> Richard
> >>   
> >>
> >>
> >> ___
> >> 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
> 



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

Re: Optical spacing -- no more?

[David Nalesnik]

On Fri, Jul 11, 2014 at 12:50 PM, Brian Barker 
wrote:

> At 16:07 11/07/2014 +0006, Abraham Lee wrote:
>
>> Maybe just me, but I don't really like the look of that. I see the stems
>> are equidistant, but, at least to me, I feel like it's not balanced and it
>> makes the notehead spacing a little awkward... I'd still rather see the
>> default behavior. But we all can have our preferences :) Not sure if either
>> is "correct".
>>
>
> For what it's worth, Elaine Gould agrees, saying (on p. 41);
>
>> In certain cases, spacing should be adjusted to create an illusion of
>> evenness. Adjacent stems 'back to back' can otherwise look too close
>> together. Notes with stems away from each other can look too far apart.
>>
>
> Brian Barker
>

In the attached example, the unevenness of stem placement is very apparent.
 As I remember it (have to dig up an old manual), the SCORE option was a
correction for this sort of situation.

--David
\version "2.18.2"

\paper {
  tagline = ##f
}

up = \change Staff = "up"
down = \change Staff = "down"

\score {
  \new PianoStaff <<
\new Staff = "up" {
  \time 2/4
  s2
}
\new Staff = "down" {
  \clef bass
  \override Beam.auto-knee-gap = 1
  c32[
  \up
  c''
  
  \down
  c
  \up
  c''
  \down
  c 
  \up
  c'']
  r4
}   
  >>
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Barline at beginning of lines of music.

[Thomas Morley]

2014-07-11 21:14 GMT+02:00 Richard Shann :
> On Fri, 2014-07-11 at 18:11 +0100, James wrote:
>> On 11/07/14 18:00, Richard Shann wrote:
>> > It is somewhat embarrassing to reply to one's own question but:
>> >
>> > \defineBarLine "|" #'("|" "|" "|")
>> >
>> > does the trick.
>> >
>> > Richard
>> So do we need to improve the documentation?
>>
>> If so, what do you suggest?
>
> Well, clearly
>
> "This and other special bar lines may be inserted manually at any point
> where they make good sense in terms of good music typesetting practice."
>
> would be an truer.
> Or did you mean, should that override be documented? I can't answer that
> because I don't know if it is a stable feature - I just guessed. In fact
> I have further problems of a similar nature. The chord chart requires
> double bars to be printed despite a start-repeat bar following on the
> next line - even writing
>
> \defineBarLine "||" #'("||" "||" "||")
>
> does not cause the double bar to appear at the line end. There is surely
> a lack of detail about what the list elements (end begin span) actually
> mean.
>
> Richard

Well, the following works for me:

\defineBarLine "||" #'("||" "||" "||")

{
c1
\break
\bar "||"
d
}

Could you provide a tiny example?

Cheers,
  Harm

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

Re: Optical spacing -- no more?

[David Nalesnik]

On Fri, Jul 11, 2014 at 5:18 PM, David Nalesnik 
wrote:

>
>
>
> On Fri, Jul 11, 2014 at 12:50 PM, Brian Barker 
> wrote:
>
>> At 16:07 11/07/2014 +0006, Abraham Lee wrote:
>>
>>> Maybe just me, but I don't really like the look of that. I see the stems
>>> are equidistant, but, at least to me, I feel like it's not balanced and it
>>> makes the notehead spacing a little awkward... I'd still rather see the
>>> default behavior. But we all can have our preferences :) Not sure if either
>>> is "correct".
>>>
>>
>> For what it's worth, Elaine Gould agrees, saying (on p. 41);
>>
>>> In certain cases, spacing should be adjusted to create an illusion of
>>> evenness. Adjacent stems 'back to back' can otherwise look too close
>>> together. Notes with stems away from each other can look too far apart.
>>>
>>
>> Brian Barker
>>
>
> In the attached example, the unevenness of stem placement is very
> apparent.  As I remember it (have to dig up an old manual), the SCORE
> option was a correction for this sort of situation.
>

Found the manual.  The "STUD" command.  It mentions that engravers
typically make stems equidistant in cross-staff beaming situations because
the eye tends to notice the uneveness at the beam in the middle.

The attached illustrates what happens with equidistant notes.

--David
\version "2.18.2"

\paper {
  tagline = ##f
}

up = \change Staff = "up"
down = \change Staff = "down"

\score {
  <<
\new Staff {
  \relative c' {
c16[ c c c c c c c]
  }
}
\new PianoStaff <<
  \new Staff = "up" {
\time 2/4
s2
  }
  \new Staff = "down" {
\clef bass
\override Beam.auto-knee-gap = 1
c16[
\up
c''
g'''
\down
c
\up
c''
\down
c c
\up
c'']
  }   
>>
  >>
  \layout {
\context {
  \Score
  proportionalNotationDuration = #(ly:make-moment 1/16)
  \override SpacingSpanner.uniform-stretching = ##t
}
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Barline at beginning of lines of music.

[Simon Albrecht]

Am 11.07.2014 18:49, schrieb Richard Shann:

For chord charts a barline is wanted at the start of each line of music
- \bar "|" is, of course ignored in this position.
Can anyone suggest how to force printing a barline here (after the time
signature, if any).

Incidentally, the documentation is slightly misleading on this point:

http://www.lilypond.org/doc/v2.18/Documentation/notation/bars#index-bar-lines

says

"This and other special bar lines may be inserted manually at any point."
Maybe it should be specified that this is a point of _time_. This makes 
clear that the relation to actual output is not immediate.


Best, Simon

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

Multiple variables in one scope

[Samuel Speer]

Hello list,

I've been trying to create several choral scores using the same
template, but sometimes I need to change just a small part of the
template, so I end up copying the original and naming it style_two.ily
or style_piecename.ily etc. For example, in one piece I need to shrink
the PianoStaff and reduce the basic-distance for a 'rehearsal piano'
sort of look, and in another I need a full sized PianoStaff for a real
keyboard accompaniment.

To simplify the process, I've been trying to split up the 'style' into
chunks (i.e. margins, paper size, ragged or not, fonts, vertical
spacing, etc. in the paper block; lyric tweaks, pianostaff shrinking
for rehearsal piano, etc in the layout block), but it seems I can't
combine the chunks into one scope.

When I try to compile the snippet below, I get

error: syntax error, unexpected OUTPUT_DEF_IDENTIFIER
  \choralOctavoMargins

%%%
\version "2.18.2"

choralOctavoDimensions = \paper { paper-height = 10.5\in }
choralOctavoMargins = \paper { top-margin = 0.5\in }

\paper { \choralOctavoDimensions \choralOctavoMargins }
\score { \new Voice { a' b' c'' d'' } }
%%%

It works if I remove one of the two variables, but combined, it will
not work. I'm having the same issue when trying to combine in the
\layout scope.

Is what I'm trying to do possible? It seems to me that my lack of
knowledge about scoping syntax is what is giving me trouble.

Thanks in advance,
Samuel.

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