Re: midi2ly
On Tue, Dec 28, 2010 at 11:46:16PM -0700, Jay Carr wrote: > On Dec 28, 2010, at 3:54 PM, Graham Percival music.ca> wrote: > > >On Tue, Dec 28, 2010 at 07:01:58PM +0100, James Bailey wrote: > >> > >>On Dec 23, 2010, at 8:20 AM, jayc...@gmail.com wrote: > >> > >>>I'm trying to use midi2ly on my MacBook Pro running OSX 10.6.5. > >>>It seems that midi2ly was not compiled properly, as it's saying that > >>>I have the wrong architecture. This despite the fact that I can run > >>>Lilypad just fine (I have the right distro, I'm quite sure.) > >> > >>Like I said earlier, it issues errors, but I do get a file. > > > >Ok, that's good to know. So 1318 is not a valid report? > >http://code.google.com/p/lilypond/issues/detail?id=1318 > > > It's hard to say still. Do you get a file or not? James Bailey said that he saw a bunch of messages, but that he got a file. If so, then there's no serious problem. > It could just be a python mismatch. For some > reason python is refusing to "import midi". Even if I just try to > run that command from the console it won't load. Does Python 2.6 > have a midi to import? We distribute a python midi module. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 884 in lilypond: pageBreak resets page-count property
Updates: Labels: fixed_2_13_25 Comment #25 on issue 884 by pnorcks: pageBreak resets page-count property http://code.google.com/p/lilypond/issues/detail?id=884 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 884 in lilypond: pageBreak resets page-count property
Updates: Status: Fixed Comment #24 on issue 884 by ColinPKCampbell: pageBreak resets page-count property http://code.google.com/p/lilypond/issues/detail?id=884 Created issue 1465 "\pageBreak breaks \page-ref" ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1465 in lilypond: \pageBreak breaks \page-ref
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical Regression
New issue 1465 by ColinPKCampbell: \pageBreak breaks \page-ref
http://code.google.com/p/lilypond/issues/detail?id=1465
In version 2.12.3 the code below behaves as expected: the \page-ref for
mark A is page 2. Under 2.13.44 it is displayed as 1.
\version "2.12.3" % Mark A is on page 2
%\version "2.13.44"
\label #'firstScore
\score {
{
c'1
\pageBreak \mark A \label #'markA
c'1
}
}
\markup { The first score begins on page \page-ref #'firstScore
"0" "?" }
\markup { Mark A is on page \page-ref #'markA "0" "?" }
\markup { The first score begins on page \page-ref #'firstScore "0" "?" }
\markup { Mark A is on page \page-ref #'markA "0" "?" }
The code is supplied by Neil Puttock, who comments on the previous issue
884:
It's a consequence of the way label-page-table is generated;
since 2.13.5 the order is consistently reversed, leading to \page-ref
accessing the first entry for markA. Here's the output for
label-page-table in 2.12 and 2.13:
(2.12.3)
((markA . 2) (markTheEnd . 2) (firstScore . 1) (markA . 1))
(2.13.45)
((firstScore . 1) (markA . 1) (markA . 2) (markTheEnd . 2))
take out a \book block >
Due to the way labels are generated inside a score (using paper
columns), the concept of a label at a page break is dubious: the same
NonMusicalPaperColumn is on two pages (at the end of the last system
before the break, and the start of the next system after the break),
hence the duplicated page marker you see in the output for
label-page-table above.
Attachments:
bug2-13-44.pdf 20.3 KB
bug2-12-3.pdf 18.8 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR 3.2.3 Reference to page numbers - buggy? (issue 884)
On Wed, 2010-12-29 at 00:49 +, Neil Puttock wrote:
> On 27 December 2010 17:58, Jean-Charles Malahieude wrote:
>
> > May I guess that it is due to \mark falling before the first note event
> > is generated?
>
> No. It's a consequence of the way label-page-table is generated;
> since 2.13.5 the order is consistently reversed, leading to \page-ref
> accessing the first entry for markA. Here's the output for
> label-page-table in 2.12 and 2.13:
>
> (2.12.3)
> ((markA . 2) (markTheEnd . 2) (firstScore . 1) (markA . 1))
>
> (2.13.45)
> ((firstScore . 1) (markA . 1) (markA . 2) (markTheEnd . 2))
>
> Of course, this means that in 2.12 the following snippet is also
> wrong, so it would be incorrect to assume this bug is a regression:
>
> \book {
> \label #'firstScore %% page 1
> \score {
> {
> c'1
> \label #'markA % still page 2, due to alist order in label-page-table
> \pageBreak
> \mark A %% page 2
> c'1 \label #'markTheEnd %% page 2
>
> }
> }
>
> \markup { The first score begins on page \page-ref #'firstScore "0" "?" }
> %% prints page 1
>
> \markup { Mark A is on page \page-ref #'markA "0" "?" }
> %% prints page 2
> \markup { Finish line on page \page-ref #'markTheEnd "0" "?" }
> %% prints page 2
> }
>
> Due to the way labels are generated inside a score (using paper
> columns), the concept of a label at a page break is dubious: the same
> NonMusicalPaperColumn is on two pages (at the end of the last system
> before the break, and the start of the next system after the break),
> hence the duplicated page marker you see in the output for
> label-page-table above.
>
> Cheers,
> Neil
I've just copied your snippet into Frescobaldi, and added a couple of
\version statements so I can change versions with a comment. Using
2.12.3 the snippet reports page 2 for markA and under 2.13.44 it is on
page 1. Also, the \book block is not part of the problem.
It may be that this is a Doc fix, explaining the use of labels at page
breaks, but since the behaviour has clearly regressed, I'll raise a new
issue.
Colin
--
At twenty years of age, the will reigns;at thirty, the wit; and at
forty, the judgment. - Benjamin Franklin (1706-1790) Statesman
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR 3.2.3 Reference to page numbers - buggy? (issue 884)
On 27 December 2010 17:58, Jean-Charles Malahieude wrote:
> May I guess that it is due to \mark falling before the first note event
> is generated?
No. It's a consequence of the way label-page-table is generated;
since 2.13.5 the order is consistently reversed, leading to \page-ref
accessing the first entry for markA. Here's the output for
label-page-table in 2.12 and 2.13:
(2.12.3)
((markA . 2) (markTheEnd . 2) (firstScore . 1) (markA . 1))
(2.13.45)
((firstScore . 1) (markA . 1) (markA . 2) (markTheEnd . 2))
Of course, this means that in 2.12 the following snippet is also
wrong, so it would be incorrect to assume this bug is a regression:
\book {
\label #'firstScore %% page 1
\score {
{
c'1
\label #'markA % still page 2, due to alist order in label-page-table
\pageBreak
\mark A %% page 2
c'1 \label #'markTheEnd %% page 2
}
}
\markup { The first score begins on page \page-ref #'firstScore "0" "?" }
%% prints page 1
\markup { Mark A is on page \page-ref #'markA "0" "?" }
%% prints page 2
\markup { Finish line on page \page-ref #'markTheEnd "0" "?" }
%% prints page 2
}
Due to the way labels are generated inside a score (using paper
columns), the concept of a label at a page break is dubious: the same
NonMusicalPaperColumn is on two pages (at the end of the last system
before the break, and the start of the next system after the break),
hence the duplicated page marker you see in the output for
label-page-table above.
Cheers,
Neil
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 884 in lilypond: pageBreak resets page-count property
On Wed, 2010-12-29 at 00:33 +, lilyp...@googlecode.com wrote: > Comment #23 on issue 884 by percival.music.ca: pageBreak resets page-count > property > http://code.google.com/p/lilypond/issues/detail?id=884 > > ok, let's move Colin's example into a new issue number, then mark this one > as fixed again (and add back the tag for the version number in which it was > fixed). > I'll look after it. Colin -- Start every day off with a smile and get it over with. - W. C. Fields ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 884 in lilypond: pageBreak resets page-count property
Comment #23 on issue 884 by percival.music.ca: pageBreak resets page-count property http://code.google.com/p/lilypond/issues/detail?id=884 ok, let's move Colin's example into a new issue number, then mark this one as fixed again (and add back the tag for the version number in which it was fixed). ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 884 in lilypond: pageBreak resets page-count property
Comment #22 on issue 884 by n.puttock: pageBreak resets page-count property http://code.google.com/p/lilypond/issues/detail?id=884 I've checked this with the versions of Lily that I have, and the behaviour is incorrect from 13.31 onwards. The original snippet correctly produces two pages on current master (and still works if you change the number of pages, despite the presence of \pageBreak). Colin's snippet is completely unrelated to this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
On Tue, Dec 28, 2010 at 1:28 PM, Michael Ellis wrote: > The Dover Edition of the Beethoven Sonatas, a reproduction of the 1923 > Universal Edition (H. Schenker, ed.) has the attached in opus 27, no 2, > second movement (Presto Agitato) mm 54,55. > > In the left hand of mm 54, the clef changes 4 times (bass, treble, bass, > treble). The movement is in E major. There is a natural sign on the A > immediately after the clef change. It's not clear, though, whether it's > there to cancel the sharp on the space (implied by the preceding C-sharp in > the bass clef) or whether it's simply a courtesy accidental that corresponds > to the one in the right hand. I think it's most likely the latter. I agree that it's the latter case. This movement is (normally) performed at a very fast tempo where the time difference between the A sharps and A naturals is about one second (maybe less). The courtesy accidentals are lifesavers, especially if you are sight reading the movement at tempo. ;) Not related to your observation per se, but the movement is actually in C-sharp minor. Thanks, Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: midi2ly
On Tue, Dec 28, 2010 at 07:01:58PM +0100, James Bailey wrote: > > On Dec 23, 2010, at 8:20 AM, jayc...@gmail.com wrote: > > > I'm trying to use midi2ly on my MacBook Pro running OSX 10.6.5. > > It seems that midi2ly was not compiled properly, as it's saying that > > I have the wrong architecture. This despite the fact that I can run > > Lilypad just fine (I have the right distro, I'm quite sure.) > > Like I said earlier, it issues errors, but I do get a file. Ok, that's good to know. So 1318 is not a valid report? http://code.google.com/p/lilypond/issues/detail?id=1318 Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Am Dienstag, 28. Dezember 2010, um 15:14:05 schrieb David Kastrup:
> Reinhold Kainhofer writes:
> > I would be great, though, if anyone can find a published example of such
> > a situation (most likely in e.g. cello/bassoon parts/scores, which
> > frequently switch between bass and tenor clef).
>
> Edition Peters, piano excerpt by Brissler from Mozart Requiem,
> "Confutatis". The g in the corni di bassotto entry is not even in the
> same octave, and still gets a natural.
Also, in the Bärenreiter piano reduction of Bach's Christmas oratorio, measure
7 of the Choral Nr. 23 ("Wir singen dir"), p.72 of Bärenreiter BA 5014a.
There is a dis' in treble clef, followed by a d in bass clef. That d gets a
natural cancellation.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
I don't know about this one. Certainly, the accidental should be (and is)
printed. It's the naturals that aren't printed. Not even when changing octaves:
\new Staff \relative c' {
\time 6/4
\clef treble
cis dis fis
\clef tenor
c d f
\clef bass
cis dis fis
\clef treble
c' d f
}
Certainly, when changing octaves the accidental (sharp or flat), but I don't
recall for naturals.
On Dec 28, 2010, at 12:41 PM, Phil Holmes wrote:
> Hello,
>
> - Original Message - From: "Xavier Scheuer"
> To: "bug-lilypond" ; "lilypond-user"
>
> Cc: "Philhar"
> Sent: Tuesday, December 28, 2010 10:53 AM
> Subject: Accidental and clef change issue
>
>
> Hi!
>
> This has been reported on the French user mailing list.
>
> In the following code the c-natural is not printed if there is a clef
> change in the middle of the measure.
>
> \relative c' {
> \clef bass cis2 c
> \clef tenor cis2 \clef bass c % natural is not printed!!
> \clef bass cis2 \clef tenor c
> }
>
> I do not know what say references like Ross, Read about this but I do
> not think this should be the correct behaviour.
> IMHO this is not what a musician (and a user) expect:
> if we have a c-sharp and then a c-natural (at the same octave)
> _in the same measure_, then the natural __MUST__ be printed!
> This is also against what is said in the regtest
> ‘accidental-clef-change.ly’: Accidentals are reset for clef changes
> (note that this regtest works fine but the reported code does not).
>
> Could you investigate this?
> Thanks in advance.
>
> Cheers,
> Xavier
>
> PS: The only "simple" workaround is to use
> #(set-accidental-style 'piano)
>
> --
> Xavier Scheuer
>
> It's doing what I would expect from reading the regtest - i.e. - when there
> is a clef change, the accidentals are reset to that which you'd expect from
> the key. Therefore, in your example we return to C major, and so there's no
> need to print the accidental. I'd welcome other thoughts as to whether this
> is correct, though.
>
> --
> Phil Holmes
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: midi2ly
On Dec 23, 2010, at 8:20 AM, jayc...@gmail.com wrote:
> I'm trying to use midi2ly on my MacBook Pro running OSX 10.6.5.
> It seems that midi2ly was not compiled properly, as it's saying that
> I have the wrong architecture. This despite the fact that I can run
> Lilypad just fine (I have the right distro, I'm quite sure.)
>
> Is there any way someone could just run a quick compile of midi2ly
> so that it can run on OSX 10.6.5? I
>
> would really appreciate it.
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
Did you ever get midi2ly to work? I did this:
18:58:33 jamesbailey lilypond snippets:echo "\score { { b4 a g a } \midi {} }"
> midi\ test.ly && ~/Applications/LilyPond.app/Contents/Resources/bin/lilypond
midi\ test.ly && ~/Applications/LilyPond.app/Contents/Resources/bin/midi2ly
midi\ test.midi && ls ./
GNU LilyPond 2.12.3
Processing `midi test.ly'
Parsing...
midi test.ly:0: warning: no \version statement found, please add
\version "2.12.3"
for future compatibility
Interpreting music...
MIDI output to `midi test.midi'...
/Users/jamesbailey/Applications/LilyPond.app/Contents/Resources/bin/midi2ly:50:
RuntimeWarning: Python C API version mismatch for module midi: This Python has
API version 1013, module midi has version 1012.
import midi
LY output to `./midi test-midi.ly'...
.#Pango.ly@.DS_Store* midi test-midi.ly midi test.ly
midi test.midi
Like I said earlier, it issues errors, but I do get a file.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Segfault with multimeasure rests and metronome markings
On Dec 27, 2010, at 6:49 PM, Chris Snyder wrote:
> We've run into a segfault in all versions of LilyPond after 2.13.32,
> including 2.13.44. I've narrowed it down to occur when a tempo marking is
> placed over a multimeasure rest when the Metronome_mark_engraver has been
> added to the staff containing the rest:
>
>
>
> \version "2.13.44"
> % works in 2.13.32 and prior
>
> \score {
> \new Staff {
> \tempo 4=150
> R1 |
> }
> \layout {
> \context {
> \Score
> \remove "Metronome_mark_engraver"
> \remove "Staff_collecting_engraver"
> }
> \context {
> \Staff
> \consists "Metronome_mark_engraver"
> \consists "Staff_collecting_engraver"
> }
> }
> }
>
>
>
> Console output:
>
> Processing `RestSegfault.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects.../home/csnyder/bin/ly-choose: line 29: 7328
> Segmentation fault $ly $*
> LilyPond [RestSegfault.ly] exited with return code 139.
>
> (ly-choose is my own wrapper script to run the version of LilyPond specified
> in the \version parameter; the segfault still occurs when this script is not
> used)
>
> I'm running Kubuntu 10.10 64-bit using the official LilyPond binaries.
>
> Thanks,
> Chris
>
> --
> Chris Snyder
> Adoro Music Publishing
> (616) 828-4436
> www.adoromusicpub.com
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
Thanks, added as issue 1464___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1464 in lilypond: Segfault with multimeasure rests and metronome markings
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical Regression
New issue 1464 by jameseli...@googlemail.com: Segfault with multimeasure
rests and metronome markings
http://code.google.com/p/lilypond/issues/detail?id=1464
A segfault will occur when a tempo marking is placed over a multimeasure
rest when the Metronome_mark_engraver has been added to the staff
containing the rest:
\version "2.13.44"
% works in 2.13.32 and prior
\score {
\new Staff {
\tempo 4=150
R1 |
}
\layout {
\context {
\Score
\remove "Metronome_mark_engraver"
\remove "Staff_collecting_engraver"
}
\context {
\Staff
\consists "Metronome_mark_engraver"
\consists "Staff_collecting_engraver"
}
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: including gregorian.ly breaks lyrics alignment in melismas
Hello, From: bug-lilypond-bounces+james.lowe=datacore@gnu.org [bug-lilypond-bounces+james.lowe=datacore@gnu.org] on behalf of Trevor Daniels [t.dani...@treda.co.uk] Sent: 28 December 2010 16:37 To: Janek Warchoł Cc: lilypond-de...@gnu.org; Lilypond Bugreports Subject: Re: including gregorian.ly breaks lyrics alignment in melismas > 2010/12/27 Trevor Daniels > That said, I'm sure there /are/ many bugs in the ancient notation section > and the documentation is clearly incomplete. But none of the currently > active developers is expert enough in ancient notation to touch this section, > so no changes are likely be made in the foreseeable future. Unless, of > course, you or Michael would like to suggest patches. - and that includes any Documentation improvements or suggestions. :) I have made a very small start on the Ancient Notation section in the Notation Reference manual. I know very little about Ancient Music myself, but am more than happy to submit documentation patches/corrections/additions for others who know more than I do. I am trying to get this section of the NR up to the normal standard and any help would be greatly appreciated. http://code.google.com/p/lilypond/issues/detail?id=1287 James ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: including gregorian.ly breaks lyrics alignment in melismas
Janek Warchoł wrote Tuesday, December 28, 2010 3:28 PM 2010/12/27 Trevor Daniels I know next to nothing about ancient notation, but whoever wrote gregorian.ly clearly intended this behaviour as the file contains the override \override SpacingSpanner #'packed-spacing = ##t on line 258, which requests notes to be packed as tightly as possible. I wouldn't describe this behaviour as "packing notes as tightly as possible" - the first note gets enormous amount of space. Don't you think that packed-spacing is bugged itself? No. The space after the first note is to accommodate the lyrics word attached to that note. Just as in modern music the note spacing adjusts as necessary to accommodate the lyrics. This is presumably to enable the usual packed spacing of Gregorian ligatures when the other facilities in gregorian.ly are used, so it is not a bug. Regardless of whether this is intended or not, i suggest changing the way it works, because it causes bad files to be easily produced: just a few days ago Michael Dykes posted a question about the attached piece (in "Not enough space between certain words" thread). Obviously he didn't know about the need to revert packed-spacing, which resulted in a badly typeset piece. gregorian.ly is supposed to be used as described in Typesetting Gregorian chant, Section 2.9.4 in the Notation Reference. You'll see there that there are special staff and voice contexts that should be used. AFAIK it is not intended to be used without these contexts, and may well exhibit strange behaviour if it is. But I would not call such behaviour bugs. That said, I'm sure there /are/ many bugs in the ancient notation section and the documentation is clearly incomplete. But none of the currently active developers is expert enough in ancient notation to touch this section, so no changes are likely be made in the foreseeable future. Unless, of course, you or Michael would like to suggest patches. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: including gregorian.ly breaks lyrics alignment in melismas
2010/12/27 Trevor Daniels
>
> If you want to use normal spacing simply revert this setting:
> \revert Score.SpacingSpanner #'packed-spacing
Thanks for this!
> I know next to nothing about ancient notation, but whoever wrote
> gregorian.ly clearly intended this behaviour as the file contains
> the override
>
> \override SpacingSpanner #'packed-spacing = ##t
>
> on line 258, which requests notes to be packed as tightly as possible.
I wouldn't describe this behaviour as "packing notes as tightly as
possible" - the first note gets enormous amount of space. Don't you
think that packed-spacing is bugged itself?
> This is presumably to enable the usual packed spacing of Gregorian
> ligatures when the other facilities in gregorian.ly are used, so it is not
> a bug.
Regardless of whether this is intended or not, i suggest changing the
way it works, because it causes bad files to be easily produced: just
a few days ago Michael Dykes posted a question about the attached
piece (in "Not enough space between certain words" thread). Obviously
he didn't know about the need to revert packed-spacing, which resulted
in a badly typeset piece.
cheers,
Janek
2010/12/27 Janek Warchoł :
> Hi,
>
> Search for "gregorian" in tracker didn't show any results like this,
> so i report:
> including gregorian.ly breaks horizontal spacing when there are lyrics.
> Example:
>
> \include "gregorian.ly"
> <<
> \new Voice = foobar { f'( a' g' f') }
> \new Lyrics \lyricsto foobar \lyricmode { lalah }
> >>
<>
06jan_secondant_lznam_2.ly
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
"Phil Holmes" writes: > "David Kastrup" wrote in message > news:87aajqowbn@lola.goethe.zz... >> "Phil Holmes" writes: >> >>> >>> Apologies. As you're probably aware, I'm a Windows man, and some >>> postings don't quote properly using my mailreader. >> >> I am sure that there are sensible configurations available also for >> Windows mailreasers. > > Hey - you're talking about M$ software here! (FWIW I use the same > software for mail and news, - partly since the lilypond newsgroups are > also mailing lists. I don't want to change). http://oe-faq.de> teaches German people how to stop annoying everybody else even while using OE or its "successor" "Windows Mail". I should be surprised if similar advice would not be available for English-speaking people (anybody here on the list able to offer a similar link?). I don't understand how "I get a crappy configuration shipped by factory and know it" is supposed to imply "It's ok if I don't bother changing it". If you like the software you get from Microsoft and want to stay with it, it is a one-time investment configuring it to behave sanely. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
"David Kastrup" wrote in message
news:87aajqowbn@lola.goethe.zz...
"Phil Holmes" writes:
"David Kastrup" wrote in message
news:87ei92oxo3@lola.goethe.zz...
"Phil Holmes" writes:
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting? Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.
Apologies. As you're probably aware, I'm a Windows man, and some
postings don't quote properly using my mailreader.
I am sure that there are sensible configurations available also for
Windows mailreasers.
Hey - you're talking about M$ software here! (FWIW I use the same software
for mail and news, - partly since the lilypond newsgroups are also mailing
lists. I don't want to change).
As a result, If I want all the > signs there, I have to put them in by
hand. In this case, I didn't bother.
You should at the very least delete the signature marker ("-- " on a
line of its own).
Good tip.
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from the key. Therefore, in your example we return to C major,
and so there's no need to print the accidental. I'd welcome other
thoughts as to whether this is correct, though.
I don't think it is correct. If you set the above with \key g\major,
you will notice that the key signature is _not_ repeated with a clef
change. So there is no visual or logical reason to assume
"accidentals are reset". If that was the underlying assumption for a
clef change, the key signature would be repeated.
So I'm confused as to what the regtest text cited means. It
(accidental-clef-change.ly) says "Accidentals are reset for clef
changes."
Which is likely the intent. It is still not proper in my opinion. I
would suppose that a conservative approach would be to mark all
non-signature accidentals in force at the time of the clef change in a
manner that will cause a (sometimes cautionary) accidental to be printed
regardless of whether the next note on the previously
accidental-equipped is in-signature or not.
That's sort of a half-reset of accidentals: it sets all non-signature
accidentals basically to "unknown".
It seems to me that, unless there is a cast iron rule in the literature (and
it would appear not to be the case) then the best option might be to treat
the clef change as a bar-line and use cautionaries as appropriate.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Reinhold Kainhofer writes: > Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes: >> "David Kastrup" wrote in message >> > I don't think it is correct. If you set the above with \key g\major, >> > you will notice that the key signature is _not_ repeated with a clef >> > change. So there is no visual or logical reason to assume "accidentals >> > are reset". If that was the underlying assumption for a clef change, >> > the key signature would be repeated. >> >> So I'm confused as to what the regtest text cited means. It >> (accidental-clef-change.ly) says "Accidentals are reset for clef changes." > > > I would be great, though, if anyone can find a published example of such a > situation (most likely in e.g. cello/bassoon parts/scores, which frequently > switch between bass and tenor clef). Edition Peters, piano excerpt by Brissler from Mozart Requiem, "Confutatis". The g in the corni di bassotto entry is not even in the same octave, and still gets a natural. confutatis.pdf Description: Adobe PDF document -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes:
> "David Kastrup" wrote in message
> > I don't think it is correct. If you set the above with \key g\major,
> > you will notice that the key signature is _not_ repeated with a clef
> > change. So there is no visual or logical reason to assume "accidentals
> > are reset". If that was the underlying assumption for a clef change,
> > the key signature would be repeated.
>
> So I'm confused as to what the regtest text cited means. It
> (accidental-clef-change.ly) says "Accidentals are reset for clef changes."
I couldn't really find anything about accidentals in combination with clef
changes in Stone or Read. The only thing that might apply is in Stone (p.54,
item "D. At Clef Changes":
If a clef changes withing a measure and the same note occurs before and after
the clef change, the accidental must be repeated:
(Example in lilypond-notation:)
\relative c'' { \time 2/4 \clef "treble" a8[( cis,]) \clef "bass" cis[( e,]) }
In that example, the cis after the clef change gets a sharp.
However, this example is only about repeating an accidental, not about whether
all previous accidentals are actually reset and no natural is required.
As a musician, I would definiely appreciate if the natural sign is displayed,
just to make it clear that it is a c and not a cis.
I would be great, though, if anyone can find a published example of such a
situation (most likely in e.g. cello/bassoon parts/scores, which frequently
switch between bass and tenor clef).
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
"Phil Holmes" writes:
> "David Kastrup" wrote in message
> news:87ei92oxo3@lola.goethe.zz...
>> "Phil Holmes" writes:
>>
>>> \relative c' {
>>> \clef bass cis2 c
>>> \clef tenor cis2 \clef bass c % natural is not printed!!
>>> \clef bass cis2 \clef tenor c
>>> }
>>
>>
>> Could you _please_ _never_ write an answer or comment in the _signature_
>> of the original posting? Sensible mailreaders don't quote the signature
>> when replying, cutting away all of your content.
>
> Apologies. As you're probably aware, I'm a Windows man, and some
> postings don't quote properly using my mailreader.
I am sure that there are sensible configurations available also for
Windows mailreasers.
> As a result, If I want all the > signs there, I have to put them in by
> hand. In this case, I didn't bother.
You should at the very least delete the signature marker ("-- " on a
line of its own).
>> Now to your comment:
>>
>>> It's doing what I would expect from reading the regtest - i.e. - when
>>> there is a clef change, the accidentals are reset to that which you'd
>>> expect from the key. Therefore, in your example we return to C major,
>>> and so there's no need to print the accidental. I'd welcome other
>>> thoughts as to whether this is correct, though.
>>
>> I don't think it is correct. If you set the above with \key g\major,
>> you will notice that the key signature is _not_ repeated with a clef
>> change. So there is no visual or logical reason to assume
>> "accidentals are reset". If that was the underlying assumption for a
>> clef change, the key signature would be repeated.
>
> So I'm confused as to what the regtest text cited means. It
> (accidental-clef-change.ly) says "Accidentals are reset for clef
> changes."
Which is likely the intent. It is still not proper in my opinion. I
would suppose that a conservative approach would be to mark all
non-signature accidentals in force at the time of the clef change in a
manner that will cause a (sometimes cautionary) accidental to be printed
regardless of whether the next note on the previously
accidental-equipped is in-signature or not.
That's sort of a half-reset of accidentals: it sets all non-signature
accidentals basically to "unknown".
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
"David Kastrup" wrote in message
news:87ei92oxo3@lola.goethe.zz...
"Phil Holmes" writes:
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting? Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.
Apologies. As you're probably aware, I'm a Windows man, and some postings
don't quote properly using my mailreader. As a result, If I want all the >
signs there, I have to put them in by hand. In this case, I didn't bother.
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from the key. Therefore, in your example we return to C major,
and so there's no need to print the accidental. I'd welcome other
thoughts as to whether this is correct, though.
I don't think it is correct. If you set the above with \key g\major,
you will notice that the key signature is _not_ repeated with a clef
change. So there is no visual or logical reason to assume "accidentals
are reset". If that was the underlying assumption for a clef change,
the key signature would be repeated.
So I'm confused as to what the regtest text cited means. It
(accidental-clef-change.ly) says "Accidentals are reset for clef changes."
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
"Phil Holmes" writes:
> \relative c' {
> \clef bass cis2 c
> \clef tenor cis2 \clef bass c % natural is not printed!!
> \clef bass cis2 \clef tenor c
> }
Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting? Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.
Now to your comment:
> It's doing what I would expect from reading the regtest - i.e. - when
> there is a clef change, the accidentals are reset to that which you'd
> expect from the key. Therefore, in your example we return to C major,
> and so there's no need to print the accidental. I'd welcome other
> thoughts as to whether this is correct, though.
I don't think it is correct. If you set the above with \key g\major,
you will notice that the key signature is _not_ repeated with a clef
change. So there is no visual or logical reason to assume "accidentals
are reset". If that was the underlying assumption for a clef change,
the key signature would be repeated.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Hello,
- Original Message -
From: "Xavier Scheuer"
To: "bug-lilypond" ; "lilypond-user"
Cc: "Philhar"
Sent: Tuesday, December 28, 2010 10:53 AM
Subject: Accidental and clef change issue
Hi!
This has been reported on the French user mailing list.
In the following code the c-natural is not printed if there is a clef
change in the middle of the measure.
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
I do not know what say references like Ross, Read about this but I do
not think this should be the correct behaviour.
IMHO this is not what a musician (and a user) expect:
if we have a c-sharp and then a c-natural (at the same octave)
_in the same measure_, then the natural __MUST__ be printed!
This is also against what is said in the regtest
‘accidental-clef-change.ly’: Accidentals are reset for clef changes
(note that this regtest works fine but the reported code does not).
Could you investigate this?
Thanks in advance.
Cheers,
Xavier
PS: The only "simple" workaround is to use
#(set-accidental-style 'piano)
--
Xavier Scheuer
It's doing what I would expect from reading the regtest - i.e. - when there
is a clef change, the accidentals are reset to that which you'd expect from
the key. Therefore, in your example we return to C major, and so there's no
need to print the accidental. I'd welcome other thoughts as to whether this
is correct, though.
--
Phil Holmes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Accidental and clef change issue
Hi!
This has been reported on the French user mailing list.
In the following code the c-natural is not printed if there is a clef
change in the middle of the measure.
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
I do not know what say references like Ross, Read about this but I do
not think this should be the correct behaviour.
IMHO this is not what a musician (and a user) expect:
if we have a c-sharp and then a c-natural (at the same octave)
_in the same measure_, then the natural __MUST__ be printed!
This is also against what is said in the regtest
‘accidental-clef-change.ly’: Accidentals are reset for clef changes
(note that this regtest works fine but the reported code does not).
Could you investigate this?
Thanks in advance.
Cheers,
Xavier
PS: The only "simple" workaround is to use
#(set-accidental-style 'piano)
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
