Re: for Jay Anderson: solution to "MergeFonts: Can't find font: feta11.pfb" problem

[Jay Anderson]

On Tue, Jul 4, 2017 at 6:53 AM, Federico Bruni  wrote:

> Jay,
>
> today I've stumbled upon the same problem you reported here:
> http://lilypond.1069038.n5.nabble.com/Building-issues-lilypo
> nd-and-docs-td198696.html#a198786
>
> Context: I'm building a Fedora container which I'd like to make available
> as an alternative to current LilyDev.
> As I want to keep it as small as possible, I do not want to add all the
> packages that a "dnf builddep lilypond" would bring in. So I had to work
> out some dependencies not caught by lilypond configure. Should this be
> reported maybe?
>
> Actually it's only one dependency. In Fedora the package is called
> perl-Math-Complex.
>
> I found it out thanks to Alexander Kobel suggestion in the thread above,
> i.e. running `make build/mf/out/feta11.pfb`, which produced some output I
> can't find anymore but basically the message was:
>
> Can't locate Math/Trig.pm
>
> Installing perl-Math-Complex solved the problem and I could run make
> successfully.
>

I think it should be reported as a build-time bug. Feels like installing
the documented build dependencies should be sufficient. In any case, I've
moved on to using lilydev which has been working fine for me. And I've
re-installed my local operating system so I'm not sure I'd be able to
re-create the issue.

A lilydev like container would be very nice. Much more light-weight and
customizable than a full virtual machine. In bocca al lupo.

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

Re: Merge Rests Engraver

[Jay Anderson]

On Wed, May 17, 2017 at 2:01 AM, Trevor Daniels 
wrote:

>
> Did you register git-cl in your account at SourceForge and obtain a bearer
> token?
> See "Authorizing git-cl for the LilyPond issue tracker" as the next step
> in configuring git-cl
> in http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl


I copied in the wrong value. Fixed now. Tracker issue updated. Sorry about
that.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Merge Rests Engraver

[Jay Anderson]

https://codereview.appspot.com/321930043/

It was requested sometime last year that I attempt to get this into
lilypond proper this is my attempt. It creates a scheme module for putting
all of the merge rest functionality. I didn't see any precedent for this,
so let me know concerns. If this approach doesn't seem right (e.g. feel it
should be part of the rest engraver) I can either add a TODO to that effect
or I can drop this patch.

When running git-cl it failed to create a new ticket number to track the
issue (the instructions say I need to request access:
http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl#configuring-git_002dcl).
There is an existing issue (
https://sourceforge.net/p/testlilyissues/issues/1228/). Let me know what
more I need to do there. Thanks.

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

Re: Building issues (lilypond and docs)

[Jay Anderson]

On Fri, Dec 30, 2016 at 2:28 PM, Phil Holmes  wrote:
> Just for clarity.  RAM or disk?

In the VM:
- Disk: 14gb (4.2gb used).
- Memory: 4gb (after increasing from 2gb)

I started re-running the doc build about an hour ago. Neither disk nor
memory seem to be in danger of being used up.

-Jay

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

Building issues (lilypond and docs)

[Jay Anderson]

In response to this thread:
https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00679.html
I'm attempting to build lilypond.

When building locally (an older version of mint linux) it ends with:

make[1]: Entering directory `/home/jay/programming/lilypond/build/mf'
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
make[1]: Leaving directory `/home/jay/programming/lilypond/build/mf'
make[1]: Entering directory `/home/jay/programming/lilypond/build/mf'
/home/jay/programming/lilypond/build/scripts/build/out/gen-emmentaler-scripts
--dir=./out --design-size=11
cd ./out && /usr/bin/fontforge -script emmentaler-11.genpe
Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
 License GPLv3+: GNU GPL version 3 or later 
 with many parts BSD . Please read LICENSE.
 Based on sources from 01:49 UTC 13-Oct-2016-ML-D.
 Based on source from git with hash: fe1d84b7d05178885a36ba0adce0559a82a493d5
Cannot open /home/jay/programming/lilypond/build/mf/out/feta11.pfb
The requested file, feta11.pfb, does not exist
MergeFonts: Can't find font: feta11.pfb
Called from...
 emmentaler-11.genpe: line 17
make[1]: *** [out/emmentaler-11.otf] Error 1
make[1]: Leaving directory `/home/jay/programming/lilypond/build/mf'
make: *** [all] Error 2

Sure enough it looks like feta11.pfb wasn't built. What should I look
at to see why it wasn't built?

Moving on from that I tried using lilydev and it builds fine in the
virtual machine, but when attempting `make doc` it ran for days on the
learning manual before I killed it. I gave the virtual machine 2gb to
work with. I'm going to try upping that to 4gb before trying again. Is
there anything else to look at here?

Thanks.

-Jay

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

Re: OpenType Features

[Jay Anderson]

On Sun, Jan 31, 2016 at 6:52 AM, Simon Albrecht  wrote:
> It definitely looks like a good way to go, except that I wouldn’t know how
> to use multiple features at the same time. Would it be possible to input
> font-features as a symbol list, i.e. (random example)
> { \override TextScript.font-features = onum.smcp 4-"foo" }
> ossia
> \markup { \override #'(font-features . (onum smcp)) "foo" } ?
> Or at least as a list of strings.

Right they can be combined as a string:

\markup { \override #'(font-features . "onum,smcp") { Hello 0123456789 } }

But this isn't especially flexible or obvious with regards to
combining features (like you said). I'll think about your other
suggestions. Thanks.

-Jay

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

Re: OpenType Features

[Jay Anderson]

On Mon, Jan 18, 2016 at 10:37 AM, Jay Anderson <horndud...@gmail.com> wrote:
> On Mon, Jan 18, 2016 at 9:59 AM, Jay Anderson <horndud...@gmail.com> wrote:
>> First issue: It appears that lilypond is dependent on pango 1.6
>> (pangoft2 - required 1.6.0, INSTALL.txt says pango 1.12 or newer so
>> I'm not totally sure what to believe.). OpenType features were added
>> in pango 1.18 (assuming I'm reading this correctly:
>> https://developer.gnome.org/pango/unstable/api-index-1-18.html). Are
>> there known issues with making this the new minimum version?
>
> I was a little wrong here. Those OpenType feature methods are
> deprecated. The supported way to set them is through PangoAttributes
> using the PANGO_ATTR_FONT_FEATURES attribute type
> (https://developer.gnome.org/pango/unstable/pango-Text-Attributes.html#PangoAttrType).
> This was added in 1.38 which was released in 2015 September
> (https://github.com/GNOME/pango/releases/tag/1.38.0). This is rather
> new (newer than my operating system includes - 1.36.3). So the minimum
> version would need to be _much_ newer than 1.18.

An update for those interested. I got something working. The attached
patch is certainly not ready to be merged, but I'm curious if the
chosen interface seems reasonable (see smallcaps.ly which is
attached). It adds a new 'font-features' property to the
font-interface (at least that's what I think I'm doing
http://www.lilypond.org/doc/v2.18/Documentation/internals/font_002dinterface).

This is using a method from pango 1.38. I'm not sure this issues
surrounding using such a new version. (It's newer than the version
included in ubuntu 15.10 for instance.)

I haven't tested it much yet, but I'm pleased with the output (tested
with Cardo - http://scholarsfonts.net/cardofnt.html).

Thanks!

-Jay
From 51b2a6eacacf32b7adca130ebd9243ca72cbde8e Mon Sep 17 00:00:00 2001
From: Jay Anderson <horndud...@gmail.com>
Date: Sat, 30 Jan 2016 22:45:32 -0700
Subject: [PATCH] Initial work to support opentype font features.

---
 lily/font-interface.cc   |  1 +
 lily/font-metric.cc  |  4 +++-
 lily/include/font-metric.hh  |  4 +++-
 lily/include/modified-font-metric.hh |  2 +-
 lily/include/pango-font.hh   |  4 +++-
 lily/modified-font-metric.cc |  8 +---
 lily/pango-font.cc   | 14 +-
 lily/text-interface.cc   | 15 ++-
 scm/define-grob-properties.scm   |  1 +
 9 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/lily/font-interface.cc b/lily/font-interface.cc
index de787fd..5e5f18c 100644
--- a/lily/font-interface.cc
+++ b/lily/font-interface.cc
@@ -72,4 +72,5 @@ ADD_INTERFACE (Font_interface,
"font-series "
"font-shape "
"font-size "
+   "font-features "
   );
diff --git a/lily/font-metric.cc b/lily/font-metric.cc
index f2b6a0e..6236a87 100644
--- a/lily/font-metric.cc
+++ b/lily/font-metric.cc
@@ -147,7 +147,9 @@ Font_metric::sub_fonts () const
 
 Stencil
 Font_metric::text_stencil (Output_def *state,
-   const string&, bool) const
+   const string&,
+   bool,
+   const string&) const
 {
   (void) state;
 
diff --git a/lily/include/font-metric.hh b/lily/include/font-metric.hh
index d74c815..0e2d15c 100644
--- a/lily/include/font-metric.hh
+++ b/lily/include/font-metric.hh
@@ -47,7 +47,9 @@ public:
   // Return stencil for given string. output_state may be modified to
   // record the font.
   virtual Stencil text_stencil (Output_def *output_state,
-const string , bool music) const;
+const string ,
+bool music,
+const string _str) const;
 
   virtual string font_name () const;
   virtual size_t count () const;
diff --git a/lily/include/modified-font-metric.hh b/lily/include/modified-font-metric.hh
index c63c532..eab1836 100644
--- a/lily/include/modified-font-metric.hh
+++ b/lily/include/modified-font-metric.hh
@@ -26,7 +26,7 @@
 struct Modified_font_metric : public Font_metric
 {
 public:
-  Stencil text_stencil (Output_def *output_state, const string&, bool) const;
+  Stencil text_stencil (Output_def *output_state, const string&, bool, const string&) const;
   Real get_magnification () const;
 
   static SCM make_scaled_font_metric (Font_metric *fm, Real magnification);
diff --git a/lily/include/pango-font.hh b/lily/include/pango-font.hh
index ff5e630..eeaa4dd 100644
--- a/lily/include/pango-font.hh
+++ b/lily/include/pango-font.hh
@@ -59,7 +59,9 @@ public:
   Stencil pango_item_string_stencil (PangoGlyphItem const *) const;
 
   virtual Stencil text_stencil (Output_def *output_state,
-   

OpenType Features

[Jay Anderson]

I'm interested in seeing what it would take to add OpenType features
-- specifically old style number figures (onum) and small caps (smcp).

First issue: It appears that lilypond is dependent on pango 1.6
(pangoft2 - required 1.6.0, INSTALL.txt says pango 1.12 or newer so
I'm not totally sure what to believe.). OpenType features were added
in pango 1.18 (assuming I'm reading this correctly:
https://developer.gnome.org/pango/unstable/api-index-1-18.html). Are
there known issues with making this the new minimum version?

Any pointers on where to start in lilypond code? I'll look into this a
bit this afternoon.

This is the lilypond issue:
https://code.google.com/p/lilypond/issues/detail?id=1388 (What's the
new issue location? I couldn't find it in my quick searching and
lilypond still points to google code
(http://www.lilypond.org/bug-reports.html).

Thanks.

-Jay

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

Re: OpenType Features

[Jay Anderson]

On Mon, Jan 18, 2016 at 9:59 AM, Jay Anderson <horndud...@gmail.com> wrote:
> First issue: It appears that lilypond is dependent on pango 1.6
> (pangoft2 - required 1.6.0, INSTALL.txt says pango 1.12 or newer so
> I'm not totally sure what to believe.). OpenType features were added
> in pango 1.18 (assuming I'm reading this correctly:
> https://developer.gnome.org/pango/unstable/api-index-1-18.html). Are
> there known issues with making this the new minimum version?

I was a little wrong here. Those OpenType feature methods are
deprecated. The supported way to set them is through PangoAttributes
using the PANGO_ATTR_FONT_FEATURES attribute type
(https://developer.gnome.org/pango/unstable/pango-Text-Attributes.html#PangoAttrType).
This was added in 1.38 which was released in 2015 September
(https://github.com/GNOME/pango/releases/tag/1.38.0). This is rather
new (newer than my operating system includes - 1.36.3). So the minimum
version would need to be _much_ newer than 1.18.

-Jay

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

Re: BreathingSigns and automatic beams

[Jay Anderson]

On Mon, Jun 23, 2014 at 10:24 PM, David Kastrup d...@gnu.org wrote:
 You don't say which frustration.  You apparently want to have automatic
 beams across breath marks.  To me, that does not make a lot of sense.

Sorry, I took out too much context from the original message. It's
pretty common in horn music (etudes especially - probably other wind
music as well) for a breath mark to suggest a possible place to take a
breath. (It doesn't necessarily indicate a short pause or break.)
Perhaps lilypond's breathe isn't quite right for what I need. Here's
how the breath I'm wanting behaves:
- The mark generally doesn't affect the music spacing or beaming in any way.
- Horizontally it is at the end of a note's duration before the
following note (or possibly over a bar line in tight situations).
- Vertically it floats above beams and articulations, but below text
and tempo markings. Generally you don't see breath marks and slurs
together. I'm sure depending on the context it could go either inside
or outside the slur.

A regular text markup will get most of this except the horizontal
positioning. Maybe I'll play with that to see if I can make it work.

 But since the beam engraver sits at Voice level, that's sort of easy to
 cheat around:
 ...
 breathe = \new Voice \breathe
 ...
 Of course, this does not follow \voiceOne/\voiceTwo settings.

That's a creative workaround. For what I'm looking for there's only
one voice so this would work fine. Thanks.

-Jay

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

Re: BreathingSigns and automatic beams

[Jay Anderson]

On Tue, Jun 24, 2014 at 4:06 AM, Werner LEMBERG w...@gnu.org wrote:
 I fully understand what you say, and similar symbols are used for
 singers, too, however, I think this somehow contradicts what lilypond
 is intended to do: engraving well-formatted music.  It's not
 lilypond's job to imitate hand-written marks!  In other words, I want
 to see some *printed* editions with such entries so that we can adjust
 lilypond accordingly, if necessary.

* 
http://imslp.org/wiki/200_%C3%89tudes_nouvelles_m%C3%A9lodiques_et_progressives_pour_cor_(Alphonse,_Maxime)
- Book 4 #3 has some examples of breaths over bar lines (though it
isn't very consistent).

* http://imslp.org/wiki/Adagio_for_Horn_and_Piano,_Op.31_(Draeseke,_Felix)
- The solo part has breath marks. None right over the bar line.
(http://imslp.org/wiki/Romanze_for_Horn_and_Piano,_Op.32_(Draeseke,_Felix)
is similar)

* http://imslp.org/wiki/Nocturno,_Op.7_(Strauss,_Franz) - The breath
marks are quite small in this one.

* http://imslp.org/wiki/60_Etudes_for_Low-Horn,_Op.6_(Kopprasch,_Georg)
- In the Gumbert edition he uses two different marks to indicate short
quick breaths and bigger breaths. Many of these marks are directly
over a bar line (see #13).

-Jay

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

Re: BreathingSigns and automatic beams

[Jay Anderson]

On Wed, Mar 6, 2013 at 6:00 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
 Well, nowadays we have the 'collision-interfaces-property but adding
 breathing-sign-interface to it seems to have no effect.

 \version 2.17.12

 respectBS = {
   \override Beam #'collision-interfaces =
 #'(beam-interface
clef-interface
breathing-sign-interface
flag-interface
inline-accidental-interface
key-signature-interface
note-head-interface
octavate-eight-interface
stem-interface
time-signature-interface)
 }

 \relative c' {
   \respectBS
   c8 d e f b[ a \breathe g f]
 }

Reviving this old thread. I was trying to do this today and found the
same frustration. It looks like it requires a simple change to the
code:

=
diff --git a/lily/auto-beam-engraver.cc b/lily/auto-beam-engraver.cc
index 8b55b44..92bc796 100644
--- a/lily/auto-beam-engraver.cc
+++ b/lily/auto-beam-engraver.cc
@@ -353,7 +353,8 @@ void
 Auto_beam_engraver::acknowledge_breathing_sign (Grob_info /* info */)
 {
   check_bar_property ();
-  if (stems_)
+  bool breathBreaksBeam = to_boolean (get_property
(breathingSignBreaksBeam));
+  if (stems_  breathBreaksBeam)
 end_beam ();
 }

diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index ebfff6a..322db5f 100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -638,6 +638,7 @@ automatically when an output definition (a @code{\\score} or
   beamHalfMeasure = ##t

   autoBeaming = ##t
+  breathingSignBreaksBeam = ##t
   autoBeamCheck = #default-auto-beam-check

   completionFactor = #unity-if-multimeasure
diff --git a/scm/define-context-properties.scm
b/scm/define-context-properties.scm
index 2d38188..3e5510d 100644
--- a/scm/define-context-properties.scm
+++ b/scm/define-context-properties.scm
@@ -115,6 +115,7 @@ arguments, @var{context}, @var{dir} [start/@/stop
(-1 or 1)], and
 starts or stops the auto beam.)
  (autoBeaming ,boolean? If set to true then beams are generated
 automatically.)
+ (breathingSignBreaksBeam ,boolean? Indicates that a breathing
sign causes beams to break.)
  (autoCautionaries ,list? List similar to @code{autoAccidentals},
 but it controls cautionary accidentals rather than normal ones.  Both
 lists are tried, and the one giving the most accidentals wins.  In
=

Is this an appropriate approach? Ideally it'd be nice to give it a
list of things that cause beams to end (e.g. breathing sign, manual
beam, bar line, etc.).

-Jay

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

Re: [GLISS] non-timed or non-musical events z y

[Jay Anderson]

On Sat, Sep 22, 2012 at 3:07 PM, Graham Percival
gra...@percival-music.ca wrote:
 I have no problem with splitting \tempo into a \tempo_bpm and
 \tempoMark command.  Or perhaps it would be better to just use
 \mark, and add markup functions which mimic the text parts of
 the existing \tempo command (if they don't already exist, which
 they probably do).

Please keep \mark and \tempo separate. They serve different purposes,
align differently with the music, and it's a pain to put multiple
marks in one place. I think having multiple tempo commands would be
fine if it simplified the parser (with whatever capitalization you
like):
- \tempoText Allegro
- \tempoBpm 4=100
- \tempoTextBpm Allegro 4=100
- \tempoEquation 4=2 %%% print quarter note = half note
- \tempoTextEquation Lo stesso tempo 4=2

Even easier: \tempoBpm can take a string instead (e.g. \tempoBpm
4=100) which it internally parses and throws an error if it doesn't
like what it sees. At that point it could be 100% scheme instead of at
the parser level. The possible downside is we'd have a mini language
for this function, but I don't think that's too bad.

tempoBpm =
#(define-music-function (parser location text) (string?)
  (let* ((eq-index (string-contains text =))
 (parsed (log2 (string-number (string-trim (substring text 0
eq-index)
 (base (make-note-by-number-markup parsed 0 1))
 (bpm (string-trim (substring text (+ 1 eq-index
 (markup #{ \markup { \normal-text { \smaller $base = $bpm } } #}))
#{ \tempo $markup #}))

Obviously this would need to be expanded to handle errors, parse what
we currently support, and generate the midi tempo change. Would this
help clean things up with the tempo command?

-Jay

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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[Jay Anderson]

On Wed, Jan 4, 2012 at 1:41 AM, David Kastrup d...@gnu.org wrote:
 Can you use git bisect for identifying the commit where things go wrong
 for you?

Git bisect results:
20670d51f8d97fd390210dd239b3b2427f071e7c is the first bad commit
commit 20670d51f8d97fd390210dd239b3b2427f071e7c
Author: Mike Solomon m...@apollinemike.com
Date:   Fri Sep 30 08:16:07 2011 +0200

It looks like this was reverted and a revised version was committed
the next day: 4f49b000d6e257724e311b406e2346b8388c1f0e. I've verified
that the commit right before this doesn't cause a segfault and this
one does. The only other information I have that's relevant is that
I've only seen this segfault happen on my 64-bit OS and not 32-bit.

-Jay

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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[Jay Anderson]

On Tue, Jan 3, 2012 at 1:12 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
 On Jan 3, 2012, at 9:02 AM, David Kastrup wrote:
 If he hadn't rerun configure since before version 2.15.21, I think that
 the compilation would likely have failed for other reasons.  The problem
 report is for 2.15.23.  It may be worth for him to report the CXXFLAGS
 setting in config.status just to be on the safe side, but I consider it
 unlikely that this particular problem has not already been covered.


I pulled down lilypond and build new just last week.

CXXFLAGS in config.status is:
- With optimization (default): O2 -finline-functions -g -pipe
-fno-optimize-sibling-calls
- Without optimization: -g -pipe -fno-optimize-sibling-calls

 Are you using an optimized binary?  Mine is unoptimized.  Please try 
 ./autogen.sh --disable-optimizing before compiling and let me know if that 
 makes the segfault go away.

I found --disable-optimising instead. Same result.

I can't reproduce this on my wife's mac or on my laptop (also running
ubuntu 11.10). The only difference I can think of is I'm running
64-bit and my laptop is 32-bit. Unless someone else can reproduce this
issue don't spend much more time on this. I have a good solution
(adding in the dynamics). Thanks!

-Jay

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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[Jay Anderson]

On Mon, Jan 2, 2012 at 6:41 PM, Keith OHara k-ohara5...@oco.net wrote:
 mike at apollinemike.com mike at apollinemike.com writes:
 Some meh news: I don't get a segfault ...
 Maybe someone else could give it a look?

 I can't produce the segfault, either.

Strange I can consistently reproduce it (just pulled the latest and
recompiled): Ubuntu 11.10, gcc 4.6.1.

 When I put a debug print at span-bar-stub-engraver.cc:119
 and run your file (with the engraver re-enabled) I never reach that line!

Again odd. I put a printf (followed by a flush) and it is printed.

 Mike, Maybe it is the empty \new Dynamics {} inside the PianoStaff in Jay's
 score?  A print at line 109 shows that LilyPond is considering the empty
 Dynamics for inclusion in affected_contexts_.  Maybe we are testing
 de-allocated memory?

This may be right. I haven't filled in the dynamics yet (so it's still
empty), but adding spacer rests over the whole piece makes the
segfault and the added print go away. This is at least a better
solution than removing the engraver.

(I played around with this idea (empty dynamics) attempting to make a
small example without any luck though.)

Thank's for taking a look.

-Jay

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

Re: a starting point to 1301

[Jay Anderson]

2011/7/18 Janek Warchoł lemniskata.bernoull...@gmail.com:
 My friend and I, having some spare time, wanted to fix a bug
 http://code.google.com/p/lilypond/issues/detail?id=1301.  It's related
 to planning distribution of music notes and other signs, so we need
 some overview how the whole process works.  Comments in the source
 code are rare and in the documentation we couldn't find a word about
 it.  Where could we find some info?

This isn't mentioned on the bug report, but the workaround I usually
use for something like this is:

\override Score.NonMusicalPaperColumn #'allow-loose-spacing = ##f

If you manage to figure this bug out this will most likely no longer
be necessary.

-Jay

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

Re: Unable to remove dynamic line inside Dynamics

[Jay Anderson]

On Mon, Sep 13, 2010 at 8:03 AM, Jay Anderson horndud...@gmail.com wrote:
 On Sun, Sep 12, 2010 at 12:46 PM, Neil Puttock n.putt...@gmail.com wrote:
 Add the Tweak_engraver to the Dynamics context.

 Works fine. Thanks. This should probably be added to engraver-init.ly.
 Are there any problems with doing this?

 diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
 index 6a94777..4992cf3 100644
 --- a/ly/engraver-init.ly
 +++ b/ly/engraver-init.ly
 @@ -371,6 +371,7 @@ a collection of staves, with a bracket in front
 and spanning bar lin
   \consists Text_engraver
   \consists Text_spanner_engraver
   \consists Axis_group_engraver
 +  \consists Tweak_engraver

   pedalSustainStrings = #'(Ped. *Ped. *)
   pedalUnaCordaStrings = #'(una corda  tre corde)


This is a somewhat old request. Are there any known issues with adding
the Tweak_engraver to the Dynamics context? Thanks.

-Jay

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Question about 'back quote' in scheme markups within Documentation examples

[Jay Anderson]

On Wed, Jun 9, 2010 at 6:34 AM, James Lowe james.l...@datacore.com wrote:
 I wondered if anyone can tell me if this is a mistake or what the
 significance of the back-quote is vs the standard singe quote?

It is intentional. Look up scheme's quasiquote and unquote functions.

-Jay

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Why don't we get rid of \chordmode?

[Jay Anderson]

On Thu, Apr 29, 2010 at 1:53 PM, Neil Puttock n.putt...@gmail.com wrote:
 I'm afraid I couldn't resist testing this, so if you're interested,
 try the attached patch.

That's great! You might also want to include simultaneous music
(...*4). Thanks!

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Why don't we get rid of \chordmode?

[Jay Anderson]

On Wed, Apr 28, 2010 at 9:40 AM, Xavier Scheuer x.sche...@gmail.com wrote:
 Current syntax (using colons):

  c4:16 d4: e: f: |
  g: a: b: c: |  % etc.

 with \repeat tremolo:

  \repeat tremolo 4 c16 \repeat tremolo 4 d16
    \repeat tremolo 4 e16 \repeat tremolo 4 f16 |
  \repeat tremolo 4 g16 \repeat tremolo 4 a16
    \repeat tremolo 4 b16 \repeat tremolo 4 c16 |  % etc.


 So please, don't change current tremolo easiness.

I only use the repeat syntax even though it's more verbose. The ':'
syntax doesn't work with \unfoldRepeats and if for some reason I want
to change it to be written out in the future I just change 'tremolo'
to 'unfold'. Here are some functions I use to make them somewhat
easier to work with: http://lsr.dsi.unimi.it/LSR/Item?id=604.

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \context for named Staff

[Jay Anderson]

 Jay, Mark, anyone: are you interested in submitting a full patch, with
 appropriate documentation, NEWS item etc? If so, we can officially
 submit it for inclusion.

Attached is a patch which adds SmallStaff to engraver-init.ly.
Everywhere that \accepts Staff was used I just added \accepts
SmallStaff. Let me know if this looks good.

I've never tried to change the documentation so I'm not quite sure
where to start with that. Should there just be an entry in the 'news'
section? Should there be other content? Once I've tested my changes to
the docs I'll add that to the patch.

-Jay
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index ed7698e..cd17b2c 100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -87,6 +87,19 @@
 \context {
   \Staff
   \type Engraver_group
+  \name SmallStaff
+  \alias Staff
+
+  fontSize = #-3
+  \override StaffSymbol #'staff-space = #(magstep -3)
+
+  \description Creates a smaller staff for use with piano accompaniaments
+and other purposes.
+}
+
+\context {
+  \Staff
+  \type Engraver_group
   \name DrumStaff
   \alias Staff
 
@@ -120,6 +133,7 @@
   shortVocalName = #'()
 
   \accepts Staff
+  \accepts SmallStaff
   \accepts DrumStaff
   \accepts RhythmicStaff
   \accepts GrandStaff
@@ -294,6 +308,7 @@ contained staves are connected vertically.
 
   \defaultchild Staff
   \accepts Staff
+  \accepts SmallStaff
   \accepts FiguredBass
   \accepts Dynamics
 }
@@ -332,6 +347,7 @@ instrument names at the start of each system.
 
   \defaultchild Staff
   \accepts Staff
+  \accepts SmallStaff
   \accepts RhythmicStaff
   \accepts DrumStaff
   \accepts GrandStaff
@@ -505,6 +521,7 @@ automatically when an output definition (a @code{\score} or
 
   \accepts FretBoards
   \accepts Staff
+  \accepts SmallStaff
   \accepts RhythmicStaff
   \accepts TabStaff
   \accepts VaticanaStaff
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \context for named Staff

[Jay Anderson]

On Sat, Aug 8, 2009 at 12:57 PM, Dan Ebled...@faithful.be wrote:
 Doesn't this mix up meaning and appearance?  What will you do when people
 come asking for LargeStaff, TinyStaff, LittleGreenStaff (for Martian music),
 and so forth?

On Sat, Aug 8, 2009 at 1:45 PM, Alexander Kobeln...@a-kobel.de wrote:
 Oh, and by the way... No experience for this on my side, but are there
 scores with small rhythmic or drum staffs? Then we should probably also have
 a SmallRhythmicStaff, SmallDrumStaff, SmallVaticanaStaff and so on, right?

Hmm... I agree that it wouldn't make sense to define versions for
every different size (or color :) ) and to define resized versions of
every staff type out there. A global variable would probably work for
the size problem, but it's still somewhat ugly to have a version for
every staff type. The the generic SmallStaff is probably the most
common case though. So what do you think? Should the SmallStaff just
be left as a snippet?

If it is a snippet ideally I'd want to do something like:

\include small_staff.lyi
\score {
  \new SmallStaff {...}
}

How would one make small_staff.lyi so this worked? This way it would
be bundled with the other global variables. The only way I found was
to do this:

small_staff.lyi
=
\context {
  \Score
  \accepts SmallStaff
}
\context {
  \Staff
  \type Engraver_group
  \name SmallStaff
  \alias Staff

  fontSize = #-3
  \override StaffSymbol #'staff-space = #(magstep -3)
}
=
other.ly
=
\score {
  \new SmallStaff {...}
  \layout { \include small_staff.lyi }
}
=

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anchors in the music stream?

[Jay Anderson]

On Wed, Jul 22, 2009 at 9:05 AM, Kieren
MacMillankieren_macmil...@sympatico.ca wrote:
 Hello all,

 Like many Lilyponders, I break down my code into variables, e.g. global (for
 time signature changes, etc.), notes, dynamics, etc. The main irritation
 with this (IMO) is that each variable requires a complete set of skips in
 order to keep the timing accurate.

 Would it be technically feasible/possible to establish a system of anchors
 instead? That is, could we declare an anchor point in the global setup, and
 then refer to it in other code? e.g.

 global =
 {
  \time 4/4 s4*4*10
  \time 3/4 s4*3*5
  \time 7/4 s4*7
  \time 4/4 \anchor #'coda s4*4*10
  \bar |.
 }

 tempoChanges =
 {
  \tempo \markup Opening tempo
  \anchorTo #'coda \tempo \markup Extremely slow
 }

 ??

 Just a brainstorm from someone who doesn't understand the internals enough
 to immediately see the stupidity of this idea...  =)


That's a neat idea. It might be easier to do something like:

global =
{
 \time 4/4 s4*4*10
 \time 3/4 s4*3*5
 \time 7/4 s4*7
 \time 4/4 \anchor #'coda s4*4*10
 \bar |.
}

\addAt #'coda \global {\tempo \markup Extremely slow}

Then the addAt function could weave the tempo in at the correct point.
Though I'm not sure how easy this would be either.

=

I've thought about something similar before and I think anchors would
be a good syntax (I don't know about the internals) to make it work:

global = {s1*4 \anchor #'place s1*4}
part = \relative c' {c1 c c c \assertAt #'place c c c c \assertEnd}
anotherPart = \relative c' {e1 e e \assertAt #'place e e e e \assertEnd} %Error
\score {  \new Staff{  \global \part  } \new Staff{  \global
\anotherPart  }   }

This would work similar to bar checks. Errors would be thrown when the
anchor and assertion don't line up. I think this might be more
complicated than the above use.

In any case I think anchors could be very useful for a variety of purposes.

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)

[Jay Anderson]

On Mon, Jun 22, 2009 at 6:03 PM, Mark Poleskymarkpole...@yahoo.com wrote:
 I know, I know, I just won't let this die. I rewrote this silly
 function yet again (by now it's more of a programming exercise
 than anything else). But the things I've learned from everyone so
 far have found their way into my other LilyPond work, so I don't
 think it's a waste of time.

 I discovered 2 procedures from srfi-1 that can work in tandem for
 this: list-index and split-at. I'm left wondering if this is an
 improvement or not. I don't know the implications of use-modules;
 perhaps there's some overhead that I don't know about that isn't
 worth it. Or maybe list-index and split-at are less optimal than
 than Jay's loop-and-reverse solution.

 Just wanting to learn...

 Thanks,
 Mark
 ___

 (use-modules (srfi srfi-1))

 (define-public (split-at-predicate predicate lst)
  Split a list into 2 lists at the first element that returns #f for
  (PREDICATE previous_element element). Return the two parts as a pair.
  Example: (split-at-predicate  '(1 2 3 2 1)) == ((1 2 3) . (2 1))
  (let ((i (list-index predicate(cdr lst) lst)))
    (if i
        (call-with-values (lambda () (split-at lst (1+ i)))
                          cons)
        `(,lst
 ___


Actually, I like this much better. A couple things:
- It doesn't handle an empty list as input. Or is an error the correct behavior?
- I'm not the biggest fan of multiple return values. You could do
(cons (take lst (1+ i)) (drop lst (1+ i))) instead (unless there are
efficiencies in the split-at approach).
- I think (list lst) is clearer than `(,lst).

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ppppp but no fffff

[Jay Anderson]

On Thu, Jun 18, 2009 at 9:16 PM, Graham
Percivalgra...@percival-music.ca wrote:
 On Thu, Jun 18, 2009 at 05:33:18PM -0700, Mark Polesky wrote:

 dynamic-scripts-init.ly

 why is there p but no f?

 IIRC I asked this 3-4 years ago, and the answer was that somebody
 had seen p in the literature (a Tchaik symphony, maybe?), but
 nobody had seen a f.


http://www.informatics.indiana.edu/donbyrd/CMNExtremesBody.htm

This page list The Tempest, Op.18 by Tchaikovsky as having f.
Check it out: 
http://imslp.org/wiki/The_Tempest%2C_Op.18_(Tchaikovsky%2C_Pyotr_Ilyich).
See page 86 of the first file and page 44 of the second file at the
Andante non tanto. The strings and the woodwinds are at the full f
while the brass and percussion are only at  :).

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)

[Jay Anderson]

On Mon, Jun 15, 2009 at 3:03 AM, Joe Neemanjoenee...@gmail.com wrote:

 On Mon, Jun 8, 2009 at 3:59 AM, Mark Polesky markpole...@yahoo.com wrote:

 my version:

 (define-public (split-at-predicate predicate lst)
  Split LST (into 2 lists) at the first element that returns #f for
   (PREDICATE previous_element element), and return the 2 new lists as a
   pair. Example: (split-at-predicate  '(1 2 3 2 1)) == ((1 2 3) 2 1)
  (if ( (length lst) 2)
      (cons lst '())
      (let loop ((L0 (list (car lst))) (L1 (cdr lst)))
        (cond ((null? L1) (cons L0 L1))
              ((predicate (car (last-pair L0))

 last-pair is an O(n) operation, since it has to traverse the whole list,
 making split-at-predicate O(n^2) instead of O(n), as it should be. You'd be
 better off building L0 backwards and reversing it at the end, so that the
 element you need is always at the beginning of a list.


Also it should avoid length when a null? check will do. Here's the
function with those changes:

(define-public (split-at-predicate predicate lst)
  Split a list into 2 lists at the first element that returns #f for
  (predicate previous_element element). Return the two parts as a pair.
  Example: (split-at-predicate  '(1 2 3 2 1)) == ((1 2 3) . (2 1))
  (if (or (null? lst) (null? (cdr lst)))
(list lst)
(let loop ((lst-a (list (car lst))) (lst-b (cdr lst)))
  (cond ((null? lst-b) (list lst))
((predicate (car lst-a) (car lst-b))
  (loop (cons (car lst-b) lst-a) (cdr lst-b)))
(else (cons (reverse lst-a) lst-b))


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: unexpected \unfoldRepeats behavior

[Jay Anderson]

On Sat, Jun 6, 2009 at 3:22 AM, Mark Poleskymarkpole...@yahoo.com wrote:

 I tried to answer a question on -user but hit a brick wall.
 \unfoldRepeats failed to work when the music block was funneled from 2
 separate expressions. Can someone explain this to me? Why does the
 following code work for voiceA but not for voiceB?

 Thanks.
 - Mark

 _


 \version 2.13.1

 voiceA = \new Voice = A \relative {
  \time 1/4
  \repeat volta 2 { a' }
  \alternative { { b } { c } }
 }


 % voiceB is built from 2 separate expressions funneled into one voice,
 % but otherwise ought to be identical to voiceA, it seems:
 voiceBrepeats = {
  \time 1/4
  \repeat volta 2 { s }
  \alternative { { s } { s } }
 }
 voiceBnotes = \relative { \time 1/4 a' b c }
 voiceB = \new Voice = B {  \voiceBrepeats \voiceBnotes  }


 % using \unfoldRepeats produces the expected MIDI output with voiceA,
 % but not with voiceB. Why?
 \score {
  \unfoldRepeats \voiceA % change to \voiceB to test.
  \midi { }
 }

This is the expected behavior. Only the spacers will be unfolded in
voiceB. The repeat needs to be around the actual notes. Use
\displayMusic and you'll see why.

If you really do want this to work you're going to need some sort of
flatten function: '\flatten  \voiceBrepeats \voiceBnotes ' which
would recursively combine the contents of nested parallel sections
into one SequentialMusic section. This would be tricky. It's easiest
to just put the repeats in all voices.

--Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: unexpected \unfoldRepeats behavior

[Jay Anderson]

On Sat, Jun 6, 2009 at 4:53 PM, Paul Scottpsl...@ultrasw.com wrote:
 Which is kind of ridiculous if you're writing an ensemble piece with many
 (even more than one) voices/parts.  How can a midi of a multi-voice work
 with any repeats be done?

I was working on a large score and originally kept the repeat
structure separate from the individual parts and ran into the same
unfold-not-working problem. I thought about this a bit and decided it
was best just to have the repeats in each part. If you're going to
make a change to the repeat structure you're almost always going to
have to change each part/voice to match. Since this is the case it
makes sense to have the repeat structure in each part. If for nothing
else it makes it easy to find the beginnings and ends of repeats in
each part.

 I don't mind having a separate file for the midi output but not being able
 to factor out the common timing and dynamics costs a lot of input time and
 makes it a lot harder to make sure I haven't dropped a bar somewhere.

Actually I found that having the repeats in each part made it easier
to notice that bars were off. Lilypond throws errors where it thinks
the repeat timing problem is without having to look too much at the
pdf output.

-Jay


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: shorthand for autoBeam control

[Jay Anderson]

Mats Bengtsson mats.bengtsson at ee.kth.se writes:
 
 We already have the predefined macro \noBeam. Do we really need yet another
 more or less obscure special case of the syntax?
 
 /Mats
 
 Werner LEMBERG wrote:
  I'm not sure whether this has been discussed before: What do you think
  of using `c[]' as a shorthand for `\autoBeamOff c \autoBeamOn'?

When I was first learning lilypond I remember trying this exact syntax to get
an unbeamed note. I think it would be useful if it worked. It's a big win to
be able to figure out how to do something with out having to consult the
documentation.

(Sorry to barge in on the dev list).

-Jay



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel