Re: Score.skipTypesetting
Hi Orm, On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl orm.finnend...@selma.hfmdk-frankfurt.de wrote: As the instrument names are short, lilypond must know that it isn't at the beginning of the piece. It would be preferrable to have unindented first staffs, as that would better resemble the final layout, if the typesetting (re)starts at linebreaks. LilyPond won't really try to guess something like this based on instrument names. If you start a new \score block LilyPond will create a new score, indented, at bar 1 etc., which is as it should be IMO (i.e. it behaves consistently rather than trying to guess your intentions). Multi-movement forms (suites, sonatas) frequently do this (start a new indented score on the same page). Sometimes it can be a good solution to use a new \score block in place of a line break in an existing score, in which case the best thing to do would be to continue as you are. If you post a snippet illustrating the problem then perhaps someone could suggest an alternative that you haven't thought of. hth, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Score.skipTypesetting
Hi Orm, I'm sorry I misunderstood your original message. I agree that it would be better if it did not indent in this case, but I don't know of any good workaround for it. Perhaps someone could request this as a feature. Kevin On Thu, Aug 13, 2015 at 2:12 PM, Orm Finnendahl orm.finnend...@selma.hfmdk-frankfurt.de wrote: Hi Barry, thanks for the answer. I might have been unclear: In a chamber music piece I'm writing, the first line of the score is (and should be) indented. While working on the score I want to typeset just the last part of the score and use Score.skipTypesetting = ##f in the beginning and set Score.skipTypesetting = ##t in some later part, e.g. after a \pageBreak. lilypond renders this partial score with the first line indented which is suboptimal as the beginning of this page will *not* get indented in the final (non partial) score. I was just proposing to fix that in case it's not very complicated. But as this is not a bug and I can circumvent this easily by setting the indentation to #0 when rendering partial scores I don't really want to start a bikeshed... -- Orm Am Donnerstag, den 13. August 2015 um 13:57:44 Uhr (+0100) schrieb Kevin Barry: Hi Orm, On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl orm.finnend...@selma.hfmdk-frankfurt.de wrote: As the instrument names are short, lilypond must know that it isn't at the beginning of the piece. It would be preferrable to have unindented first staffs, as that would better resemble the final layout, if the typesetting (re)starts at linebreaks. LilyPond won't really try to guess something like this based on instrument names. If you start a new \score block LilyPond will create a new score, indented, at bar 1 etc., which is as it should be IMO (i.e. it behaves consistently rather than trying to guess your intentions). Multi-movement forms (suites, sonatas) frequently do this (start a new indented score on the same page). Sometimes it can be a good solution to use a new \score block in place of a line break in an existing score, in which case the best thing to do would be to continue as you are. If you post a snippet illustrating the problem then perhaps someone could suggest an alternative that you haven't thought of. hth, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Score.skipTypesetting
Hi Barry, thanks for the answer. I might have been unclear: In a chamber music piece I'm writing, the first line of the score is (and should be) indented. While working on the score I want to typeset just the last part of the score and use Score.skipTypesetting = ##f in the beginning and set Score.skipTypesetting = ##t in some later part, e.g. after a \pageBreak. lilypond renders this partial score with the first line indented which is suboptimal as the beginning of this page will *not* get indented in the final (non partial) score. I was just proposing to fix that in case it's not very complicated. But as this is not a bug and I can circumvent this easily by setting the indentation to #0 when rendering partial scores I don't really want to start a bikeshed... -- Orm Am Donnerstag, den 13. August 2015 um 13:57:44 Uhr (+0100) schrieb Kevin Barry: Hi Orm, On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl orm.finnend...@selma.hfmdk-frankfurt.de wrote: As the instrument names are short, lilypond must know that it isn't at the beginning of the piece. It would be preferrable to have unindented first staffs, as that would better resemble the final layout, if the typesetting (re)starts at linebreaks. LilyPond won't really try to guess something like this based on instrument names. If you start a new \score block LilyPond will create a new score, indented, at bar 1 etc., which is as it should be IMO (i.e. it behaves consistently rather than trying to guess your intentions). Multi-movement forms (suites, sonatas) frequently do this (start a new indented score on the same page). Sometimes it can be a good solution to use a new \score block in place of a line break in an existing score, in which case the best thing to do would be to continue as you are. If you post a snippet illustrating the problem then perhaps someone could suggest an alternative that you haven't thought of. hth, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Score.skipTypesetting
Am 13.08.2015 um 15:12 schrieb Orm Finnendahl: Hi Barry, thanks for the answer. I might have been unclear: In a chamber music piece I'm writing, the first line of the score is (and should be) indented. While working on the score I want to typeset just the last part of the score and use Score.skipTypesetting = ##f in the beginning and set Score.skipTypesetting = ##t in some later part, e.g. after a \pageBreak. lilypond renders this partial score with the first line indented which is suboptimal as the beginning of this page will *not* get indented in the final (non partial) score. I was just proposing to fix that in case it's not very complicated. But as this is not a bug and I can circumvent this easily by setting the indentation to #0 when rendering partial scores I don't really want to start a bikeshed... Actually this is what I wanted to say too. Score.skipTypesetting is most surely used as a means for optimizing the workflow, and ideally you'd have the output a real excision of the compiled score - which is of course inherently impossible. But I would also prefer the output of such a compilation start with a regular (i.e. non-first) staff, that is without indentation, instrument names hidden measure number, and perhaps even time signature. I think this should be rather trivial to implement, either as skipTypesetting's default behaviour or in a new wrapper function. More involved (but maybe not impossible) would be the wish to automatically add missing spanner parts, e.g. starting dynamics or slurs etc. One thing I want to implement in Frescobaldi (rather soon, when our current manuscript viewer is finished) is a compilation mode where - one compilation writes the line and page breaks to a log file - subsequently any single system can be recompiled through skipTypesetting - while Frescobaldi determines the proper points for this using the log file - The compiled line will be replaced in the music view. For this I want to create a new viewing mode where a score is composed of a chain of systems without the notion of a page. This will work as long as the changes don't require the line breaking to change - which should be detectable. I hope that this will significantly smooth the user experience, although I know it's far from instant (for example LilyPond still has to interpret the whole score first, so engraving one system out of a 300 system score still takes a significant amount of time. For such an undertaking having the partially compiled score start just like from within the score (instead of creating a complete score) would be quite useful, although I can easily see a workaround (for my case): Compile one additional measure before and after the current system and insert manual line breaks. So I second Orm's feature request. Urs -- Orm Am Donnerstag, den 13. August 2015 um 13:57:44 Uhr (+0100) schrieb Kevin Barry: Hi Orm, On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl orm.finnend...@selma.hfmdk-frankfurt.de wrote: As the instrument names are short, lilypond must know that it isn't at the beginning of the piece. It would be preferrable to have unindented first staffs, as that would better resemble the final layout, if the typesetting (re)starts at linebreaks. LilyPond won't really try to guess something like this based on instrument names. If you start a new \score block LilyPond will create a new score, indented, at bar 1 etc., which is as it should be IMO (i.e. it behaves consistently rather than trying to guess your intentions). Multi-movement forms (suites, sonatas) frequently do this (start a new indented score on the same page). Sometimes it can be a good solution to use a new \score block in place of a line break in an existing score, in which case the best thing to do would be to continue as you are. If you post a snippet illustrating the problem then perhaps someone could suggest an alternative that you haven't thought of. hth, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with installed font when set-global-staff-size is changed
Jonathan
On 8/11/2015 5:15 PM, jonathan.scholbach [via Lilypond] wrote:
(Setting the font-sizes manually is necessary since for some unknown
reason, the font-size decreases.)
This is because virtually everything that has any kind of font property
is scaled relative to the staff-height. So, at 20pt staff-height, a 12pt
font looks just right, but at 17pt staff-height, it ends up being scaled
down to 12*(17/20) = 10.2pt. There are ways around this, though. Markups
have the \abs-fontsize macro, but there isn't a built-in one for
anything else, like Lyrics. A really nice macro was put together by Mike
Solomon so the absolute nature of font size can be applied to any
other kind of text object. Here's the code for it:
allowGrobCallback =
#(define-scheme-function (parser location syms) (symbol-list?)
(let ((interface (car syms))
(sym (cadr syms)))
#{
\with {
\consists #(lambda (context)
`((acknowledgers .
((,interface . ,(lambda (engraver grob source-engraver)
(let ((prop (ly:grob-property grob sym)))
(if (procedure? prop) (ly:grob-set-property! grob sym
(prop grob)))
)))
}
#}))
absFontSize =
#(define-scheme-function (parser location pt)(number?)
(lambda (grob)
(let* ((layout (ly:grob-layout grob))
(ref-size (ly:output-def-lookup (ly:grob-layout grob)
'text-font-size 12)))
(magnification-font-size (/ pt ref-size))
)))
\layout {
\context {
\Score
\allowGrobCallback font-interface.font-size
}
}
which you then can use like this:
\override LyricText.font-size = \absFontSize 11.5
Without this, then to get back up to 12pt you'd need to manually
increase the font-size, which is what you've learned already.
Regards,
Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/problem-with-installed-font-when-set-global-staff-size-is-changed-tp179484p179539.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
PDF properties
Hi, lately there was a mail on this list about PDF properties/headers. I tried them and it seems like the PDF author field is filled with the composer. This is nice fall back but in most cases the author of the document and the composer will be different. Of course, I can write pdfcomposer = Author Name Then it appears correctly as /Author(Author Name) But it also appears as /Composer(Author Name) which is wrong. Wouldn't it make sense to offer both fields: Author and Composer? A fallback if no author is given makes sense but it would be good to be able to specify an author differing from the composer. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Score.skipTypesetting
At 15:12 13/08/2015 +0200, Orm Finnendahl wrote: In a chamber music piece I'm writing, the first line of the score is (and should be) indented. While working on the score I want to typeset just the last part of the score and use Score.skipTypesetting = ##f in the beginning and set Score.skipTypesetting = ##t in some later part, e.g. after a \pageBreak. lilypond renders this partial score with the first line indented which is suboptimal as the beginning of this page will *not* get indented in the final (non partial) score. Wouldn't a (slightly messy) workaround be to position the restart of typesetting at a point before the page break - and perhaps a bar or two before that? You'd get a first, rubbish page, but the part you do want should be closer to how it will appear in the final copy. Brian Barker ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Centering a stencil on another stencil
Here’s another possibility that uses an optional axis argument. -Paul
\version 2.19.22
#(define* (center-stencil-on-stencil stil-a stil-b #:optional axis)
Return a copy of stencil @var{stil-b} that has been moved
so it is centered on stencil @var{stil-a} on @var{axis}. When
@var{axis} is omitted, the centering is done on both X and
Y axes. @var{axis} is 0 for X axis, 1 for Y axis.
(if axis
;; center on one axis only
(ly:stencil-translate-axis
(ly:stencil-aligned-to stil-b axis CENTER)
(interval-center (ly:stencil-extent stil-a axis))
axis)
;; center on both X and Y axes
(ly:stencil-translate
(centered-stencil stil-b)
(cons
(interval-center (ly:stencil-extent stil-a X))
(interval-center (ly:stencil-extent stil-a Y))
square =
#(make-connected-path-stencil
'((0 0) (4 0) (4 4) (0 4) (0 0))
0.4 1 1 #f #f)
blue-square =
#(stencil-with-color (make-filled-box-stencil '(0.4 . 2) '(0.4 . 2)) blue)
\markup
\override #'(word-space . 3)
\line {
\stencil #(ly:stencil-add square blue-square)
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square X))
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square Y))
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square))
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Sat, 25 Jul 2015 02:18:40 +0200
David Kastrup d...@gnu.org wrote:
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hi all,
I’m no Scheme expert, of course… but it seems there should be
a relatively easy way to code a music function which says
“take all pitches [entered as ’naturals’] and add any
accidentals which exist in the corresponding key signature
entry for that pitch class”, no? i.e., if the input is ‘c’,
and there’s a C# in the key signature, output cis; if the
input is ‘d’, and there’s a Db in the key signature, output
des; etc.
What _is_ the current key signature?
\key a \major \transpose c d { \key f \major \transpose d f { a
b c d e f g } }
What should the result be? Is f \major supposed to be fis
\major ? Are we talking about \transpose cis d or \transpose c
d ?
You can define rules LilyPond will be able to follow, sure.
But at what point will they stop making sense to humans and
other tools?
If this input were wrapped in a function, then the final
input code would really be no less readable/manipulable than
if it were wrapped in a \transpose.
Just a thought,
Getting dogmatic about LilyPond's input language and declaring
it as God-given at least has the advantage that one avoids
extended discussions about recurring bad ideas every three
months.
Where would Bach's Kunst der Fuge had been if b a c h had
not spelled out a theme unambiguously? I'm sure if I think
hard enough, I can come up with more strained references to
authority to bolster my case.
I am no expert but it seems there should be a relatively easy
way is a good way to start sentences that will cause actual
experts to go into conniptions.
You don't want to go there is something nobody ever believes
me, so I have to settle for if you want to go there, you'll
need to learn how to do it yourself, and by the time you know
how to do it, you'll understand why it's a bad idea.
Was the key signature a bad idea? Writing music by hand, do you
write all the chromatic signs or write a key signature? The only
difference with writing and typing is that a program can type
whatever chromatic signs you want in for you.
Kindest regards, Rale
--
Guitar teaching materials and original music for all styles and
levels. Site: http://www.openguitar.com (()) eMail:
d.raleigh.arn...@gmail.com Contact:
http://www.openguitar.com/contact.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Sat, 25 Jul 2015 00:31:42 +0200 Hans Aberg haber...@telia.com wrote: On 25 Jul 2015, at 00:18, Brother Gabriel-Marie brgabr...@sspx.org wrote: My problem was a coding issue, not a musical issue. I wanted a coding solution to save keystrokes but everyone wanted to talk music theory. If you use \language english then flats are suffix “f” and sharps “s”, so that saves keystrokes. I hate that f. b for flats makes more sense to me, and I use that sometimes too. And IMO the option of using # for sharps would be a good idea. That makes a language suitable for indicating music to be written by hand or quoting a few notes or chords in text. If it could be used to enter notes in lilypond as well, it would be very much more useful, IMO. I'd call it American-International. Kindest regards, Rale -- Guitar teaching materials and original music for all styles and levels. Site: http://www.openguitar.com (()) eMail: d.raleigh.arn...@gmail.com Contact: http://www.openguitar.com/contact.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Mon, 10 Aug 2015 07:18:18 +0200
David Kastrup d...@gnu.org wrote:
David Raleigh Arnold d...@openguitar.com writes:
On Thu, 23 Jul 2015 11:33:50 -0500
Brother Gabriel-Marie brgabr...@sspx.org wrote:
When you use key signatures like A major or B Major you end
up with a lot of naturals in the score for which you may
have to manually add sharps.
Is there a switch that will automatically sharp all the
naturals?
I was looking at this:
http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals
This was the closest I could see:
\accidentalStyle modern
The developers have resisted this from the beginning, because
they don't realize how easy it would be. There may be also a
certain contempt for the user or composer who is not expected
to know what key he's in.
Well, at some point of time you'll need to decide yourself
whether LilyPond's semantics are due to stupidity or to
malice. It seems a bit greedy to claim both.
At any rate, it is more a certain contempt for the computer
that is not expected to know what key it's in. Instead, it
uses accidental rules at the time of typesetting (not even
iteration) in order to figure out the best graphical
representation for the pitch. That's not infallible as issues
like
URL:https://code.google.com/p/lilypond/issues/detail?id=1134
show.
That reminder and cautionary accidentals are an integral part
of music typesetting would tend to give some indication that
humans share those problems.
At any rate, I cannot find a single commit in all of LilyPond's
code base attributed to you.
Wouldn't it be more convincing if you were able to back up your
better understanding of the involved matters with actual code?
It's not involved. It just saves typing. Kindest regards, Rale
# keys.sed
# Writes chromatic signs according to key for _single letter_ notes
# within a range begun with, for examples: Key2#, Key3b, Keynn, and
# ended with: Key0 (0=zero). There is no transposition, but you can use
# a different key indication from lilypond's. Writes english.ly but
# you may enter b (or f) for flat, bb (or w) for double flat,
# and # (or s) for sharp, but only x for double sharp. Use 'n' to
# protect an accidental natural. You may enter h, b, or bn, but
# there is no h#. These alternative language choices are both easier
# to read and quicker to write than lilypond input, but lilypond is not
# the only use for these alternatives.
# More shortcuts, etc., inside range:
# r=a4 will become a4\rest
# V3 = \voiceThree
# Outside range:
# %% -- all lines starting thus will be deleted. NB space
# (c)2005 David Raleigh Arnold. --GNU Enjoy! rev. 20100528
# comments: del from whole file
/^%% .*/d
# key range -- top
/Key[1-7n][b#n]/,/Key0/{
# branch to fall off end--problem dumb mistake?
#/%.*/b
### Format:
# no tabs
s/\t/ /g
# space follows/precedes curly, pointer, to prettify.
s/[{]/ /g
s/[}]/ /g
# put spaces at begin and end of line, double spaces inside
# to simplify process of note names
s/ */ /g
s/^ */ /
s/ *$/ /
### Actions
# change # to s with notes
s/\( [a-g]\)#/\1s/g
# make r=a4 into a4\rest. Work with R?
s/ r=\([a-g]\)\([^ ]*\) / \1n\2\\rest /g
# voices
s/V1/\\voiceOne/g
s/V2/\\voiceTwo/g
s/V3/\\voiceThree/g
s/V4/\\voiceFour/g
s/V0/\\oneVoice/g
# mark single letter notes only. Accidentals will
# be added as they fall into the right key.
s/\( [a-g]\)\([^wbfnxs#]\)/\1%flatORsharp%\2/g
# goto (branch) and fall through
/Key7b/,/Key0/b keycb
/Key6b/,/Key0/b keygb
/Key5b/,/Key0/b keydb
/Key4b/,/Key0/b keyab
/Key3b/,/Key0/b keyeb
/Key2b/,/Key0/b keybb
/Key1b/,/Key0/b keyfn
/Key7#/,/Key0/b keycs
/Key6#/,/Key0/b keyfs
/Key5#/,/Key0/b keybn
/Key4#/,/Key0/b keyen
/Key3#/,/Key0/b keyan
/Key2#/,/Key0/b keydn
/Key1#/,/Key0/b keygn
/Keynn/,/Key0/b finish
:keycb
s/f%flatORsharp%/f%flat%/g
:keygb
s/c%flatORsharp%/c%flat%/g
:keydb
s/g%flatORsharp%/g%flat%/g
:keyab
s/d%flatORsharp%/d%flat%/g
:keyeb
s/a%flatORsharp%/a%flat%/g
:keybb
s/e%flatORsharp%/e%flat%/g
:keyfn
s/b%flatORsharp%/b%flat%/g
b finish
:keycs
s/b%flatORsharp%/b%sharp%/g
:keyfs
s/e%flatORsharp%/e%sharp%/g
:keybn
s/a%flatORsharp%/a%sharp%/g
:keyen
s/d%flatORsharp%/d%sharp%/g
:keyan
s/g%flatORsharp%/g%sharp%/g
:keydn
s/c%flatORsharp%/c%sharp%/g
:keygn
s/f%flatORsharp%/f%sharp%/g
:finish
# could leave out next line for debugging;
s/%flatORsharp%//g
# output english.ly. You can easily convert to
# any other language you want.
# flat is f
s/%flat%/f/g
# conversions:
s/ h/ bn/g
s/\( [a-g]\)b/ \1f/g
s/\( [a-g]\)w/ \1ff/g
s/\( [a-g]\)bb/ \1ff/g
# sharp is s
s/%sharp%/s/g
# ss or x should not require action
# clean up. Getting rid of n's
s/\( [a-g]\)n/\1/g
# finger number in front of one note: use -hyphen
# 2? so it can't be done twice?. notes are done already
s/\( [a-g][^- \t]*\)-\([1-4]\)/ \\fol \1-\2/g
# include lynn
# reformat
s/{ */{ /g
s/ */ /g
s/ */ /g
s/ *}/ }/g
s/{ *{/{{/g
s/{ *{/{{/g
s/}
Re: sharping naturals
On Sat, 25 Jul 2015 09:35:44 +0200
Malte Meyn lilyp...@maltemeyn.de wrote:
Am 25.07.2015 um 01:32 schrieb Kieren MacMillan:
I’m no Scheme expert, of course… but it seems there should be
a relatively easy way to code a music function which says
“take all pitches [entered as ’naturals’] and add any
accidentals which exist in the corresponding key signature
entry for that pitch class”, no? i.e., if the input is ‘c’,
and there’s a C# in the key signature, output cis; if the
input is ‘d’, and there’s a Db in the key signature, output
des; etc.
What you can do is something like
bmajoraccidentals = { c cis d dis f fis g gis a ais }
\modalTranspose c cis \bmajoraccidentals \relative {
\key b \major
b c d e f g a b
}
So you don’t even need a new function. But that’s very
unflexible as it doesn’t allow you to enter pitches other than
b cis dis e fis gis ais, bis, eis, and all the flats. But you
won’t get it much more flexible even with a new function.
\key a Major ... \follow gs cs ff {...
More flexible, but insane in the example.
Kindest regards, Rale
--
Guitar teaching materials and original music for all styles and
levels. Site: http://www.openguitar.com (()) eMail:
d.raleigh.arn...@gmail.com Contact:
http://www.openguitar.com/contact.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Fri, 24 Jul 2015 14:20:24 +0200 David Kastrup d...@gnu.org wrote: Robert Schmaus robert.schm...@web.de writes: I wasn't being rude, Rudeness is determined at the receiving end of a communication. The best you can say is that you did not intend to be rude. just reminding the guy what his patron saint considers to be objective, absolute, and immutable truth. Which everyone's free to believe ... as long as they keep it to themselves. And then I have my problems even reconciling that with what you write here. Rude would be to badmouth guys (like you me) for trying to help - the advice on SE was pretty much the same as from the list - because they suggested that you might not understand what you're doing. LilyPond's notename philosophy happens to be from a culture remote from the English speaking world. In Dutch or German, you never, ever, would call a cis anything other than cis. It's not a c sharp, namely some qualified c. That's a totally different note and name. There is no such thing as a c natural when talking about notes. It's either c or not. You don't need to specify the key signature when discussing a chord: all note names are absolute. Always. LilyPond is internationalized in that it offers English notenames, but it does not offer the accompanying notename philosophy. And the fuzziness coming with such a philosophy is not helpful in the context of a computer description of music, so it's not all that likely that this will ever change. But that does not mean that other philosophies are only entertained by idiots, so there is no necessity of letting that kind of vibe come off here. The best advice with regard to dealing with LilyPond's notename philosophy is to get used to it. LilyPond editing tools may give offer some of the efficiency advantages of more flexible naming philosophies without having ambiguities creep into the resulting input text. As for tolerance: I agree I shouldn't have made the remark in the first place. This is not the place for it, so sorry to everyone for the extra mails. But the Pius Brothers are about as tolerant as the IS when it comes to anything outside their objective, absolute truths (note the plural), so I simply couldn't suppress the urge. This mailing list is not the place for trying to propagate your religious affiliations. People are invited to communicate here about LilyPond without having to hide their gender, religion, nationality and other parts of their identity. It may be worth mentioning that one priest who was grateful for LilyPond allowing him to prepare scores suitable for the eyesight of his older brethren gave me some part of his modest remaining possessions when he took his vow of poverty. Different religious convictions do not preclude us from treating each other with respect. Even if it means suppressing your urges. Let's not forget that the whole idea of being civilized is not being a slave to your urges. Just a reminder from a Buddhist that if it weren't for the Christian church, we would not have music notation. We'd be stuck with tablature like every other society. Kindest regards, Rale -- Guitar teaching materials and original music for all styles and levels. Site: http://www.openguitar.com (()) eMail: d.raleigh.arn...@gmail.com Contact: http://www.openguitar.com/contact.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Centering a stencil on another stencil
Hi Harm, On Aug 13, 2015, at 3:43 PM, Thomas Morley thomasmorle...@gmail.com wrote: I like this best and would go for it. Sounds good ...and done: http://lsr.di.unimi.it/LSR/Item?id=1009 Regretable my vacations ended. Meaning I've reasonable less time :( I suppose all good things must come to an end… Hope they went well! Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Sat, 25 Jul 2015 12:07:19 +0200 David Kastrup d...@gnu.org wrote: Wols Lists antli...@youngman.org.uk writes: On 25/07/15 08:04, David Kastrup wrote: If we wanted to support natural English note entry, it would become LilyPond's problem. As an irrelevant aside :-) Throwing another little spanner in the works - about what words mean ... I really hate it when people say English, and mean American ... (yes, we use the same names for pitch, but we do not use the same names for length ...) Because UK went metric and the US loves the royals so much they stuck with Imperial? At any rate, Americans tend to write C4 instead of c' so I am not sure why you are objecting against my characterization. Along with France, the U. S. was the first country to officially adopt the metric system. We each have meter bars. Unfortunately, the implementation has been delayed. How could anything like that happen? Kindest regards, Rale- -- Guitar teaching materials and original music for all styles and levels. Site: http://www.openguitar.com (()) eMail: d.raleigh.arn...@gmail.com Contact: http://www.openguitar.com/contact.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Mon, 10 Aug 2015 13:47:34 +0200
David Kastrup d...@gnu.org wrote:
Thomas Morley thomasmorle...@gmail.com writes:
If I understand correctly your proposal is that
\language english
m = { ff' f' fs' }
\m
\follow fs \m
\follow ff \m
will be printed different.
Well, it would be more likely
\follow fs \m
\follow ff \m
here. That would be _one_ basic idea of implementation. This
one would mark non-explicit pitches c d e f g a b specially so
that \follow can distinguish them from cn dn en fn gn an bn.
The unspecificness would be kept in the music. How and when
should it get resolved when there is no \follow involved at
all? What happens if we \transpose music containing unspecific
pitches?
Why make it hard? The aim is just to have the option of
\follow-ing the key signature, and that must be all done before
\transpose or any other choices are made.
Another implementation would be to keep the music expressions
unambiguous and instead use a different notename language
variant, perhaps invoking it like
\language \key a \major english
which will redefine all unspecific note names in
correspondence with the key. Or maybe just
\languagekey a \major
It's just a 14 item hash table for each language. The n could
be the same everywhere, since it's in no language anyway, or, if
I'm wrong about that, make it 15 items.
That will basically make the typical document be written in a
large variety of notename languages which makes for a lot of
fun when editing and/or copy/pasting motives around.
This is an advantage of keeping it an editing tool. You have a
few now, none as useful as this, to me anyway.
In
particular, editing functionality like that of Frescobaldi
(which may be asked to transpose passages for the user) will
become unreliable, and the inability of an external tool to
figure out the right pitches without context of course is
matched by a similar potential for confusing users.
Again, without \key, \follow makes no sense.
In my thinking that's absolute crude.
Though, obviously there are other opinions about that.
Patches are always welcome.
But one needs to be warned that they may meet resistance to
acceptance, so there is some sense in figuring out the other
developers' opinions before investing a lot of work, at least
if one's ultimate goal is the inclusion as an integral part of
the standard LilyPond distribution.
A somewhat smaller but comparable can of worms is \relative
mode. A frequent topic on the mailing list is how do I make my
music functions work in \relative mode? and often answers are
not straightforward. Many LSR snippets work only either in
absolute mode or in relative mode, and not necessarily reliably
so.
An editing tool should do the conversion before lilypond goes
cattywampus. And what is the purpose of \relative? To save typing.
So it is pretty much established that the music-based approach
comes with a healthy load of problems, and the input language
based approach, while condensing most of the problems in one
place, makes source code management a headache because each
source code passage comes with its own associated input
language.
The inclusion of \relative or \follow need not cause difficulties
if conversions from them can be supplied to the user as
part of the editing process. Both are basically editing tools
which need not be allowed to cause problems with ensuing
processes.
Kindest regards, Rale
--
Guitar teaching materials and original music for all styles and
levels. Site: http://www.openguitar.com (()) eMail:
d.raleigh.arn...@gmail.com Contact:
http://www.openguitar.com/contact.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Fri, 24 Jul 2015 17:18:09 -0500
Brother Gabriel-Marie brgabr...@sspx.org wrote:
Mr. Schmaus,
My problem was a coding issue, not a musical issue.
I wanted a coding solution to save keystrokes but everyone
wanted to talk music theory.
So I thought I would ask here where everyone knows both.
In the end, I've learned that there's no easy coding
solution and that I'm going to have to sharp all the
naturals myself in the code. I am used to programming
languages where you can wrap a string in a custom function
and have it do that for you; moving from regular programming
languages to a layout code like this requires one to think
differently.
But you can play with it before lilypond sees it:
# keys.sed
# Writes chromatic signs according to key for _single letter_ notes
# within a range begun with, for examples: Key2#, Key3b, Keynn, and
# ended with: Key0 (0=zero). There is no transposition, but you can use
# a different key indication from lilypond's. Writes english.ly but
# you may enter b (or f) for flat, bb (or w) for double flat,
# and # (or s) for sharp, but only x for double sharp. Use 'n' to
# protect an accidental natural. You may enter h, b, or bn, but
# there is no h#. These alternative language choices are both easier
# to read and quicker to write than lilypond input, but lilypond is not
# the only use for these alternatives.
# More shortcuts, etc., inside range:
# r=a4 will become a4\rest
# V3 = \voiceThree
# Outside range:
# %% -- all lines starting thus will be deleted. NB space
# (c)2005 David Raleigh Arnold. --GNU Enjoy! rev. 20100528
# comments: del from whole file
/^%% .*/d
# key range -- top
/Key[1-7n][b#n]/,/Key0/{
# branch to fall off end--problem dumb mistake?
#/%.*/b
### Format:
# no tabs
s/\t/ /g
# space follows/precedes curly, pointer, to prettify.
s/[{]/ /g
s/[}]/ /g
# put spaces at begin and end of line, double spaces inside
# to simplify process of note names
s/ */ /g
s/^ */ /
s/ *$/ /
### Actions
# change # to s with notes
s/\( [a-g]\)#/\1s/g
# make r=a4 into a4\rest. Work with R?
s/ r=\([a-g]\)\([^ ]*\) / \1n\2\\rest /g
# voices
s/V1/\\voiceOne/g
s/V2/\\voiceTwo/g
s/V3/\\voiceThree/g
s/V4/\\voiceFour/g
s/V0/\\oneVoice/g
# mark single letter notes only. Accidentals will
# be added as they fall into the right key.
s/\( [a-g]\)\([^wbfnxs#]\)/\1%flatORsharp%\2/g
# goto (branch) and fall through
/Key7b/,/Key0/b keycb
/Key6b/,/Key0/b keygb
/Key5b/,/Key0/b keydb
/Key4b/,/Key0/b keyab
/Key3b/,/Key0/b keyeb
/Key2b/,/Key0/b keybb
/Key1b/,/Key0/b keyfn
/Key7#/,/Key0/b keycs
/Key6#/,/Key0/b keyfs
/Key5#/,/Key0/b keybn
/Key4#/,/Key0/b keyen
/Key3#/,/Key0/b keyan
/Key2#/,/Key0/b keydn
/Key1#/,/Key0/b keygn
/Keynn/,/Key0/b finish
:keycb
s/f%flatORsharp%/f%flat%/g
:keygb
s/c%flatORsharp%/c%flat%/g
:keydb
s/g%flatORsharp%/g%flat%/g
:keyab
s/d%flatORsharp%/d%flat%/g
:keyeb
s/a%flatORsharp%/a%flat%/g
:keybb
s/e%flatORsharp%/e%flat%/g
:keyfn
s/b%flatORsharp%/b%flat%/g
b finish
:keycs
s/b%flatORsharp%/b%sharp%/g
:keyfs
s/e%flatORsharp%/e%sharp%/g
:keybn
s/a%flatORsharp%/a%sharp%/g
:keyen
s/d%flatORsharp%/d%sharp%/g
:keyan
s/g%flatORsharp%/g%sharp%/g
:keydn
s/c%flatORsharp%/c%sharp%/g
:keygn
s/f%flatORsharp%/f%sharp%/g
:finish
# could leave out next line for debugging;
s/%flatORsharp%//g
# output english.ly. You can easily convert to
# any other language you want.
# flat is f
s/%flat%/f/g
# conversions:
s/ h/ bn/g
s/\( [a-g]\)b/ \1f/g
s/\( [a-g]\)w/ \1ff/g
s/\( [a-g]\)bb/ \1ff/g
# sharp is s
s/%sharp%/s/g
# ss or x should not require action
# clean up. Getting rid of n's
s/\( [a-g]\)n/\1/g
# finger number in front of one note: use -hyphen
# 2? so it can't be done twice?. notes are done already
s/\( [a-g][^- \t]*\)-\([1-4]\)/ \\fol \1-\2/g
# include lynn
# reformat
s/{ */{ /g
s/ */ /g
s/ */ /g
s/ *}/ }/g
s/{ *{/{{/g
s/{ *{/{{/g
s/} *}/}}/g
s/} *}/}}/g
# undo spaces at begin and end of line, double spaces
# restore polyphony construction.
s/^ *//
s/*$//
s/ */ /g
s/ * *{/{/g
s/} * */}/g
s/} * *{/}{/g
# put back these tabs
s/^[|]/\t|/
# get rid of flags
/Key[0-7n][b#n]/d
/Key0/d
# quit
/QUIT/,${
d
}
} # end of range
BTW, I think that what confused the multitude was your terming
chromatic signs accidentals. Then I went and made the same
mistake in my first reply, but fortunately not consistently.
Kindest regards, Rale
--
Guitar teaching materials and original music for all styles and
levels. Site: http://www.openguitar.com (()) eMail:
d.raleigh.arn...@gmail.com Contact:
http://www.openguitar.com/contact.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Centering a stencil on another stencil
2015-08-14 0:40 GMT+02:00 Paul Morris p...@paulwmorris.com: Hi Harm, On Aug 13, 2015, at 3:43 PM, Thomas Morley thomasmorle...@gmail.com wrote: I like this best and would go for it. Sounds good ...and done: http://lsr.di.unimi.it/LSR/Item?id=1009 Approved as http://lsr.di.unimi.it/LSR/Item?u=1id=1009 Best, Harm Regretable my vacations ended. Meaning I've reasonable less time :( I suppose all good things must come to an end… Hope they went well! Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Mon, 10 Aug 2015 14:36:42 +0200
David Kastrup d...@gnu.org wrote:
Thomas Morley thomasmorle...@gmail.com writes:
2015-08-10 13:47 GMT+02:00 David Kastrup d...@gnu.org:
So it is pretty much established that the music-based
approach comes with a healthy load of problems, and the
input language based approach, while condensing most of the
problems in one place, makes source code management a
headache because each source code passage comes with its own
associated input language.
Well, I will not work on such a patch. I already had a hard
time to understand the thinking behind the proposal.
It's not all that hard to do. Just let \key run through the
current notename language and replace all single-character note
names with the setting from the new key (Germans would likely
be furious about what this does to b but then they are hardly
the target for such a change).
Once you start arranging your input in variables (\global
anyone?), work with multiple voices and transpositions, things
will start to fall apart.
Even things like \transpose c f become ambiguous since they
could mean \transpose cn fs when uttered in \key gn \major.
Though, at a lower level one could start adding a snippet to
the LSR so that users can play around with it. Rale mentioned
some, but refused to post links...
s/refused/omitted/. I cannot remember anybody asking for such
links yet, so one can hardly accuse him of refusing.
Without \key, no \follow would make sense. I believe I sent my
little tool to this list some time ago, but here it is again. To
do it with other languages in my suggested crude fashion would
require a 14 or 15 item hash table for each language. Listing the
notes to be substituted would simplify implementation and
understanding of what \follow would do.
I was not insulted by calling it crude it certainly is, but it's
worked well for me. I hadn't had \follow suggested at the time. I hope
this version still works. Kindest
regards, Rale
# keys.sed
# Writes chromatic signs according to key for _single letter_ notes
# within a range begun with, for examples: Key2#, Key3b, Keynn, and
# ended with: Key0 (0=zero). There is no transposition, but you can use
# a different key indication from lilypond's. Writes english.ly but
# you may enter b (or f) for flat, bb (or w) for double flat,
# and # (or s) for sharp, but only x for double sharp. Use 'n' to
# protect an accidental natural. You may enter h, b, or bn, but
# there is no h#. These alternative language choices are both easier
# to read and quicker to write than lilypond input, but lilypond is not
# the only use for these alternatives.
# More shortcuts, etc., inside range:
# r=a4 will become a4\rest
# V3 = \voiceThree
# Outside range:
# %% -- all lines starting thus will be deleted. NB space
# (c)2005 David Raleigh Arnold. --GNU Enjoy! rev. 20100528
# comments: del from whole file
/^%% .*/d
# key range -- top
/Key[1-7n][b#n]/,/Key0/{
# branch to fall off end--problem dumb mistake?
#/%.*/b
### Format:
# no tabs
s/\t/ /g
# space follows/precedes curly, pointer, to prettify.
s/[{]/ /g
s/[}]/ /g
# put spaces at begin and end of line, double spaces inside
# to simplify process of note names
s/ */ /g
s/^ */ /
s/ *$/ /
### Actions
# change # to s with notes
s/\( [a-g]\)#/\1s/g
# make r=a4 into a4\rest. Work with R?
s/ r=\([a-g]\)\([^ ]*\) / \1n\2\\rest /g
# voices
s/V1/\\voiceOne/g
s/V2/\\voiceTwo/g
s/V3/\\voiceThree/g
s/V4/\\voiceFour/g
s/V0/\\oneVoice/g
# mark single letter notes only. Accidentals will
# be added as they fall into the right key.
s/\( [a-g]\)\([^wbfnxs#]\)/\1%flatORsharp%\2/g
# goto (branch) and fall through
/Key7b/,/Key0/b keycb
/Key6b/,/Key0/b keygb
/Key5b/,/Key0/b keydb
/Key4b/,/Key0/b keyab
/Key3b/,/Key0/b keyeb
/Key2b/,/Key0/b keybb
/Key1b/,/Key0/b keyfn
/Key7#/,/Key0/b keycs
/Key6#/,/Key0/b keyfs
/Key5#/,/Key0/b keybn
/Key4#/,/Key0/b keyen
/Key3#/,/Key0/b keyan
/Key2#/,/Key0/b keydn
/Key1#/,/Key0/b keygn
/Keynn/,/Key0/b finish
:keycb
s/f%flatORsharp%/f%flat%/g
:keygb
s/c%flatORsharp%/c%flat%/g
:keydb
s/g%flatORsharp%/g%flat%/g
:keyab
s/d%flatORsharp%/d%flat%/g
:keyeb
s/a%flatORsharp%/a%flat%/g
:keybb
s/e%flatORsharp%/e%flat%/g
:keyfn
s/b%flatORsharp%/b%flat%/g
b finish
:keycs
s/b%flatORsharp%/b%sharp%/g
:keyfs
s/e%flatORsharp%/e%sharp%/g
:keybn
s/a%flatORsharp%/a%sharp%/g
:keyen
s/d%flatORsharp%/d%sharp%/g
:keyan
s/g%flatORsharp%/g%sharp%/g
:keydn
s/c%flatORsharp%/c%sharp%/g
:keygn
s/f%flatORsharp%/f%sharp%/g
:finish
# could leave out next line for debugging;
s/%flatORsharp%//g
# output english.ly. You can easily convert to
# any other language you want.
# flat is f
s/%flat%/f/g
# conversions:
s/ h/ bn/g
s/\( [a-g]\)b/ \1f/g
s/\( [a-g]\)w/ \1ff/g
s/\( [a-g]\)bb/ \1ff/g
# sharp is s
s/%sharp%/s/g
# ss or x should not require action
# clean up. Getting rid of n's
s/\( [a-g]\)n/\1/g
# finger number in front of one note: use -hyphen
# 2? so it can't be done
Re: arabic tabs?
2015-08-12 13:49 GMT+02:00 BB bb-543...@telecolumbus.net:
Thank you very much for your Help with your code! Your code works fine,
here is an example code:
oud = \stringTuning f a d' g' c'' f''
% https://en.wikipedia.org/wiki/Rast_%28maqam%29
RastC = {
\relative c'
{
c d eqf f g a bqf c |
c d eqf f g a bqf c |
}
%\break
}
\new Staff
% \clef G_8
^Rast on C
\RastC
\new TabStaff
\set TabStaff.stringTunings = #oud
\tabFullNotation
\RastC
\new Staff
% \clef G_8
^Rast on D
\transpose c d
\RastC
\new TabStaff
\set TabStaff.stringTunings = #oud
\tabFullNotation
\transpose c d
\RastC
The mnemonic is great compared to makam.ly and arabic.ly. So I always give
your solution preference ove the other both. Should become part of lilypond,
2.10.1 Common notation for non-Western music!
the use goes far bejond only just oriental music notation! One might use it
for music with extended quarter-tone music. What is bejond that ? How to
notate sixth-tone?
I can work with the turkish way of notation, but I would prefer the arabic
notation of quarter tones. Is that possible to change in a somple way?
Glad to hear my coding works for you.
Though, I've no knowledge in microtonal music at all.
All I did was to let the TabStaff print positions like 1½ etc.
I've even no clue, whether the result is correct and would need you
and others for feedback about it.
But if you have a look into makam.ly you see how pitches and names are
defined. You could do similiar to create own names and pitches.
TabStaff _should_ then display them correctly, if not report it.
No idea about midi, though...
Just for information , the word makam
https://en.wikipedia.org/wiki/Makam
is used for the turkish way of notation, whereas the word maqam
https://en.wikipedia.org/wiki/Arabic_maqam
is used by the arabs for the arab way of notation. (In the wikipedia article
for maqam the notation is not consistent, as it uses turish/arabic notation
mixed. Better have a look at
http://maqamworld.com/
for the arabic way of notation.
So, the file makam.ly at least is a misnomer! Should be maqam.ly. (Not
really important, but may be inetresting in detail.)
Thanks again,
BB
On 10.08.2015 23:52, Thomas Morley wrote:
Hi,
attached you'll find my attempt for a such a tab.
It's based on `determine-frets' from translation-functions.scm
There's surely wide room for improvements and maybe the one or other glitch
...
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Mon, 10 Aug 2015 13:05:15 +0200
Thomas Morley thomasmorle...@gmail.com wrote:
2015-08-10 3:05 GMT+02:00 David Raleigh Arnold
d...@openguitar.com:
On Thu, 23 Jul 2015 11:33:50 -0500
Brother Gabriel-Marie brgabr...@sspx.org wrote:
When you use key signatures like A major or B Major you end
up with a lot of naturals in the score for which you may
have to manually add sharps.
Is there a switch that will automatically sharp all the
naturals?
I was looking at this:
http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals
This was the closest I could see:
\accidentalStyle modern
Hi Rale,
I hesitated to post in this thread for some reasons.
One reason was, I had no clue what it was about. I simply did
not understand the question.
In an earlier post David Kastrup wrote about different thinking
about note-names due to language and culture. It really helped
me to understand that Brother Gabriel-Marie expected
{ key a \major c }
to print what I'd call a cis.
I never ever would have had that expectation, but after David
K's post I can understand the thinking, at least.
Let me quote this part of his post again:
2015-07-24 14:20 GMT+02:00 David Kastrup d...@gnu.org:
[...]
LilyPond's notename philosophy happens to be from a culture
remote from the English speaking world. In Dutch or German,
you never, ever, would call a cis anything other than
cis. It's not a c sharp, namely some qualified c.
That's a totally different note and name. There is no such
thing as a c natural when talking about notes. It's either
c or not. You don't need to specify the key signature when
discussing a chord: all note names are absolute. Always.
LilyPond is internationalized in that it offers English
notenames, but it does not offer the accompanying notename
philosophy. And the fuzziness coming with such a philosophy
is not helpful in the context of a computer description of
music, so it's not all that likely that this will ever change.
[...]
I'd suggest you read it again und try to understand.
I answer every one of his points below:
The developers have resisted this from the beginning, because
they don't realize how easy it would be.
I really doubt.
There may be also a
certain contempt for the user or composer who is not expected
to know what key he's in.
This is bullshit, sorry.
There are editing tools which will add the
chromatic signs for you. I posted one on this list some time
ago, a bash script using sed. Nicholas Sceaux has written
one. It may be that the Garibaldi editor will do it, I don't
know.
The appropriate notes are sharped or flatted unless there is
an n or any other chromatic sign. That's it. Simple, fault
tolerant, and not requiring any changes at all to the many
choices already present in lilypond.
\follow {} has been suggested as the command. I would suggest
that \follow indicate which notes with the sharp or flat, as
\follow fs cs gs {music}
to avoid language problems as much as possible.
It is possible that a piece may have so many of certain
accidentals that \follow would be more trouble unless you lied
about the key. You would probably not use it for a blues in G.
The need is to insert the chromatic signs
before anything else, such as transposition, is done.
Kindest regards, Rale
If I understand correctly your proposal is that
\language english
m = { ff' f' fs' }
\m
\follow fs \m
\follow ff \m
will be printed different.
Only f' would be printed differently, as fs or ff. fss, fff, fn,
etc. would be ignored.
But you still need \key. Without \key, \follow makes no sense.
How you say it is irrelevant. You say C-sharp but you write
Sharp-C. c is quicker to type than cis or cs, especially
cis. The point is that on the staff, in A major, a c# looks like
a c and writing what it looks like has nothing to do with
language, it just saves typing,
just as writing key signatures saves a lot of writing chromatic
signs. I don't write all the sharps or flats when I write by
hand. Why should I have to do it when typing? With 3-7 chromatic
signs in the key it saves a *lot* of typing.
An individual who didn't like it would not have to use it. I
believe that a majority of music professionals would like it. I
have been doing it for many years, using a crude editing tool.
In my thinking that's absolute crude.
Perhaps, but it is the most flexible way, and the easiest to
implement in any language with a 14 item hash. It's simple
substitution.
Chords are no problem. No sane person would apply \follow to
chord names. The substitutions should be done before chord names
become an issue, and this won't interfere with hunting down
the target notes or cause additional confusion, as long as you
know what key you're in.
Though, obviously there are other opinions about that.
Patches are always welcome.
Thank
Re: Centering a stencil on another stencil
Hi Paul,
2015-08-13 19:50 GMT+02:00 Paul Morris p...@paulwmorris.com:
Here’s another possibility that uses an optional axis argument. -Paul
\version 2.19.22
#(define* (center-stencil-on-stencil stil-a stil-b #:optional axis)
Return a copy of stencil @var{stil-b} that has been moved
so it is centered on stencil @var{stil-a} on @var{axis}. When
@var{axis} is omitted, the centering is done on both X and
Y axes. @var{axis} is 0 for X axis, 1 for Y axis.
(if axis
;; center on one axis only
(ly:stencil-translate-axis
(ly:stencil-aligned-to stil-b axis CENTER)
(interval-center (ly:stencil-extent stil-a axis))
axis)
;; center on both X and Y axes
(ly:stencil-translate
(centered-stencil stil-b)
(cons
(interval-center (ly:stencil-extent stil-a X))
(interval-center (ly:stencil-extent stil-a Y))
square =
#(make-connected-path-stencil
'((0 0) (4 0) (4 4) (0 4) (0 0))
0.4 1 1 #f #f)
blue-square =
#(stencil-with-color (make-filled-box-stencil '(0.4 . 2) '(0.4 . 2)) blue)
\markup
\override #'(word-space . 3)
\line {
\stencil #(ly:stencil-add square blue-square)
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square X))
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square Y))
\stencil #(ly:stencil-add square
(center-stencil-on-stencil square blue-square))
}
I like this best and would go for it.
Regretable my vacations ended. Meaning I've reasonable less time :(
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: guile-question: 3/2 - 1 1/2
2015-08-12 12:28 GMT+02:00 Andrew Bernard andrew.bern...@gmail.com: Hi Harm, User specification of input only guessed at by me. :-) Of course, for negative and positive input (e.g. -3/2): (define (mixed-num x) (let* ((n (numerator x)) (d (denominator x))) (cons (truncate (/ n d)) (abs (/ (remainder n d) d) But are you saying you also need the function to take any number as input, not just a known fraction? Do you really want something like the rationalize function ? The common mathematical term for 3 1/2 is mixed number, or mixed fraction, by the way. Andrew On 12/08/2015 09:09, Thomas Morley lilypond-user-bounces+andrew.bernard=gmail@gnu.org on behalf of thomasmorle...@gmail.com wrote: `mixed-num' can't deal with negative input right now, returning wrong (could be fixed ofcourse). In case the input is not exact `mixed-num' crashes, whereas `integer-and-fraction' doesn't, although returning not a fraction. Hi Andrew, converting 3/2 - 1½ is ofcourse a helper-function for some larger project. Because I'm not entirely sure the input will always positive and exact, I tested what happens. I'll add that exact?-condition (already mentioned) and/or I'll make sure the input will always be exact. Thanks again for your input, it's highly appreciated! Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Align scores in markup
I am using a custom markup command that allows inserting scores into markups.
It works great except when one score uses high notes the scores are not
aligned.
http://lilypond.1069038.n5.nabble.com/file/n179568/shouldBeAligned.png
%=
% WRITE SCORE
%
%=
#(define-markup-command (writeScore layout props music) (ly:music?)
(let ((score (ly:make-score music))
(score-layout (ly:output-def-clone $defaultlayout)))
;; possibly, change some settings in the \layout block
%(ly:output-def-set-variable! score-layout 'indent 0)
;; add the \layout block to the score
(ly:score-add-output-def! score score-layout)
(interpret-markup layout props (markup #:vcenter #:score score) )
))
\markup {
this should be aligned \writeScore ##{ c' d' e' #}
with this \writeScore ##{ c d e #}
}
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Align-scores-in-markup-tp179568.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Align scores in markup
2015-08-14 3:32 GMT+02:00 Thomas Morley thomasmorle...@gmail.com:
2015-08-14 3:13 GMT+02:00 MarcM m...@mouries.net:
I am using a custom markup command that allows inserting scores into markups.
It works great except when one score uses high notes the scores are not
aligned.
http://lilypond.1069038.n5.nabble.com/file/n179568/shouldBeAligned.png
%=
% WRITE SCORE
%
%=
#(define-markup-command (writeScore layout props music) (ly:music?)
(let ((score (ly:make-score music))
(score-layout (ly:output-def-clone $defaultlayout)))
;; possibly, change some settings in the \layout block
%(ly:output-def-set-variable! score-layout 'indent 0)
;; add the \layout block to the score
(ly:score-add-output-def! score score-layout)
delete #:vcenter
(interpret-markup layout props (markup #:vcenter #:score score) )
))
\markup {
this should be aligned \writeScore ##{ c' d' e' #}
with this \writeScore ##{ c d e #}
}
(hit wrong key)
Though, I don't see an advantage not to use the default-markup-command:
\markup \score ...
Cheers,
Harm
Please always post the version you use!!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Align scores in markup
2015-08-14 3:13 GMT+02:00 MarcM m...@mouries.net:
I am using a custom markup command that allows inserting scores into markups.
It works great except when one score uses high notes the scores are not
aligned.
http://lilypond.1069038.n5.nabble.com/file/n179568/shouldBeAligned.png
%=
% WRITE SCORE
%
%=
#(define-markup-command (writeScore layout props music) (ly:music?)
(let ((score (ly:make-score music))
(score-layout (ly:output-def-clone $defaultlayout)))
;; possibly, change some settings in the \layout block
%(ly:output-def-set-variable! score-layout 'indent 0)
;; add the \layout block to the score
(ly:score-add-output-def! score score-layout)
delete #:vcenter
(interpret-markup layout props (markup #:vcenter #:score score) )
))
\markup {
this should be aligned \writeScore ##{ c' d' e' #}
with this \writeScore ##{ c d e #}
}
Though, I don't see an advantage not to use the default-markup-command:
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Text spanner text in the middle
Hello Ponderers, I need a custom text spanner with text centred in the middle of the spanner. I know you can provide text at the left or the right with the bound-details alist, but how would one go about making a spanner with text in the middle, similar to a tuplet bracket which has the number in the centre of the span? So, like this: [ x3 ] Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Align scores in markup
thanks. this allows to have multiple small score snippets aligned. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Align-scores-in-markup-tp179568p179571.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arabic tabs?
On 13 Aug 2015, at 17:51, BB bb-543...@telecolumbus.net wrote: Thanks for the interesting links! There are other differences: Turkish music is typically notated a 4th above sounding. In AEU notation, the sharp is erroneously given 4 commas—the E53 sharp has value 5 commas. In Arab music, the microtonal values are larger than in Turkish music. In E53, try raising with 2 commas, lowering 3. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Tuplet Bracket and \fermataMarkup
Hello,
I'm setting my first piece using Lilypond, and I've run into one problem I
can't solve. The piece is unmetered, and it has several long, timed rests.
I have the music looking almost the way I would like except the tuplet
bracket collides with the fermata. Changing staff priority seems to have no
effect.
I am open to alternative notation suggestions. I could just get ride of the
fermata altogether.
\version 2.18.2
\relative c {
\omit Staff.TimeSignature
\once \override TupletNumber.text = ~ 25 sec.
\once \set tupletFullLength = ##t
\once \set tupletFullLengthNote = ##f
\once \override MultiMeasureRestText #'outside-staff-priority = #'200
\hideNotes
\tuplet 3/2 {c2 c c}R1\fermataMarkup
\unHideNotes
}
Thank you
Jeremy
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Tuplet-Bracket-and-fermataMarkup-tp179574.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: PDF properties
2015-08-13 19:18 GMT+02:00 Noeck noeck.marb...@gmx.de: Hi, lately there was a mail on this list about PDF properties/headers. I tried them and it seems like the PDF author field is filled with the composer. This is nice fall back but in most cases the author of the document and the composer will be different. Of course, I can write pdfcomposer = Author Name Then it appears correctly as /Author(Author Name) But it also appears as /Composer(Author Name) which is wrong. Wouldn't it make sense to offer both fields: Author and Composer? A fallback if no author is given makes sense but it would be good to be able to specify an author differing from the composer. Cheers, Joram I'd adress the bug-list or maybe discuss on -devel first. Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arabic tabs?
Thanks for the interesting links! Regards, BB On 12.08.2015 18:09, Hans Åberg wrote: On 12 Aug 2015, at 15:54, BB bb-543...@telecolumbus.net wrote: I tried to to rivet on differences in turkish/arab way of noatation, but I am sure I missed the point. For someone interested, here is a much better (short) description: http://www.oud.eclipse.co.uk/notation.html For Arab maqam, there is http://www.maqamworld.com/ A Turkish makam notation system often described is called AEU (Arel-Ezgi-Uzdilek), as on https://en.wikipedia.org/wiki/Makam Also see Ozan Yarman, http://www.musicstudies.org/Abjad_JIMS_071203.pdf ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
