Re: Question for all LilyPond users (especially power users)
2014-07-11 4:50 GMT+02:00 tisimst tisi...@gmail.com: Schneidy wrote I did that, but I let it unfinished for a couple of weeks now... see = http://lilypond.1069038.n5.nabble.com/LilyJAZZ-in-v2-18-td162423.html#a162444 Pierre Yes! Thank you, Pierre, for your good work! I had fun making some updates to it. I think there are enough people interested in the Jazzy hand-written font that we should get this incorporated better. Since it is only available in binary font formats, is openlilylib the best place to put it? The only thing is, if we want to make the use of LilyJAZZ easier, it really needs the patched file that I mentioned in the initial post. Putting binary files in openlilylib may not be the best possible option (btw, how big they are and how muhc they are expected to change?) but it would be way better than the current situation (i.e. with the LilyJazz stuff scattered all over the mailing list, which is a sure way to hinder its acceptance and make our lives difficult). I don't have time to handle this issue myself, but i'll wholeheartedly welcome anyone doing something about it. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypondforum.nl
Il 10/lug/2014 19:22 Johan Vromans jvrom...@squirrel.nl ha scritto: On the risk of getting off-topic: IMHO having too many discussion platforms may work counter-productive. I personally stopped participating in Stack Overflow c.s. when I only got 'wrong forum' responses. 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... Some time ago I wanted to start a mailing list for Italian lilypond users but then realized that we are a very small number (at least in this mailing list.. I'd guess less than 20). Today I'd be curious to try one of these modern tools like Drums or Discourse. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
Hi, 2014-07-10 19:25 GMT+02:00 tisimst tisi...@gmail.com: 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? Does fontforge have its own format that contains a source-like description of the fonts? (i have no idea how it works, all my font work was with Metafont) Maybe we could distribute that? I'd say that it's important to distribute the fonts in a format that is most accessible for modification, but if all we have is binary files, then we have to live with that. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
tisimst tisi...@gmail.com 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. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: List defect?
now there definitely seems to be something wrong with mail delivery on the list. Some people already reported they were not receiving some posts at all. With me, some posts pop up another time two days or so after they were originally sent (including my own). Do any of you know what might be going on? And where to eventually report this buggy behaviour? gnu.org is notorious for such delays since there is a single server that handles the completel gnu.org e-mail. Usually everyhing is back to normal after a few days, so please be patient. Werner ___ 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)
Am 11.07.2014 08:20, schrieb Janek Warchoł: 2014-07-11 4:50 GMT+02:00 tisimst tisi...@gmail.com: Schneidy wrote I did that, but I let it unfinished for a couple of weeks now... see = http://lilypond.1069038.n5.nabble.com/LilyJAZZ-in-v2-18-td162423.html#a162444 Pierre Yes! Thank you, Pierre, for your good work! I had fun making some updates to it. I think there are enough people interested in the Jazzy hand-written font that we should get this incorporated better. Since it is only available in binary font formats, is openlilylib the best place to put it? The only thing is, if we want to make the use of LilyJAZZ easier, it really needs the patched file that I mentioned in the initial post. Putting binary files in openlilylib may not be the best possible option (btw, how big they are and how muhc they are expected to change?) but it would be way better than the current situation (i.e. with the LilyJazz stuff scattered all over the mailing list, which is a sure way to hinder its acceptance and make our lives difficult). I would also say the actual openlilylib/openlilylib repository might not be ideal, but I think we could open a dedicated repository like openlilylib/alternative-fonts. 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. While it would be of course the nicest thing to have them all readily available that seems like a reasonable burden for the user. Actually, if you want to change fonts in other programs it's also the natural way that you have to get and install them separately. I don't have time to handle this issue myself, but i'll wholeheartedly welcome anyone doing something about it. I don't really have time either but I can take care of stuff that is related to the openlilylib organization. Urs cheers, Janek ___ 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: Follow-up question to alternate music fonts
Am 11.07.2014 07:00, schrieb David Kastrup: tisimst tisi...@gmail.com 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)
Urs Liska u...@openlilylib.org 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)
Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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)
Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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)
Am 11.07.2014 09:20, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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)
Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:20, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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)
Am 11.07.2014 09:29, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:20, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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)
Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:29, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:20, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 11.07.2014 09:10, schrieb David Kastrup: Urs Liska u...@openlilylib.org 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
On 11/07/14 08:01, Urs Liska wrote: Am 11.07.2014 07:00, schrieb David Kastrup: tisimst tisi...@gmail.com 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
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 tisi...@gmail.com 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
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, wishlist to
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
Federico Bruni fedel...@gmail.com 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?
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)
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?
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
On Wed, 09 Jul 2014 12:52:13 +0100
Richard Shann rich...@rshann.plus.com 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
{
c' e' g'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
On Wed, 09 Jul 2014 12:52:13 +0100
Richard Shann rich...@rshann.plus.com 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
{
c' e' g'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?
2014-07-11 13:56 GMT+02:00 Abel Cheung abelche...@gmail.com:
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?
On Thu, Jul 10, 2014 at 5:09 AM, Abraham Lee tisi...@gmail.com wrote:
On Thu, Jul 10, 2014 at 3:39 AM, James Harkins jamshar...@gmail.com
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?
Yes, this is exactly what I needed, thanks a lot!
On Fri, Jul 11, 2014 at 9:08 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:
2014-07-11 13:56 GMT+02:00 Abel Cheung abelche...@gmail.com:
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?
On Fri, Jul 11, 2014 at 7:09 AM, David Nalesnik
david.nales...@gmail.com wrote:
On Thu, Jul 10, 2014 at 5:09 AM, Abraham Lee tisi...@gmail.com
wrote:
On Thu, Jul 10, 2014 at 3:39 AM, James Harkins
jamshar...@gmail.com 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?
On 11 July 2014 15:08, Janek Warchoł janek.lilyp...@gmail.com 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 x.sche...@gmail.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Optical spacing -- no more?
Abraham Lee tisi...@gmail.com 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?
On Fri, Jul 11, 2014 at 8:00 AM, David Kastrup d...@gnu.org wrote: Abraham Lee tisi...@gmail.com 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.
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.
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.
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?
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)
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 http://lilypond.1069038.n5.nabble.com/Question-about-customizing-emmentaler-font-td161702.html . 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.
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?
On Fri, Jul 11, 2014 at 12:50 PM, Brian Barker b.m.bar...@btinternet.com
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''
cis'' dis''
\down
c
\up
c''
\down
c cis dis
\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.
2014-07-11 21:14 GMT+02:00 Richard Shann rich...@rshann.plus.com:
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?
On Fri, Jul 11, 2014 at 5:18 PM, David Nalesnik david.nales...@gmail.com
wrote:
On Fri, Jul 11, 2014 at 12:50 PM, Brian Barker b.m.bar...@btinternet.com
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.
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
