Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[N. Andrew Walsh]

Actually, coverting between the ratios and semitones has alread been done,
as there's a simple set of log and mround functions that do it. Have a look
in the OLL repository under notation-tools and you should find the .ily
files.

Cheers,

A

On Sun, Dec 13, 2015 at 7:51 AM,  wrote:

> On Sat, 12 Dec 2015, N. Andrew Walsh wrote:
> > accidentals as needed. I suppose, rather than having Lily/Scheme
> calculate
> > prime factors on the fly at runtime, it would be easier to have a lookup
> > table of the prime factorization for each integer up to a certain limit
> (but
> > that would end up being very high, so maybe not). That's a computational
> > problem for further down the road, though.
>
> For numbers of 32 bits or so, doing prime factorization by simple-minded
> trial and error on a present-day computer is cheaper than most people
> realize.  It's a tight loop that fits in cache; the arithmetic may
> actually be faster than a lookup table in main memory, and it's at least
> unlikely to be prohibitively slow.
>
> I think a trickier computational problem may be converting between
> LilyPond's "rational number of semitones" and just-intonation's "rational
> ratio of frequencies" ways to express pitch.  Because of the log function
> in between, in general any number that has a representation on one of
> those scales will have no exact representation on the other, and you're
> forced to do some kind of rounding, or maybe abandon LilyPond's pitch
> scheme for something else.  Have you decided how you want to deal with
> this issue yet?
>
> --
> Matthew Skala
> msk...@ansuz.sooke.bc.ca People before principles.
> http://ansuz.sooke.bc.ca/
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[mskala]

On Sat, 12 Dec 2015, N. Andrew Walsh wrote:
> accidentals as needed. I suppose, rather than having Lily/Scheme calculate
> prime factors on the fly at runtime, it would be easier to have a lookup
> table of the prime factorization for each integer up to a certain limit (but
> that would end up being very high, so maybe not). That's a computational
> problem for further down the road, though.

For numbers of 32 bits or so, doing prime factorization by simple-minded
trial and error on a present-day computer is cheaper than most people
realize.  It's a tight loop that fits in cache; the arithmetic may
actually be faster than a lookup table in main memory, and it's at least
unlikely to be prohibitively slow.

I think a trickier computational problem may be converting between
LilyPond's "rational number of semitones" and just-intonation's "rational
ratio of frequencies" ways to express pitch.  Because of the log function
in between, in general any number that has a representation on one of
those scales will have no exact representation on the other, and you're
forced to do some kind of rounding, or maybe abandon LilyPond's pitch
scheme for something else.  Have you decided how you want to deal with
this issue yet?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: Noteheads slightly too large

[David Wright]

On Sat 12 Dec 2015 at 09:47:18 (+0100), David Kastrup wrote:
> David Wright  writes:
> 
> > Excuse my top-posting, but is there any context for this message?
> > http://lists.gnu.org/archive/html/lilypond-user/2015-12/msg00296.html
> > is no help either. It *might* be helpful to be able to see the
> > Message-ID and In-Reply-To for the postings there, but the list
> > administrators seem more interested in displaying
> > User-agent:Microsoft-MacOutlook/0.0.0.151105
> > in which I have absolutely no interest.
> 
> Shrug.  _Your_ mail contains
> 
> Message-ID: <20151212052418.GA966@alum>
> References: <1449833831278-184659.p...@n5.nabble.com> <566b5607.20...@mail.de>
>   <566b5f8d.8060...@openlilylib.org>
>   <37898cee-3a56-49ea-9f5c-46da34a16...@gmail.com>
> 
> headers.  So at least your user agent is perfectly aware of the context
> of this message.  Why it would not pass this knowledge on to you, I have
> no idea.

As you know, my MUA is mutt, and typing h reveals the header
information on any email. Naturally, I searched for the strings above
in Google, but none of them is known to it, even the gmail one. I also
tried Googling for the string "why not exceed the lower staff line also",
but no match there either. Nor for "least I recall speaking someone
from a major publishing house" copied from Urs's posting.

So perhaps you could tell me whether I'm using the wrong tools to search
for the message context† in this mailing list (fairly new to me) which
appears not to be indexed on the web. Is there a "go to" archive other than
http://lists.gnu.org/archive/html/lilypond-user/2015-12/msg00296.html
that your MUA (having gnus in its name) perhaps knows about? On other
lists, I've got used to just typing, say, 20150910160748.GB8353@alum
into google and getting the relevant postings returned.

† by context, I mean "how I would get to *see these noteheads*", not
"how I would *follow a thread of machine-generated strings*".

Cheers,
David.

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

Re: Lower-case letter rehearsal marks

[Thomas Morley]

2015-12-13 0:16 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> Though, I thought about some sort of macro, doing the job like:
>>
>> %% the macro:
>> \simple-define-markup-command
>> %% the args:
>>   % name:
>>   bold-red
>>   % body:
>>   \bold \with-color #red \etc
>>
>> I think it would prevent some confusions.
>
> \etc is not a "body".  It's a "the last markup command is incomplete,
> defer to its signature for the types of the missing arguments" marker.
> And you have nothing in your "macro" that would actually switch the
> "body" into markup mode.  To me, that looks like being harder to explain
> to both compiler and user.

Harder to the compiler? Yes, not hard to imagine.
To the user? I'm not sure. But that's only me.

This is the user-list, though, other users could step in as well...


Cheers,
  Harm

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

Re: Lower-case letter rehearsal marks

[David Kastrup]

Thomas Morley  writes:

> Though, I thought about some sort of macro, doing the job like:
>
> %% the macro:
> \simple-define-markup-command
> %% the args:
>   % name:
>   bold-red
>   % body:
>   \bold \with-color #red \etc
>
> I think it would prevent some confusions.

\etc is not a "body".  It's a "the last markup command is incomplete,
defer to its signature for the types of the missing arguments" marker.
And you have nothing in your "macro" that would actually switch the
"body" into markup mode.  To me, that looks like being harder to explain
to both compiler and user.

-- 
David Kastrup

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

Re: accidentals for just intonation

[Urs Liska]

Am 12. Dezember 2015 16:38:13 MEZ, schrieb "N. Andrew Walsh" 
:
>Hi Paul,
>

...

>
>The system works like this:
>
>1) each accidental has a long thin vertical line: approximately 1
>staff-height,

This triggers a question: *where* do you want the accidental to be printed, at 
the usual accidental position or above the staff? And: does it work properly 
with non-monophonic music?

> though maybe slightly less or more depending on:

Urs

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

Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[Urs Liska]

Am 12. Dezember 2015 23:08:53 MEZ, schrieb Paul Morris :
>> On Dec 12, 2015, at 3:34 PM, Johan Vromans 
>wrote:
>> 
>> If I understand the procedure correctly, wouldn't it be easier to use
>a
>> tool like fontforge add/adjust font glyphs?
>
>Maybe so, but the result is less portable because (if I understand
>correctly) you'd have to have a custom font and have it installed
>correctly, etc. for anyone to be able to use the glyph...  as opposed
>to just having the custom glyphs in an include file that you’re going
>to be including anyway.  
>
>-Paul

I think the font idea *may* be an approach worth considering.

Our stuff will reside in a library anyway, and I think it should be possible to 
have that library call a font reliably when it is in the same directory IIRC.

We could then have a font with glyphs for each constituent of your accidentals 
and construct the actual accidental as a markup using \combine, which should be 
pretty straightforward.

Urs

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

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

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

Re: Extending staff lines through key change

[David Sumbler]

> > From: Cynthia Karl 
> > To: lilypond-user 
> > Subject: Extending staff lines through key change
> > Date: Sat, 12 Dec 2015 15:41:32 -0600
> > 
> > I’m engraving a piece that ends with a D.C. al Fine.  Also the key
> > at the beginning of the piece is different from the key at the end
> > of the piece.  So, in order to cue the performer, a final key change
> > is issued for the initial key:
> > 
> > 
> > \version "2.19.32"
> > 
> > 
> > { \relative c'' {
> > \key g\major
> > \repeat unfold 4 { c d e fis }
> > \break
> > 
> > 
> > 
> > \key f\major
> > \repeat unfold 4 { c d e f }
> > \mark\markup { D.C. }
> > \key g\major
> > } }
> > 
> > 
> > The problem with this is that the staff lines do not extend through
> > the final key change.  Is there a way do do this?

I had a similar problem, which was solved by adding a spacer rest after
the last complete bar:

c4 d e f \mark \markup { D.C. } \key g \major s16

David


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

Re: Lower-case letter rehearsal marks

[Thomas Morley]

2015-12-11 11:50 GMT+01:00 David Kastrup :

>> Having
>> \markup bold-red = <ẃhat-ever>
>> ,i.e. a definition might lead to confusions.
>
> The compiler isn't confused.  The question is more about the user.

Yep, that was exactly my concern.

>> Is it possible to create a sort-of-markup-macro to be used like:
>>
>> \sort-of-markup-macro sort-of-markup-macro-name = 
>>
>> instead?
>> (Just brain-storming)
>
> Uh, that went over my head.  Care to elaborate?  I cannot really fit the
> wildcard pieces here.

Well, still only brain-storming ...

(1) A step in my past

I remember as a starter with LilyPond I was a little confused that we
had a plethora of things like:

nameI = 
nameII = 
nameIII = 

Where  was a quite simple expression or a
music-function or ...

But markup-commands were different.
There was some define-thing then as argument the name and others.
(nowadays I could probably describe this a little better, but I'm
trying to recall my starter-thoughts).

And it lasted some time to sort it all.

(2) Your proposal: \markup bold-red = \bold \with-color #red \etc

If I'm not mistaken then this would define a valid markup-command with
the name 'bold-red.
In general it would allow to newly define markup-commands using
preexisting ones in an easy and userfriendly way.

Though, I thought about some sort of macro, doing the job like:

%% the macro:
\simple-define-markup-command
%% the args:
  % name:
  bold-red
  % body:
  \bold \with-color #red \etc

I think it would prevent some confusions.
Though it omitts the "="-sign, no idea whether it's possible or desirable.


Cheers,
  Harm

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

Re: Extending staff lines through key change

[tisimst]

Just add a "s8" after the key change.

HTH,
Abraham

On Saturday, December 12, 2015, Cynthia Karl [via Lilypond] <
ml-node+s1069038n184706...@n5.nabble.com> wrote:

> I’m engraving a piece that ends with a *D.C. al Fine*.  Also the key at
> the beginning of the piece is different from the key at the end of the
> piece.  So, in order to cue the performer, a final key change is issued for
> the initial key:
>
> \version "2.19.32"
>
> { \relative c'' {
> \key g\major
> \repeat unfold 4 { c d e fis }
> \break
>
>
> \key f\major
> \repeat unfold 4 { c d e f }
> \mark\markup { D.C. }
> \key g\major
> } }
>
> The problem with this is that the staff lines do not extend through the
> final key change.  Is there a way do do this?
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Extending-staff-lines-through-key-change-tp184706.html
> To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Extending-staff-lines-through-key-change-tp184706p184711.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Extending staff lines through key change

[Pierre Perol-Schneider]

Hi,

see a recent conversation:
http://lilypond.1069038.n5.nabble.com/WAS-Staff-ends-before-clef-time-and-key-td183976.html

HTH,
~Pierre

2015-12-12 22:41 GMT+01:00 Cynthia Karl :

> I’m engraving a piece that ends with a *D.C. al Fine*.  Also the key at
> the beginning of the piece is different from the key at the end of the
> piece.  So, in order to cue the performer, a final key change is issued for
> the initial key:
>
> \version "2.19.32"
>
> { \relative c'' {
> \key g\major
> \repeat unfold 4 { c d e fis }
> \break
>
>
> \key f\major
> \repeat unfold 4 { c d e f }
> \mark\markup { D.C. }
> \key g\major
> } }
>
> The problem with this is that the staff lines do not extend through the
> final key change.  Is there a way do do this?
>
> ___
> 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: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[Paul Morris]

> On Dec 12, 2015, at 3:34 PM, Johan Vromans  wrote:
> 
> If I understand the procedure correctly, wouldn't it be easier to use a
> tool like fontforge add/adjust font glyphs?

Maybe so, but the result is less portable because (if I understand correctly) 
you'd have to have a custom font and have it installed correctly, etc. for 
anyone to be able to use the glyph...  as opposed to just having the custom 
glyphs in an include file that you’re going to be including anyway.  

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

Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[N. Andrew Walsh]

It would not, because the accidentals I use are in an open system of just
intonation (not a fixed scale) in which *any* conceivable ratio can be
represented (so long as I have the module for its respective prime
factors). This is a serious limitation of a lot of systems, in that the
moment you start getting into primes above, say, 17 (or even to certain
combinations of them), there are no accidentals to represent them, and
you're back to using numbers in markups.

My endgame here is to make stencils for each prime factor up to 512 (so,
2^10, thus ten octaves, of which there are about 100 primes [which seems
felicitous]), so that you can represent any conceivable fraction up to a
ridiculous complexity, on the fly, within Lily.

In that context, it makes much more sense (so far as I can tell) to make
individual stencils for each prime, and then arrange them for the
accidentals as needed. I suppose, rather than having Lily/Scheme calculate
prime factors on the fly at runtime, it would be easier to have a lookup
table of the prime factorization for each integer up to a certain limit
(but that would end up being very high, so maybe not). That's a
computational problem for further down the road, though.

For now, I'll get to fiddling with Inkscape and trying to make some
stencils, so I can at least show what I'm talking about.

Cheers,

A

On Sat, Dec 12, 2015 at 9:34 PM, Johan Vromans  wrote:

> > Anyway, that’s how I’ve done this kind of thing.  It’s not simple but it
> > works!
>
> If I understand the procedure correctly, wouldn't it be easier to use a
> tool like fontforge add/adjust font glyphs?
>
> -- Johan
>
> ___
> 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: Controlling hairpin length

[Thomas Morley]

2015-12-12 22:35 GMT+01:00 Thomas Morley :
> 2015-12-12 17:46 GMT+01:00 David Sumbler :
>> Although I quite often find myself needing to use
>>
>> \override Voice.Hairpin.minimum-length = #2
>>
>> or similar, I find that the results are unpredictable (to me!)
>>
>> Sometimes I have a very short hairpin, perhaps starting on a quaver and
>> ending on the next quaver.  In the output such a hairpin sometimes
>> appears as a short vertical line (i.e. with length=0), and a warning is
>> shown in the compiler output.
>>
>> If I change Hairpin.minimum-length I have to do it by trial and error,
>> because the result does not seem necessarily to correspond to the value
>> I have specified.  (I am assuming that the units are staff spaces.)  I'm
>> guessing that this may perhaps be something to do with having an actual
>> dynamic such as mf attached to one or both notes.
>
> It's issue 2207
> https://sourceforge.net/p/testlilyissues/issues/2207/
>
>>
>> The Internals Reference says that use of the minimum-length property
>> with a hairpin "requires an appropriate callback for the
>> springs-and-rods property".  Unfortunately I have no clear idea what
>> this means, and I haven't managed to find out yet either by searching or
>> by experimentation.  The best I have come up with so far is
>>
>> \override Hairpin.springs-and-rods = #ly:spanner::set-spacing-rods
>
> This is already the default for Hairpins (but nor for Glissando par example)
> No need to set it again in your file.
>
>>
>> This doesn't improve the output at all, but at least it doesn't produce
>> any additional error or warning!
>>
>> How can I guarantee that all hairpins will be printed with a minimum
>> length of, say, 1.5 staff spaces, and the notes spaced appropriately,
>> regardless of preceding or following dynamics?
>
> You may find the discussion at the linked issue enlightning.
>
> For now you may try the following as a workaround.
> Though, please be aware it's not tested beyond the example, your turn ;)
> Ofcorse I'll try to improve the code, if you notice issues
>
> \version "2.18.2"

Sorry, this needs a more recent version.

>
> %% a helper:
> #(define (look-up-for-parent name-symbol axis grob)
> "Return the parent of @var{grob}, specified by it's @var{name-symbol} in
> axis @var{axis} or @var{grob}, if equal to the grob named @var{name-symbol}
> already.
> If not found, look up for the next parent."
>  (let* ((parent (ly:grob-parent grob axis)))
>  (cond
>((not (ly:grob? parent))
> (ly:error
>(_"Perhaps typing error for \"~a\" or \"~a\" is not in the 
> parent-tree.")
>name-symbol name-symbol))
>((equal? name-symbol (grob::name grob)) grob)
>((not (equal? name-symbol (grob::name parent)))
> (look-up-for-parent name-symbol axis parent))
>(else parent
>
> #(define ((hairpin-minimum-length my-minimum) grob)
>   (let* ((bound-left (ly:spanner-bound grob LEFT))
>  (bound-right (ly:spanner-bound grob RIGHT))
>  (sys (look-up-for-parent 'System Y grob))
>  (left-x-ext (ly:grob-extent bound-left sys X))
>  (right-x-ext (ly:grob-extent bound-right sys X)))
> (ly:grob-set-property! grob 'minimum-length
>   ;; keep 'minimum-length user-settable
>   (max (ly:grob-property-data grob 'minimum-length)
>;; nb, this calculation is only an approximation
>;; should work in most cases, though
>(+ my-minimum (abs (cdr left-x-ext)) (abs (cdr right-x-ext)))
>
> myHairpinMinimumLength =
> #(define-music-function (parser location minimum)(number?)
> #{
>   \override Hairpin.before-line-breaking =
> #(hairpin-minimum-length minimum)
> #})
>
> {
> \override Hairpin.color = #red
> \myHairpinMinimumLength #1.5
> \repeat unfold 8 { c4\\> d\\! c d \noBreak }
> \break
> %% overriding 'minimum-length is still possible
> \override Hairpin.minimum-length = 20
> \repeat unfold 8 { c4\\> d\\! c d \noBreak }
> }
>
>
>
> HTH,
>   Harm

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

Extending staff lines through key change

[Cynthia Karl]

I’m engraving a piece that ends with a D.C. al Fine.  Also the key at the 
beginning of the piece is different from the key at the end of the piece.  So, 
in order to cue the performer, a final key change is issued for the initial key:

\version "2.19.32"

{ \relative c'' {
\key g\major
\repeat unfold 4 { c d e fis }
\break

\key f\major
\repeat unfold 4 { c d e f }
\mark\markup { D.C. }
\key g\major
} }

The problem with this is that the staff lines do not extend through the final 
key change.  Is there a way do do this?___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: problem adding \epsfile to markup

[Thomas Morley]

2015-12-12 21:41 GMT+01:00 Pierre Perol-Schneider
:
> Hi Harm,
>
> 2015-12-06 0:44 GMT+01:00 Thomas Morley :
>>
>> 2015-12-05 21:49 GMT+01:00 Pierre Perol-Schneider
>> :
>> > Hi Ryan,
>> > The attached file seems to do the job.
>> > Cheers,
>> > Pierre
>>
>> @Pierre
>> How did you create the file?
>> If I manually delete the non-UTF-characters, it sort of works, though
>> I think you did something using cairo, the BoundingBox is changed a
>> little, though.
>
>
> Sorry for the late reply, I thought I answerd "to all".
> Here's a copy :
>
> 2015-12-05 22:34 GMT+01:00 Pierre Perol-Schneider
> :
>>
>> Hi Ryan
>> I used Inkscape here. Simply import and save.
>> Actually, I never use postscript files in my scores.
>> I'd do :
>>
>> \version "2.18.2"
>>
>> niolin = \markup
>>   \path #0.2
>> #'((moveto   0.05   2.10)
>>(curveto  3.50   2.80  5.45  2.70  5.75  1.80)
>>(curveto  6.10   1.00  6.30  0.40  7.03  0.13)
>>(curveto  7.20   0.80  7.55  1.35  8.10  1.35)
>>(curveto  9.00   1.35  9.50  0.15  9.90  0.15))
>>
>> {
>>a \harmonic\glissando^\niolin
>> }
>>
>> Personal choice...
>>
>> HTH,,
>> Pierre
>
>
> Cheers,
> Pierre
>
>

So you recreated the code using third-party software, I hoped you
found a direct method.

Cheers,
  Harm

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

Re: Controlling hairpin length

[Simon Albrecht]

On 12.12.2015 17:46, David Sumbler wrote:

Although I quite often find myself needing to use

\override Voice.Hairpin.minimum-length = #2

or similar, I find that the results are unpredictable (to me!)


You’re not alone with the problem: 
…


Yours, Simon

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

Re: Controlling hairpin length

[Thomas Morley]

2015-12-12 17:46 GMT+01:00 David Sumbler :
> Although I quite often find myself needing to use
>
> \override Voice.Hairpin.minimum-length = #2
>
> or similar, I find that the results are unpredictable (to me!)
>
> Sometimes I have a very short hairpin, perhaps starting on a quaver and
> ending on the next quaver.  In the output such a hairpin sometimes
> appears as a short vertical line (i.e. with length=0), and a warning is
> shown in the compiler output.
>
> If I change Hairpin.minimum-length I have to do it by trial and error,
> because the result does not seem necessarily to correspond to the value
> I have specified.  (I am assuming that the units are staff spaces.)  I'm
> guessing that this may perhaps be something to do with having an actual
> dynamic such as mf attached to one or both notes.

It's issue 2207
https://sourceforge.net/p/testlilyissues/issues/2207/

>
> The Internals Reference says that use of the minimum-length property
> with a hairpin "requires an appropriate callback for the
> springs-and-rods property".  Unfortunately I have no clear idea what
> this means, and I haven't managed to find out yet either by searching or
> by experimentation.  The best I have come up with so far is
>
> \override Hairpin.springs-and-rods = #ly:spanner::set-spacing-rods

This is already the default for Hairpins (but nor for Glissando par example)
No need to set it again in your file.

>
> This doesn't improve the output at all, but at least it doesn't produce
> any additional error or warning!
>
> How can I guarantee that all hairpins will be printed with a minimum
> length of, say, 1.5 staff spaces, and the notes spaced appropriately,
> regardless of preceding or following dynamics?

You may find the discussion at the linked issue enlightning.

For now you may try the following as a workaround.
Though, please be aware it's not tested beyond the example, your turn ;)
Ofcorse I'll try to improve the code, if you notice issues

\version "2.18.2"

%% a helper:
#(define (look-up-for-parent name-symbol axis grob)
"Return the parent of @var{grob}, specified by it's @var{name-symbol} in
axis @var{axis} or @var{grob}, if equal to the grob named @var{name-symbol}
already.
If not found, look up for the next parent."
 (let* ((parent (ly:grob-parent grob axis)))
 (cond
   ((not (ly:grob? parent))
(ly:error
   (_"Perhaps typing error for \"~a\" or \"~a\" is not in the parent-tree.")
   name-symbol name-symbol))
   ((equal? name-symbol (grob::name grob)) grob)
   ((not (equal? name-symbol (grob::name parent)))
(look-up-for-parent name-symbol axis parent))
   (else parent

#(define ((hairpin-minimum-length my-minimum) grob)
  (let* ((bound-left (ly:spanner-bound grob LEFT))
 (bound-right (ly:spanner-bound grob RIGHT))
 (sys (look-up-for-parent 'System Y grob))
 (left-x-ext (ly:grob-extent bound-left sys X))
 (right-x-ext (ly:grob-extent bound-right sys X)))
(ly:grob-set-property! grob 'minimum-length
  ;; keep 'minimum-length user-settable
  (max (ly:grob-property-data grob 'minimum-length)
   ;; nb, this calculation is only an approximation
   ;; should work in most cases, though
   (+ my-minimum (abs (cdr left-x-ext)) (abs (cdr right-x-ext)))

myHairpinMinimumLength =
#(define-music-function (parser location minimum)(number?)
#{
  \override Hairpin.before-line-breaking =
#(hairpin-minimum-length minimum)
#})

{
\override Hairpin.color = #red
\myHairpinMinimumLength #1.5
\repeat unfold 8 { c4\\> d\\! c d \noBreak }
\break
%% overriding 'minimum-length is still possible
\override Hairpin.minimum-length = 20
\repeat unfold 8 { c4\\> d\\! c d \noBreak }
}



HTH,
  Harm

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

Re: problem adding \epsfile to markup

[Pierre Perol-Schneider]

Hi Harm,

2015-12-06 0:44 GMT+01:00 Thomas Morley :

> 2015-12-05 21:49 GMT+01:00 Pierre Perol-Schneider
> :
> > Hi Ryan,
> > The attached file seems to do the job.
> > Cheers,
> > Pierre
>
> @Pierre
> How did you create the file?
> If I manually delete the non-UTF-characters, it sort of works, though
> I think you did something using cairo, the BoundingBox is changed a
> little, though.
>

Sorry for the late reply, I thought I answerd "to all".
Here's a copy :

2015-12-05 22:34 GMT+01:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> Hi Ryan
> I used Inkscape here. Simply import and save.
> Actually, I never use postscript files in my scores.
> I'd do :
>
> \version "2.18.2"
>
> niolin = \markup
>   \path #0.2
> #'((moveto   0.05   2.10)
>(curveto  3.50   2.80  5.45  2.70  5.75  1.80)
>(curveto  6.10   1.00  6.30  0.40  7.03  0.13)
>(curveto  7.20   0.80  7.55  1.35  8.10  1.35)
>(curveto  9.00   1.35  9.50  0.15  9.90  0.15))
>
> {
>a \harmonic\glissando^\niolin
> }
>
> Personal choice...
>
> HTH,,
> Pierre
>

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

Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[Johan Vromans]

> Anyway, that’s how I’ve done this kind of thing.  It’s not simple but it
> works!

If I understand the procedure correctly, wouldn't it be easier to use a
tool like fontforge add/adjust font glyphs?

-- Johan

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

converting svg glyph to path data for use in scheme (was: accidentals for just intonation)

[Paul Morris]

Hi Andrew,

> On Dec 12, 2015, at 10:38 AM, N. Andrew Walsh  
> wrote:
> 
> I've been doing some background work on my just-intonation accidentals, and I 
> was hoping you could give me some advice on the svg-to-path translation. I 
> know what the stencils should look like, but I'm not sure about things like 
> scaling (how many units high or wide should a stencil have if it's 
> equivalent, say, to the thick bars in a sharp sign?), and what the best 
> procedure might be for drawing them. Could you give me some advice/help? 
> 
> I think this is going to be geared towards adding into the OLL repository as 
> part of the "contemporary notation" extensions, so probably aimed at the dev 
> branch. So I'll see about the make-path-stencil (are you sure it's that and 
> not the "make-connected-path-stencil" I see in the LSR?).


Here’s what I’d suggest for going from an svg to a path from my experience with 
doing this.  

You can create a simple .ly file with a few notes and accidentals, then render 
it to SVG and open that SVG in Inkscape.  Then use Inkscape to draw your 
accidentals (or parts of accidentals) so they look good next to the notes and 
standard accidentals.  Having the default notes, accidentals, staff, in the SVG 
will help you get it at approximately the right scale.  (Although this may not 
matter, you will probably have to change the scaling later anyway…  I can’t 
remember for sure.)

Cut and paste your shape into a separate Inkscape SVG file and export/save as a 
plain SVG.  I found that I had to horizontally flip the shape in Inkscape first 
because svgs from Inkscape apparently come out reversed for some reason.  So 
you may need to do that.

Open that SVG file in a text editor and find the path data.  It should look 
something like this (a custom whole note glyph I made):



Working with this is the tedious part…  You can take out the parts you don’t 
need.  Here’s the part you do need:

d="m 304.96006,540.93655 c 11.66747,0 16.5678,6.05308 16.5678,16.78715 
0,18.43458 -14.00096,28.9213 -32.43555,28.9213 -11.66747,0 -16.33444,-6.05308 
-16.33444,-16.78715 0,-18.43458 13.7676,-28.9213 32.20219,-28.9213 z m 
-66.27119,22.85423 c 0,10.03402 7.93387,17.50119 17.0345,22.40152 
12.60086,6.76713 27.06851,9.33397 41.30282,9.33397 14.23429,0 28.9353,-2.56684 
41.53616,-9.33397 9.10063,-4.90033 17.0345,-12.3675 17.0345,-22.40152 
0,-10.03402 -7.93387,-17.5012 -17.0345,-22.40153 -12.60086,-6.76713 
-27.30186,-9.33397 -41.53616,-9.33397 -14.23431,0 -28.70196,2.56684 
-41.30282,9.33397 -9.10063,4.90033 -17.0345,12.36751 -17.0345,22.40153 z"

You can manually reformat that so it is easier to read and then use something 
like
http://petercollingridge.appspot.com/svg_transforms 

to transform the path in various ways. 

For example the following is scaled using "scale(0.016, 0.016)" and converted 
to absolute coordinates.  It may help to look up "SVG path" on the web to get 
familiar with the commands C c M m z and the possible transformations, etc.



You might want to shift / translate it so it is snug to (0,0) with 
“translate(x, y)” where x and y are the inverse of the smallest X and Y values 
in the path.  (I did this, but it may not be necessary…)

Now you have a path that can be used by “make-path-stencil”.  It will look 
something like the following as embedded scheme in a LilyPond file:

#(define whole-note-outline
'(M 0 0
   C 0 0.16054432 0.12694192 0.28001904 0.272552 0.35842432
   C 0.47416576 0.4666984 0.70564816 0.50776784 0.93339712 0.50776784
   C 1.16114576 0.50776784 1.39636192 0.4666984 1.59797568 0.35842432
   C 1.74358576 0.28001904 1.87052768 0.16054432 1.87052768 0
   C 1.87052768 -0.16054432 1.74358576 -0.2800192 1.59797568 -0.35842448
   C 1.39636192 -0.46669856 1.16114592 -0.507768 0.93339712 -0.507768
   C 0.70564816 -0.507768 0.47416576 -0.46669856 0.272552 -0.35842448
   C 0.12694192 -0.2800192 0 -0.16054432 0 0
   z))

Then you can use it like so:

  (make-path-stencil whole-note-outline 0.0001 1 1 #t)

in the scheme code you’re using to override the accidental glyphs.  The 
arguments are:

(make-path-stencil 
path-data-list 
thickness-of-path-line
x-scale-factor 
y-scale-factor 
filled-or-not)

(Oh, and yes make-path-stencil is what I'd use if you’re targeting 2.19 or 
higher.  The make-connected-path-stencil procedure is similar but more limited. 
 make-path-stencil is not in the LSR yet...)

To get the scaling right is basically a trial and error dance.  Use the scale 
factor arguments to test until you’ve got it right, then go back and scale the 
path data itself with those values so it’s the correct size to start with.  
(You could go back to Inkscape and scale there if you prefer…)

…so you’ll need some scheme code for overriding the standard accidental 
stencils with your path stencils.  (It might make sense to just create some 
simple line stencils in scheme, as a kind of

Controlling hairpin length

[David Sumbler]

Although I quite often find myself needing to use

\override Voice.Hairpin.minimum-length = #2

or similar, I find that the results are unpredictable (to me!)

Sometimes I have a very short hairpin, perhaps starting on a quaver and
ending on the next quaver.  In the output such a hairpin sometimes
appears as a short vertical line (i.e. with length=0), and a warning is
shown in the compiler output.

If I change Hairpin.minimum-length I have to do it by trial and error,
because the result does not seem necessarily to correspond to the value
I have specified.  (I am assuming that the units are staff spaces.)  I'm
guessing that this may perhaps be something to do with having an actual
dynamic such as mf attached to one or both notes.

The Internals Reference says that use of the minimum-length property
with a hairpin "requires an appropriate callback for the
springs-and-rods property".  Unfortunately I have no clear idea what
this means, and I haven't managed to find out yet either by searching or
by experimentation.  The best I have come up with so far is

\override Hairpin.springs-and-rods = #ly:spanner::set-spacing-rods

This doesn't improve the output at all, but at least it doesn't produce
any additional error or warning!

How can I guarantee that all hairpins will be printed with a minimum
length of, say, 1.5 staff spaces, and the notes spaced appropriately,
regardless of preceding or following dynamics?

David


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

Re: accidentals for just intonation

[N. Andrew Walsh]

Hi Paul,

thanks for getting back to me. To update the list: I'm working on making a
set of stencils (using the various svg-to-path functions that Lily and the
snippets repository have), which will then be used by the just-intonation
toolset Urs is working on to build custom accidentals from individual
stencils on the fly.

The way that system would work is complicated, and based on fundamentally
different design principles than conventional accidentals (or any of the
usual variants used for music in just intonation, including Helmholtz, Ben
Johnson's set, or [I suspect] any others). I want to reiterate: I'm not
looking to be convinced of why some *other* system of accidentals is better
(for whatever metric one might use to measure "better"), but rather want to
see what's involved in getting the system I use to engrave properly within
Lily.

The system works like this:

1) each accidental has a long thin vertical line: approximately 1
staff-height, though maybe slightly less or more depending on:
2) any number of smaller stencils, each approximately as wide as a normal
accidental. Each of these corresponds to a prime number
3) the number and arrangement of those smaller stencils is determined by
the prime factorization of the numerator and denominator of the fraction
that makes up the harmonic ratio.

So, I suspect the thin vertical line needs no stencil, as it's easy enough
to draw on the fly. But the smaller stencils are more efficiently drawn as
stencils beforehand (rather than drawing a path each time), especially
since their placement depends on things like collision avoidance.

Paul says he can give me tips on drawing the stencils. I can fire up
Inkscape, but where do I start? How large should the shape be?

Thanks in advance for the help.

Cheers,

A

On Sat, Dec 12, 2015 at 3:27 PM, Paul Morris  wrote:

> Hi Andrew,
>
> Glad to share what I know about svg-to-path work.  Could we continue the
> discussion on the user list so that it’s public for others to benefit from,
> and/or chime in?  If that works for you, would you re-send your message
> below to the user list and I’ll reply there?
>
> Cheers,
> -Paul
>
>
> On Dec 11, 2015, at 8:57 AM, N. Andrew Walsh 
> wrote:
>
> Hi Paul,
>
> I've been doing some background work on my just-intonation accidentals,
> and I was hoping you could give me some advice on the svg-to-path
> translation. I know what the stencils should look like, but I'm not sure
> about things like scaling (how many units high or wide should a stencil
> have if it's equivalent, say, to the thick bars in a sharp sign?), and what
> the best procedure might be for drawing them. Could you give me some
> advice/help?
>
> I think this is going to be geared towards adding into the OLL repository
> as part of the "contemporary notation" extensions, so probably aimed at the
> dev branch. So I'll see about the make-path-stencil (are you sure it's that
> and not the "make-connected-path-stencil" I see in the LSR?).
>
> Cheers,
>
> A
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Noteheads slightly too large

[Andrew Bernard]

Oh, so sorry - the original message I now see was on the lilypond bug
list, not the lilypond user list to which I have incorrectly replied.
Apologies for the mistake,

Andrew

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

Re: Noteheads slightly too large

[David Kastrup]

David Wright  writes:

> Excuse my top-posting, but is there any context for this message?
> http://lists.gnu.org/archive/html/lilypond-user/2015-12/msg00296.html
> is no help either. It *might* be helpful to be able to see the
> Message-ID and In-Reply-To for the postings there, but the list
> administrators seem more interested in displaying
> User-agent:Microsoft-MacOutlook/0.0.0.151105
> in which I have absolutely no interest.

Shrug.  _Your_ mail contains

Message-ID: <20151212052418.GA966@alum>
References: <1449833831278-184659.p...@n5.nabble.com> <566b5607.20...@mail.de>
<566b5f8d.8060...@openlilylib.org>
<37898cee-3a56-49ea-9f5c-46da34a16...@gmail.com>

headers.  So at least your user agent is perfectly aware of the context
of this message.  Why it would not pass this knowledge on to you, I have
no idea.

-- 
David Kastrup

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

Re: November font

[Andrew Bernard]

Hello All,

In discussion with the developer and some checks we have done, it appears that 
the issue lies with Adobe Acrobat rendering on Mac OS X El Capitan. Using 
Preview on the Mac, everything is rendered nicely. It also renders fine on 
Document Viewer in Linux. I am pleased to report therefore that there do not 
appear to be issues with the font itself.

As the creators and custodians of PDF as a format, one would expect Adobe’s own 
Acrobat to get things right, but apparently not in this case.

Andrew


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