enharmonic problem with \transpose - should we modify it?
Summary: { \key c \minor \transpose gis as { es } } produces feses in
output. I think it would be better if it outputted es.
I have a piece written in es minor, which contains a lot of sharps and
naturals (along with passages of flat notes). I'd like to transpose it
enharmonically so that sharp notes become flat notes a scale step above,
natural notes become double-flatted notes, but regular passages of flat
notes aren't affected. \transpose gis as works for this with one exception:
it produces ceses and feses everywhere instead of bes and es (which would
fit the key signature better). This disturbs the harmonic structure: when a
passage like this { \key es \minor as' bes' des'' bes' ges' es' as' as' } is
transposed, most flat notes aren't affected (because \transpose doesn't
create triple flats), but some are - and intervals change, for example first
one changes from major second to diminished third.
I tried using \naturalizeMusic from NR 1.1.2 on it, but this results in
problems in other places (because \naturalizeMusic ignores key signature).
I think it would be good to either modify \transpose function, or add a
function which is similar to \transpose, so that described results can be
acheived.
What do you think?
I searched for transpose in sources and checked all results that were not
docs and regtests, but my scheme reading skills are too low: i cannot
identify where it is defined (i have an impression that it's definition
isn't all in one place). Please give me some pointers.
cheers,
Janek
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1693 in lilypond: Attaches bound info to beam for better normalized-endpoint calculations
Updates: Labels: -Patch-new Patch-review Comment #1 on issue 1693 by colinpkc...@gmail.com: Attaches bound info to beam for better normalized-endpoint calculations http://code.google.com/p/lilypond/issues/detail?id=1693 Applied to 2.15 cleanly. Trailing whitespace at line 36. Several reg tests showed change, although the amount of change is unnoticeable, at least to me. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1697 in lilypond: Add ties from Completion_note_heads_engraver to a TieColumn
Status: Accepted Owner: Labels: Type-Enhancement Priority-Medium Patch-new New issue 1697 by percival.music.ca: Add ties from Completion_note_heads_engraver to a TieColumn http://code.google.com/p/lilypond/issues/detail?id=1697 http://codereview.appspot.com/4592060/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1694 in lilypond: Modifies Spanner::spanner_length to better handle line-spanners
Updates: Status: Fixed Labels: -Patch-new fixed_2_15_2 Comment #1 on issue 1694 by percival.music.ca: Modifies Spanner::spanner_length to better handle line-spanners http://code.google.com/p/lilypond/issues/detail?id=1694 this was pushed. d02c9ba13cc3a7c96cc6374e232e94501a833ed1 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: enharmonic problem with \transpose - should we modify it?
2011/6/16 Benkő Pál benko@gmail.com:
Summary: { \key c \minor \transpose gis as { es } } produces feses in
output. I think it would be better if it outputted es.
I think that
- \transpose does the theoretically right thing
and should keep ignoring enharmony
- \naturalizeMusic is far closer to your needs, it just have to be enhanced
to know the key in the spirit of modal transposition - it may even have a
parameter for the enharmonic interval (diminished second as default).
if I have time (and that's quite a big if) I'll mock up something.
Maybe i'll write something myself next week, especially if the result
would be included in Lily (i mean, not as a helper function in the
docs, but built in Lily). If you could write a very small example of
how to use key signature in scheme code it would help me much - i can
handle the algorithm, but writing scheme code is still some problem to
me.
I searched for transpose in sources and checked all results that were not
docs and regtests, but my scheme reading skills are too low: i cannot
identify where it is defined (i have an impression that it's definition
isn't all in one place). Please give me some pointers.
it's implemented in C++
(Pitch::transpose and ly_transpose_key_alist in music-scheme.cc).
Ah! I overlooked it because it was so simple :)
Thanks!
Janek
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1695 in lilypond: Clef change placed outside score
Comment #3 on issue 1695 by percival.music.ca: Clef change placed outside score http://code.google.com/p/lilypond/issues/detail?id=1695 the problem occurred between BAD: 9a63326816f586dd79d326776583697f95203330 and GOOD: d3d40f3469eda2cb327bebbd392c1ce88b114394 but unfortunately the bisect in the middle has a broken commit which doesn't compile. :( there's probably some way to make git test a commit manually (so that I could avoid the broken-compile commit), but that range only has about 10 commits in it, so at least I've reduced the range? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1697 in lilypond: Add ties from Completion_note_heads_engraver to a TieColumn
Updates: Labels: -Patch-new Patch-review Comment #1 on issue 1697 by percival.music.ca: Add ties from Completion_note_heads_engraver to a TieColumn http://code.google.com/p/lilypond/issues/detail?id=1697 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1359 in lilypond: GUB always rebuilds everywhere
Updates: Status: Verified Comment #4 on issue 1359 by colinpkc...@gmail.com: GUB always rebuilds everywhere http://code.google.com/p/lilypond/issues/detail?id=1359 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: enharmonic problem with \transpose - should we modify it?
Janek Warchoł lemniskata.bernoullego at gmail.com writes:
Summary: { \key c \minor \transpose gis as { es } } produces feses in
output. I think it would be better if it outputted es.
I have used `\transpose gis as` to change enharmonic spellings, so probably
others have used it as well, so it should probably continue to function as
it does.
\transpose does the theoretically correct thing in all cases except :
when a
passage like this { \key es \minor as' bes' des'' bes' ges' es' as' as' } is
transposed, most flat notes aren't affected (because \transpose doesn't
create triple flats), but some are - and intervals change, for example first
one changes from major second to diminished third.
because LilyPond does not have a way to display a triple flat, so a year ago
Neil made LilyPond automatically convert triple sharp/flats to their enharmonic
equivalent so at least something would be printed.
Probably the new modal transformations from Mike Ellis will provide what you
want, Janek:
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00768.html
--
Keith
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
