Re: Draft: Extended mensural notation support
On 2/23/15 10:38 AM, Lukas Pietsch lukas.piet...@freenet.de wrote: I have a working draft of the Lilypond coding, which involves quite a bit of Scheme code, a patched Lilypond font with a section of new proposed glyphs, and a few minor patches to Lilypond's C++ codebase. Unfortunately, owing to the latter, the whole system currently works only with a patched, custom-compiled Lilypond installation. I'd like to hear if there's interest among the Lilypond folks to merge these extensions into the standard distribution, and how best to proceed to do so. Wow -- this seems like a tremendous amount of work! I'm basically ignorant of mensural notation, but this seems like a great advance. I think it should be implemented in LilyPond. And I think that the things you have found in LilyPond that are inconsistent with best practices (e.g. the incorrect use of flexa when it should be obliqua or oblonga; misnomer of maxima and longa rests) should be fixed. It would seem that the way to go about fixing this is to create a patch for submission. The patch should explain the need for all the changes in the codebase, and should include regression tests for new features added. If there are any changes (like changing the name of the long rests) that will affect existing files, a convert-ly rule should be developed. I'd encourage you to add this to the codebase. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft: Extended mensural notation support
I have a working draft of the Lilypond coding, which involves quite a bit of Scheme code, a patched Lilypond font with a section of new proposed glyphs, and a few minor patches to Lilypond's C++ codebase. Unfortunately, owing to the latter, the whole system currently works only with a patched, custom-compiled Lilypond installation. I'd like to hear if there's interest among the Lilypond folks to merge these extensions into the standard distribution, and how best to proceed to do so. Congrats! It's indeed very impressive. I think it should be implemented in LilyPond. Yes. And I think that the things you have found in LilyPond that are inconsistent with best practices (e.g. the incorrect use of flexa when it should be obliqua or oblonga; misnomer of maxima and longa rests) should be fixed. Indeed. Most of us are no experts in Gregorian chant, and if you are willing to help here, this would be great. It would seem that the way to go about fixing this is to create a patch for submission. No. Not a patch, but a series of patches, adding the stuff in small, incremental steps that are easy to review. I'm willing to proof-read all changes to the Metafont sources. To simplify the process, I suggest that you get write access to the lilypond git repository so that you can add such incremental patches to one or more separate branches (I like this method bettern than the `modern' way of forking lilypond at github, then followed by push requests) – unfortunately, with Rietveld you only see all commits squeezed to a single commit. After a first review, you could add a new branches that replaces older ones with better commits, etc., etc. If we have concensus, it should be easy then to merge everything into `staging'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft: Extended mensural notation support
David Kastrup dak at gnu.org writes: You state The notation samples, which include numerous highly uncommon and idiosyncratic forms, will be encoded in the corpus in an XML-based format. If the forms are highly uncommon and idiosyncratic, can they be described by an XML-based expressions that are _not_ highly uncommon and idiosyncratic? For me the most important question arising is not as much whether we should merge your support for a particular set of uncommon and idiosyncratic notation, but rather what kind of support we would need in LilyPond such that this and other forms of uncommon and idiosyncratic notations can be supported _without_ recompilation of LilyPond. Do you have an idea how LilyPond could be generally better for such tasks out of the box? Indeed, I quite agree it's a matter of how best to make the basic Lilypond system most efficiently extendable. I'd like to think of what I'm proposing as a thing with two layers. There is a set of core functional extensions that will just enhance the coverage of standard features of mensural notation: an improved glyph set for mainstream white notation, support for mainstream black notation, a consistent and user-friendly set of commands for such things as perfect/imperfect meters, rests, coloration and so on. This will be standard stuff and useful for all users of mensural notation. 99% of it will be implemented either in Metafont or in a Scheme stylesheet, which a user will be able to simply include (just as they now include gregorian.ly to get quadratic notation). There are only a very few small patches to the C++ code that will be needed to support this, and they should be easy enough to merge into the standard distribution without affecting anything else. The second layer is a general support mechanism that provides an infrastructure for adding further, user-defined features such as additional alternative glyph sets, non-standard note shapes and so on. Think of it as similar to the way shape notes are implemented now: a standard extension mechanism that allows users to define their own new sets of noteheads on the fly. The idiosyncratic features required by the TML project will be implemented as one such set of user-defined extensions. The standard distribution merely needs to provide the general functional infrastructure for it. That, too, can be done entirely in Scheme; no further changes in the C++ codebase are needed for it beyond those mentioned above. Best Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft: Extended mensural notation support
Lukas Pietsch lukas.piet...@freenet.de writes: Indeed, I quite agree it's a matter of how best to make the basic Lilypond system most efficiently extendable. I'd like to think of what I'm proposing as a thing with two layers. There is a set of core functional extensions that will just enhance the coverage of standard features of mensural notation: an improved glyph set for mainstream white notation, support for mainstream black notation, a consistent and user-friendly set of commands for such things as perfect/imperfect meters, rests, coloration and so on. This will be standard stuff and useful for all users of mensural notation. 99% of it will be implemented either in Metafont or in a Scheme stylesheet, which a user will be able to simply include (just as they now include gregorian.ly to get quadratic notation). There are only a very few small patches to the C++ code that will be needed to support this, and they should be easy enough to merge into the standard distribution without affecting anything else. The second layer is a general support mechanism that provides an infrastructure for adding further, user-defined features such as additional alternative glyph sets, non-standard note shapes and so on. Think of it as similar to the way shape notes are implemented now: a standard extension mechanism that allows users to define their own new sets of noteheads on the fly. The idiosyncratic features required by the TML project will be implemented as one such set of user-defined extensions. The standard distribution merely needs to provide the general functional infrastructure for it. That, too, can be done entirely in Scheme; no further changes in the C++ codebase are needed for it beyond those mentioned above. Sounds really good. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft: Extended mensural notation support
Werner LEMBERG wl at gnu.org writes: No. Not a patch, but a series of patches, adding the stuff in small, incremental steps that are easy to review. I'm willing to proof-read all changes to the Metafont sources. To simplify the process, I suggest that you get write access to the lilypond git repository so that you can add such incremental patches to one or more separate branches (I like this method bettern than the `modern' way of forking lilypond at github, then followed by push requests) – unfortunately, with Rietveld you only see all commits squeezed to a single commit. After a first review, you could add a new branches that replaces older ones with better commits, etc., etc. If we have concensus, it should be easy then to merge everything into `staging'. Thanks for this advice. I'm afraid I have to admit I'm a total novice at dealing with these kinds of versioning tools, commits and branches and stuff, so I can only hope I'll manage these things without messing up too much. I also found dealing with Metafont a real challenge - I just about managed to get the shapes the way I wanted them, but the code might still be quite messy and technically sub-optimal. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Add scheme engraver for StaffTab notation
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
Re: Draft: Extended mensural notation support
Hi Lukas, once again, I am no expert on ancient notation. So I don't know whether the length of the stems in your renaissance style are required to be exactly as long as they are now. They roughly end in the middle of a staff space for notes on this position and on a staff line for notes on a staff line – but not quite. My aesthetic feeling would prefer it if these stems are about 5% - 10% of a staff space longer to make the visual impression that the ‘bubble’/the thicker end of the stem is centred visually between the staff lines or on the staff line and not just reaching a very tiny bit over it as it is now. To illustrate what I mean, I attached a small part of your score (stems only). The first and the third stem are from your original and the second and fourth stem are my proposition (only regarding the thicker end of it – of course they would have to reach down to the note head). What do you think? Two more questions: - What usage scenarios are you thinking about for these styles? A complete renaissance score to reproduce a historic original, incipits, renaissance and modern staffs in the same score, anything else? - How easy would is it to reuse the musical content of an ancient staff in a modern staff to show a modern equivalent? Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
Here's the patch: 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! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
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: Draft: Extended mensural notation support
To simplify the process, I suggest that you get write access to the lilypond git repository so that you can add such incremental patches to one or more separate branches (I like this method bettern than the `modern' way of forking lilypond at github, then followed by push requests) – unfortunately, with Rietveld you only see all commits squeezed to a single commit. After a first review, you could add a new branches that replaces older ones with better commits, etc., etc. If we have concensus, it should be easy then to merge everything into `staging'. Thanks for this advice. I'm afraid I have to admit I'm a total novice at dealing with these kinds of versioning tools, commits and branches and stuff, so I can only hope I'll manage these things without messing up too much. Don't worry, we will assist you. If you restrict your actions to one or more separate branches, you won't interfere with anything else. I also found dealing with Metafont a real challenge - I just about managed to get the shapes the way I wanted them, but the code might still be quite messy and technically sub-optimal. Indeed, it is sub-optimal – a lot of glyphs defined in `parmesan-custom.mf' are simple translations from outline fonts. It would be necessary to convert them to *constructed* outlines so that size-specific parameters are taken into account. This is a very time-consuming process, I fear, but in the end you get something better :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
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. Indeed, the line length is OK in stafftab-engraver.scm, but both stafftab.ly and string-tunings-init.ly exceed the limit. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
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
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
Re: [PATCH] Add scheme engraver for StaffTab notation
Hi Ricardo, On Mon, Feb 23, 2015 at 4:42 PM, Ricardo Wurmus rek...@elephly.net wrote: Here's the patch: 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 notice that the version statement in nyan.ly is 2.14.2. Are you working off 2.19.16? --David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
On Mon, Feb 23, 2015 at 5:15 PM, David Nalesnik david.nales...@gmail.com wrote: Hi Ricardo, On Mon, Feb 23, 2015 at 4:42 PM, Ricardo Wurmus rek...@elephly.net wrote: Here's the patch: 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 notice that the version statement in nyan.ly is 2.14.2. Are you working off 2.19.16? Oh, sorry. My dumb mistake! Need to alter the path on the \include... --David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
On Mon, Feb 23, 2015 at 5:24 PM, David Nalesnik david.nales...@gmail.com wrote: On Mon, Feb 23, 2015 at 5:15 PM, David Nalesnik david.nales...@gmail.com wrote: Hi Ricardo, On Mon, Feb 23, 2015 at 4:42 PM, Ricardo Wurmus rek...@elephly.net wrote: Here's the patch: 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 notice that the version statement in nyan.ly is 2.14.2. Are you working off 2.19.16? Oh, sorry. My dumb mistake! Need to alter the path on the \include... Hmmm... moved the contents of stafftab.ly directly into the example file, same result. Not sure what is happening here. --David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
