Text formatting inside `\wordwrap-field`

[Br. Samuel Springuel]

How do I apply formatting to text in a header field which is destined to 
be inside a `\wordwarp-field` command.  Say, for instance, that I wanted 
to italicize the words "incididunt ut labore" in the following snippet 
(taken from the documentation for `\wordwrap-field`):


%%% BEGIN snippet %%%
\version 2.19.80

\header {
  title = "My title"
  myText = "Lorem ipsum dolor sit amet, consectetur adipisicing
elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua.  Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat."
}

\paper {
  bookTitleMarkup = \markup {
\column {
  \fill-line { \fromproperty #'header:title }
  \null
  \wordwrap-field #'header:myText
}
  }
}

\markup {
  \null
}
%%% END snippet %%%
--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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

lyluatex inline question

[Craig Dabelstein]

Hi all,

So far lyluatex is working brilliantly for me. A question about setting a
musical example inline. To make the staff smaller to match the surrounding
text I need the inline-staffsize command but I can't get this example to
work.

\lilypond[insert=bare-inline, inline-staffsize=8]{a4 a8 a}

Any ideas what I'm doing wrong?

Thanks in advance,

Craig




-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: bookparts (OT)

[J Martin Rushton]

On 12/03/18 21:47, Noeck wrote:
> Hi all,
> 
> thanks a lot to all how replied to my questions!
> I got quite discouraged by the first reply but having my questions
> (mostly) confirmed helps a lot.
> 
> Summary of the main points:
> 
> - \bookpart is something like a scope for \paper settings
> - I have to use unique variable naming
> - While includes can go in several places, variable definitions can only
>   appear on top level (so can includes containing definitions).
> 
> The unique naming is the biggest issue for me now and I have to
> restructure a lot concerning variables and includes. But it is solvable.
> 
> Thanks for all your input!
> Joram
> 
Scope! Whazzat?

From my formative years ...

Real Programmers...
• Don't eat quiche. Real programmers don't even know how to spell
quiche. They like Twinkies, Coke, and palate-scorching Szechwan food.
• Don't write applications programs. They program right down to the bare
metal. Applications programs are for dullards who can't do systems
programming.
• Don't comment their code. If it was hard to write, it should be hard
to understand and even harder to modify.
• Don't draw flowcharts. Flowcharts are, after all, the illiterate's
form of documentation. Cavemen drew flowcharts; look how much it did for
them.
• Don't use COBOL. COBOL is for wimpy applications programmers.
• Don't use FORTRAN. FORTRAN is for wimpy engineers who wear white
socks, pipe stress freaks, and crystallography weenies. They get excited
over finite state analysis and nuclear reactor simulations.
• Don't use LOGO. In fact  programmers use LOGO after puberty.
• Don't use APL unless the whole program can be written on one line.
• Don't use LISP. Only effeminate programmers use more parentheses than
actual code.
• Don't use Pascal, BLISS, ADA, or any of those sissy-pinko computer
science languages. Strong typing is a crutch for people with weak memories.
• Never work 9 to 5. If any are around at 9 a.m. it's because they were
up all night.
• Don't play tennis or any other sport that requires a change of
clothes. Mountain climbing is OK, though, and real programmers often
wear climbing boots to work in case a mountain should suddenly spring up
in the middle of the machine room.
• Don't like the team programming concept. Unless, of course, they are
the Chief Programmer.
• Have no use for managers. Managers are a necessary evil. They are for
dealing with personnel bozos, bean counters, senior planners, and other
mental defectives.
• Don't drive around in clapped out mavericks. They prefer BMW's,
Lincolns, or pick-up trucks with floor shifts. Fast motorcycles are
highly regarded.
• Like vending machine popcorn. Coders pop it in the microwave oven.
Real programmers use the heat given off by the CPU. They can tell what
job is running just by listening to the rate the corn is popping.
• Know every nuance of every instruction and use them all in every real
program. Puppy architects won't allow execute instructions to address
another execute as the target instruction. Real programmers despise such
petty restrictions.
• Don't bring brown bag lunches to work. If the vending machine sells
it, they eat it. If the vending machine doesn't sell it, they don't eat
it. Vending machines don't sell quiche.
- Author Unknown

(Nicked from
https://www.daniweb.com/community-center/threads/139423/real-programmers-don-t-eat-quiche
who had pinched it from an April 1985 DEC magazine)



signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Right aligned text in header

[Br. Samuel Springuel]

On 3/13/18 5:02 PM, Thomas Morley wrote:

Hi,

do you mean like below?
Based on
http://lsr.di.unimi.it/LSR/Item?u=1=765

#(define (general-column align-dir baseline mols)
   (let* ((aligned-mols
(map (lambda (x) (ly:stencil-aligned-to x X align-dir)) mols)))
 (stack-lines -1 0.0 baseline aligned-mols)))

#(define-markup-command (my-wordwrap-field layout props symbol)
   (symbol?)
   #:category align
   #:properties ((baseline-skip)
 (align-dir LEFT))
   (let* ((m (chain-assoc-get symbol props)))
 (if (string? m)
 (general-column align-dir baseline-skip
   (wordwrap-string-internal-markup-list layout props #f m))
 empty-stencil)))


RIGHT instead of LEFT in this and then it does what I want.  Thanks.


--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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

Re: Right aligned text in header

[Thomas Morley]

2018-03-13 20:31 GMT+01:00 Br. Samuel Springuel :
> I'm creating a custom bookTitleMarkup for a project I'm working on and have
> some lines which are setup like `meter` and `arranger` in the default
> template (two blocks of text, one flushed left the other right, on the same
> line).
>
> However, on one of those lines the header properties to be used may be very
> long and thus I need to force word wrapping to less than the full line width
> for each field.  On the left side, that is not a problem, I just use
> `\override #'(line-width . 30) \wordwrap-field`.  However, on the right side
> this doesn't work because the wrapping of the text within the field is left
> aligned inside its box (which is right aligned on the line).  What I'd like
> is for the wrapped text to be right aligned inside its box.  I tried
> changing `text-direction` to -1, and this did change the alignment, but also
> reversed the word order on each line.
>
> Is there an equivalent for `\wordwrap-field` that will flush right the text
> (much like `\justify-field` leads to it being justified)?
>
> %%% Begin Snippet %%%
> \paper  {
> % custom title layout
> bookTitleMarkup = \markup { \column {
> \fill-line { \fromproperty #'header:title }
> \fill-line {
> \fromproperty #'header:meter
> \fromproperty #'header:tune
> }
> \fill-line {
> \fromproperty #'header:poet
> \fromproperty #'header:composer
> }
> \fill-line {
> { \override #'(line-width . 30) \wordwrap-field
> #'header:poet_copyright }
> { \override #'(line-width . 30) \wordwrap-field
> #'header:tune_copyright }
> }
> }}
> scoreTitleMarkup = {}
> }
>
> \header {
> title = "Title of song (from lyrics)"
> meter = "8.8.8.8"
> tune = "name of tune"
> poet = "Poet"
> composer = "Composer"
> poet_copyright = "A sometimes long statement indicating at least the
> year of the copyright.  Should be flushed left."
> tune_copyright = "Also may be long and in need of wrapping.  Should be
> flushed right."
> }
>
> \new Staff
> {
>   \new Voice = "mel" { c' }
> }
>
> %%% End Snippet %%



Hi,

do you mean like below?
Based on
http://lsr.di.unimi.it/LSR/Item?u=1=765

#(define (general-column align-dir baseline mols)
  (let* ((aligned-mols
   (map (lambda (x) (ly:stencil-aligned-to x X align-dir)) mols)))
(stack-lines -1 0.0 baseline aligned-mols)))

#(define-markup-command (my-wordwrap-field layout props symbol)
  (symbol?)
  #:category align
  #:properties ((baseline-skip)
(align-dir LEFT))
  (let* ((m (chain-assoc-get symbol props)))
(if (string? m)
(general-column align-dir baseline-skip
  (wordwrap-string-internal-markup-list layout props #f m))
empty-stencil)))


\paper  {
% custom title layout
bookTitleMarkup = \markup { \column {
\fill-line { \fromproperty #'header:title }
\fill-line {
\fromproperty #'header:meter
\fromproperty #'header:tune
}
\fill-line {
\fromproperty #'header:poet
\fromproperty #'header:composer
}
\fill-line {
{
  \override #'(line-width . 30)
  \wordwrap-field #'header:poet_copyright
}
{
  \override #'(line-width . 30)
  \override #'(align-dir . 1)
  \my-wordwrap-field #'header:tune_copyright
}
}
}}
scoreTitleMarkup = {}
}

\header {
title = "Title of song (from lyrics)"
meter = "8.8.8.8"
tune = "name of tune"
poet = "Poet"
composer = "Composer"
poet_copyright = "A sometimes long statement indicating at least the year
of the copyright.  Should be flushed left."
tune_copyright = "Also may be long and in need of wrapping.
Should be flushed right."
}

\new Staff
{
  \new Voice = "mel" { c' }
}


Cheers,
  Harm

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

Re: Thriple flat/sharp glyphs...

[Noeck]

Hi Torsten,

I am in favour of version 3 (or between 3 and 4).
Equally spaced, full-sized flats with maximal overlap. I think, saving
horizontal width is important.

I like your "intermediate 3/4 pdf".
In a very large size (your pdf 400%) they look perfect to me.
It is hard to tell with the limited resolution of a monitor, but in
usual sizes (100%) they might be too much overlapping (i.e. still moving
a little bit towards version 4 might be preferable).
Printed on paper, the pdf looks right and doesn't need less overlap to
my eyes.

Cheers,
Joram

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

Right aligned text in header

[Br. Samuel Springuel]

I'm creating a custom bookTitleMarkup for a project I'm working on and 
have some lines which are setup like `meter` and `arranger` in the 
default template (two blocks of text, one flushed left the other right, 
on the same line).


However, on one of those lines the header properties to be used may be 
very long and thus I need to force word wrapping to less than the full 
line width for each field.  On the left side, that is not a problem, I 
just use `\override #'(line-width . 30) \wordwrap-field`.  However, on 
the right side this doesn't work because the wrapping of the text within 
the field is left aligned inside its box (which is right aligned on the 
line).  What I'd like is for the wrapped text to be right aligned inside 
its box.  I tried changing `text-direction` to -1, and this did change 
the alignment, but also reversed the word order on each line.


Is there an equivalent for `\wordwrap-field` that will flush right the 
text (much like `\justify-field` leads to it being justified)?


%%% Begin Snippet %%%
\paper  {
% custom title layout
bookTitleMarkup = \markup { \column {
\fill-line { \fromproperty #'header:title }
\fill-line {
\fromproperty #'header:meter
\fromproperty #'header:tune
}
\fill-line {
\fromproperty #'header:poet
\fromproperty #'header:composer
}
\fill-line {
{ \override #'(line-width . 30) \wordwrap-field 
#'header:poet_copyright }
{ \override #'(line-width . 30) \wordwrap-field 
#'header:tune_copyright }

}
}}
scoreTitleMarkup = {}
}

\header {
title = "Title of song (from lyrics)"
meter = "8.8.8.8"
tune = "name of tune"
poet = "Poet"
composer = "Composer"
poet_copyright = "A sometimes long statement indicating at least 
the year of the copyright.  Should be flushed left."
tune_copyright = "Also may be long and in need of wrapping.  Should 
be flushed right."

}

\new Staff
{
  \new Voice = "mel" { c' }
}

%%% End Snippet %%

--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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

Re: can the leading \markup command be eliminated in a new markup command?

[Kieren MacMillan]

Hi David,

> You either define an event function or a markup command. […]
> One is the markup, the other is a text script post event.  Markups can
> be used in a variety of circumstances (as text scripts, as lyrics, as
> part of other markup, as tempo strings, as mark texts and so on).  Text
> scripts can be used as text scripts.

Since all I usually want/need in such situations are text scripts — never to be 
[re]used in any other circumstances — I will go forward under the impression 
that event functions suit my need just fine, and adjust my function library 
accordingly.

Thanks again!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: can the leading \markup command be eliminated in a new markup command?

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>>> Is there any technical reason not to make *every* markup function work
>>> like this?
>> 
>> There are markup commands and event functions and they are in different
>> name spaces.
>
> Sorry for pushing for more clarity/understanding, but: is it [in terms
> of behaviour] that the event-function version of the function simply
> provides a "wrapper" for the markup-function version (thus saving the
> \markup, but doing nothing else),

What?  You either define an event function or a markup command.  They
aren't related.  If you are feeling fancy, you can define a markup
command and use it in the definition of an event function of the same
name.  But that's entirely up to the user.

> or does either version have additional pros and/or cons (e.g.,
>  more/less expensive, more/less prone to problems, etc.).

One is the markup, the other is a text script post event.  Markups can
be used in a variety of circumstances (as text scripts, as lyrics, as
part of other markup, as tempo strings, as mark texts and so on).  Text
scripts can be used as text scripts.

>> We don't prescripe how people are going to use markups.
>
> That's probably a good thing! =)
>
> But since \cue is both clearer (more immediately obvious) and cleaner
> (less typing) than \markup \cue, I'm trying to determine if there’s
> any downside to modifying my entire library with
> define-markup-function --> define-event-function (besides the
> search-and-replace migration effort on legacy scores, obviously).

It depends on whether you want a markup or some post event that is
implemented using a text script.

-- 
David Kastrup

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

Re:Thriple flat/sharp glyphs...

[Flaming Hakama by Elaine]

> From: Werner LEMBERG 
> Subject: Re: Thriple flat/sharp glyphs...
>
> Nice work!
>
> > 2. Abraham's equally compressed flats
> >
> > Both flats are equally compressed as a compromise, thus keeping the
> > original glyph width:
> >
> >  flat-2-abraham-equal.png>
>
> This is my favourite.
>
>
> Werner
>

+1

The narrow width is helpful, but more importantly I like that it retains
more curvature.


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

Re: Thriple flat/sharp glyphs...

[Stefano Troncaro]

Hi Torsten, I'm undecided between the second and the third. Would it be
possible to compare them in a musical example?

2018-03-13 12:38 GMT-03:00 Werner LEMBERG :

>
> Nice work!
>
> > 2. Abraham's equally compressed flats
> >
> > Both flats are equally compressed as a compromise, thus keeping the
> > original glyph width:
> >
> >  flat-2-abraham-equal.png>
>
> This is my favourite.
>
>
> Werner
>
> ___
> 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: Thriple flat/sharp glyphs...

[Torsten Hämmerle]

Urs Liska-3 wrote
> If I had to choose between 3) and 4) I would go for 4), but actually I'd 
> suggest to go for something between those two.

Good point. To narrow down the number of suggestions, I just took the
extreme cases. If we go for natural width flats, the overlap can be
optimized.


Urs Liska-3 wrote
> The problem I have with 3) is the upper edge of the intersection between 
> the left and right glyph: I have the impression (although this should be 
> verified in a realistic-sized setting with notational context) that this 
> section is somewhat blurred because the line is still nearly horizontal 
> at the intersection.

Yes, these big proof versions may be fine, but in the end, they'll have to
be reviewed in realistic sizes (and, by the way, in all Emmentaler sizes
from 11 to 26.

My personal "ideal" double-flat overlap would be so that the upper arches
(thinking the stems away) form nice and harmonic arcades like they do in the
Antiqua letter m, if you know what I mean...

Here you go with my issue3356 testing PDF, this time with an intermediate
3./4. version:
test-issue3356.pdf
  

All the best,
Torsten



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

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

Re: Edition Engraver bug?

[Stefano Troncaro]

Hi Jan-Peter,

Thank you for your work! I will test the changes later today and let you
know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt :

> Am 13.03.2018 um 11:37 schrieb David Kastrup:
>
>> Jan-Peter Voigt  writes:
>>
>> Hi Stefano,
>>>
>>> I have been looking into the issue and created a branch
>>> 'refactor-override' for the edition-engraver.
>>> The following is changed in there:
>>> * Overrides are not applied "by hand" but send as a StreamEvent so
>>> that once is handled by lily and not the EE
>>> * Override (and Revert, Set, Unset) sent by the EE are marked so that
>>> they can be distinguished from other overrides
>>>
>>> That means once-overrides are note reverted wrong anymore and the EE
>>> gives a warning if an overrides supersedes/overwrites an EE mod. This
>>> is still not completely satisfactory when the EE shall override all
>>> other settings. But at least it doesn't revert wrong.
>>>
>>> If this branch is tested more thoroughly I will merge it into master.
>>> Now I am looking for a way to let the EE be the last broadcaster so
>>> that it will not be overridden by overrides sent from the actual music
>>> stream.
>>>
>>
>> How do you trigger the EE?  Overrides from the music stream are sent by
>> the iterators.  That's after start-translation-timestep and before
>> process-music.
>>
>
> The EE broadcasts overrides (events) inside start-translation-timestep. I
> tried to do it in process-music, but then they were applied too late.
> The EE is looking in its internal mod-store if there is something to do
> for this timestep (for this context). Is there a way to act between those
> slots - the latest action before process-music?
>
>
> ___
> 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: can the leading \markup command be eliminated in a new markup command?

[Kieren MacMillan]

Hi David,

>> Is there any technical reason not to make *every* markup function work
>> like this?
> 
> There are markup commands and event functions and they are in different
> name spaces.

Sorry for pushing for more clarity/understanding, but: is it [in terms of 
behaviour] that the event-function version of the function simply provides a 
"wrapper" for the markup-function version (thus saving the \markup, but doing 
nothing else), or does either version have additional pros and/or cons (e.g., 
more/less expensive, more/less prone to problems, etc.). 

> We don't prescripe how people are going to use markups.

That's probably a good thing! =)

But since \cue is both clearer (more immediately obvious) and cleaner (less 
typing) than \markup \cue, I'm trying to determine if there’s any downside to 
modifying my entire library with define-markup-function --> 
define-event-function (besides the search-and-replace migration effort on 
legacy scores, obviously).

Thanks again!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

calling lilybin (or similar) as a service triggered from a [JavaScript?] form in a web page

[Kieren MacMillan]

Hello all,

Has anyone tried to set up a form (e.g., Javascript) in a web page which, when 
submitted, triggers a Lilypond-on-server (LoS?) application/environment (e.g., 
lilybin.com) and returns a PDF?

I'd like to offer some music and music education documents and templates on my 
website, but (a) don’t want to show my Lilypond code, and (b) if possible, 
avoid installing and maintaining the Lilypond server installation myself.

Thanks for any hints/advice/pointers.
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Thriple flat/sharp glyphs...

[Werner LEMBERG]

Nice work!

> 2. Abraham's equally compressed flats
> 
> Both flats are equally compressed as a compromise, thus keeping the
> original glyph width:
> 
> 
>  

This is my favourite.


Werner

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

Re: Thriple flat/sharp glyphs...

[Urs Liska]

Hi Torsten,

thank you for that comparison.


Am 13.03.2018 um 15:52 schrieb Torsten Hämmerle:

...

Double-flat alternatives in comparison

In the old discussions mentioned in some of the answers, Abraham proposed a
compromise that kept the original glyph width by applying an average
compression to both flats.

I've used MetaFont's proof sheets (with outlines so show how the flat
symbols are put together on the left and the filled-in normal versions to
check the visual appearance).
There has been some manual cleansing of distracting outlines of superimposed
parts and I've unified some parameters that made the counter (the small
"hole" in the flat symbol) look slightly different in some accidentals
containing flats.

1. Original Feta design

The compressed left flat even "bites off" part of the lower stem and makes
it look considerably thinner. And the compression of the left flat only
reminds me of a rear-shunt car crash, sort of... ;)



2. Abraham's equally compressed flats

Both flats are equally compressed as a compromise, thus keeping the original
glyph width:



3. Torsten's "real" flats with maximum overlap

Both flats are "real" unaltered flats. Maximum overlap makes the double-flat
glyph only marginally wider than the original design (cf. Dorico's Bravura
font):



4. Abraham's "real" flats with minimum overlap

Both flats are "real" unaltered flats, there is only a slight overlap. This
is the widest of all the designs mentioned here (cf. Sibelius' Opus font):



All the graphics have exactly the same height/width and glyph positioning,
so you can download them and flip through them to directly see how the
design slightly changes from image to image and gradually widens up.

What do you think?


I would vote for changing the current design, i.e. rule out version 1)

I don't really like the compressed version 2)

If I had to choose between 3) and 4) I would go for 4), but actually I'd 
suggest to go for something between those two.
The problem with 4) is obviously (and only) that it takes much 
horizontal space - especially if you extend it to triple flats.
The problem I have with 3) is the upper edge of the intersection between 
the left and right glyph: I have the impression (although this should be 
verified in a realistic-sized setting with notational context) that this 
section is somewhat blurred because the line is still nearly horizontal 
at the intersection.


Urs



Thanks for the support,
Torsten



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

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



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

Re: Thriple flat/sharp glyphs...

[Torsten Hämmerle]

First of all,

Thank you very much for all the feedback!
Sorry I didn't dig the archives myself, but initially I took the original
Feta designs for granted and carved in stone.

Where did the original double-flat design come from?

Music(X)TeX was a good guess, but the Music(X)TeX accidentals look
completely different.
Thinking of the introductory LilyPond Background Essay, there's a  section
about the flat symbol design

  
and they mention Henle (computer typesetting) compared to Bärenreiter (hand
engraving). 
When looking at the examples, the LilyPond flat seems to have been derived
from the Bärenreiter stencil.

*Conclusion:* Bärenreiter use standard flat widths for double-flat flats, so
I don't see why we shouldn't adapt the existing Feta double-flat accidentals
and create a matching (triple-flat, of course).
Without Abraham's encouragement I'd never have dared touch the original Feta
designs, though.
Basically, nobody but LilyPond seems to use a compressed left flat. 

Double-flat alternatives in comparison

In the old discussions mentioned in some of the answers, Abraham proposed a
compromise that kept the original glyph width by applying an average
compression to both flats.

I've used MetaFont's proof sheets (with outlines so show how the flat
symbols are put together on the left and the filled-in normal versions to
check the visual appearance).
There has been some manual cleansing of distracting outlines of superimposed
parts and I've unified some parameters that made the counter (the small
"hole" in the flat symbol) look slightly different in some accidentals
containing flats.

1. Original Feta design

The compressed left flat even "bites off" part of the lower stem and makes
it look considerably thinner. And the compression of the left flat only
reminds me of a rear-shunt car crash, sort of... ;)

 

2. Abraham's equally compressed flats

Both flats are equally compressed as a compromise, thus keeping the original
glyph width:


 

3. Torsten's "real" flats with maximum overlap

Both flats are "real" unaltered flats. Maximum overlap makes the double-flat
glyph only marginally wider than the original design (cf. Dorico's Bravura
font):


 

4. Abraham's "real" flats with minimum overlap

Both flats are "real" unaltered flats, there is only a slight overlap. This
is the widest of all the designs mentioned here (cf. Sibelius' Opus font):


 

All the graphics have exactly the same height/width and glyph positioning,
so you can download them and flip through them to directly see how the
design slightly changes from image to image and gradually widens up.

What do you think?

Thanks for the support,
Torsten



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

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

Re: can the leading \markup command be eliminated in a new markup command?

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> %%%  SNIPPET BEGINS
>> \version "2.19.80"
>> 
>> cue =
>> #(define-event-function (text) (markup?)
>>  #{ ^\markup \bold #text #})
>> 
>> { c''\cue "This is the cue." }
>> %%%  SNIPPET ENDS
>> 
>> If you don't want to bake the direction in, use - instead of ^ .
>
> Thanks for that!
>
> Is there any technical reason not to make *every* markup function work
> like this?

There are markup commands and event functions and they are in different
name spaces.

> It seems like a no-brainer to save the keystrokes every time… but it
>  may not be "blessed" for some reason I don’t know.

We don't prescripe how people are going to use markups.

-- 
David Kastrup

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

Re: can the leading \markup command be eliminated in a new markup command?

[Kieren MacMillan]

Hi David,

> %%%  SNIPPET BEGINS
> \version "2.19.80"
> 
> cue =
> #(define-event-function (text) (markup?)
>  #{ ^\markup \bold #text #})
> 
> { c''\cue "This is the cue." }
> %%%  SNIPPET ENDS
> 
> If you don't want to bake the direction in, use - instead of ^ .

Thanks for that!

Is there any technical reason not to make *every* markup function work like 
this? It seems like a no-brainer to save the keystrokes every time… but it may 
not be "blessed" for some reason I don’t know.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Edition Engraver bug?

[Jan-Peter Voigt]

Am 13.03.2018 um 11:37 schrieb David Kastrup:

Jan-Peter Voigt  writes:


Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This
is still not completely satisfactory when the EE shall override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so
that it will not be overridden by overrides sent from the actual music
stream.


How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.


The EE broadcasts overrides (events) inside start-translation-timestep. 
I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do 
for this timestep (for this context). Is there a way to act between 
those slots - the latest action before process-music?


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

Re: Edition Engraver bug?

[David Kastrup]

Jan-Peter Voigt  writes:

> Hi Stefano,
>
> I have been looking into the issue and created a branch
> 'refactor-override' for the edition-engraver.
> The following is changed in there:
> * Overrides are not applied "by hand" but send as a StreamEvent so
> that once is handled by lily and not the EE
> * Override (and Revert, Set, Unset) sent by the EE are marked so that
> they can be distinguished from other overrides
>
> That means once-overrides are note reverted wrong anymore and the EE
> gives a warning if an overrides supersedes/overwrites an EE mod. This
> is still not completely satisfactory when the EE shall override all
> other settings. But at least it doesn't revert wrong.
>
> If this branch is tested more thoroughly I will merge it into master.
> Now I am looking for a way to let the EE be the last broadcaster so
> that it will not be overridden by overrides sent from the actual music
> stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

-- 
David Kastrup

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

Re: Edition Engraver bug?

[Jan-Peter Voigt]

Hi Stefano,

I have been looking into the issue and created a branch 
'refactor-override' for the edition-engraver.

The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so that 
once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that 
they can be distinguished from other overrides


That means once-overrides are note reverted wrong anymore and the EE 
gives a warning if an overrides supersedes/overwrites an EE mod. This is 
still not completely satisfactory when the EE shall override all other 
settings. But at least it doesn't revert wrong.


If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so that 
it will not be overridden by overrides sent from the actual music stream.


Jan-Peter


Am 26.02.2018 um 15:26 schrieb Stefano Troncaro:
Hi everyone! I tried to isolate the issue with Tie directions that I 
posted earlier and I'm fairly confident I've stumbled upon a bug.


Look at the output of this snippet (Sorry for the length, I made it as 
short as I could)


\version  "2.19.80" \language  "english" \include  "oll-core/package.ily" 
\loadPackage  edition-engraver
\addEdition  test
\consistToContexts  #edition-engraver Voice

\layout  { \context  { \Score \time  6/4
 \omit  TimeSignature \omit  Clef } } forceRebelTie =
#(define-music-function  (dir) (ly:dir?)
#{
  \override  Tie.before-line-breaking  =
  #(lambda  (grob)
 (ly:grob-set-property!  grob 'direction dir)) #} )

ovA =\once  \tieDown ovB =\once \override  Tie.direction  = #DOWN ovC =\once  \forceRebelTie  #DOWN formA =\new  Staff  \with  {  instrumentName  ="All V1"  } << \new  Voice  \relative  c''{  \voiceOne  b~  4 4~  4 4~  4} >> formB =\new  Staff  \with  {  instrumentName  ="1V V1"  } << \new  Voice  \relative  c''{  b~  \voiceOne  4  \oneVoice  4~  \voiceOne  4  \oneVoice  4~  \voiceOne  4  } >> controlA =\new  Staff  \with  {  instrumentName  ="No EE"  } << \new  Voice  \relative  c''{  \voiceOne  \ovA  b~  4 4~  4 4~  4  } >> controlB =\new  Staff  \with  {  instrumentName  ="No EE"  } << \new  Voice  \relative  c''{  \voiceOne  \ovB  b~  4 4~  4 4~  4  } >> controlC =\new  Staff  \with  {  instrumentName  ="No EE"  } << \new  Voice  \relative  c''{  \voiceOne  \ovC  b~  4 4~  4 4~  4  } >> \markup  "Results with \\tieDown" \editionMod  test1 0  Voice.A\ovA \editionMod  test1 0  Voice.B\ovA \score  { \new  StaffGroup  << \formA \formB \controlA >> } \markup  "Results with \\override Tie.direction" \editionMod  test1 0  Voice.D\ovB \editionMod  test1 0  Voice.E\ovB \score  { \new  StaffGroup  << \formA \formB \controlB >> } \markup  "Results with ly:grob-set-property!" \editionMod  test1 0  Voice.G\ovC \editionMod  test1 0  Voice.H\ovC \score  { \new  StaffGroup  << \formA \formB \controlC >> } \markup  "No overrides (default behavior for comparison)" \score  { \new  StaffGroup  << \formA \formB >> } 



When \voiceOne is in full effect, both \once \tieDown and\once \override 
Tie.direction seem to have a permanent effect that kicks in after the 
moment they are used, which is exactly the opposite to what they should 
do (take effect only in the moment they are called and revert to the 
previous behavior after). This is very clear when you compare the All V1 
Staff with the No EE Staff: the All V1 behaves in the exact opposite way.


I have absolutely no idea about why this may be happening, but I'm 
certain that one should expect the EE to achieve the same results that 
manually writing the code in the desired place and moment would.


Hopefully Jan-Peter or someone more knowledgeable than I can look into it!

I hope this "research" can be useful!
Stéfano


___
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: can the leading \markup command be eliminated in a new markup command?

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
> Sorry if this is a silly question… but can this function be modified such 
> that the user can use
>
> { c''^\cue #"This is the cue." }
>
> instead of
>
> { c''^\markup \cue #"This is the cue." }
>

%%%  SNIPPET BEGINS
\version "2.19.80"

cue =
#(define-event-function (text) (markup?)
  #{ ^\markup \bold #text #})

{ c''\cue "This is the cue." }
%%%  SNIPPET ENDS

If you don't want to bake the direction in, use - instead of ^ .

-- 
David Kastrup

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

Accessing grobs generated by a music event?

[Stefano Troncaro]

Hello everyone,

I was wondering, is there a way to, given a 'NoteEvent (or 'EventChord, or
whatever other music expression for that matter) find the grob or grobs
that it generates?

Although I don't know how Lilypond actually processes input, I suspect that
this isn't possible. I imagine that if a function is getting passed the
events then they have not been translated into grobs yet, and if they have
then I imagine that functions in the input have already been processed at
this point. But I don't really know, so I'd rather ask.

So, more concretely, say that in the following:

\relative c' {
  c d \something e f
}

Is it possible for `\something`, a music function that is receiving the
note e as its argument (of type `ly:music?`), to get to the grob generated
by that e and store a reference to it in a variable?

So, something among the lines of

something =
#(define-music-function (e-note) (ly:music?)
   (let ((e-notehead-grob (???magic-proc??? e-note)))
 (display e-notehead-grob)
 e-note))

I am curious as to whether this has a solution or not.

Thank you in advance!
Stéfano
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user