Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]
Il giorno dom, 24/04/2011 alle 19.43 -0600, Carl Sorensen ha scritto:
I find it simpler to just do
\new TabStaff \relative c' {
\chordGlissando
bes\3 cis\2 fis\18 b\3 d\2 g\1
\chordGlissando
bes='\3 cis\2 fis\18 b\3 d\2 g\1
}
It still gets the warning, but I think it's easier than the
\octaveCheck
form.
I agree, but I thought it didn't work. It works indeed, if only = is
used (without '): bes=\3
I'll use this snippet.
Thanks
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
mergeDifferentlyHeaded inconsistency
From Damien Pallant:
\new Staff {
\key ees \major
\clef treble
\override Staff.NoteCollision #'merge-differently-headed = ##t
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\relative c' {
{ r8 g ( bes d-3 ) f4-5 -- ees-4 -- } \\ { s8 g,~ g bes2. }
{ r8 aes ( bes ees-4 ) f4-5 -- ees-4 -- } \\ { s8 aes,~ aes bes2. }
}
}
merge-differently-headed works on the first chord but not the second.
Is this a known issue?
Cheers,
MS
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1624 in lilypond: Segfault with stabel and development versions
Comment #4 on issue 1624 by brownian.box: Segfault with stabel and development versions http://code.google.com/p/lilypond/issues/detail?id=1624 Sorry, what are fixed_2_15_0 and backport ? This code still segfaults with 2.13.60. Please, what's the version to verify with? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1623 in lilypond: Override Stem #'length-fraction not applied to leger notes
Updates: Status: Verified Comment #2 on issue 1623 by brownian.box: Override Stem #'length-fraction not applied to leger notes http://code.google.com/p/lilypond/issues/detail?id=1623 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: mergeDifferentlyHeaded inconsistency
m...@apollinemike.com m...@apollinemike.com writes:
From Damien Pallant:
\new Staff {
\key ees \major
\clef treble
\override Staff.NoteCollision #'merge-differently-headed = ##t
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\relative c' {
{ r8 g ( bes d-3 ) f4-5 -- ees-4 -- } \\ { s8 g,~ g bes2. }
{ r8 aes ( bes ees-4 ) f4-5 -- ees-4 -- } \\ { s8 aes,~ aes bes2. }
}
}
merge-differently-headed works on the first chord but not the second.
I have a hard time imagining what result you expect here. The chords in
the lower voice are stemmed with a single stem (one voice - one stem).
The aes-bes chord requires juggling the note heads to fit them on one
stem, so that they are no longer vertically aligned. How would you
merge the resulting construct with the upper voice?
Do you have a scan or a handwritten version illustrating the desired
result?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: mergeDifferentlyHeaded inconsistency
On Apr 25, 2011, at 6:14 AM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
From Damien Pallant:
\new Staff {
\key ees \major
\clef treble
\override Staff.NoteCollision #'merge-differently-headed = ##t
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\relative c' {
{ r8 g ( bes d-3 ) f4-5 -- ees-4 -- } \\ { s8 g,~ g bes2. }
{ r8 aes ( bes ees-4 ) f4-5 -- ees-4 -- } \\ { s8 aes,~ aes bes2. }
}
}
merge-differently-headed works on the first chord but not the second.
I have a hard time imagining what result you expect here. The chords in
the lower voice are stemmed with a single stem (one voice - one stem).
The aes-bes chord requires juggling the note heads to fit them on one
stem, so that they are no longer vertically aligned. How would you
merge the resulting construct with the upper voice?
Do you have a scan or a handwritten version illustrating the desired
result?
I think what the user wants are the two Bb merged the second time round. So,
keep the horizontal spacing of the lower voice and shift the upper voice such
that the Bbs meet up.
Cheers,
MS
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1624 in lilypond: Segfault with stabel and development versions
Comment #5 on issue 1624 by percival.music.ca: Segfault with stabel and development versions http://code.google.com/p/lilypond/issues/detail?id=1624 2.15.0 is the lowest version of lilypond that we think it will work. Since 2.13.60 is lower than 2.15.0, you should not attempt to verify this. Ignore the backport. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1634 in lilypond: make find(1) work on BSDs
Status: Fixed Owner: Labels: Type-Build Priority-Critical backport New issue 1634 by percival.music.ca: make find(1) work on BSDs http://code.google.com/p/lilypond/issues/detail?id=1634 8f4f11d08a43df534f9b720395f7e11a989e1664 should be backported. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1626 in lilypond: Articulate produces faulty barcheck warnings
Comment #3 on issue 1626 by percival.music.ca: Articulate produces faulty barcheck warnings http://code.google.com/p/lilypond/issues/detail?id=1626 patch here: http://codereview.appspot.com/4435069 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1633 in lilypond: pdf utf-16be breaks doc compile
Comment #4 on issue 1633 by percival.music.ca: pdf utf-16be breaks doc compile http://code.google.com/p/lilypond/issues/detail?id=1633 Here's two bach schenkers. One is from a standalone compile with out/bin/lilypond and the other is from the docs. Both are from the same computer, same libraries, same git version, fresh build dir, etc. The only difference is whether it comes from make doc or from the raw command-line. Attachments: bach-schenker-standalone.ps 311 KB bach-schenker-docs.ps 260 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Part Combiner problems
I'm not top posting.
I have found an issue with the \partcombine tool, but I am not quite
sure whether it is a definite bug or one of the various limitations
it has. If one starts a tie, slur, crescendo hairpin or other such
while in one mode of \partcombine (\partcombineChords,
\partcombineApart, \partcombineUnisono, etc.) and then switches to
another before the tie, slur or crescendo hairpin is complete,
Lilypond prints a warning about unterminated and does not print
it. The following source code triggers the bug:
\version 2.13.60
FlautoI = \relative c''{ \partcombineChords c2~ \partcombineApart c }
FlautoII = \relative c''{ \partcombineChords b2\ \partcombineApart b\! }
\relative c''{
\partcombine \FlautoI \FlautoII
}
I suspect this is because in regular polyphony, inter-Voice spanning
objects are disallowed?
Olexa Bilaniuk
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1635 in lilypond: clean up misleading warnings in website build
Status: Accepted Owner: CC: philehol...@googlemail.com, colinpkc...@gmail.com Labels: Type-Build Priority-High Maintainability New issue 1635 by percival.music.ca: clean up misleading warnings in website build http://code.google.com/p/lilypond/issues/detail?id=1635 Start with make website. If the build completes successfully, there should be no warnings. We currently have tons of warning and scary-looking messages. Off the top of my head, I think that over 95% of them can be resolved by modifying less than 5 lines of python code in one of the scripts/build/*.py files. (we have way more tons of such warnings in the main doc build, but let's take this one step at a time and focus on the website first) Phil, Colin: this would be a good test of the website build instructions, and your own interest in the build system. I know that neither of you are python users, but it's a fairly easy language to pick up. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1607 in lilypond: patch for mandolin freboard diagrams
Updates: Status: Fixed Labels: -Patch-review fixed_2_15_0 Comment #3 on issue 1607 by percival.music.ca: patch for mandolin freboard diagrams http://code.google.com/p/lilypond/issues/detail?id=1607 pushed. 5becf12f5ada67346f70ad8cfe68589466619305 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Wrong version of midi.so in LilyPond 2.13.60
(This is MacOS X 10.5.8 on Intel.) If I try to run midi2ly, I get a version mismatch for the midi library imported by python. I made sure to run python from the app bundle: /Applications/LilyPond.app/Contents/MacOS/python /Applications/LilyPond.app/Contents/Resources/bin/midi2ly example.mid -o example1.ly /Applications/LilyPond.app/Contents/Resources/bin/midi2ly:54: RuntimeWarning: Python C API version mismatch for module midi: This Python has API version 1013, module midi has version 1012. import midi Sorry for double posting: I forgot to write this about LilyPond 2.13.60. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]
Il giorno lun, 25/04/2011 alle 00.09 +0200, Federico Bruni ha scritto:
Or should I rather edit
Documentation/snippets/new/chord-glissando-in-tablature.ly?
I've changed my mind and I think that I should edit this file instead of
fretted-strings.itely.
In the meanwhile I've realized that relative mode triggers another error
when chordGlissando moves down (from higher to lower pitches). Pitches
are correct, but glissandi are in a mess.
See chord-glissando-down.ly attached.
There's a workaround for this error?
I think that documentation should cover this issue as well (if there's
not a workaround, we might say that a chordGlissando moving back
should be entered in absolute mode?).
Thanks,
Federico
\version 2.13.60
relativeMode = \relative c' {
\chordGlissando
f\3 a\2 c\1 c\3 e\2 g\18
}
\new StaffGroup
\new Staff { \clef G_8 \relativeMode }
\new TabStaff { \clef moderntab \relativeMode }
absoluteMode = {
\chordGlissando
f'\3 a'\2 c''\1 c'\3 e'\2 g'\18
}
\new StaffGroup
\new Staff { \clef G_8 \absoluteMode }
\new TabStaff { \clef moderntab \absoluteMode }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]
On 4/25/11 11:26 AM, Federico Bruni fedel...@gmail.com wrote: Il giorno lun, 25/04/2011 alle 00.09 +0200, Federico Bruni ha scritto: Or should I rather edit Documentation/snippets/new/chord-glissando-in-tablature.ly? I've changed my mind and I think that I should edit this file instead of fretted-strings.itely. In the meanwhile I've realized that relative mode triggers another error when chordGlissando moves down (from higher to lower pitches). Pitches are correct, but glissandi are in a mess. See chord-glissando-down.ly attached. There's a workaround for this error? I think that documentation should cover this issue as well (if there's not a workaround, we might say that a chordGlissando moving back should be entered in absolute mode?). It looks to me like the proper documentation is a warning that says chordGlissando is unreliable in relative mode. It is recommended to be always used in absolute mode. A bug report should be posted. We don't normally list bugs as warnings, so maybe once we list the bug we can't have the warning. It appears to me right now that chordGlissando is a sufficiently rough hack that it should probably be removed from the distribution and just be present in the LSR. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]
On 11-04-25 11:33 AM, Carl Sorensen wrote: On 4/25/11 11:26 AM, Federico Brunifedel...@gmail.com wrote: Il giorno lun, 25/04/2011 alle 00.09 +0200, Federico Bruni ha scritto: Or should I rather edit Documentation/snippets/new/chord-glissando-in-tablature.ly? I've changed my mind and I think that I should edit this file instead of fretted-strings.itely. In the meanwhile I've realized that relative mode triggers another error when chordGlissando moves down (from higher to lower pitches). Pitches are correct, but glissandi are in a mess. See chord-glissando-down.ly attached. There's a workaround for this error? I think that documentation should cover this issue as well (if there's not a workaround, we might say that a chordGlissando moving back should be entered in absolute mode?). It looks to me like the proper documentation is a warning that says chordGlissando is unreliable in relative mode. It is recommended to be always used in absolute mode. A bug report should be posted. We don't normally list bugs as warnings, so maybe once we list the bug we can't have the warning. It appears to me right now that chordGlissando is a sufficiently rough hack that it should probably be removed from the distribution and just be present in the LSR. Thanks, Carl Should this be a new issue, Carl, or should I just add this message to issue 1617? Colin Campbell -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]
It appears to me right now that chordGlissando is a sufficiently rough hack that it should probably be removed from the distribution and just be present in the LSR. +1. I will have time this weekend to work on an implementation that uses a context property to control how glissandi are typeset for chords. Cheers, MS ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1618 in lilypond: unpredictable placement of rests
Comment #5 on issue 1618 by percival.music.ca: unpredictable placement of rests http://code.google.com/p/lilypond/issues/detail?id=1618 Amazing work as always. I can confirm the clean regtests, and I've uploaded the patch here: http://codereview.appspot.com/4441066/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1620 in lilypond: Midi overflow with instrument changes
Updates: Labels: fixed_2_15_0 backport Comment #9 on issue 1620 by k-ohara5...@oco.net: Midi overflow with instrument changes http://code.google.com/p/lilypond/issues/detail?id=1620 So we need to mention midiChannelMapping in CHANGES. I will try to add that soon. midiVolume did work in versions 2.12.3 through at least 2.13.48, so I'll raise another issue for that. Workaround is to avoid zero volume, such as : midiMinimumVolume = #0.01 midiMaximumVolume = #0.02 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1636 in lilypond: midiVolume 0.0 not respected
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical Regression
New issue 1636 by k-ohara5...@oco.net: midiVolume 0.0 not respected
http://code.google.com/p/lilypond/issues/detail?id=1636
Setting midi volume to 0.0 for some instruments is very useful for
proofreading (proof-listening) scores. With the current mixed
implementation of dynamics as part MIDI velocity, part MIDI volume, the net
effect of volume 0.0 should be silence, but it is not.
Fortunately, the workaround is very easy: 0.001. (I intend to mention the
workaround in CHANGES soon, in hopes of making thus not-release-blocking;
that mention can be deleted if the bug can be fixed.)
--8--
\version 2.13.60 % 2.12.3 and 2.13.48 work
%{ midiM*Volume not respected if volume is 0.0
Below, dynamics are not essential, but helpful for reading the MIDI file.
%}
\score {
{
g'4\fff g'4\ppp
\set Staff.midiMinimumVolume = #0.0
\set Staff.midiMaximumVolume = #0.0 % workaround: #0.0001
g'4\fff g'4\ppp
}
\midi { }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1618 in lilypond: unpredictable placement of rests
Updates: Labels: -Patch-new Patch-review Comment #6 on issue 1618 by k-ohara5...@oco.net: unpredictable placement of rests http://code.google.com/p/lilypond/issues/detail?id=1618 I resolved my connection problem, and uploaded the patch and a regtest at http://codereview.appspot.com/4442083/ The patch resolves both this issue and issue 1547. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Doc: LSR: midi
A revision to the snippet in section 3.5.1 of the Notation Reference is awaiting approval in the LSR. Changing MIDI output to one channel per voice [corrected] The only change is the text. The old text there are only 16 MIDI channels available per track was wrong. Tracks are purely file organization and you can have thousands of tracks if you like. There are only 16 MIDI channels in the protocol. To get more channels, you need more MIDI cables (ports) and more synthesizers (soundcards) to connect via those cables (ports). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
