Re: [PATCH] Add scheme engraver for StaffTab notation
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
Re: [PATCH] Add scheme engraver for StaffTab notation
Hi Ricardo, On Sun, Mar 1, 2015 at 8:31 AM, Ricardo Wurmus rek...@elephly.net wrote: 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. This patch fails to apply in ly/string-tunings-init.ly I imagine that is because current master incorporates a more recent change to this file: commit 67ed495d4f5e6a02224f87faf4c00979996675e0. --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 Sun, Mar 1, 2015 at 10:32 AM, David Nalesnik david.nales...@gmail.com wrote: Hi Ricardo, On Sun, Mar 1, 2015 at 8:31 AM, Ricardo Wurmus rek...@elephly.net wrote: 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. This patch fails to apply in ly/string-tunings-init.ly I imagine that is because current master incorporates a more recent change to this file: commit 67ed495d4f5e6a02224f87faf4c00979996675e0. Yes--the patch applies to an earlier checkout. ___ 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 w...@gnu.org writes: #(for-each (lambda (elem) (let* ((sym (car elem)) (chord (cdr elem))) (ly:parser-include-string parser (string-append \\makeDefaultStringTuning sym -tuning \\stringTuning chord '((guitar . e, a, d b g e') (guitar-seven-string . b,, e, a, d b g e') (guitar-drop-d . d, a, d g b e') (guitar-drop-c-tuning . c, g, c f a d') ... ) ) Disagree. The current solution has a constant visual pattern (just that it does not use whitespace for that). It's not significantly less readable on a pure visual basis (one might want to block-align the tuning names). However, your version is utterly incomprehensible on the basis of understanding what it does while the original version has each line stand for itself, with a readily readable _meaning_ of the line. It's not clear to me how an alist of tuning names and the associated string tunings is `utterly incomprehensible'... Oh well. So what is the purpose of having _strings_ here? What does the . mean? What do the parens mean? All that ly:parser-include-string is actually on a level of code ugliness even below using primitive-eval because it pieces together stuff that is not even at a syntactical level. Yes, but exactly this is the power of `ly:parser-include-string'! To hide from the editor and reader what one is doing? So that you don't get syntax highlighting and become unable to convert notenames or absolute/relative? Not everything that is possible to do is a good idea. It is a nice utility to use Scheme's iteration stuff (i.e., `for-each' and friends) while not too deeply diving into Scheme. I doubt that you even realize what you are doing here. Let's put some problems in: #(for-each (lambda (elem) (let* ((sym (car elem)) (chord (cdr elem))) (ly:parser-include-string parser (string-append \\makeDefaultStringTuning sym -tuning \\stringTuning chord '((guitar . e, a, d b g e') (guitar-seven-string . b,, e, a, d b g e') (guitar-drop-d . d, a, d g b e') (guitar-drop-c-tuning . c, g, c f a d'))) Now what will the results be? One error already introduced by yourself is that guitar-drop-c-tuning will be undefined since instead you are defining guitar-drop-c-tuning-tuning. Which stresses my point about it being a bad idea to use different words in definition and use. The next thing to note is that the error messages are entirely incomprehensible and that the lines are obviously processed in _reverse_ order (since a later ly:parser-include-string pushes another string to the _top_ of the include stack where it is processed earlier than strings lower in the stack). lilypond /tmp/gork.ly GNU LilyPond 2.19.16 Processing `/tmp/gork.ly' Parsing... included string:1:83: error: syntax error, unexpected \makeDefaultStringTuning guitar-drop-c-tuning-tuning \stringTuning c, g, c f a d' included string:1:77: error: syntax error, unexpected \makeDefaultStringTuning guitar-drop-d-tuning \stringTuning d, a, d g b e' /tmp/gork.ly:13:53: error: syntax error, unexpected end of input (guitar-drop-c-tuning . c, g, c f a d'))) /tmp/gork.ly:1: warning: no \version statement found, please add \version 2.19.16 for future compatibility fatal error: failed files: /tmp/gork.ly Compilation exited abnormally with code 1 at Wed Feb 25 13:13:14 Of course, this also means that the input will be read, parsed, and tokenized, several times in a row, making this also quite less efficient. Admittedly, we don't have to use such things in the lilypond init files; I accept your veto and won't further push into this direction. It's not just a bad idea in LilyPond's init files. It is a good practice to have the syntactical context of input be its location in the file, without juggling it around between interpreters and input stacks manually. Otherwise, error messages cannot properly track the source locations, and the editor cannot help with formatting and highlighting the source code appropriately. And you avoid recombining tokens and several tokenizers working in sequence on the same input, requiring escaping of quote characters and other stuff. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
It's not clear to me how an alist of tuning names and the
associated string tunings is `utterly incomprehensible'... Oh
well.
So what is the purpose of having _strings_ here?
For me this is the most natural form to present input that gets
massaged later on.
What does the . mean? What do the parens mean?
Uh, oh, ... alist ... Please don't pretend to be a noob.
To hide from the editor and reader what one is doing? So that you
don't get syntax highlighting and become unable to convert notenames
or absolute/relative? Not everything that is possible to do is a
good idea.
Huh? Are we still talking about string tunings? What you do here is
trick number 3 in Schopenhauer's `Eristic Dialectic': Generalize your
opponent's specific statements. Please don't do that.
One error already introduced by yourself is that
guitar-drop-c-tuning will be undefined since instead you are
defining guitar-drop-c-tuning-tuning.
Yep, copy-and-paste error.
Which stresses my point about it being a bad idea to use different
words in definition and use.
Well, lilypond happily accepts a line like
\makeDefaultStringTuning #'guitar-asus4-tunink \stringTuning e, a, d e a e'
without any error message. Your argument is thus weak.
The next thing to note is that the error messages are entirely
incomprehensible
Again, I wouldn't call an error message `entirely incomprehensible' if
the offending line and position in the line is displayed.
Of course, this also means that the input will be read, parsed, and
tokenized, several times in a row, making this also quite less
efficient.
This, however, is indeed true and a valid argument. Just as a side
note for others who are reading this thread: the same is true for
`#{ ... #}', which is just syntactical sugar around
`ly:parser-parse-string', a variant of `ly:parser-include-string'.
It is a good practice to have the syntactical context of input be
its location in the file, without juggling it around between
interpreters and input stacks manually.
Otherwise, error messages cannot properly track the source
locations, and the editor cannot help with formatting and
highlighting the source code appropriately. And you avoid
recombining tokens and several tokenizers working in sequence on the
same input, requiring escaping of quote characters and other stuff.
I agree. *However*, there are IMHO situations where some sweeps with
a magic wand makes everything looks more nicely.
Just for fun: Attached are the original and my massaged version of
`string-tunings-init.ly'. Is my version really *that*
incomprehensible?
Werner
This file is part of LilyPond, the GNU music typesetter.
Copyright (C) 2010--2015 Carl D. Sorensen c_soren...@byu.edu
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/.
\version 2.16.0
%% A stringTuning is a list of pitches ordered by string number
%% from 1 to N.
%% Here we define a number of default string tunings.
%% A music function for converting a chord to a string tuning.
%% The music argument for \makeStringTuning must be a chord in
%% absolute mode ordered from the highest string number to the
%% lowest string number
stringTuning =
#(define-scheme-function (parser location chord)
(ly:music?)
(_i Convert @var{chord} to a string tuning.
@var{chord} must be in absolute pitches and should have the highest
string number (generally the lowest pitch) first.)
(let* ((ev-chord (car (extract-named-music chord 'EventChord
(reverse! (event-chord-pitches ev-chord
defaultStringTunings = #'()
makeDefaultStringTuning =
#(define-void-function (parser location symbol pitches) (symbol? list?)
(_i This defines a string tuning @var{symbol} via a list of @var{pitches}.
The @var{symbol} also gets registered in @code{defaultStringTunings}
for documentation purposes.)
(ly:parser-define! parser symbol pitches)
(set! defaultStringTunings (acons symbol pitches defaultStringTunings)))
%% guitar tunings
\makeDefaultStringTuning #'guitar-tuning \stringTuning e, a, d g b e'
\makeDefaultStringTuning #'guitar-seven-string-tuning \stringTuning b,, e, a,
d g b e'
\makeDefaultStringTuning #'guitar-drop-d-tuning \stringTuning d, a, d g b e'
\makeDefaultStringTuning #'guitar-drop-c-tuning \stringTuning c, g, c f a d'
\makeDefaultStringTuning #'guitar-open-g-tuning \stringTuning d, g, d g b d'
Re: [PATCH] Add scheme engraver for StaffTab notation
On 2/25/15 8:36 AM, David Kastrup d...@gnu.org wrote: The current solution does not switch modes apart from jumping into Scheme mode for #'guitar-tuning and we could easily get rid of that #' as well (yes, that will actually cause a measurable speedup as I found out in the course of issue 2883). Another advantage of the current system is that the input is disconnected from the internals, that is, it is not necessary to know the details of how stringTunings are stored in order to add a new tuning. I believe that the input files should use native LilyPond syntax as much as reasonable, and that string-tunings-init.ly should use \makeDefaultStringTuning directly on the chord. I think that it is a good improvement to let \makeDefaultStringTuning have either a stringTuning or a chord as an input variable, and thus allow \makeDefaultStringTuning #'cello-tuning c, g, d a in addition to \makeDefaultStringTuning #'cello-tuning \stringTuning c, g, d a Thanks, Carl ___ 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 w...@gnu.org writes: that simplifies \makeDefaultStringTuning #'guitar-tuning \stringTuning e, a, d g b e' to the much more readable \T guitar e, a, d g b e' You can write \makeDefaultStringTuning guitar-tuning \stringTuning e, a, d g b e' already. \T is not more readable but merely shorter. Well, `merely shorter' in this is case *is* `more readable' to me. It would be possible to redefine \makeDefaultStringTuning to _optionally_ allow \makeDefaultStringTuning guitar-tuning e, a, d g b e' as well. Ah, this would help a bit. I don't believe in increasing readability by renaming symbols into stuff that is not the same in definition and usage. OK. What about this? #(for-each (lambda (elem) (let* ((sym (car elem)) (chord (cdr elem))) (ly:parser-include-string parser (string-append \\makeDefaultStringTuning sym -tuning \\stringTuning chord '((guitar . e, a, d b g e') (guitar-seven-string . b,, e, a, d b g e') (guitar-drop-d . d, a, d g b e') (guitar-drop-c-tuning . c, g, c f a d') ... ) ) Disagree. The current solution has a constant visual pattern (just that it does not use whitespace for that). It's not significantly less readable on a pure visual basis (one might want to block-align the tuning names). However, your version is utterly incomprehensible on the basis of understanding what it does while the original version has each line stand for itself, with a readily readable _meaning_ of the line. All that ly:parser-include-string is actually on a level of code ugliness even below using primitive-eval because it pieces together stuff that is not even at a syntactical level. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
#(for-each (lambda (elem) (let* ((sym (car elem)) (chord (cdr elem))) (ly:parser-include-string parser (string-append \\makeDefaultStringTuning sym -tuning \\stringTuning chord '((guitar . e, a, d b g e') (guitar-seven-string . b,, e, a, d b g e') (guitar-drop-d . d, a, d g b e') (guitar-drop-c-tuning . c, g, c f a d') ... ) ) Disagree. The current solution has a constant visual pattern (just that it does not use whitespace for that). It's not significantly less readable on a pure visual basis (one might want to block-align the tuning names). However, your version is utterly incomprehensible on the basis of understanding what it does while the original version has each line stand for itself, with a readily readable _meaning_ of the line. It's not clear to me how an alist of tuning names and the associated string tunings is `utterly incomprehensible'... Oh well. It seems we have to agree to disagree. Your interpretation of readability greatly differs from what I perceive as well readable. All that ly:parser-include-string is actually on a level of code ugliness even below using primitive-eval because it pieces together stuff that is not even at a syntactical level. Yes, but exactly this is the power of `ly:parser-include-string'! It is a nice utility to use Scheme's iteration stuff (i.e., `for-each' and friends) while not too deeply diving into Scheme. Admittedly, we don't have to use such things in the lilypond init files; I accept your veto and won't further push into this direction. 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
[...] 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.
Indeed. Mhmm. I would define an auxiliary, temporary function
T = #(define-void-function (parser location name chord)
(string? ly:music?)
Auxiliary function to set up tunings.
(let ((sym (string-symbol (string-append name -tuning
#{ \makeDefaultStringTuning #sym \stringTuning #chord #}))
that simplifies
\makeDefaultStringTuning #'guitar-tuning \stringTuning e, a, d g b e'
to the much more readable
\T guitar e, a, d g b e'
The only thing I don't know how to remove this function after it has
been used – AFAIK, Scheme doesn't allow this, but what about LilyPond?
Can a tuning definition be continued on the next line? If so: how?
You can break a line at whitespace as you like.
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 w...@gnu.org writes:
[...] 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.
Indeed. Mhmm. I would define an auxiliary, temporary function
T = #(define-void-function (parser location name chord)
(string? ly:music?)
Auxiliary function to set up tunings.
(let ((sym (string-symbol (string-append name -tuning
#{ \makeDefaultStringTuning #sym \stringTuning #chord #}))
that simplifies
\makeDefaultStringTuning #'guitar-tuning \stringTuning e, a, d g b e'
to the much more readable
\T guitar e, a, d g b e'
You can write
\makeDefaultStringTuning guitar-tuning \stringTuning e, a, d g b e'
already. \T is not more readable but merely shorter. It would be
possible to redefine \makeDefaultStringTuning to _optionally_ allow
\makeDefaultStringTuning guitar-tuning e, a, d g b e'
as well. I don't believe in increasing readability by renaming
symbols into stuff that is not the same in definition and usage.
--
David Kastrup
___
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 rek...@elephly.net writes: 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. Add context definitions for the \midi output in a similar way you do for \layout. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add scheme engraver for StaffTab notation
that simplifies \makeDefaultStringTuning #'guitar-tuning \stringTuning e, a, d g b e' to the much more readable \T guitar e, a, d g b e' You can write \makeDefaultStringTuning guitar-tuning \stringTuning e, a, d g b e' already. \T is not more readable but merely shorter. Well, `merely shorter' in this is case *is* `more readable' to me. It would be possible to redefine \makeDefaultStringTuning to _optionally_ allow \makeDefaultStringTuning guitar-tuning e, a, d g b e' as well. Ah, this would help a bit. I don't believe in increasing readability by renaming symbols into stuff that is not the same in definition and usage. OK. What about this? #(for-each (lambda (elem) (let* ((sym (car elem)) (chord (cdr elem))) (ly:parser-include-string parser (string-append \\makeDefaultStringTuning sym -tuning \\stringTuning chord '((guitar . e, a, d b g e') (guitar-seven-string . b,, e, a, d b g e') (guitar-drop-d . d, a, d g b e') (guitar-drop-c-tuning . c, g, c f a d') ... ) ) Werner ___ 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 staff
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: [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
Re: scheme engraver for StaffTab notation
Am 07.01.2015 um 22:27 schrieb 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. Hi Ricardo, can you show as the engraver in action? I think *every* enhancement for LilyPond is great, so why not support Stickists? Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme engraver for StaffTab notation
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
