Re: NR 4.2.2, table column should be called "glyph name"?

[tisimst]

On Mon, Jun 12, 2017 at 6:18 AM, Carl Sorensen-3 [via Lilypond] <
ml+s1069038n20373...@n5.nabble.com> wrote:

> On 6/12/17 4:06 AM, "Federico Bruni" <[hidden email]
> > wrote:
>
> >
> >
> >Il giorno sab 10 giu 2017 alle 2:54, Carl Sorensen <[hidden email]
> >
> >ha scritto:
> >> On 6/8/17 10:26 AM, "Federico Bruni" <[hidden email]
> > wrote:
> >>> Should "font name" be replaced with "glyph name"?
> >>
> >> Not in my opinion.  The font is feta11 (the font family is feta).  The
> >> staff height is 11.22 pt.  The staff height is 3.9 mm.
> >>
> >>
> >
> >Hi Carl, are you sure?
> >The context of my report was:
> >
> >commit 18d03fa6a724b0102ccc47d194209802cea02f2e
> >Author: James Lowe
> >Date: Sun Mar 5 16:34:39 2017 +
> >
> >Doc - NR + CG: Clarify Emmentaler is the 'font' and Feta/Parmesan
> >are glyphs
> >
> >Issue 4966
> >
> >Distinguish between Emmentaler
> >the 'font' and Feta/Parmesan
> >glyphs that make up the
> >Emmentaler font family.
>
> In this context, I guess that the proper word is 'subfont' rather than
> 'glyph'.  The emmentaler font is made up of several subfonts, according to
> the files in the out/mf directory.  In the case of emmentaler-11 (which is
> the font), the subfonts include
> feta11
> feta-noteheads11
> feta-flags11
> parmesan11
> parmesan-noteheads11
> feta-alphabet11
>
> Each of these subfonts is a collection of glyphs.  And the glyphs have
> individual names.
>
> If I were to try to fix the problem you have identified, I would probably
> change the contents of the first column from 'fetaxx' to 'emmentaler-xx'.
>

Having delved into the depths of the way fonts are created and work in
LilyPond, I agree that this is the most precise correction here. I guess
the only question is should it be "emmentaler-xx" (which is the font file
name) or "Emmentaler-xx" (which is the internal font name). Which is the
correct reference? It's a small detail, but perhaps it's best to get it
right and be done with it.

I believe that when one sets the font-size in general, it applies to
> Emmentaler, not to Feta.  The only place I have found in the documentation
> that uses anything other than the whole font is in NR 1.8.3, where some
> font-encodings are used.  But I cannot find any documentation that
> describes which glyphs are in which encodings, so I don't know how to use
> this in general.
>

The three encodings are basically as follows:
- fetaText: all alpha-numeric glyphs (i.e., /space, 0-9, and the letters f,
m, p, r, s, z).
- fetaBraces: all grand-staff brace glyphs (all of which are found in the
font "emmentaler-brace")
- fetaMusic: every other glyph, including those found in the "parmesan"
sub-set of glyphs.

I suppose this would be good information to have documented somewhere.

Also, I wonder if a new entry should be in the "Entire Document Fonts"
sub-section to describe the usage of set-global fonts? I can't say it
should completely replace the make-pango-font-tree example, but there isn't
an entry for set-global-fonts anywhere at the moment.


> So, in looking at all of this, my recommendation is not to change the
> heading of the table, but to change the contents of the first column.
>

Agreed.

On a side, but related, note, the whole business with using the names
"feta" and "emmentaler" interchangeably is a bit confusing all throughout
the code. For example, the use of 'feta as the font-family symbol for the
music font. Why not just call it 'music? The three main encodings could
then be 'musicText, 'musicBraces, and 'musicSymbol (I've not bought-off
that last one). Perhaps it's just me coming from the world were other music
fonts are now available. After all, we use the more generic terms 'roman,
'sans, 'typewriter for the main text font-families.

That's all for now.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/NR-4-2-2-table-column-should-be-called-glyph-name-tp203699p203736.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: change music font not documented?

[tisimst]

Federico,

On Wed, May 10, 2017 at 10:47 AM, Federico Bruni-2 [via Lilypond] <
ml+s1069038n203067...@n5.nabble.com> wrote:

> I think that set-global-fonts is not properly documented, especially
> for music font changes.
>

Outside of the inline comments found in scm/font.scm, this is true.
Actually, I didn't know it was even used in the docs at all. The *changes*
page only hints at why this function exists with this statement:

*"Support for making it easier to use alternative ‘music’ fonts other than
the default Emmentaler in LilyPond has been added.
See http://fonts.openlilylib.org/  for more
information."*

...which needs to be updated anyway. My fault, really. Much thanks to Urs
for including this statement.


> $ cd Documentation
> $ git grep -n set-global-fonts notation/
> notation/ancient.itely:2414:(set-global-fonts
> notation/ancient.itely:2594:(set-global-fonts
> notation/input.itely:2526:(set-global-fonts
>
> Best resource is the blog:
> http://lilypondblog.org/2015/03/managing-alternative-fonts-with-lilypond/
>
> Should I open an issue for this?
>

I think that's a good idea, perhaps the right time to update the entry for
replacing the notation font?
http://lilypond.org/doc/v2.19/Documentation/notation/replacing-the-notation-font

Thinking ahead towards the potential of making LP SMuFL-compliant, I also
wonder if this might be a good time to create a couple of other public
scheme functions that make it easier to use music fonts that don't have
more than one design size. I've tested successfully such functions on my
own machine and think they would be a useful addition as we try to attract
more potential power users in the industry.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/change-music-font-not-documented-tp203067p203073.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Italic numbers for fingerings (feature request)

[tisimst]

Hi, Urs!

On Thu, Feb 16, 2017 at 3:08 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n200207...@n5.nabble.com> wrote:

> if I'm not mistaken (and a very recent post in the German forum
> http://www.lilypondforum.de/index.php?topic=2465.0 seems to confirm
> that) LilyPond doesn't have built-in support for italics in fingerings.
>
> As using italics for fingerings is a regular use case (e.g. to
> differentiate between editor's and composer's fingerings) I would like
> to see native support for italics in fingerings.
>
> So there would have to be a) glyphs for italics numbers in Emmentaler
> and b) a way to choose between upright and italics for fingerings.
>

The default mechanism uses the 'fetaText encoding to get the numbers. If
you

\override Fingering.font-encoding = 'latin1

you should then be able to change the font to any normal text font and turn
on Italics. I didn't try this myself, but it works with other kinds of
grobs in this situation.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Italic-numbers-for-fingerings-feature-request-tp200207p200208.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond taking forever to typeset

[tisimst]

Everyone,

On Mon, Jul 11, 2016 at 5:08 AM, Mojca Miklavec [via Lilypond] <
ml-node+s1069038n192549...@n5.nabble.com> wrote:

> To answer to David: yes, it's one-time cost (that gets re-triggered
> every now and then in order to be able to get a more recent database
> including potential new fonts on the system, but I don't know the
> "rule" of when this gets triggered). In any case, after the initial
> 10-minute-waiting each lilypond processing is reasonably fast.
>
> In order to be able to reproduce the problem reliably I would have to
> figure out where the font cache is stored and make sure to delete it.
>
> There is a folder
> LilyPond.app/Contents/Resources/var/cache/fontconfig
> but it is empty (which makes sense).
>
> There is
>
> ~/Library/Caches/org.lilypond.lilypond/com.apple.opencl/com.apple.ocl.32.{data|maps}
>
> which seems to be something else.
>
> I'm not yet sure where else to look for.
>

I've noticed this one-time startup delay as well on Windows (7 and 8) and
found that it got triggered anytime I changed the contents of the system
font folder (C:\Windows\Fonts), whether adding or deleting a file. At the
next time of compiling a LilyPond file, a new font-cache database would be
created in "C:\Users\[MYUSERNAME]\.lilypond-fonts.cache-2" (note the
initial period in the directory name). If I clear the contents of this
folder, the initial delay comes up again to create a new database file. I
suspect that this directory can be found across OSs in a similar location
in the user's main directory, but I haven't confirmed this.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Re-Lilypond-taking-forever-to-typeset-tp192544p192552.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[tisimst]

On Wed, Feb 10, 2016 at 3:10 AM, Andrew Bernard [via Lilypond] <
ml-node+s1069038n187069...@n5.nabble.com> wrote:

> Hi Abraham,
>
> Thanks for this explanation. Now that I have read up on this, for TrueType
> at least, I see that FUnits, or font units are used, and that there are a
> given number of units-per-em for a specific design, say 1000 or 2048 and so
> on. I can’t find much reference to em-units - to me that suggests 'units of
> em’s'. Would it not be units per em? I assume this is what you are
> referring to, that fonts designed for lilypond are made with a metric of
> 1000 font units per em.
>

It's definitely possible I'm using improper terminology. What you are
saying is probably more accurate. I guess there isn't a consensus as to
what to call the font units (not that they need to). So, yes, in music
fonts, a staff height has traditionally been 1000 units-per-em. Thanks for
correcting me.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187084.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[tisimst]

Gilberto, et al,

On Tue, Feb 9, 2016 at 7:14 AM, Gilberto Agostinho [via Lilypond] <
ml-node+s1069038n187039...@n5.nabble.com> wrote:

> Hi Urs,
>
> Urs Liska wrote
> Are you completely sure that the issue is in LilyPond's output and not in
> the displaying program?
>
> Well, I don't know how can I be *completely* sure about it, but I see this
> issue on Evince and Okular pdf readers, as well as in Frescobaldi. If you
> have some suggestion on how to test this further, please let me know.


WARNING!! TECHNICAL ANALYSIS AHEAD!! ;-)

Although microscopic, I can confirm this is true at the font level (at
least at the default printed 20pt size, I didn't check the other optical
variants). Relative to a 1000-em unit staff height (which is what the fonts
are designed to, center of bottom staff line to center of top staff line),
here are the dimensions causing the problem you are seeing:

staff-space = 250-em
staff line thickness = 25-em (i.e., 0.1 staff-space)
solid notehead height = 276-em

Now, here's the discrepancy. The distance between the bottom of a staff
line to the top of the next staff line up, is 250+25 = 275-em. That means
that there is an overall difference in size of 1-em unit (at the 20pt
printed size, this equates to 1/50pt = 0.00028in = 0.0071mm difference). In
other words, we are technically splitting hairs with this, but nonetheless,
it is a difference. The solid notehead is "too large" by 1/100pt on either
side.

I'm not sure if this warrants a design change or not, but there, at least,
is the evidence. It's not just the PDF reader. I've looked it over with
many different readers in both PDF and SVG backends and it always shows up.
Well, there's why.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187044.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[tisimst]

On Tue, Feb 9, 2016 at 8:49 AM, Paul Morris [via Lilypond] <
ml-node+s1069038n187046...@n5.nabble.com> wrote:

> > On Feb 9, 2016, at 10:12 AM, tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=187046=0>> wrote:
> >
> > Although microscopic, I can confirm this is true at the font level (at
> > least at the default printed 20pt size, I didn't check the other optical
> > variants). Relative to a 1000-em unit staff height (which is what the
> fonts
> > are designed to, center of bottom staff line to center of top staff
> line),
> > here are the dimensions causing the problem you are seeing:
> >
> > staff-space = 250-em
> > staff line thickness = 25-em (i.e., 0.1 staff-space)
> > solid notehead height = 276-em
> >
> > Now, here's the discrepancy. The distance between the bottom of a staff
> > line to the top of the next staff line up, is 250+25 = 275-em. That
> means
> > that there is an overall difference in size of 1-em unit (at the 20pt
> > printed size, this equates to 1/50pt = 0.00028in = 0.0071mm difference).
> In
> > other words, we are technically splitting hairs with this, but
> nonetheless,
> > it is a difference. The solid notehead is "too large" by 1/100pt on
> either
> > side.
>
> Interesting...  Here’s some code for experimenting with this.  It scales
> notehead stencils. A scaling of 250/276 should make the solid notes equal
> to one staff-space.  (Or should it be 275/276 to make it the "distance
> between the bottom of a staff line to the top of the next staff line up”?)
>
> -Paul
>
>
> \version "2.19.36"
>
> example = \relative {
>   c' d e f g a b c
> }
>
> {
>   \example
> }
>
> {
>   \override NoteHead.stencil =
>   #(lambda (grob)
>  (ly:stencil-scale
>   (ly:note-head::print grob)
>   250/276  250/276))
>
>   \example
> }
>

Well, that depends on where you want the top/bottom of the notehead to
touch the staff-lines:
- 275/276 - If you want it to have the same vertical extent as the two
touch staff lines.
- 250/276 - If you want it to touch the centers of the staff lines
- 225/276 - If you wanted them to fit perfectly withing the staff lines

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187048.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[tisimst]

Andrew,

On Tue, Feb 9, 2016 at 6:13 PM, Andrew Bernard [via Lilypond] <
ml-node+s1069038n187064...@n5.nabble.com> wrote:

> What unit is this particular em? In typography at least an em is a
> measurement equal to the currently specified point size for a font. That
> does not seem to fit your analysis here.


This is a good question, and my apologies for just throwing it out
there without defining it properly. I think what you are referring to is a
little different. An "em", like with an "em-dash" is defined as something
that has the same width as the capitol letter "M" in that typeface,
irrespective of pt size. The relative size is the same at 8pt as at 96pt.

What I'm referring to are the units that are used to define the shape of a
glyph, called em-units. These don't have anything to do with the displayed
size. Here's an example. It is fairly common in a text font to make the
capital letter "M" around 800-em units tall. "em-units" are just for
defining a relative scale. As the Wikipedia article[1] states it (under the
"History" section, 2nd paragraph):

"*In digital type, the em is a grid of arbitrary resolution that is used as
the design space of a digital font.*" That's all I mean.

Most fonts are usually defined relative to a resolution of a 1000em-unit
scale, a 1024em-unit scale or a 2048em-unit scale. In virtually all music
fonts, glyphs are defined relative to a 1000-em unit staff-size (center of
bottom line to center of top line), which makes a single staff-space equal
to 250-em units. It's just a convenience thing.

HTH,
Abraham

[1] https://en.wikipedia.org/wiki/Em_%28typography%29




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187066.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Install confirmation test file misleading

[tisimst]

Paul,

The very first time compiling any .ly file should take longer because LP
creates a font cache (note that this also applies whenever you change the
contents of the system font directory). After that you should notice
"normal" compilation speeds.

HTH,
Abraham

On Tuesday, February 2, 2016, Paul Booker [via Lilypond] <
ml-node+s1069038n186776...@n5.nabble.com> wrote:

> While I had no problems installing 2.18.2, moving to 2.29.36 was
> repeatedly
> challenging, on Win 7 and 8.1.
> The installation itself appears fine, but the test.ly file which is
> offered
> to confirm the install and initiate newcomers has been misleading me.
>
> It fails to generate a pdf. The log file gets as far as "Drawing
> systems..."
> Or it's taking s long...?
> I note that there is another LP icon in Public\Public Desktop and Lilypad
> defaults to this one on first attempt to save test.ly.
>
> As a newbie, I went through several installs of 2.19.36, 2.19.35, and
> reverted to 2.18.2 to verify the test.ly procedure, mistaken in thinking
> that it actually initiates the software, rather than initiating me. Things
> went a lot better when I started ignoring it.
> I also felt the test.ly took a long time to generate, but that was more
> likely the result of repeated restarts and system house-keeping.
>
> Paul
>
>
> ___
> bug-lilypond mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Install-confirmation-test-file-misleading-tp186776.html
> To start a new topic under Bugs, email
> ml-node+s1069038n58488...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Install-confirmation-test-file-misleading-tp186776p186779.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lilypond-book: "external" fonts and --pdf option problem

[tisimst]

Masamichi,

On Thu, Dec 10, 2015 at 7:23 AM, Masamichi Hosoda [via Lilypond] <
ml-node+s1069038n18463...@n5.nabble.com> wrote:

> If I understand correctly,
> the cause is lilypond's `-dgs-load-fonts' option
> with non-emmentaler music font.
>
> I've reproduced the issue with the following smaller example.
> ...
> Of course, it has no error without `-dgs-load-fonts' option.
> Here is a quick hack patch for the issue.
>
> ```
> --- framework-ps.scm.org 2015-09-27 21:01:25.0 +0900
> +++ framework-ps.scm 2015-12-10 22:03:53.743514600 +0900
> @@ -249,6 +249,7 @@
>(define (internal-font? file-name)
>  (or (string-startswith file-name "Emmentaler")
>  (string-startswith file-name "emmentaler")
> +(string-startswith file-name "improviso")
>  ))
>
>(define (load-font-via-GS font-name-filename)
> ```
>

Thank you for finding this. I'm wondering if there is a more generic way to
identify third-party fonts rather than hard-coding it like this? Perhaps by
checking if the font has the LILY, LILC, and LILF subtables? I'm just
brain-storming...

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/lilypond-book-external-fonts-and-pdf-option-problem-tp184556p184642.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lilypond-book: "external" fonts and --pdf option problem

[tisimst]

Dmytro,

Sorry for my delayed comment. I don't know what is causing this, but I've
seen this come up before from other users. I'm excited to see you like
Improviso! I hope we can get this figured out.

Best,
Abraham

On Tuesday, December 8, 2015, Dmytro O. Redchuk-2 [via Lilypond] <
ml-node+s1069038n184579...@n5.nabble.com> wrote:

> Sorry, this "patch" has huge problems .(
>
> 2015-12-08 11:44 GMT+02:00 Dmytro O. Redchuk <[hidden email]
> >:
>
> > With this patch it looks like "it works for me".
> >
> > I will check more. What would I check besides of a "regular"
> > (lilypond's and lilypond-book's) output generation?
> >
> > Please, anyone knowledgeable, review this diff and give your feedback,
> > because, as usually, I don't know what I am doing.
> >
> > Thank you!
> >
> > 2015-12-08 9:57 GMT+02:00 Dmytro O. Redchuk <[hidden email]
> >:
> >> 2015-12-08 9:55 GMT+02:00 Dmytro O. Redchuk <[hidden email]
> >:
> >>> Hello,
> >>>
> >>> to avoid any misunderstanding with any "include"'s I've tested this
> >>> issue with this source:
> >> And the command was (no -I...), of course:
> >>
> >> $ lilypond-book --out=out [--pdf] test.lytex
> >>
> >>>
> >>> %  8< --
> >>> \documentclass{article}
> >>> \begin{document}
> >>> \begin{lilypond}
> >>>   { c''4 }
> >>>   \paper {
> >>> #(define fonts
> >>>   (set-global-fonts
> >>>   #:music "improviso"
> >>>   #:factor (/ staff-height pt 20)
> >>> ))
> >>>   }
> >>> \end{lilypond}
> >>> \end{document}
> >>> %  8< --
> >>>
> >>> And I have the same result, attached.
> >>>
> >>> 2015-12-07 22:00 GMT+02:00 Dmytro O. Redchuk <[hidden email]
> >:
>  2015-12-07 19:55 GMT+02:00 James <[hidden email]
> >:
> > Hello Dmytro,
>  Hello James :)
> 
> >>> I want lilypond to engrave it with "improviso" font,
> >>> https://fonts.openlilylib.org/improviso/ --- I have set it up,
> it's
> >>> ok.
>  ... and the subject of this thread is: "lilypond-book: 'external'
>  fonts and --pdf option problem" .)
> 
>  I have no any problem with lilypond-book and Emmentaler (lilypond's
>  default) font. With or without --pdf, really.
> 
>  I am sorry to be unclear. That \include imports the stylesheet for
>  improviso font (https://fonts.openlilylib.org/improviso/, an
> alternate
>  font for lilypond).
> 
>  So, without --pdf I have nice result, with --pdf I have a score(s)
>  with "improviso-related" objects missed.
> >>
> >> --
> >>   Dmytro O. Redchuk
> >
> >
> >
> > --
> >   Dmytro O. Redchuk
>
>
>
> --
>   Dmytro O. Redchuk
>
> ___
> bug-lilypond mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/lilypond-book-external-fonts-and-pdf-option-problem-tp184556p184579.html
> To start a new topic under Bugs, email
> ml-node+s1069038n58488...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/lilypond-book-external-fonts-and-pdf-option-problem-tp184556p184597.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: slurs with more than 2 control points

[tisimst]

Malte,

On Thursday, November 26, 2015, lilypond-7 [via Lilypond] <
ml-node+s1069038n184151...@n5.nabble.com> wrote:

> Hi list,
>
> how complicated would it be to get slurs with more than 2 control
> points?


With the current code? Nothing automatic, but you could definitely create a
function that could take an arbitrary number of control points, but I
can see that taking effect as a direct postscript drawing routine. I have
done quite a few curve routines for other projects in the past so I know
it's possible.

Slurs with an S shape often have very flat ends and slurs with
> more than one "direction change" (sometimes used in
> romantic/impressionistic piano music) aren't possible at all, are they?


Current slurs can take the S shape, but only to an extent. By definition,
since the slurs are defined as 3rd-order Bézier curves, they mathematically
can only have a single inflection point. It would take a higher order curve
to change directions more than one time. They aren't mathematically
complex, but beyond the scope of the current code infrastructure.

In short, are they possible at the moment? No. Are they impossible? No, but
it requires some new code. I might consider tackling that in the near
future.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/slurs-with-more-than-2-control-points-tp184151p184186.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Irregularity in horizontal spacing

[tisimst]

Are you referring to the final 16ths in each of the beamed groups in the
center stave?

- Abraham

On Friday, November 20, 2015, Urs Liska [via Lilypond] <
ml-node+s1069038n183851...@n5.nabble.com> wrote:

> Hi,
>
> one more question.
> I am right now experiencing an irregularity in the horizontal spacing
> that is very small but still pretty annoying.
>
> In the attached image you can see how the quavers are spaced out
> irregularly. It is most obvious in the melody staff but you can also see
> it in the piano left hand.
>
> I have the impression that LilyPond takes the right hand figurations
> into account and spaces the downward notes more closely because a
> notehead can somewhat "slip" below the previous one.
> This leads to the semiquavers being spaced out pretty good but the other
> voices having ugly side effects.
>
> a)
> I think this is a suboptimal spacing (so a bug report). Although it's
> quite tiny it is absolutely inacceptable for a publication.
>
> b)
> Is there a way to work around this without specifying offsets manually
> (totally out of question for a three-page piece)?
>
> TIA
> Urs
>
> ___
> bug-lilypond mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> *schwan.png* (33K) Download Attachment
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851.html
> To start a new topic under Bugs, email
> ml-node+s1069038n58488...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851p183853.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: dynamics-barline collision

[tisimst]

I was looking through the source and it makes me wonder what causes
anything to avoid the BarLine or SpanBarLine grobs? I couldn't tell.

- Abraham

On Friday, November 20, 2015, Urs Liska [via Lilypond] <
ml-node+s1069038n183828...@n5.nabble.com> wrote:

> Hi list,
>
> I am somewhat surprised that dynamics can still collide with barlines as
> shown in the attached image. I thought this kind of issue had been quite
> long overcome.
>
> The \pp is defined in a Dynamics context, and of course I can work
> around the collision by overriding self-alignment-X. But is there a
> proper way to let LilyPond avoid that kind of collision automatically?
>
> Best
>
> Urs
>
> ___
> bug-lilypond mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> *schwan.png* (7K) Download Attachment
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/dynamics-barline-collision-tp183828.html
> To start a new topic under Bugs, email
> ml-node+s1069038n58488...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/dynamics-barline-collision-tp183828p183857.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: dynamics-barline collision

[tisimst]

Here's something that may point to a solution: Lyrics avoid bar lines, but
Dynamics don't. Maybe DynamicText can be taught to do the same? Not sure
what causes Lyrics to do it. They definitely utilize different engravers,
but my preliminary tests of including the engravers and overrides in the
Lyrics context into the Dynamics context have been unfruitful. See attached
to show what I mean.

Best,
Abraham

On Fri, Nov 20, 2015 at 10:44 AM, Abraham Lee 
wrote:

> I was looking through the source and it makes me wonder what causes
> anything to avoid the BarLine or SpanBarLine grobs? I couldn't tell.
>
> - Abraham
>
>
> On Friday, November 20, 2015, Urs Liska [via Lilypond] <
> ml-node+s1069038n183828...@n5.nabble.com> wrote:
>
>> Hi list,
>>
>> I am somewhat surprised that dynamics can still collide with barlines as
>> shown in the attached image. I thought this kind of issue had been quite
>> long overcome.
>>
>> The \pp is defined in a Dynamics context, and of course I can work
>> around the collision by overriding self-alignment-X. But is there a
>> proper way to let LilyPond avoid that kind of collision automatically?
>>
>> Best
>>
>> Urs
>>
>> ___
>> bug-lilypond mailing list
>> [hidden email] 
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>> *schwan.png* (7K) Download Attachment
>> 
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://lilypond.1069038.n5.nabble.com/dynamics-barline-collision-tp183828.html
>> To start a new topic under Bugs, email
>> ml-node+s1069038n58488...@n5.nabble.com
>> To unsubscribe from Lilypond, click here
>> 
>> .
>> NAML
>> 
>>
>


dynamictext-barline-collision-but-not-lyrictext.png (10K) 





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/dynamics-barline-collision-tp183828p183871.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes and staff miss-alignment

[tisimst]

On 9/22/2015 10:43 AM, David Kastrup [via Lilypond] wrote:
> tisimst <[hidden email] 
> > writes:
>
> > On 9/22/2015 9:42 AM, David Kastrup [via Lilypond] wrote:
> >> Pierre Perol-Schneider <[hidden email]
> >> > writes:
> >>
> >> >>I'm not top posting
> >> >
> >> > Hi Squad,
> >> >
> >> > When many grace notes, staves are miss aligned:
> >> >
> >> > %%
> >> > \version "2.19.27"
> >> >
> >> > \transpose c c' {
> >> >   \repeat unfold 16 { e'8 a }
> >> >   R1*8
> >> > }
> >> >
> >> > \transpose c c' {
> >> >   \repeat unfold 16 { \grace dis'8 e' \grace gis8 a }
> >> >   R1*8
> >> > }
> >> > %%
> >>
> >> Huh?  That example demonstrates that measures with many grace notes in
> >> them will take more space than _independently_ typeset measures 
> without
> >> the grace notes in them.
> >>
> >> Which is not surprising at all.  What is the misalignment you are
> >> talking about?
> >
> > I think this is what he meant (first as separate scores, then in the
> > same score):
> >
> >
> >
> > The notes line up, but the second system doesn't break/compress like it
> > should.
> >
> > - Abraham
> >
> >
> > fbbigajb.png (87K)
> > 
> <http://lilypond.1069038.n5.nabble.com/attachment/181536/0/fbbigajb.png>
>
> Well, stuff lines up perfectly on my system.  So where's the difference?
> 64-bit system vs 32-bit (the latter would be mine)?  Different fonts
> (less likely)?

Sounds like it might be OS-specific. I'm on Windows 7, 64-bit, LilyPond 
2.19.27, using default fonts.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p181540.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes and staff miss-alignment

[tisimst]

On 9/22/2015 9:42 AM, David Kastrup [via Lilypond] wrote:
> Pierre Perol-Schneider <[hidden email] 
> > writes:
>
> >>I'm not top posting
> >
> > Hi Squad,
> >
> > When many grace notes, staves are miss aligned:
> >
> > %%
> > \version "2.19.27"
> >
> > \transpose c c' {
> >   \repeat unfold 16 { e'8 a }
> >   R1*8
> > }
> >
> > \transpose c c' {
> >   \repeat unfold 16 { \grace dis'8 e' \grace gis8 a }
> >   R1*8
> > }
> > %%
>
> Huh?  That example demonstrates that measures with many grace notes in
> them will take more space than _independently_ typeset measures without
> the grace notes in them.
>
> Which is not surprising at all.  What is the misalignment you are
> talking about?

I think this is what he meant (first as separate scores, then in the 
same score):



The notes line up, but the second system doesn't break/compress like it 
should.

- Abraham


fbbigajb.png (87K) 





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p181536.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: da capo al 2nd ending

[tisimst]

Do you mean for midi? I don't see any reason that this would be a challenge
notating. If you could provide a tiny (complete) example of your efforts,
that would help to clarify the issue, I think.

Best,
Abraham

On Thursday, September 17, 2015, Pepper [via Lilypond] <
ml-node+s1069038n181285...@n5.nabble.com> wrote:

> da capo al 2nd ending
>
> is it possible to implement this structure with lilypond? It's common in
> jazz lead sheets that obey the form
> A A' B A'
> ___
> bug-lilypond mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://lilypond.1069038.n5.nabble.com/da-capo-al-2nd-ending-tp181285.html
> To start a new topic under Bugs, email
> ml-node+s1069038n58488...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/da-capo-al-2nd-ending-tp181285p181289.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Obscure melisma fail

[tisimst]

On 9/8/2015 6:11 PM, simon.albrecht [via Lilypond] wrote:
> Hello,
>
> in the following example Lily fails to recognise the melisma iff
> – there is a second voice (comment it to test)
> – the music is referenced by a variable and not directly inserted in
> \score {} (sic!)
>
> 
> \version "2.19.25"
>
> alto = \relative {
><<
>  { d'2\melisma e4\melismaEnd cis }
>  \new Voice { \voiceTwo s1 }
>>>
> }
>
> altText = \lyricmode {
>side, sit
> }
>
> \score {
><<
>  \new Staff \alto
>  \addlyrics \altText
>>>
> }
>
> % exactly the same, but without using a variable for the music
> \score {
><<
>  \new Staff \relative {
><<
>  { d'2(\melisma e4)\melismaEnd cis }
>  \new Voice { \voiceTwo s1 }
>>>
>  }
>  \addlyrics \altText
>>>
> }
> %
>
> It’s really astounding what kind of situations sometimes arise…

I'd like to add to this bug report (single voice using a variable):

%%

altoOneVoice = \relative {
   d'2\melisma e4\melismaEnd cis
}

altoTwoVoices = \relative {
<<
  { d'2\melisma e4\melismaEnd cis }
  \new Voice { \voiceTwo s1 }
>>
}

altText = \lyricmode {
side, sit
}

\markup \column { "One voice in a music variable" "(center-aligned 
melisma)" }
\score {
<<
  \new Staff \altoOneVoice
  \addlyrics \altText
>>
}

\markup \column { "Two voices in a music variable" "(no melisma at all)" }
\score {
<<
  \new Staff \altoTwoVoices
  \addlyrics \altText
>>
}

% same music as above, but explicitly written out in the \score block
\markup \column { "One voice explicitly written out in \score block" 
"(left-aligned melisma)" }
\score {
<<
  \new Staff \relative {
d'2\melisma e4\melismaEnd cis
  }
  \addlyrics \altText
>>
}

% same music as above, but explicitly written out in the \score block
\markup \column { "Two voices explicitly written out in \score block" 
"(left-aligned melisma)" }
\score {
<<
  \new Staff \relative {
<<
  { d'2\melisma e4\melismaEnd cis }
  \new Voice { \voiceTwo s1 }
>>
  }
  \addlyrics \altText
>>
}

%%



- Abraham


ihahchha.png (55K) 





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Obscure-melisma-fail-tp180855p180897.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Obscure melisma fail

[tisimst]

On 9/9/2015 10:57 AM, David Kastrup [via Lilypond] wrote:
> David Kastrup <[hidden email] 
> > writes:
>
> > Here is the difference: The first variant adds the lyrics to \new Staff
> > \altoOneVoice.  The second variant adds the lyrics to { d'2 ... } even
> > _before_ \relative is called.  \addlyrics is sort of sticky.  Once the
> > \addlyrics is sucked _into_ the \relative, it does not have a chance to
> > combine with \new Staff in a useful manner.  So basically you get
> >
> > \score {
> >   <<
> >  \new Staff \relative << \new Voice="xxx" { d'2 ... cis}
> >  \new Lyrics \lyricsto "xxx" ... >>
> >   >>
> > }
> >
> > Or something like that.  Lesson: \addlyrics is for simple cases.
> Here is the output after making \displayLilyMusic stupid about
> \addlyrics and somewhat more \verbose about the result of \relative:
>
>
>
> altoOneVoice = \relative {
>d'2\melisma e4\melismaEnd cis
> }
>
> altoTwoVoices = \relative {
> <<
>   { d'2\melisma e4\melismaEnd cis }
>   \new Voice { \voiceTwo s1 }
> >>
> }
>
> altText = \lyricmode {
> side, sit
> }
>
> \markup \column { "One voice in a music variable" "(center-aligned 
> melisma)" }
> \score {
>   \displayLilyMusic
> <<
>   \new Staff \altoOneVoice
>   \addlyrics \altText
> >>
> }
>
> % same music as above, but explicitly written out in the \score block
> \markup \column { "One voice explicitly written out in \score block"
> "(left-aligned melisma)" }
> \score {
>   \displayLilyMusic
> <<
>   \new Staff \relative {
> d'2\melisma e4\melismaEnd cis
>   }
>   \addlyrics \altText
> >>
> }
>
>
> /usr/local/tmp/lilypond/out/bin/lilypond bibo.ly
> GNU LilyPond 2.19.27
> Processing `bibo.ly'
> Parsing...
> << << \new Staff = "uniqueContext0" \absolute { d'2 \melisma e'4 
> \melismaEnd cis'4 } \lyrics \lyricsto "uniqueContext0" { side, sit  } 
> >> >>
>
> << \new Staff \absolute << \context Voice = "uniqueContext1" { d'2 
> \melisma e'4 \melismaEnd cis'4 } \lyrics \lyricsto "uniqueContext1" { 
> side, sit  } >> >>

David,

This is a great explanation and almost exactly what I suspected after 
reading through the comments in the parser. Personally, I really 
discourage users from using \addlyrics except in the simplest of 
situations. I almost NEVER use it myself.

Anyways, quark explained, but also raises some questions about how using 
variables affects the internal representation of the data. I'm certainly 
not concerned with it, but it still is curious. Has anyone found other 
instances where this causes problems? (maybe this opens a bad can of 
worms...)

Thanks, as always, for your excellent work and explanations.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Obscure-melisma-fail-tp180855p180902.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue: Add StaffAxis context type

[tisimst]

I'm not necessarily against it being called StaffAxis, but I wonder if 
something like MixedStaff is more appropriate? Just thinking out loud. 
I love this idea, btw.

- Abraham

On 8/26/2015 10:52 AM, David Kastrup [via Lilypond] wrote:

 New issue

 Status: Started
 Summary: Add StaffAxis context type
 Tags: Type-Enhancement Patch-new

 Rietveld issue: 265730043 (https://codereview.appspot.com/265730043)
 Issue description:
   Add StaffAxis context type  See the regression test for more info.


 -- 
 David Kastrup

 ___
 bug-lilypond mailing list
 [hidden email] /user/SendEmail.jtp?type=nodenode=180204i=0
 https://lists.gnu.org/mailman/listinfo/bug-lilypond


 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204.html
  

 To start a new topic under Bugs, email 
 ml-node+s1069038n58488...@n5.nabble.com
 To unsubscribe from Lilypond, click here 
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=.
 NAML 
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
  






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180207.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue: Add StaffAxis context type

[tisimst]

On 8/26/2015 4:23 PM, David Kastrup [via Lilypond] wrote:
 tisimst [hidden email] 
 /user/SendEmail.jtp?type=nodenode=180227i=0 writes:

  On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
  David Kastrup [hidden email]
 
   Perhaps OneStaff?
 
  \oneVoice _is_ sort of the name for not separating voices vertically.
 
  I can see that, but it still doesn't seem quite right to me. As I've
  thought about this more, I'm having a hard time understanding what is
  different about this proposed StaffAxis vs. the already defined
  StaffGroup? It already accepts most other staff contexts, so can we 
 just
  further add to its capabilities? It seems like all it's really lacking
  is the Axis_group_engraver. I haven't tested what you've added to
  engraver-init.ly, etc., but does it look like this:
 
  
 
  \layout {
 \context {
   \StaffGroup
   \consists Axis_group_engraver
 }
  }
 
  \new StaffGroup {
 \new Staff {
   c' d' e' f'
   \chords \with { \override ChordName.Y-offset = -1 } {
 d1:m7 b1:min7.5-
   }
 }
 \chords \with { \override ChordName.Y-offset = -1 } {
   d1:m7 b1:min7.5-
 }
  }

 StaffGroup has a Vertical_align_engraver.  It accepts contexts with a
 vertical alignment, like StaffGroup itself or GrandStaff.  As a vertical
 grouper, it has a Span_bar_engraver.  It has an Instrument_name_engraver
 and a System_start_delimiter_engraver.  It's quite a different kettle of
 fish.

  I realize that the StaffAxis \accepts more contexts than StaffGroup
  does,

 That is probably a shortcoming of StaffGroup.  More important are the
 contexts that StaffGroup _does_ accept and StaffAxis doesn't.  And the
 multitude of different engravers.

Got it. How about one of these:

- AlignmentStaff
- StaffAligner
- ContextAligner
- CompositeStaff
- HybridStaff
- StaffBlend
- AssortedStaff

Maybe StaffAxis is the best one. Is the purpose just to fix the 
vertical alignment issue?

- Abraham






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180229.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue: Add StaffAxis context type

[tisimst]

On 8/26/2015 4:45 PM, David Kastrup [via Lilypond] wrote:
 tisimst [hidden email] 
 /user/SendEmail.jtp?type=nodenode=180230i=0 writes:
  - CompositeStaff
  - HybridStaff
  - StaffBlend
  - AssortedStaff
 
  Maybe StaffAxis is the best one.

 Of those?  Probably.  Not that it's all that good.  I like OneStaff
 better.

I think I'll put my vote is in for that, too, unless a more descriptive 
one comes up. I think that's what I feel is missing, more description in 
the name to make it more obvious to a new user. StaffContainer?

  Is the purpose just to fix the vertical alignment issue?

 Uh, it's not a bug workaround.  It's a feature.  It's sole purpose is to
 use common Y coordinates for all contained staves.  There are a number
 of uses for that, for both parallel and immediately successive contexts.

Poor word choice on my part. I didn't mean to suggest it was a bug. I'm 
pretty sure I understand what it does for successive contexts, but I'm 
not sure what it does for parallel ones. Can you show an example?

Thanks,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180231.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New issue: Add StaffAxis context type

[tisimst]

On 8/26/2015 1:14 PM, David Kastrup [via Lilypond] wrote:
 David Kastrup [hidden email] 
 /user/SendEmail.jtp?type=nodenode=180216i=0 writes:

  David Kastrup [hidden email] 
 /user/SendEmail.jtp?type=nodenode=180216i=1 writes:
 
  tisimst [hidden email] 
 /user/SendEmail.jtp?type=nodenode=180216i=2 writes:
 
  I'm not necessarily against it being called StaffAxis, but I wonder
  if something like MixedStaff is more appropriate? Just thinking out
  loud.  I love this idea, btw.
 
  StaffAxis is as appropriate as it gets.  MixedStaff, however, 
 might
  be more suggestive of the typical use case.  I'm a bit skeptical 
 because
  it is _not_ a Staff.  But then neither are ChoirStaff or GrandStaff.
 
  Other ideas would be Squashed (we use that in Pitch_squash_engraver),
  Collapsed, CollapsedStaff.  That brings the behavior of the axis into
  the name again.
 
  \new CollapsedStaff
  
 \new Staff ...
 \new Lyrics ...
 \new ChordNames ...
 
 
  seems pretty descriptive, more so than MixedStaff.
 
  Perhaps OneStaff?
 
  OneStaff to rule them all, OneStaff to find them,
  OneStaff to bring them all and in the \layout bind them
  in the scope of \paper where the note heads lie.

Dude! That's awesome! 10 Tolkien points for you!

 \oneVoice _is_ sort of the name for not separating voices vertically.

I can see that, but it still doesn't seem quite right to me. As I've 
thought about this more, I'm having a hard time understanding what is 
different about this proposed StaffAxis vs. the already defined 
StaffGroup? It already accepts most other staff contexts, so can we just 
further add to its capabilities? It seems like all it's really lacking 
is the Axis_group_engraver. I haven't tested what you've added to 
engraver-init.ly, etc., but does it look like this:



\layout {
   \context {
 \StaffGroup
 \consists Axis_group_engraver
   }
}

\new StaffGroup {
   \new Staff {
 c' d' e' f'
 \chords \with { \override ChordName.Y-offset = -1 } {
   d1:m7 b1:min7.5-
 }
   }
   \chords \with { \override ChordName.Y-offset = -1 } {
 d1:m7 b1:min7.5-
   }
}





I realize that the StaffAxis \accepts more contexts than StaffGroup 
does, but what do you think?

- Abraham


iibafihh.png (8K) 
http://lilypond.1069038.n5.nabble.com/attachment/180221/0/iibafihh.png




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/New-issue-Add-StaffAxis-context-type-tp180204p180221.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Enhancement: Implement parenthesizing spanners

[tisimst]

On 8/16/2015 10:35 PM, Werner LEMBERG [via Lilypond] wrote:

  I made an updated version for 2.19.24 and newer (…), which you find
  attached.  [...]

 Thanks!  I think this should be added to the Lilypond core.
Great work! The have two concerns that I'd like to at least put on the 
table.

1. Parenthesizing non-horizontally-fixed grobs (like slurs!): As it 
stands, which works great for most other grobs, a slur gets parentheses 
that span the entire vertical extent, rather than the initial and final 
control points. I think that latter would be much cleaner, but requires 
a separate section specifically customized for (Phrasing)Slurs. Not sure 
how hard this would be to implement, though I know it's easy to get the 
control point information. Then, the parentheses would be positioned 
relative to those points.

2. Parenthesizing a group of similar grobs in a single set of 
parentheses (like a series of staccato marks): I think it would also be 
helpful to have leftPar/rightPar variants that only put a parenthesis on 
the left/right by itself so that multiple instances of the same type of 
grob can appear to parenthesized together, rather than individually. I 
would expect these variants to act more like \once \override to only 
affect the current grob. Such a function would be helpful to group a 
series of, say, staccato marks in a single set of parentheses, a left 
parenthesis on the first one and a right parenthesis on the last one. 
I've seen this on numerous occasions. This one, I know, can be addressed 
quickly with variants of the current parenthesis-stencil and par 
functions.

Just my thoughts on the matter.

- Abraham





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Enhancement-Implement-parenthesizing-spanners-tp179714p179734.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: repeat volta 2

[tisimst]

On Thu, Jun 25, 2015 at 3:41 AM, pihentagy [via Lilypond] 
ml-node+s1069038n178188...@n5.nabble.com wrote:

  tisimst wrote
 Gergely,

 On Mon, Jun 22, 2015 at 2:55 PM, Gergely [via Lilypond] 
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=178188i=0
 wrote:

   I'm not top posting.
 
  % Should I expect lilypond to understand what's going on?
  % violin and viola are both 5 bar lenght staff, but see the combined
  output?
 
  violin = \relative c'' {
  \repeat volta 2 { c4 d e f | }
  \alternative { { c2 e | } { f2 g | } }
  c1
  }
 
  viola = \relative c' {
  \repeat volta 2 { c4 d e f | c2 c }
  c1
  }
 
  \score {

  \new Staff \violin
   \new Staff { \clef alto  \viola }

  }
 

 Not a bug. Actually, they aren't the same length. If we line up the two
 parts I get this:

 violin = |: c4 d e f | c2 e :| f2 g | c1 |
 viola =  |: c4 d e f | c2 e :| c1   |

 Nope, it is:

 violin = | c4 d e f | c2 e | c4 d e f | f2 g | c1 |
 viola =  | c4 d e f | c2 e |c4 d e f  | c2 e | c1 |

 Look, I understand what you are saying and, you're right, that is how the
musician *performs* it, but this isn't how LilyPond *engraves* it. If the
two parts are to be engraved in that expanded form, great! They each have
five bars and all questions are answered, but if they are to be engraved
using repeat bars, then we have a different problem if the OP doesn't want
to engrave a 2nd alternate ending in the conductor's score or the viola's
part and that's going to cause rehearsal confusion. I hope we can agree on
that at least.

 tisimst wrote

 So, looking at it by the raw musical content, I see 4 bars for violin and
 only 3 for viola. The problem would seem to be the missing 2nd alternative
 ending for the viola. Does this help clarify what's going on? The \repeat
 function won't automatically duplicate the notes for you. You need to do
 that, like you did with the violin part:

 viola = \relative c' {
   \repeat volta 2 { c4 d e f | }
   \alternative { { c2 e | } { c2 e | }}
   c1
 }

 Note that there are fancier ways of dealing with this situation, but see
 if
 what I've explained works for you.

 HTH,
 Abraham

 I am interested in the fancier ways. And shouldn't lilypond warn me /
 throw me an error about that inconsistency?


I'll get into the fancier ways in a moment, but first about the warnings.
Should there be one? I don't know if there needs to be in this case. The
real confusion is in what we *think* we're telling LilyPond to engrave and
what is *actually* being engraved. We engrave the specifed notes, the staff
lines, the clefs, the barlines, the alternate ending brackets and numbers.
We don't tell LilyPond, engrave these notes the first time through to the
repeat sign, then go back and engrave the second repeat this way. It
doesn't interpret the music like that. LilyPond's engraving rules are
deep-rooted in classical notation. I've never seen a classical score try to
take this shortcut for repeats, so we shouldn't expect LilyPond to
interpret that intention. It doesn't think of these parts as having 5 bars
each to engrave, it sees the violin with 4 bars and the viola with 3 bars.
We can change that with \unfoldRepeats, but that also changes what we are
really telling LilyPond to engrave.

So, the moral of this story is: Expect LilyPond to more literally engrave
what you give it. It is designed to think like an engraver, not a performer.

Now, what I meant by fancier ways really has to do with the practice of
separating music from layout/structure. If you've never done this before,
this is MAJORLY helpful when you need to engrave different editions of the
same music. Here's an example of how this can be done, the benefit is that
you only need to input the notes once and you can reuse it multiple times.
I'll also show how to use the handy \tag function to conditionally include
code:

%-- SNIP --

\version 2.18.2

violinMusic = \relative c'' {
  c4 d e f |
  c2 e |
  g2 g |
  c1
}

violaMusic = \relative c' {
  c4 d e f |
  c2 e |
  \tag #'forConductorScore { c2 e } |
  c1
}

conductorScoreStructure = {
  \repeat volta 2 { s1 }
  \alternative { { s1 } { s1 } }
  s1
}

violinPartStructure = \conductorScoreStructure

violaPartStructure = {
  \repeat volta 2 { s1*2 }
  s1
}

% Conductor's Score
\score {
  
\new Staff 
  \conductorScoreStructure
  \violinMusic
  
\new Staff 
   \conductorScoreStructure
  { \clef alto \violaMusic }

  
}

% Violin's Part
\score {
  \new Staff 
\violinPartStructure
  \violinMusic
  
}

% Viola's Part
\score {
  \new Staff 
\violaPartStructure
  { \clef alto \removeWithTag #'forConductorScore \violaMusic }
  
}

%-- SNIP --

One thing to take away from this is that if you don't use \removeWithTag,
you don't need to say anything for the tagged music to be engraved. There
are variations on this theme, but this is the general idea that can

Re: repeat volta 2

[tisimst]

Gergely,

On Mon, Jun 22, 2015 at 2:55 PM, Gergely [via Lilypond] 
ml-node+s1069038n178090...@n5.nabble.com wrote:

  I'm not top posting.

 % Should I expect lilypond to understand what's going on?
 % violin and viola are both 5 bar lenght staff, but see the combined
 output?

 violin = \relative c'' {
 \repeat volta 2 { c4 d e f | }
 \alternative { { c2 e | } { f2 g | } }
 c1
 }

 viola = \relative c' {
 \repeat volta 2 { c4 d e f | c2 c }
 c1
 }

 \score {
   
 \new Staff \violin
  \new Staff { \clef alto  \viola }
   
 }


Not a bug. Actually, they aren't the same length. If we line up the two
parts I get this:

violin = |: c4 d e f | c2 e :| f2 g | c1 |
viola =  |: c4 d e f | c2 e :| c1   |

So, looking at it by the raw musical content, I see 4 bars for violin and
only 3 for viola. The problem would seem to be the missing 2nd alternative
ending for the viola. Does this help clarify what's going on? The \repeat
function won't automatically duplicate the notes for you. You need to do
that, like you did with the violin part:

viola = \relative c' {
  \repeat volta 2 { c4 d e f | }
  \alternative { { c2 e | } { c2 e | }}
  c1
}

Note that there are fancier ways of dealing with this situation, but see if
what I've explained works for you.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/repeat-volta-2-tp178090p178094.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \finger \markup \tied-lyric option for tie to appear above numbers

[tisimst]

Eugene,

I had to do this recently, so here's a simple function catered for this
exact purpose. It uses two string numbers as input and looks very similar
to the normal downward tie (and could be further developed to act more
robustly like the \tied-lyric function, but my needs didn't stretch that
far):

#(define-markup-command (tied-finger-up layout props f1 f2)
   (string? string?)
   (interpret-markup layout props
 #{
   \markup {
   \override #'(baseline-skip . 1.2)
   \center-column {
 \scale #'(1 . -1) \musicglyph #ties.lyric.default
 \concat { #f1 \hspace #0.6 #f2 }
   }
   }
 #}
   ))

{ d''2\finger \markup { \tied-finger-up #1 #4 } }

Like I said, it could be further developed so that it follows the same
input syntax of #1~4, but there's still some Scheme-fu for me to come to
grips with. I agree, though, that it would be nice to just write 1^~4
into the \tied-lyric function and have it do it automagically :-)

Maybe I'll have a look at that myself. The only issue I can't quickly
understand is how to use the various markup functions in Scheme-mode.
Perhaps someone with more experience can help out here.

- Abraham

On Tue, Apr 28, 2015 at 10:15 AM, Eugene Cormier [via Lilypond] 
ml-node+s1069038n175595...@n5.nabble.com wrote:

  I'm not top posting.

 Hi folks, I'm working on a back score that requires the following:
 { d''2\finger \markup \tied-lyric #1~4 }

 but I can't seem to find a way to make the tie placement above the
 numbers. Is there a way to override? Should an easier method be added.

 I have tried the following with no luck:
 \override Tie.direction = #UP
 \tieUp
 \tied-lyric #1^~4
 etc

 Eugene

 --
 Eugene Cormier
 ---
 Full-time Instructor
 Acadia University
 www.eugenecormier.com
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=175595i=0
 Office: Denton Hall Rm.235
 Office Hours: Monday  Wednesday 10:30-11:30 (or by appointment)
 Phone: (902) 585-1329


 ---
 Statement of Confidentiality
 This message (including attachments) may contain confidential or
 privileged information intended for a specific individual or
 organization. If you have received this communication in error, please
 notify the sender immediately. If you are not the intended recipient,
 you are not authorized to use, disclose, distribute, copy, print or rely
 on this email, and should promptly delete this email from your entire
 computer system.


 ___
 bug-lilypond mailing list
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=175595i=1
 https://lists.gnu.org/mailman/listinfo/bug-lilypond


 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://lilypond.1069038.n5.nabble.com/finger-markup-tied-lyric-option-for-tie-to-appear-above-numbers-tp175595.html
  To start a new topic under Bugs, email
 ml-node+s1069038n58488...@n5.nabble.com
 To unsubscribe from Lilypond, click here
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
 .
 NAML
 http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/finger-markup-tied-lyric-option-for-tie-to-appear-above-numbers-tp175595p175599.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [LSR-620] Vertical line as a baroque articulation mark

[tisimst]

On Wed, Apr 8, 2015 at 10:55 AM, Mats Bengtsson-4 [via Lilypond] 
ml-node+s1069038n174231...@n5.nabble.com wrote:

 I would perhaps have written

This short vertical line placed above the note is commonly used in
 baroque music. p
It is commonly typeset using \staccatissimo, but if you want the
 original layout, the following example demonstrates how to achieve such
 a notation.

 Possibly, you could also add a comment on the technical implementation:
 The code uses an arbitrarily chosen articulation (stopped) and replaces
 the symbol by a markup that gives the desired layout. 


Why not have it UN-arbitrarily replace the staccatissimo stencil instead?

- Abraham


 /Mats

 On 2015-04-08 11:55, Pierre Perol-Schneider wrote:

  Ok, so how about:
 
  %{
This short vertical line placed above the note is commonly used in
  baroque music.
pIts meaning can vary, but generally indicates notes that should
  be played staccatissimo.
pThe following example demonstrates how to achieve such a notation.
  %}
 
  baroqueStaccatissimo =
  #(define-event-function (parser location) ()
 #{
%% possible tweaks here, e.g:
%-\tweak padding #1
%-\tweak avoid-slur #'around
%-\tweak direction #DOWN
-\tweak stencil #(lambda (grob) (grob-interpret-markup grob
#{
   \markup
   \override #'(thickness . 3)
   \draw-line #'(0 . 1)
#}))
 \stopped
 #})
 
  \relative c' {
a'4^\baroqueStaccatissimo a( c d')_\baroqueStaccatissimo
  }
 
  Cheers,
  Pierre
 
  2015-04-07 18:35 GMT+02:00 Mats Bengtsson [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=0
  mailto:[hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=1:
 
  As a side-note, I normally typeset this articulation as a
  staccatissimo, when transcribing baroque music and as far as I
  know, it's common practice. This can at least be worth to mention
  in the comment of the snippet.
 
 /Mats
 
 
  On 2015-04-07 18:01, [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=2
  mailto:[hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=3 wrote:
 
  Hi Squad Members,
 
  Regarding this snippet:
  http://lsr.di.unimi.it/LSR/Item?id=620
  I'm not sure about the 'font-size 3' effect; was it for the
  articulation
  line thickness?
  Anyway I'm thinking about putting a more user-friendly script.
  How about:
 
  upline =
  #(define-event-function (parser location) ()
  #{
 %% possible tweaks here, e.g:
 %-\tweak padding #1
 %-\tweak avoid-slur #'around
 %-\tweak direction #DOWN
 -\tweak stencil #(lambda (grob) (grob-interpret-markup
 grob
 #{
\markup
\override #'(thickness . 3)
\draw-line #'(0 . 1)
 #}))
  \stopped
  #})
 
  \relative c' {
 a'4^\upline a( c d')_\upline
  }
 
  Cheers,
  Pierre
 
 
  --
  =
  Mats Bengtsson
  Signal Processing
  School of Electrical Engineering
  Royal Institute of Technology (KTH)
  SE-100 44  STOCKHOLM
  Sweden
  Phone: (+46) 8 790 8463 tel:%28%2B46%29%208%20790%208463
  Email: [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=4
  mailto:[hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=5
  WWW: http://www.ee.kth.se/~mabe 
 http://www.ee.kth.se/%7Emabe
  =
 
 
  ___
  bug-lilypond mailing list
  [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=6 mailto:[hidden
 email] http:///user/SendEmail.jtp?type=nodenode=174231i=7
  https://lists.gnu.org/mailman/listinfo/bug-lilypond
 
 

 --
 =
 Mats Bengtsson
 Signal Processing
 School of Electrical Engineering
 Royal Institute of Technology (KTH)
 SE-100 44  STOCKHOLM
 Sweden
 Phone: (+46) 8 790 8463
 Email: [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=174231i=8
 WWW: http://www.ee.kth.se/~mabe
 =


 ___
 bug-lilypond mailing list
 [hidden email] http:///user/SendEmail.jtp?type=nodenode=174231i=9
 https://lists.gnu.org/mailman/listinfo/bug-lilypond


 

Re: small caps

[tisimst]

James,

Thanks for the pointer to that thread. It seems to be the same issue. So,
does the \fromproperty command not return a markup object? In the source
code, the function's docstring says this:

Read the @var{symbol} from property settings, and produce a stencil
from the markup contained within.  If @var{symbol} is not defined, it
returns an empty markup.

So... does it return a stencil or a markup?

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Re-small-caps-tp170553p170574.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: LSR : Dashed slurs indicating optional slurs between lyric lines

[tisimst]

Pierre,

I'm very much in favor of moving the slur closer, but I'm not in love 
with the method, even if it works. Shouldn't Whee! technically be a 
melisma? Isn't that the point of the snippet? It seems like it should 
be something like this instead:

%--- SNIP -

\version 2.18.2 

\score { 
   
\new Voice = melody \relative c' { 
  \set melismaBusyProperties = #'()
  \slurDashed
  c8 e d-\tweak line-thickness #2.5 ( f ) e g f a 
} 
\new Lyrics \lyricsto melody { 
  One two three four five six seven eight 
} 
\new Lyrics \lyricsto melody { 
  One two Whee! _ that's a dashed slur! 
} 
   
} 

%--- SNIP -

Just my thoughts.

-Abraham

On Wed, Nov 12, 2014 at 6:57 AM, Schneidy [via Lilypond] 
ml-node+s1069038n168671...@n5.nabble.com wrote:
 Hi Squad, 
 
 In this snippet : http://lsr.di.unimi.it/LSR/Item?id=308
 the slur is to low. 
 So I'd like to slightly change it to : 
 
 \version 2.18.2 
 
 \score { 

 \new Voice = melody \relative c' { 
   c8 e8 

 { 
   d8 f8 
 } 
 \new Voice { 
   \omit Stem 
   \override NoteColumn.ignore-collision = ##t 
   \slurDashed 
   d4*1/2 -\tweak line-thickness #2.5 ( f) 
 } 

   \oneVoice 
   e8 g8 f8 a8 
 } 
 \new Lyrics \lyricsto melody { 
   One two three four five six seven eight 
 } 
 \new Lyrics \lyricsto melody { 
   One two Whee! \skip 4 that's a dashed slur! 
 } 

 } 
 
 Any objection ? 
 
 Cheers, 
 Pierre 
 ___ 
 bug-lilypond mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 ~Pierre
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/LSR-Dashed-slurs-indicating-optional-slurs-between-lyric-lines-tp168671.html
 To start a new topic under Bugs, email 
 ml-node+s1069038n58488...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LSR-Dashed-slurs-indicating-optional-slurs-between-lyric-lines-tp168671p168673.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Quoting from first measure

[tisimst]

Helge,

This worked for me (moving \global to be after the quote is defined):

% SNIP --

\version 2.18.0 

global = { 
  \key g \major 
  \tempo 4=90 
} 

upperHarpI = \relative c'' { 
  c4 c c c  % --- take \global out of here
} 

\addQuote harp1u { \upperHarpI }  % --- this no longer quotes \tempo

upperHarpII = \relative c'' { 
  \quoteDuring #harp1u { s1 } 
} 

\score {
   
\new Staff { \global \upperHarpI }  % --- and put it here instead
\new Staff \upperHarpII 
  
}

% SNIP --

HTH,
Abraham

On Fri, Oct 31, 2014 at 1:25 PM, Helge Kruse-4 [via Lilypond] 
ml-node+s1069038n168148...@n5.nabble.com wrote:
 Hello, 
 
 I have a piece where the first measures are played unisono. This was 
 my 
 first try to use quotes. Unfortunately the Lilypond log outputs a 
 warning: 
 
 C:/Users/Helge/Documents/Scores/Editor/Example/quotesample.ly:6:3 
 0: 
 warning: Two simultaneous tempo-change events, junking this one 
 
 \tempo 4=90 
 
 
 This can be reproduced with this example: 
 
 %% 
 \version 2.18.0 
 
 
 global = { 
 
\key g \major 
 
\tempo 4=90 
 
 } 
 
 
 upperHarpI = \relative c'' { 
 
\global 
 
c4 c c c 
 
 } 
 
 
 \addQuote harp1u { \upperHarpI } 
 
 
 upperHarpII = \relative c'' { 
 
\quoteDuring #harp1u { s1 } 
 
 } 
 
 \score  
 
\new Staff \upperHarpI 
 
\new Staff \upperHarpII 
 
   
 
 
 %% 
 
 
 The warning can be suppressed by writing the first note in the 
 upperHarpII and reducing the quote-length by the length of the note. 
 But 
 this is not very elegant. 
 
 Regards 
 Helge 
 
 
 
 
 ___ 
 bug-lilypond mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/Quoting-from-first-measure-tp168148.html
 To start a new topic under Bugs, email 
 ml-node+s1069038n58488...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Quoting-from-first-measure-tp168148p168150.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1129: Font styles return to default when font size changed

[tisimst]

On Fri, Aug 8, 2014 at 2:21 AM, Hilary Snaden [via Lilypond] 
ml-node+s1069038n165395...@n5.nabble.com wrote:
 Is this likely to be resolved? Perhaps a more fully-functioning 
 workaround? 
 
 I'm not nearly clever enough to do either myself, and it looks as 
 though 
 I must generate a series of scores with manually-set page numbers 
 (and 
 blank pages) and combine them with pdftk. 
 
 -- 
 Hilary 
 
 ___ 
 bug-lilypond mailing list 
 [hidden email] 
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/Issue-1129-Font-styles-return-to-default-when-font-size-changed-tp165395.html
 To start a new topic under Bugs, email 
 ml-node+s1069038n58488...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML
 
Hilary,

What exactly are you wanting to do? Maybe there's a workaround...

-Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Issue-1129-Font-styles-return-to-default-when-font-size-changed-tp165395p165396.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: barcheck failure with partial in middle of piece

[tisimst]

On Fri, Aug 8, 2014 at 8:53 AM, Paul Morris [via Lilypond] 
ml-node+s1069038n165402...@n5.nabble.com wrote:
 I'm getting an unexpected barcheck failure when using partial in the 
 middle of a piece.  In the minimal example below, if you comment out 
 the chords the first barcheck succeeds, but with the chords included 
 it fails.  (Also the beaming in that first measure is off.)   
 
 Not sure if this is a bug or if I'm expecting too much from \partial. 
  In 2.18 there was a warning for using \partial after the start of a 
 piece, but not in 2.19. 
 
 (Actual use case: in fiddle tunes where the A and B parts are each 
 repeated, and there's a line \break before the start of the B part... 
  the pickup notes for the B part should be notated at the beginning 
 of the B part, rather than at the end of the A part, to easily see 
 them when repeating back to the start of the B part.  Hence the use 
 of partial in the middle of a piece.) 
 
 Cheers, 
 -Paul 
 
 
 \version 2.19.11 
 
 melodyOne = \relative { 
   \time 6/8 
   a'8 a a a a a | % this barcheck fails when chords are present 
   \partial 8 
   d8 | 
   c8 c c c c c | 
 } 
 
 chordsOne = \chordmode { 
   \time 6/8 
   a2. | 
   \partial 8 
   s8 | 
   a2. | 
 } 
 
 \score { 

 \new ChordNames { \chordsOne } 
 \new Staff { \melodyOne } 

 } 
 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://lilypond.1069038.n5.nabble.com/barcheck-failure-with-partial-in-middle-of-piece-tp165402.html
 To start a new topic under Bugs, email 
 ml-node+s1069038n58488...@n5.nabble.com 
 To unsubscribe from Lilypond, click here.
 NAML
 
Paul,

I can't say I know what's going on, but to get the job done you might 
be able to use the function I created in response to this post:

http://lilypond.1069038.n5.nabble.com/partial-in-the-middle-of-piece-td163365.html

Regards,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/barcheck-failure-with-partial-in-middle-of-piece-tp165402p165403.html
Sent from the Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond