Re: GUB

[Ricardo Wurmus]

Hi David,

> It's just possible that the Guix developers will refuse accepting a
> Guile-1.8 development package on philosophical grounds.

We Guix people have had a “guile-1.8” package since a long time and it
is still used by our “lilypond” package.  There are no plans to remove
it.

--
Ricardo


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

Re: Programming Language

[Ricardo Wurmus]

Hi Conor,

David Kastrup  writes:

> For extending LilyPond, you need Scheme.  Scheme knowledge is only of
> limited marketing value but of course the general kind of solving
> programming tasks from within a fourth generation extension language may
> still be reasonably relevant.

Scheme is a very good language to know.  It is also reasonably close to
Clojure, which seems to be quite popular these days.

~~ Ricardo


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

Re: midi articulation

[Ricardo Wurmus]

Carl Sorensen  writes:

>>Midi Sounds
>>__
>>
>>I¹m no midi expert, but I¹ve used it over the years. My impression is
>>that tools like Apple Logic, Sibelius, and so on, provide their own
>>sounds, which are unrelated, in particular, to midi, which only gives a
>>slight clue to the desired sound. To give a reasonable midi result, I
>>believe we must go that route: provide a sound library, and a player. A
>>user would then be able to write a lilypond score, and get a reasonable
>>audio playback of that score. We could generate midi as we have always
>>done, but the midi would have much better articulation and dynamics than
>>it currently does.
>
> I really don't think this is the right approach.  LilyPond should not be
> developing sound libraries or players.  There already exist high-quality
> sound libraries, and full-featured midi players.  Why should LilyPond
> reinvent the wheel?  What are the weaknesses and/or limitations of, for
> example, Qsynth or Timidity++?

I agree with Carl.  It is sufficient for Lilypond to produce performance
information in MIDI format.  Users can pick from a wide variety of
MIDI-interpreting synthesizers such as soundfont players, LV2
synthesizers, external General MIDI devices and more.

> I'm quite on board with recommending a particular midi player and/or sound
> font.  But I don't see how creating a new synthesizer is necessary (or
> desirable) to improve articulation and dynamics.  While I'm not an expert,
> I would expect that the appropriate MIDI commands can be embedded in a
> MIDI file created by LilyPond, and we just need to make sure a known good
> sound library and player are available.

Integrated score editing environments like Frescobaldi could probably
include a General MIDI soundfont and a MIDI player, but I don’t think
Lilypond should ensure the availability of MIDI players.  It already
doesn’t care what DVI or PDF viewer is installed (if any).

Lilypond currently doesn’t generate all performance information that the
MIDI format allows.  When MIDI itself becomes the limiting factor (which
it is not now) it may make sense to also offer OSC support.

~~ Ricardo


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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Ricardo Wurmus]

David Kastrup <d...@gnu.org> writes:

> Ricardo Wurmus <rek...@elephly.net> writes:
>
>>>> I don't know what the current Guile-2.0 situation is, but compiling
>>>> Guile-2.1 (namely master) is insane.  It takes about a day on my
>>>> computer.
>>>
>>> Took me ~8h
>>
>> There is a “guile-next” package for GNU Guix, which makes it possible
>> to get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
>> ftp://alpha.gnu.org).
>
> Absolutely no point in fighting with Guile 2.1 yet.

I just meant to comment on “compiling Guile-2.1 [...] is insane”.  If
you want to test against Guile 2.1 for some reason, it may make more
sense to install the binary with Guix rather than waiting for a day for
the build to succeed.

As Paul mentioned, there also is a package for Guile 2.0.11 in Guix.

~~ Ricardo


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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Ricardo Wurmus]

>> I don't know what the current Guile-2.0 situation is, but compiling
>> Guile-2.1 (namely master) is insane.  It takes about a day on my
>> computer.
>
> Took me ~8h

There is a “guile-next” package for GNU Guix, which makes it possible to
get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
ftp://alpha.gnu.org).

GNU Guix can be used as a package manager on top of any GNU+Linux
system.  This should make it a little easier to experiment with a more
recent version of Guile.

~~ Ricardo


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

Re: lilypond version manager

[Ricardo Wurmus]

Philip Olson  writes:

> I just finished a beta version of my lilypond version manager "lilyvm" found 
> on 
> github
>
> https://github.com/olsonpm/lilyvm
>
> I'm emailing because I would like to know whether it's a tool that would help 
> anyone besides myself, and if so, what kind of OS's are most widely used from 
> people using lilypond's CLI.  Lilyvm is currently restricted to linux on x86 
> and amd64 processors - which is why I ask.  The work involved in adding 
> support 
> for more kernels and processors is mostly testing.  The entire program is 
> written in POSIX sh so portability is built in.

I’d like to add that GNU Guix has a package for Lilypond.  Guix supports
installing multiple versions of any package into different profiles, so
I can have the stable version of Lilylpond installed at
~/.lily-stable/bin and the development version at ~/.lily-dev/bin,
provided I have package expressions for both versions.

Currently, Guix contains a package expression for 2.19.33 (that’s the
one I’m using).  It is almost trivial to create package variants with
Guix by inheriting from existing packages:

  (define my-lilypond
(package (inherit lilypond)
  (version "2.18.whatever")
  (source (origin
  (method url-fetch)
  (uri (string-append
"http://download.linuxaudio.org/lilypond/sources/v;
(version-major+minor version) "/"
"lilypond-" version ".tar.gz"))
  (sha256
   (base32
"0s4vbbfy4xwq4da4kmlnndalmcyx2jaz7y8praah2146qbnr90xh"))

This also only works on GNU systems, and currently the build fails for
mips64el and armhf (though it seems that the reason is a mere timeout in
building documentation, which could be due to the slow build slaves for
these architectures), so like Lilyvm this method is limited to x86 and
i686 for the moment.

~~ Ricardo


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

Re: compiling on Debian on an ARMv7

[Ricardo Wurmus]

Hi,

> I getting used to the BeagleBone Black, so I though I'd try compiling
> Lilypond.  It runs Debian, but on an ARM. LilyPond hasn't provided a
> precompiled binary for ARM for a decade.

The GNU Guix project is providing binary substitutes for Lilypond for
four systems (armhf, mips64el, i686, x86_64).  We are building the
latest unstable release on hydra.gnu.org, and you can take a look at the
latest build for armhf here:

http://hydra.gnu.org/build/703773

Installation only requires

guix package -i lilypond

Building it locally is possible by disabling binary substitutes:

guix build --no-substitutes lilypond

For a development environment containing all dependencies to build
Lilypond you could run:

guix environment lilypond

This creates a sub-shell in which all dependencies are available.

As Guix can be used on top of another distribution, this probably also
works on the BeagleBone Black running Debian.

~~ Ricardo


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

Re: Fwd: LilyDev Docker image?

[Ricardo Wurmus]

 are there any plans to build a Docker image for building LilyPond? It would
 be a much more lightweight solution than a VirtualBox image, so I think
 contributors would be grateful.

I would like to note that Lilypond has been packaged for GNU Guix, a
functional package manager.  To create a lightweight development
environment in which all build dependencies are available one only needs
to run

guix environment lilypond

It obviously does not include the maintenance tools that come with
LilyDev (such as the extensions/wrappers around git), but I think it’s
very useful and doesn’t require an opaque solution like a Docker image.

~~ Ricardo


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

Re: [PATCH] Add scheme engraver for StaffTab notation

[Ricardo Wurmus]

I already implemented the following changes:

- added context definitions for \midi in addition to \layout
- restricted maximum line length to 80 chars

Attached is a new patch.

I suppose this engraver should be documented somewhere, but I'm not sure
which of the many files under Documentation this should go to.  Could
you please tell me the most appropriate location in the manual for
documenting this engraver?  Is there a similar section in the manual
that I could use as a template (to know just how much it should
contain).

Are there other things you want me to change?

~~ Ricardo

From e9686ff0e6534292278924de4ac1586e366adcd5 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus rek...@elephly.net
Date: Mon, 23 Feb 2015 23:00:54 +0100
Subject: [PATCH] Add scheme engraver for StaffTab notation

The StaffTab notation is a system combining graphic elements of
tablature with standard music notation and Emmett Chapman's finger
symbols for notating tapping on a Chapman Stick.
---
 ly/stafftab.ly|  50 +++
 ly/string-tunings-init.ly |  19 +++
 scm/lily.scm  |   1 +
 scm/stafftab-engraver.scm | 344 ++
 4 files changed, 414 insertions(+)
 create mode 100644 ly/stafftab.ly
 create mode 100644 scm/stafftab-engraver.scm

diff --git a/ly/stafftab.ly b/ly/stafftab.ly
new file mode 100644
index 000..b0387d6
--- /dev/null
+++ b/ly/stafftab.ly
@@ -0,0 +1,50 @@
+\layout {
+  \context {
+\Score
+\accepts StaffTab
+  }
+  \context {
+\Staff
+\name StaffTab
+\alias Staff
+\denies Voice
+\defaultchild StickVoice
+\accepts StickVoice
+\description Same as @code{Staff} context, except that it is
+accommodated for typesetting a piece in StaffTab notation.
+  }
+  \context {
+\Voice
+\name StickVoice
+\alias Voice
+\description Same as @code{Voice} context, except that it is
+accomodated for typesetting a piece in StaffTab notation.
+\remove Fingering_engraver
+\remove New_fingering_engraver
+\consists #stafftab-engraver
+  }
+}
+
+\midi {
+  \context {
+\Score
+\accepts StaffTab
+  }
+  \context {
+\Staff
+\name StaffTab
+\alias Staff
+\denies Voice
+\defaultchild StickVoice
+\accepts StickVoice
+\description Same as @code{Staff} context, except that it is
+accommodated for typesetting a piece in StaffTab notation.
+  }
+  \context {
+\Voice
+\name StickVoice
+\alias Voice
+\description Same as @code{Voice} context, except that it is
+accomodated for typesetting a piece in StaffTab notation.
+  }
+}
diff --git a/ly/string-tunings-init.ly b/ly/string-tunings-init.ly
index 034e9a2..1f2c969 100644
--- a/ly/string-tunings-init.ly
+++ b/ly/string-tunings-init.ly
@@ -85,8 +85,27 @@ for documentation purposes.)
 \makeDefaultStringTuning #'cello-tuning \stringTuning c, g, d a
 \makeDefaultStringTuning #'double-bass-tuning \stringTuning e,, a,, d, g,
 
+%% tunings for 12-string Chapman Stick
+\makeDefaultStringTuning #'stick-classic-tuning
+  \stringTuning d' a e b, fis, cis, c,, g,, d, a, e b
+\makeDefaultStringTuning #'stick-matched-reciprocal-tuning
+  \stringTuning c' g d a, e, b,, c,, g,, d, a, e b
+
+
 defaultStringTunings = #(reverse! defaultStringTunings)
 
 %% convert 5-string banjo tuning to 4-string by removing the 5th string
 four-string-banjo = #(lambda (tuning)
 			 (take tuning 4))
+
+%% convert 12-string Chapman Stick tuning to 10-string tuning
+ten-string-stick = #(lambda (tuning)
+ (append (list-head tuning 5)
+ (list-head (list-tail tuning 6) 5)))
+
+%% get either the bass or the melody string group
+stick-string-group = #(lambda (tuning group)
+   (let ((num (/ (length tuning) 2)))
+(if (equal? group 'bass)
+ (list-head tuning num)
+ (list-tail tuning num
diff --git a/scm/lily.scm b/scm/lily.scm
index 6322e01..151e913 100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -585,6 +585,7 @@ messages into errors.)
 define-grob-interfaces.scm
 define-stencil-commands.scm
 scheme-engravers.scm
+stafftab-engraver.scm
 titling.scm
 text.scm
 
diff --git a/scm/stafftab-engraver.scm b/scm/stafftab-engraver.scm
new file mode 100644
index 000..f280255
--- /dev/null
+++ b/scm/stafftab-engraver.scm
@@ -0,0 +1,344 @@
+ This file is part of LilyPond, the GNU music typesetter.
+
+ Copyright (C) 2015 Ricardo Wurmus rek...@elephly.net
+
+ LilyPond is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ LilyPond is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS

[PATCH] Add scheme engraver for StaffTab notation

[Ricardo Wurmus]

Hi,

I failed to authenticate with Rietveld via git-cl (using the web interface it
works just fine); the reason is given as WebLoginRequired.  Since I don't know
how to fix this, I'm sending my patch along with this email.

It adds new tunings for the Chapman Stick and a StaffTab engraver.

Here's an example of how to use it:



nyan.ly
Description: Binary data

I'm not particularly fond of the position of the fret indicators, nor do I like
that they get so very close to the annotations (arr. Ricardo Wurmus) on the
top right.

This is not *exactly* the same as StaffTab notation as the string numbers on the
very left, next to the note lines are not indicated, but it works well enough to
be useful for Stickists.

Here's the patch:

From 5cb85101ce9772cef8ed005021a2f4b53743d38c Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus rek...@elephly.net
Date: Mon, 23 Feb 2015 23:00:54 +0100
Subject: [PATCH] Add scheme engraver for StaffTab notation

The StaffTab notation is a system combining graphic elements of
tablature with standard music notation and Emmett Chapman's finger
symbols for notating tapping on a Chapman Stick.
---
 ly/stafftab.ly|  26 
 ly/string-tunings-init.ly |  16 +++
 scm/lily.scm  |   1 +
 scm/stafftab-engraver.scm | 344 ++
 4 files changed, 387 insertions(+)
 create mode 100644 ly/stafftab.ly
 create mode 100644 scm/stafftab-engraver.scm

diff --git a/ly/stafftab.ly b/ly/stafftab.ly
new file mode 100644
index 000..869b460
--- /dev/null
+++ b/ly/stafftab.ly
@@ -0,0 +1,26 @@
+\layout {
+  \context {
+\Score
+\accepts StaffTab
+  }
+  \context {
+\Staff
+\name StaffTab
+\alias Staff
+\denies Voice
+\defaultchild StickVoice
+\accepts StickVoice
+\description Same as @code{Staff} context, except that it is accommodated for typesetting a piece in StaffTab notation.
+%% Here come all the context modifications (different font, whatever)
+  }
+  \context {
+\Voice
+\name StickVoice
+\alias Voice
+\description Same as @code{Voice} context, except that it is accomodated for typesetting a piece in StaffTab notation.
+
+\remove Fingering_engraver
+\remove New_fingering_engraver
+\consists #stafftab-engraver
+  }
+}
diff --git a/ly/string-tunings-init.ly b/ly/string-tunings-init.ly
index 034e9a2..e0a09e9 100644
--- a/ly/string-tunings-init.ly
+++ b/ly/string-tunings-init.ly
@@ -85,8 +85,24 @@ for documentation purposes.)
 \makeDefaultStringTuning #'cello-tuning \stringTuning c, g, d a
 \makeDefaultStringTuning #'double-bass-tuning \stringTuning e,, a,, d, g,
 
+%% tunings for 12-string Chapman Stick
+\makeDefaultStringTuning #'stick-classic-tuning \stringTuning d' a e b, fis, cis, c,, g,, d, a, e b
+\makeDefaultStringTuning #'stick-matched-reciprocal-tuning \stringTuning c' g d a, e, b,, c,, g,, d, a, e b
+
+
 defaultStringTunings = #(reverse! defaultStringTunings)
 
 %% convert 5-string banjo tuning to 4-string by removing the 5th string
 four-string-banjo = #(lambda (tuning)
 			 (take tuning 4))
+
+%% convert 12-string Chapman Stick tuning to 10-string tuning
+ten-string-stick = #(lambda (tuning)
+ (append (list-head tuning 5) (list-head (list-tail tuning 6) 5)))
+
+%% get either the bass or the melody string group
+stick-string-group = #(lambda (tuning group)
+   (let ((num (/ (length tuning) 2)))
+(if (equal? group 'bass)
+ (list-head tuning num)
+ (list-tail tuning num
diff --git a/scm/lily.scm b/scm/lily.scm
index 6322e01..151e913 100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -585,6 +585,7 @@ messages into errors.)
 define-grob-interfaces.scm
 define-stencil-commands.scm
 scheme-engravers.scm
+stafftab-engraver.scm
 titling.scm
 text.scm
 
diff --git a/scm/stafftab-engraver.scm b/scm/stafftab-engraver.scm
new file mode 100644
index 000..f280255
--- /dev/null
+++ b/scm/stafftab-engraver.scm
@@ -0,0 +1,344 @@
+ This file is part of LilyPond, the GNU music typesetter.
+
+ Copyright (C) 2015 Ricardo Wurmus rek...@elephly.net
+
+ LilyPond is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ LilyPond is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with LilyPond.  If not, see http://www.gnu.org/licenses/.
+
+(use-modules (srfi srfi-26))
+
+
+;; settings
+(define staff-padding-bass 2.5)   ; Padding below bass staff
+(define staff

Re: [PATCH] Add scheme engraver for StaffTab notation

[Ricardo Wurmus]

Werner LEMBERG writes:

 Just having a quick look (since I don't understand Tab notation at
 all) I ask you the same as almost everybody else who commits a patch
 the first time: Please try to limit the line length to 80 characters!

The line length in the patch is already limited to 80 characters.  I use
fci-mode in Emacs to display the fill column and it is set to 70
characters and is crossed at only one point.  Do you want me to change
the maximum length from 70 to 80?

The example (which is not part of the patch) has no strict length
restrictions.

StaffTab notation is very much unlike common tab notation, so
familiarity with guitar tabs would not help.  Familiarity with the
Chapman Stick, however, would help.  It is primarily like regular
notation with a few additions and a few modifications:

- the shape of the note head indicates what finger is to be used to play
  the note.  A perfectly circular disc-shaped note head indicates that
  the first/index finger is to be used; a diamond-shaped note head
  indicates the second finger; a triangle the third finger; a rectangle
  the fourth.

- as the Stick has 10 to 12 strings the note lines can be abused to
  represent strings.  In a grand staff with two systems the upper staff
  represents the first string group (the melody strings to be played
  with the right hand), the lower staff represents the second string
  group (the bass strings to be played with the left hand).  String
  markers (somewhat faint, wide rectangles) are added onto the note
  lines if a string number is provided in the sources.  The markers are
  somewhat spread horizontally to show an approximation of the chord
  shape.

- fret numbers are computed from the string number and pitch; they are
  collected for all notes at a timestep and string group, joined by a
  dot, and printed over (for strings in the upper staff) or under (for
  bass strings) the note.

That's pretty much all there is to it.

~~ Ricardo


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

Re: [PATCH] Add scheme engraver for StaffTab notation

[Ricardo Wurmus]

Werner LEMBERG writes:

 The line length in the patch is already limited to 80 characters.

 Indeed, the line length is OK in stafftab-engraver.scm, but both
 stafftab.ly and string-tunings-init.ly exceed the limit.

Ah, I see.  Sorry about that.  I already modified stafftab.ly to break
the description, but in string-tunings-init.ly there are also other
tunings that exceed 80 characters, such as guitar-seven-string-tuning,
bass-five-string-tuning, and bass-six-string-tuning.

Can a tuning definition be continued on the next line?  If so: how?

I will also break the definition of ten-string-stick at an appropriate
point in the next iteration of the patch.

~~ Ricardo


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

Re: [PATCH] Add scheme engraver for StaffTab notation

[Ricardo Wurmus]

David Nalesnik writes:

 When I apply your patch and try to compile the example file I get:

 warning: cannot find or create new `StaffTab'
 warning: cannot find or create new `StaffTab'
 warning: cannot find or create new `StickVoice'
 warning: cannot find or create new `StickVoice'
 MIDI output to `nyan.midi'...

I do get the same warnings, but they have no effect on the resulting
MIDI file or the PDF.  This may be related only to generating MIDI.  I'd
be glad for pointers as to how to prevent these warnings.

 I notice that the version statement in nyan.ly is 2.14.2.  Are you working
 off 2.19.16?

Yeah, that version statement is very old because the example is really
old already.  I started working on this a couple of years ago and left
it sitting as an extension for anyone interested in StaffTab notation
with Lilypond, but recently decided to clean this all up and submit it
upstream as a proper patch.

I'm working off latest master.  I should have changed the version
statement to avoid confusion.

~~ Ricardo


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

scheme engraver for StaffTab notation

[Ricardo Wurmus]

Hi,

a while ago I wrote a scheme engraver that outputs something close to
StaffTab notation.  StaffTab notation is a mix of standard two staff
notation with a few elements of tabulature tailored to the free hands
methods of playing the Chapman Stick.

Here's the essence of what it does:

The engraver changes the noteheads dependent on fingering and string
position information (e.g. c-3\4 would result in the note c rendered
with a triangular notehead representing the third finger, plus a
string marker on the line matching the fourth string).  In addition,
the fret position dependent on the selected tuning is computed and
printed above the staff (this looks still a bit uglier than what I
can accept).

I actually first worked on this in 2011 and didn't feel comfortable
enough with the results to dare submitting a patch set.  The engraver
does not yet result in the very same output one would expect from
hand-crafted StaffTab notation, but it gets reasonably close, at least
for my purposes.

As the intersection of people playing the Chapman Stick and using
Lilypond for their notation needs is probably very small I wonder if it
makes sense to polish this engraver a little and submit it for inclusion
in Lilypond.  The alternative is probably watching it the engraver go
stale and bitrot.

Is an engraver for StaffTab notation (plus some standard Chapman Stick
tuning definitions) something you'd think would be an appropriate
contribution to Lilypond or is it too much of a niche application and
should rather remain as an external engraver?

-- Ricardo


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

Re: chaotic stems when querying direction property

[Ricardo Wurmus]

  So ly:glob-property has side effects because of the stem callback?
  How can I make sure to get the final stem direction after all
  dependent properties were calculated?
 
  I want to replace a note head with a triangle, but there is a gap
  between note head a stem when the stem points upward. To correct this, I
  modify the stem-attachment property of the note head. This correction
  offset must be different when the stem points down.

 I'd override the default callback for stem-attachment.  It should be
 safe to get the stem direction at this point since it's already been
 calculated and cached.

 Cheers,
 Neil

Thanks, Neil. That helped.

I will read a little more about callbacks. A number of ugly parts of my
code could be solved a lot more elegantly through callbacks.

Best,
Rekado

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

chaotic stems when querying direction property

[Ricardo Wurmus]

Hi list,

I'm having a problem with a scheme engraver. Whenever I fetch the
direction property of a grob's stem object (or directly through a
listener on stem-event), the following warning is shown:

   warning: no viable initial configuration found: may not find good
beam slope

The resulting score has a few notes with their stems pointing in the
wrong direction, so that the beams have a terribly ugly slope. As soon
as I remove the code to store the direction everything is fine again.

I've attached a simple demo file where the chaotic stem directions can
be observed. All the code does is to save all grobs it encounters during
the acknowledge phase and then query the direction for each stored grob
during the processing phase.

I'd be happy if you could explain to me why this happens.

Best,
Rekado
\version 2.14.2

% ---

#(define my-engraver
   (let ((grobs '()))
 (list
   ;; process each note object with each saved grob
   (cons 'process-acknowledged
 (lambda (trans)
   (for-each
 (lambda (grob)
   (if (ly:grob? grob)
   (let* ((stem-grob (ly:grob-object grob 'stem))
  (direction (ly:grob-property stem-grob 
'direction)))
 (display direction)
 ))) grobs)))

   ;; save grob for processing
   (cons 'acknowledgers
 (list
   (cons 'note-head-interface
 (lambda (engraver grob source-engraver)
   (set! grobs (append grobs (list grob)
   ))
   )))

% ---

\score {
  \new Staff {
\clef bass
\key c \major
\new MyVoice {
  \relative f {
%e8-4\8
r2.. e8-4\8 ~ e
e,8-1\7 fis-2 g16-1 g-2 a8-4 cis-1\8 d-2 e8-4
  }
}
  }

  \layout {
\context {
  \Voice
  \name MyVoice
  \alias Voice
  \description A voice using my engraver

  \remove Fingering_engraver
  \remove New_fingering_engraver
  \consists \my-engraver
}
\context {
  \Staff
  \accepts MyVoice
}

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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

On Aug 10, Reinhold Kainhofer wrote:
 Am Mittwoch, 10. August 2011, 17:11:44 schrieb Ricardo Wurmus:
  On Aug 10, Neil Puttock wrote:
   BTW, if you're prepared to wrap the notes in a chord (so you have
   access to 'articulations), you won't even need a scheme engraver (all
   the processing can take place in the NoteHead's stencil callback).
 
  It should be a generic engraver, so I cannot assume that notes will
  always be wrapped in a chord. I'll play around with defining a function
  for process-acknowledged and see where it leads me.

 One detail that might be interesting for you is that you can define engraver-
 wide variables by wrapping the whole engraver in a (let (..) ...) block.
 See e.g. the scheme engraver instance regtest (input/regression/scheme-
 engraver-instance.ly in the source code tree):

snip


 In this example, instance-counter is a global variable, which is reused by
 every voice, while instance-id and private-note-counter are variables that are
 separate for each voice. In this example, instance-id stores the number of the
 voice, while private-note-counter counts the number of notes in each voice
 separately.
 In particular, the engravers used in the first and in the second voice will
 have different private-note-counter variables.

 You can use this to collect information from all encountered objects and thin
 in 'process-acknowledged or 'stop-translation-timestep procell all of them at
 once. For a list of all possible functions inside the engraver, see
 input/regression/scheme-engraver.ly

Thanks, this helped me quite a bit. The engraver is already working
basically. Will just have to clean up and add a few more features.

 Cheers,
 Reinhold

Best,
Rekado

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

custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

Hello,

I'm currently attempting to write a custom engraver in scheme.
This is the shortened code:

;; global variables to be used in `do-something'
#(define g_filled #f)
#(define g_direction 0)
#(define g_finger 0)
#(define g_string-number 0)
;; 


#(define-public (music-cause grob)
  (let*
  ((event (event-cause grob)))

(if (ly:stream-event? event)
(ly:event-property event 'music-cause)
#f)))


#(define my-engraver
   (list

 (cons 'acknowledgers
   (list
 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
 (let* ((event (event-cause grob))
(mus (music-cause grob))

;; TODO: how do I get *into* this articulations list?
(articulations (ly:music-property mus 'articulations)))

   ;; note head filling depends on duration
   (set! g_filled (ly:moment? duration filled-threshold))
   (do-something grob))
 ))

The `do-something' function (not shown here) replaces note heads according to
variables that I hope to extract from the event data structure.

In my code, the `mus' variable contains the music object, which has a property
`articulations'. This is what the music object looks like when displaying it:

#Prob: Music C++: Music(
  (length . #Mom 1/4)
  (elements)
  (duration . #Duration 4 )
  (articulations #Prob: Stream_event C++: Stream_event
 ((music-cause . #Prob: Music C++: Music
   ((digit . 2)
(origin . #location test.ly:50:14))
   ((display-methods #procedure #f (event 
parser))
(name . FingeringEvent)
(types general-music fingering-event 
event)) )
  (digit . 2)
  (origin . #location test.ly:50:14))
 ((class . fingering-event)) 
 )
  (pitch . #Pitch bes )
  (origin . #location test.ly:50:11))

((display-methods #procedure #f (note parser))
 (name . NoteEvent)
 (types general-music event note-event rhythmic-event melodic-event)) 

I'm trying to get to the music object *inside* the `articulations' list,
but I cannot seem to find a way to do so. Simply getting the property
`articulations' with ly:music-property returns a list, but I cannot run
cdr or car on that list to get to the Stream_event.

Is there a way to do this? Maybe this is the wrong approach. Is there
another way to get access to all music properties from within an
acknowledger?
Can I use more than one interface in the same acknowledger?

I tried using event listeners before to collect the note properties, but
this fails as soon as there is more than one voice, because the
acknowledgers are called after *all* the listeners at a certain moment.

I'd appreciate any comments or hints.

Thanks,

Rekado

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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

On Aug 10, Reinhold Kainhofer wrote:
 Am Wednesday, 10. August 2011, 09:44:00 schrieb Ricardo Wurmus:
  Hello,
 
  I'm currently attempting to write a custom engraver in scheme.
  This is the shortened code:

 It will increase the chances for a useful answer dramatically if you could
 attach a working example that one just has to run through lilypond, rather
 than trying to read your code, trying to image how to use it, constructing the
 example myself and then try to figure out how to solve it.

I was trying to simplify it, because my scheme-foo is only a day old.
But I guess you are right. Here is a working example of my engraver:

  https://github.com/rekado/Lilystick

The engraver is in stick-tab-engraver.ly, a test file using the engraver
is test.ly. Running `lilypond test.ly` will generate roughly what I want.
This all fails, though, when more than one Voice is used.

The reason for that is that I'm using event listeners to collect note
properties and evaluate them in the acknowledger code. The listeners are
executed first for all notes at a moment, and then the achnowledger code
(stick-fingers grob) runs. Hence, the global variables (g_string-number,
g_finger ...) are overwritten.

To overcome this, I want to let the acknowledger grab note properties
for each individual grob, instead of having the listeners grab them.

Rekado

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

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

 I have now spent ~25 minutes trying to strip down the engraver and adding what
 you had in your first mail, but I can't reproduce anything. The music-cause
 simply does not have any articulations here.
 So, I now wasted almost half an hour for what?

Oh shoot, I confused my example scores. I just noticed that the
articulations key (and the music-cause) only appears in the event list
when there are simultaneous notes.

This invalidates the approach (or rather workaround); anyway, I have
attached a simple working example (articulations.ly) that generates the
output I presented in my first email. I'm afraid it is not worth
spending time on this anymore, now that the inadequacy of this procedure
is established.

I'm very sorry to have wasted your time. Your comments actually helped
me to see how flawed my approach really is. Thank you for that.

 As I said above, I can't reproduce your claim that the music-cause has the
 articulations, so probably I did something different from what you had in mind
 (but didn't include it in your list). Please adjust the file to show your
 problem (and only your problem). In the future, this is the form that we would
 expect from you.
 So, if you really want us to spend precious time helping you, please make our
 life easier by sending really small, relevant examples.

Noted and understood. Thanks for your patience.

I think I will have to start from scratch (again).
This is what I'm trying to do for each note in the score:

   1. get the string number
  (string-number-interface)
   2. get the finger info
  (finger-interface)
   3. get the stem direction
  (stem-interface)
   4. replace the note head dependent on 1-3
  (note-head-interface)

I tried to add acknowledgers for all these interfaces, but the function
for the note-head-interface was always called *before* the others (see
attached example ack-order.ly).
Is there a way to change that order, or call the note-head-interface
function again at the very end for processing a grob?

I'm sure I'm missing something obvious here. (My ignorance even after
reading the documentation for multiple times annoys me so much.)
#(define-public (music-cause grob)
  (let*
  ((event (event-cause grob)))
(if (ly:stream-event? event)
(ly:event-property event 'music-cause)
#f)))

#(define stick-tab-engraver
   (list
 (cons 'acknowledgers
   (list
 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
 (let* ((context (ly:translator-context engraver))
(event (event-cause grob))
(mus (music-cause grob))

;; get music object inside articulations
;; TODO: how do I get to the music-cause property in 
the Stream_event?
(articulations (ly:music-property mus 'articulations)))

   ;; output articulations, so I can see how to
   ;; get to the music object inside.
   (display articulations)(newline)

   ;; replace the note head
   (do-something grob


#(define (do-something grob)
   (display Not important\n))


% --


\version 2.14.2

\score {
  
\time 2/4
\new Staff {
  \clef treble
  \key g \minor
  \new Voice {
\relative c'' {
  d4-1\4
}
  }
}
\new Staff {
  \clef bass
  \key g \minor
  \new Voice {
\relative g {
  % ugh, articulations only exist when
  % there are simultaneous notes
  d-2\4 g-4
}
  }
}
  

  \layout {
\context {
  \Staff
  \remove Fingering_engraver
  \consists \stick-tab-engraver
}
  }
}
#(define stick-tab-engraver
   (list
 (cons 'acknowledgers
   (list
 (cons 'string-number-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get string-number info and store in var
   (display getting STRING info\n)
   ))

 (cons 'finger-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get fingering info and store in var
   (display getting FINGER info\n)
   ))

 (cons 'stem-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: get stem direction info and store in var
   (display getting STEM info\n)
   ))

 (cons 'note-head-interface
   (lambda (engraver grob source-engraver)
   ;; TODO: replace the note head
   (do-something grob)))

#(define (do-something grob)
   (display Replacing note head\n))


% --


\version 2.14.2

\score {
  
\time 2/4
\new Staff {
  \clef treble
  \key g \minor
  

Re: custom engraver in scheme: accessing nested Music object

[Ricardo Wurmus]

On Aug 10, Neil Puttock wrote:
 On 10 August 2011 15:00, Ricardo Wurmus ricardo.wur...@gmail.com wrote:

  Is there a way to change that order, or call the note-head-interface
  function again at the very end for processing a grob?

 Acknowledger order depends on the order engravers are \consist-ed (the
 only exception is if you set must-be-last to #t)

 If you want to do useful things to the NoteHead, you should wait until
 all the acknowledging has finished, i.e., store the NoteHead grob and
 process the information in a process-acknowledged or
 stop-translation-timestep function.

Thank you very much for the information. This is the bit I must have
overlooked.

 BTW, if you're prepared to wrap the notes in a chord (so you have
 access to 'articulations), you won't even need a scheme engraver (all
 the processing can take place in the NoteHead's stencil callback).

It should be a generic engraver, so I cannot assume that notes will
always be wrapped in a chord. I'll play around with defining a function
for process-acknowledged and see where it leads me.

 Cheers,
 Neil

Best,
Rekado

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