Re: sharping naturals
On Mon, 10 Aug 2015 14:36:41 +0200
Peter Bjuhr 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?
>
> David, in a previous thread some time ago on a similar topic I think I
> recall that you mentioned that this may be better seen as an editor task
> than a task for LilyPond.
>
> In Frescobaldi (since v 2.18) there is a tool (Tools->Pitch->Mode shift)
> that adjusts the pitch to a given mode or scale. I just realized that
> this may be able to accomplish the above:
>
> If you enter:
>
>b c d e f g a
>
> and use the Mode shift tool with the mode b major the result will be:
>
>b cis dis e fis gis ais
>
> As mentioned before (in this thread), the problems start if you actually
> do not want some of the notes to be sharpened. Then of course you'll
> have to adjust this manually! But with a piece with only a few
> exceptionds to the given key it may be worth while to use this method...
I seriously doubt it, since another tool uses "n". the "n" is only for
the few notes which otherwise would be changed by \follow. If you already
have typed some of the sharps, nothing will happen to them. Without \follow,
there is no reason to tolerate "n" in the input.
If I hadn't already done it by key signature with a simple sed script, I would
use the
note list \follow fs cs ... because it is most flexible and would be
a simple search and replace rather than needing to fall through,
but that didn't occur to me until this latest discussion.
The problem with integration with lilypond is the range { }. That prevents
getting it sorted before the proper program sees it. If use of \follow and|or
relative could produce a new source file and|or a finished product
both \follow and \relative would be easier and more profitable to use IMO.
If truth in typing is the sole grounds for objection, \relative is a far
greater problem than \follow could ever be. IMO. Kindest regards, Rale
___
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:41 +0200 Peter Bjuhr 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? > > David, in a previous thread some time ago on a similar topic I think I > recall that you mentioned that this may be better seen as an editor task > than a task for LilyPond. > > In Frescobaldi (since v 2.18) there is a tool (Tools->Pitch->Mode shift) > that adjusts the pitch to a given mode or scale. I just realized that > this may be able to accomplish the above: > > If you enter: > >b c d e f g a > > and use the Mode shift tool with the mode b major the result will be: > >b cis dis e fis gis ais > > As mentioned before (in this thread), the problems start if you actually > do not want some of the notes to be sharpened. Then of course you'll > have to adjust this manually! But with a piece with only a few > exceptionds to the given key it may be worth while to use this method... > > Best > Peter > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user So should \relative be just an editing tool. It saves typing to enter a single line voice, but it's a mess in a score, and I ___ 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 wrote: > Robert Schmaus 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: sharping naturals
On Sat, 25 Jul 2015 00:31:42 +0200 Hans Aberg wrote: > > > On 25 Jul 2015, at 00:18, Brother Gabriel-Marie > > 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 Sat, 25 Jul 2015 12:07:19 +0200 David Kastrup wrote: > Wols Lists 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 Sat, 25 Jul 2015 02:18:40 +0200
David Kastrup wrote:
> Kieren MacMillan 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 09:35:44 +0200
Malte Meyn 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 17:18:09 -0500
Brother Gabriel-Marie 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: sharping naturals
On Mon, 10 Aug 2015 07:18:18 +0200
David Kastrup wrote:
> David Raleigh Arnold writes:
>
> > On Thu, 23 Jul 2015 11:33:50 -0500
> > Brother Gabriel-Marie 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
> 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/< */
Re: sharping naturals
On Mon, 10 Aug 2015 14:36:42 +0200
David Kastrup wrote:
> Thomas Morley writes:
>
> > 2015-08-10 13:47 GMT+02:00 David Kastrup :
> >
> >> 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
Re: sharping naturals
On Mon, 10 Aug 2015 13:47:34 +0200
David Kastrup wrote:
> Thomas Morley 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 \m
> \follow \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 Mon, 10 Aug 2015 13:05:15 +0200
Thomas Morley wrote:
> 2015-08-10 3:05 GMT+02:00 David Raleigh Arnold
> :
> > On Thu, 23 Jul 2015 11:33:50 -0500
> > Brother Gabriel-Marie 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 :
> [...]
> > 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
Re: sharping naturals
> On 10 Aug 2015, at 13:05, Thomas Morley wrote: > 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. I think OP might have been about being used to ABC style syntax, where the key changes the values of the note names. For example, if one writes A major, then the names will refer to this scale. If one then writes a b c d e f g, the expectation would be to produce the A major scale, but in LilyPond there will be a lot naturals. Whence the topic. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Thomas Morley writes: > 2015-08-10 13:47 GMT+02:00 David Kastrup : > >> 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". -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
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? David, in a previous thread some time ago on a similar topic I think I recall that you mentioned that this may be better seen as an editor task than a task for LilyPond. In Frescobaldi (since v 2.18) there is a tool (Tools->Pitch->Mode shift) that adjusts the pitch to a given mode or scale. I just realized that this may be able to accomplish the above: If you enter: b c d e f g a and use the Mode shift tool with the mode b major the result will be: b cis dis e fis gis ais As mentioned before (in this thread), the problems start if you actually do not want some of the notes to be sharpened. Then of course you'll have to adjust this manually! But with a piece with only a few exceptionds to the given key it may be worth while to use this method... Best Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
2015-08-10 13:47 GMT+02:00 David Kastrup : > Thomas Morley writes: >> In my thinking that's absolute crude. Better wording would have been: strange as strange could be... >> 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. > > 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. 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... Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Thomas Morley 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 \m
\follow \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?
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
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. 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.
> 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.
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.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
2015-08-10 3:05 GMT+02:00 David Raleigh Arnold :
> On Thu, 23 Jul 2015 11:33:50 -0500
> Brother Gabriel-Marie 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 :
[...]
> 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.
> 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.
In my thinking that's absolute crude.
Though, obviously there are other opinions about that.
Patches are always welcome.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
David Raleigh Arnold writes: > On Thu, 23 Jul 2015 11:33:50 -0500 > Brother Gabriel-Marie 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 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? There are quite a number of outstanding bugs that can be attributed to an imperfect understanding of LilyPond as to what the current key is. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Thu, 23 Jul 2015 11:33:50 -0500
Brother Gabriel-Marie 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. 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
--
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
Message: 1 Date: Sat, 25 Jul 2015 12:07:19 +0200 From: David Kastrup To: Wols Lists Cc: lilypond-user@gnu.org Subject: Re: sharping naturals Message-ID: <87wpxok0tk@fencepost.gnu.org> Content-Type: text/plain Wols Lists 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. -- David Kastrup --- I think he's referring to crotchets and quavers vs. quarter notes and eighth notes, but that doesn't enter into the Lilypond language directly, so it's of no consequence. Tim___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
> On 23 Jul 2015, at 18:33, Brother Gabriel-Marie 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? One can change the meaning of the note names. This is done in the GHB (Great Highland Bagpipe) file bagpipe.ly. This music is in A Mixolydian, so it defines note names for that. Then it is traditional to suppress the key signature in this bagpipe notation. However, the music is still typeset internally in the A Mixolydian scale, and the key signature does not alter the values of the note names. But if you have a heap of ABC music, which follows the convention you seem to want, and does not want to convert it to LilyPond notation, it might be useful. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Wols Lists 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. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
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 ...) Cheers, Wol ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
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.
A even simpler way to do this (however with different midi output):
\relative {
\omit Accidental
\key b \major
b c d e f g a b
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Kieren MacMillan writes:
> Hi David,
>
>> 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?
>
> Well, when I run that code in Lilypond, the visible key signature has
> three sharps.
[Slaps forehead] The visible one. Because I have two key signatures at
the same time and the second one gets junked. That's actually a
complication in the example I had not planned for. Uhm, put a c before
the second \key f \major. At any rate, it's rather essential for
figuring out the meaning of all that that the pitch names reliably spell
out a particular pitch and don't float meaning along with the "current
key". The second key could be g \major, it could be gis \major or it
could be ges \major depending on whether its "f" means "f" or "fis" and
whether \transpose c d actually means \transpose cis d. And then the
meaning of _that_ key is supposed to determine the meaning of anything
ambiguous that follows.
> Whether or not that is the key signature the OP wants to work in would
> be the OP’s problem.
If we wanted to support "natural English note entry", it would become
LilyPond's problem. And that's a problem I prefer not having. Our
current manual section explaining the Dutch notename philosophy is a bit
overbearing but reasonably clear. I shudder at having to write a manual
entry explaining how to interpret the above passage in English notename
philosophy rather than Dutch one.
>> "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”.
>
> OK.
In that case I think it's really better solved in the editor. If the
editor automatically adds accidentals based on some current "input key"
which you change explicitly, the result is predictable and unambiguous
and you still save most of the key presses.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Hi David,
> 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?
Well, when I run that code in Lilypond, the visible key signature has three
sharps.
Whether or not that is the key signature the OP wants to work in would be the
OP’s problem.
> But at what point will they stop making sense to humans and other tools?
I lack sufficient data to answer that question.
> 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.
True.
> Where would Bach's "Kunst der Fuge" had been if "b a c h" had not
> spelled out a theme unambiguously?
Perhaps it might have been Schoenberg’s Opus 1? ;)
> "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”.
OK.
Thanks,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Kieren MacMillan 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".
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
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. 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, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
J Martin Rushton writes: > Perhaps your approach is causing you problems? I tend to think of > Lilypond in the same way that I would regard other markup scripts: > LaTeX, DSR, Postscript and HTML come to mind. They are not > programming languages like C or FORTRAN, and to expect them to have > the same functionality is unfair. You are not "coding", you are > performing "data preparation" for someone else's code to work on. > > I will accept that interpreted languages do blur the data/code > relationship somewhat, but even comparing Lilypond to Python you can > see radical differences in emphasis. LilyPond has Scheme as its underlying programming language, and it is straightforward enough to let the \key command redefine the note names on the fly. so that a...h correspond to the pitch of the key signature. In a similar vein, you can use LaTeX's underlying TeX engine to redefine catcodes and commands in order to create a different input language, and you can use C's preprocessor to redefine reserved words and things like repeat...until. Creating your own language in that manner means that nobody but you and the compiler will understand your code any more. In particular, editors which otherwise help with things like indentation, completion, syntactic highlighting or even more complex things like transposition or augmentation will stop understanding your code. Tools like convert-ly which upgrade your files from one version of syntax to the next will no longer work: you'll have to maintain all of your code manually. So yes: one could teach LilyPond to do things differently. People don't do it not because it is impossible but rather because it comes with a price tag attached, and the price is a permanent tax as opposed to adapting your thinking to that of LilyPond, a one-time cost. That is: people who have the skills to change LilyPond's ways have been exposed to LilyPond's ways long enough not to feel the desire to do so. And those who don't have the skills trust the others to do what is sensible. And so we arrive at explanations and justifications and arguments which approach that of religious fervor, based not on rational necessity or insight but rather the trust in your elders' wisdom and your rationalizations of their ulterior motives. Going elsewhere is not sacrilege or impossible, but it means that you are out on your own. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Perhaps your approach is causing you problems? I tend to think of Lilypond in the same way that I would regard other markup scripts: LaTeX, DSR, Postscript and HTML come to mind. They are not programming languages like C or FORTRAN, and to expect them to have the same functionality is unfair. You are not "coding", you are performing "data preparation" for someone else's code to work on. I will accept that interpreted languages do blur the data/code relationship somewhat, but even comparing Lilypond to Python you can see radical differences in emphasis. Just my 2d worth! On 24/07/15 23:18, Brother Gabriel-Marie 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. > > I apologize if I have bothered you in any way. You are welcome to > ignore my messages. > > > On 7/24/2015 2:47 AM, Robert Schmaus wrote: >> Seriously? You've asked the exact same thing on stack exchange! >> Did you actually ignore all the helpful comments from users >> there? A couple of days ago, you complained on this list how SE >> users give you a hard time - like suggesting to get a at least >> rudimentary understanding of musical notation before writing >> music. So, here's how you get rid of your accitentals: Just pray >> them away. >> >> __ >> >> Truth does not change according to our ability to stomach it. -- >> /Flannery O'Connor/ >> > > > > ___ lilypond-user > mailing list lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVsr8RAAoJEAF3yXsqtyBlbwQP/izxzNxcTJ9fa+QeR5z4o589 V+lkPYz8fvcDKU5jrxHpyDyn4trysAKATdnp+EFJGhJKXJyKdN7RA+5619FPoWBd aSYNkA+kcuJvKlBxu0y22q+7f9RO3gIN4bmAMx1SaU0ehi20ZtLCFHtzv2MN1+pI lDTFOI/JVzwqdOw9jW3zL9g7GaJSnJi9MSbfVZ715LhDiEODKOA+KNmVRHajm1M+ aPHkPwFXLANC0L0MsO/lLK/u5VMmwihTPk/RPQnSLjbuz5Et3Kzhk86HpifhVf8C Hf5vPyJvq48nhvgdgvJEpNGarHyyHVKNVHHl2wk30HigrElNepmjX5msv8jP+mnY cUiyGtcSOG7DNn1nGcjxd5RKlV84oPKMXc+aDg1u2gDQ0Uci7gd2UwQck4EPbhgH SOTpYt3GyvPfalioAP5INUIuq68zkGWU0tzDMGZNjT2lO7gcdnmYgOFCmgqfpPSX DNwtMpgiXjwSRl68veKIGNGvmGbXSiT6ksWs+UCdzj25++kDeUo3FipU9cUGxGb5 NP3clrhvDAvIH7R7U6HF32p99aNmS5HMaW4M+VoJVSX9BzRrk7BiYsr+YzOtNhXd N0nPzgfl9Kp7LmwpQLgiZ0hZLyWc3n9SbIwkW7xWtevYgwqxOY7MyVbnO8S7g9Uy rj1wqI8OtxoLG5FuIg/E =QtNF -END PGP SIGNATURE- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
> On 25 Jul 2015, at 00:18, Brother Gabriel-Marie 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. > 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. In LilyPond, as in music staff notation, one enter notes by their names as they are in the music, and adds a key signature in order to reduce the appearances of the accidentals within the music itself. > 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. There is a transpose function to do that on the semantic level, as was described. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
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. I apologize if I have bothered you in any way. You are welcome to ignore my messages. On 7/24/2015 2:47 AM, Robert Schmaus wrote: Seriously? You've asked the exact same thing on stack exchange! Did you actually ignore all the helpful comments from users there? A couple of days ago, you complained on this list how SE users give you a hard time - like suggesting to get a at least rudimentary understanding of musical notation before writing music. So, here's how you get rid of your accitentals: Just pray them away. __ Truth does not change according to our ability to stomach it. -- /Flannery O'Connor/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Robert Schmaus 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. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Mark 11:23/24: Truly, I say to you, whoever says to this mountain, ‘Be taken up and thrown into the sea,’ and does not doubt in his heart, but believes that what he says will come to pass, it will be done for him. Therefore I tell you, whatever you ask in prayer, believe that you have received it, and it will be yours. I wasn't being 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. 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. 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. __ Truth does not change according to our ability to stomach it. -- Flannery O'Connor > On 24 Jul 2015, at 12:24, Malte Meyn wrote: > > > >> Am 24.07.2015 um 09:47 schrieb Robert Schmaus: >> So, here's how you get rid of your accitentals: Just pray them away. > You might possibly be right in general but there’s no need to be so rude! It > might be that you don’t understand religion but be tolerant and don’t offend > anyone. > > > ___ > 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: sharping naturals
Am 24.07.2015 um 09:47 schrieb Robert Schmaus: So, here's how you get rid of your accitentals: Just pray them away. You might possibly be right in general but there’s no need to be so rude! It might be that you don’t understand religion but be tolerant and don’t offend anyone. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Am 24.07.2015 um 10:12 schrieb Peter Bjuhr: I think you misunderstood Malte's (not completely properly worded) question. He didn't use 'lead' in the sense of leading note. What he meant is: "If a key signature of b major (five sharps) is given and in a notation system typing 'g' would be interpreted as g sharp - what would you have to write if you want to express a g natural?" Yes, sorry for the misunderstanding! I wasn't grasping the full context of his question... Yes I meant g as in e minor, not fisis as in dis major. Maybe “produce a gis” would have been better than “lead to a gis” As the Germans say: “again what learnt” ;) Schon peinlich, ich hab vor vier Jahren ein ganz gutes Englisch-Leistungskurs-Abitur geschrieben und tu mich manchmal schwer mit klaren Formulierungen … ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On 2015-07-24 09:59, Urs Liska wrote: By the way, how would one write a g natural in b major, if ‘g’ lead >>to a g sharp? ‘ges’? But if so, how to write a ges? > >I assume you mean g# minor with the same accidentals in the key >signature as b major. The lead tone to gis (g sharp) is fisis (f >double-sharp) and not g (natural). I think you misunderstood Malte's (not completely properly worded) question. He didn't use 'lead' in the sense of leading note. What he meant is: "If a key signature of b major (five sharps) is given and in a notation system typing 'g' would be interpreted as g sharp - what would you have to write if you want to express a g natural?" Yes, sorry for the misunderstanding! I wasn't grasping the full context of his question... And as I've said that input language would then have a syntax to express 'natural'. Yes, naturally! :) Best Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Am 24.07.2015 um 09:52 schrieb Peter Bjuhr: > On 2015-07-23 19:29, Malte Meyn wrote: >> By the way, how would one write a g natural in b major, if ‘g’ lead >> to a g sharp? ‘ges’? But if so, how to write a ges? > > I assume you mean g# minor with the same accidentals in the key > signature as b major. The lead tone to gis (g sharp) is fisis (f > double-sharp) and not g (natural). I think you misunderstood Malte's (not completely properly worded) question. He didn't use 'lead' in the sense of leading note. What he meant is: "If a key signature of b major (five sharps) is given and in a notation system typing 'g' would be interpreted as g sharp - what would you have to write if you want to express a g natural?" And as I've said that input language would then have a syntax to express 'natural'. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On 2015-07-23 19:29, Malte Meyn wrote:
By the way, how would one write a g natural in b major, if ‘g’ lead to
a g sharp? ‘ges’? But if so, how to write a ges?
I assume you mean g# minor with the same accidentals in the key
signature as b major. The lead tone to gis (g sharp) is fisis (f
double-sharp) and not g (natural).
Take a look at the following example:
cmaj = { c' d' e' f' g' a' b' }
ahmin = { a' b' c'' d'' e'' f'' gis'' }
\score {
<<
\new Staff {
\key c \major
\cmaj
}
\new Staff {
\key a \minor
\ahmin
}
\new Staff {
\key b \major
\transpose c b, { \cmaj }
}
\new Staff {
\key gis \minor
\transpose a gis { \ahmin }
}
>>
}
Best
Peter
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Seriously? You've asked the exact same thing on stack exchange! Did you actually ignore all the helpful comments from users there? A couple of days ago, you complained on this list how SE users give you a hard time - like suggesting to get a at least rudimentary understanding of musical notation before writing music. So, here's how you get rid of your accitentals: Just pray them away. __ Truth does not change according to our ability to stomach it. -- Flannery O'Connor > On 23 Jul 2015, at 18:33, Brother Gabriel-Marie 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 > > > ___ > 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: sharping naturals
On Thu, 2015-07-23 at 22:14 +0100, Michael Hendry wrote: > > So the rule is that you enter your music as if the key signature were > C major, I would not recommend thinking of it like that, you enter your music using the actual names of the notes you are entering. So you always type fis if you mean f-sharp, regardless of preceding key signatures or notes. The Denemo "trick" is just a keypress-saver, it makes the entry method less elegant but once understood generally saves time. Richard ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
> On 23 Jul 2015, at 19:09, Richard Shann wrote:
>
> On Thu, 2015-07-23 at 19:40 +0200, Urs Liska wrote:
>>> Am 23.07.2015 um 19:15 schrieb Christopher R. Maden:
They will look different, but will be the same notes. The music
describes itself; the key signature affects presentation.[*]
>>> That’s true and I think that this is one of LilyPonds strengths as
>> it
>>> allows to be very flexible with transposing, quoting, changing key
>>> signatures etc.
>>
>> I think so too.
>> However, there *are* programs/formats that "think" differently. I know
>> of Amadeus an midt notably MEI where you basically write diwn what you
>> *see*. If not explicitly altered the actual pitch is determined by the
>> key signature.
>
> presumably not just the key signature but also any preceding altered
> pitches in the same bar. Denemo allows this method of entry by default,
> for a series of f-sharps in a bar only the first needs a keypress to say
> it is a sharp, subsequent presses of the key "f" enter f-sharps, until
> the end of the bar. Of course, it emits the (more verbose) fis syntax
> for each note, but it saves typing on entry.
>
> Richard
It seems to me that the replies so far are missing the OP’s underlying
misunderstanding of the way in which Lilypond interprets the pitches that are
entered.
G natural is entered thus: { g }
G sharp is entered thus:{ gis }
G flat is entered thus: { ges }
(assuming the default Dutch convention for sharps and flats).
Following a key signature such as G major, the G natural will have no
accidental, but the other two will have sharp and flat signs.
In the case of A major, G natural will have a natural sign, the G sharp will
have no accidental and the G flat with have a flat sign.
Similarly if the key signature says G flat major, the G natural and G sharp
will each have an accidental, and the G flat will have none.
So the rule is that you enter your music as if the key signature were C major,
and Lilypond will display the music correctly if you subsequently choose a
different key signature.
Michael
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
On Thu, 2015-07-23 at 19:40 +0200, Urs Liska wrote: > >Am 23.07.2015 um 19:15 schrieb Christopher R. Maden: > >> They will look different, but will be the same notes. The music > >> describes itself; the key signature affects presentation.[*] > >> > >That’s true and I think that this is one of LilyPonds strengths as > it > >allows to be very flexible with transposing, quoting, changing key > >signatures etc. > > I think so too. > However, there *are* programs/formats that "think" differently. I know > of Amadeus an midt notably MEI where you basically write diwn what you > *see*. If not explicitly altered the actual pitch is determined by the > key signature. presumably not just the key signature but also any preceding altered pitches in the same bar. Denemo allows this method of entry by default, for a series of f-sharps in a bar only the first needs a keypress to say it is a sharp, subsequent presses of the key "f" enter f-sharps, until the end of the bar. Of course, it emits the (more verbose) fis syntax for each note, but it saves typing on entry. Richard ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Am 23. Juli 2015 19:29:38 MESZ, schrieb Malte Meyn : > > >Am 23.07.2015 um 19:15 schrieb Christopher R. Maden: >> They will look different, but will be the same notes. The music >> describes itself; the key signature affects presentation.[*] >> >That’s true and I think that this is one of LilyPonds strengths as it >allows to be very flexible with transposing, quoting, changing key >signatures etc. I think so too. However, there *are* programs/formats that "think" differently. I know of Amadeus an midt notably MEI where you basically write diwn what you *see*. If not explicitly altered the actual pitch is determined by the key signature. > >By the way, how would one write a g natural in b major, if ‘g’ lead to >a >g sharp? ‘ges’? But if so, how to write a ges? No, a g natural would be encided as a g natural, however the syntax is. E.g. gn. Users of these systems are very convinced of it - as are we ... Ur > >P.S.: There is a very ugly hack abusing modalTranspose to achieve >something similar so that b c d e f becomes b cis dis e fis. But it >breaks when you want to use pitches other than those from the original >b >major scale like above. > >___ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
Am 23.07.2015 um 19:15 schrieb Christopher R. Maden: They will look different, but will be the same notes. The music describes itself; the key signature affects presentation.[*] That’s true and I think that this is one of LilyPonds strengths as it allows to be very flexible with transposing, quoting, changing key signatures etc. By the way, how would one write a g natural in b major, if ‘g’ lead to a g sharp? ‘ges’? But if so, how to write a ges? P.S.: There is a very ugly hack abusing modalTranspose to achieve something similar so that b c d e f becomes b cis dis e fis. But it breaks when you want to use pitches other than those from the original b major scale like above. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sharping naturals
If you don’t want to write things like
\relative { \key b \major b cis dis e fis gis ais b }
you could enter it in another key and use the transpose function:
\transpose c' b \relative { \key c \major c' d e f g a b c }
\transpose bes b \relative { \key bes \major bes c d es f g a bes }
Accidental styles will never change pitches but only the behaviour, how
pitches are represented by accidentals.
Am 23.07.2015 um 18:33 schrieb Brother Gabriel-Marie:
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
___
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: sharping naturals
On 07/23/2015 11:33 AM, Brother Gabriel-Marie 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. I think this is a common misunderstanding for new Lilypond users. Another way to phrase this is, If you write music with a lot of naturals, in a key with sharps, you will end up with a lot of accidentals. The solution is to write music with the sharp notes you actually want. For instance, I can write: \key c \major d e fis g | a1 Or I can write: \key d \major d e fis g | a1 They will look different, but will be the same notes. The music describes itself; the key signature affects presentation.[*] HTH, Chris [*] Yes, it has semantic implications, too, the tonic and mode, etc., but I’m trying to keep this simple(ish). -- Chris Maden, text nerd http://crism.maden.org/ > “Do you not know that a man is not dead while his name is still spoken?” — PTerry GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9 A210 4A51 DBAC 5C5C 3D5E ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
