Re: Proposed Changes to the Usage 5.5 Make and Makefiles

On 6/7/20, Fr. Samuel Springuel wrote: > Attached is my proposed revision to the sample Makefile which deals with all > of the above issues. Greetings, I’ve tried integrating your changes (see attached), but I have a few questions: - are we definitely sure that -djob-count is a no-op? Couldn’t i

Re: Ugly acciaccatura slurs?

On 6/10/20, Paul Hodges wrote: > On 10/06/2020 19:00:29, "Caio Barros" wrote: > >>I don't recall right now a good example of this notation from the >>literature, but I think the output should be something like > Have an example, typeset by Universal Edition in 1927: > https://cassland.org/images/

Re: Outside staff dotted rests (v2.20 & 2.21)

On 6/5/20, Pierre Perol-Schneider wrote: > Here's my proposal for dots stable alignment for outside staff rests: Hey Pierre, thanks for investigating this! Do you have access to the GitLab tracker? I think you should go ahead and open a page there (assuming there isn’t one already; I remember s

Re: Filtering chunks of the score so to speed up the compiling time

On 6/14/20, Paolo Prete wrote: > However, the doc says that "it skips all events, including tempo and > instrument changes", but in the proposed example the \tempo instruction is > not skipped. The sentence you’re quoting regards the MIDI output; it means that if you only listen to the rendered

Re: Fingering inside staff

On 5/30/20, Thomas Morley wrote: > add-stem-support is not really documented. > Alas, I've not the time and energy to write a patch myself and fight > my way through the new GitLab process. “Fighting your way” sounds pretty accurate these days. If I may give it a try: https://gitlab.com/lilypond

Re: Fingering inside staff

On 5/30/20, Valentin Villenave wrote: > Excellent; NOTABUT then. Ouch. NOTABUG. (Though I can’t say I wasn’t childishly tempted to add an additional T :-) V. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listi

Re: Fingering inside staff

On 5/30/20, Thomas Morley wrote: > Fingering.add-stem-support is per default set to 'only-if-beamed' Of course!! I vaguely remembered having come across something like that. Sorry for making a fool of myself. > Try: > \override Fingering.add-stem-support = #'() > and it'll work Excellent; NOT

Re: Fingering inside staff

On 5/29/20, Pierre Perol-Schneider wrote: > Hi Simone, > A basic solution: > \relative c' { > \stemUp > \override Fingering.staff-padding = #'() > 4 8 > } Sure there are workarounds, but: shouldn’t we be treating this as a bug? There’s no obvious reason why unsetting staff-padding should b

Re: musicxml2ly

On 5/23/20, Martin Tarenskeen wrote: > > On Sat, 23 May 2020, Martin Tarenskeen wrote: >> There must be something seriously broken if musicxml2ly can't convert >> this > > P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and > the problem disappeared. So it does look like a reg

Re: Keys won't display as text in saxophone diagram

On 5/23/20, Antonio Ortega Brook wrote: > @Carl: yes, that's exactly what I was looking for (although things may have > changed a bit, now...), thank you very much. As far as I can tell, > everything seems to be working as expected. Great! Carl, feel free to open a merge request or to push new c

Re: Keys won't display as text in saxophone diagram

On 5/21/20, Antonio Ortega Brook wrote: > Hello everyone. First of all I think maybe I misunderstood the instructions > for bug reporting and I've opened an issue in GitLab before posting to this > list and now I think that I might not be supposed to do that. I'm very > sorry for the inconvenience

Re: musicxml2ly fails on with multiple

On 5/18/20, Noam Postavsky wrote: >> > Ping? >> Ping?? > Ping??? Greetings Noam, thanks for being so persistent; I’m not very familiar with musicxml2ly but I submitted your patch here on your behalf: https://gitlab.com/lilypond/lilypond/-/merge_requests/65 As far as I can see it doesn’t break a

Re: Small bugs in "Changes" document

On 5/16/20, Timothy Lanfear wrote: > The descriptions of changes to \powerChords, \partcombine and > \autochange have acquired an extra backslash. Thanks for catching that; it should be fixed shortly: https://gitlab.com/lilypond/lilypond/-/merge_requests/58 Cheers, -- V. ___

Re: accidentalStyle choral: too many accidentals in situations with ties

On 5/15/20, Alexander Kobel wrote: > a clear case of undesired behavior. … Otherwise known as a bug. I agree. I’m thinking there’s a good chance that it’s another instance of https://gitlab.com/lilypond/lilypond/-/issues/3466 (but Simon’s example is much nicer so I’ve just added it there.) Che

Re: [bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver

On 5/6/20, Trevor Bača wrote: > The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1. Wow, that’s a nice one. I’m marking this as Critical because its a/ a segfault, b/ a regression and c/ not that unusual a use case. https://sourceforge.net/p/testlilyissues/issues/5964/ Since i

Re: Bar number with chord name

On 4/18/20, Aidan O Connor wrote: > When chord names are included, the bar numbers are positioned above the > chord name. Greetings, Well, yes and no. They are positioned above the whole *system* (the Score context), of which the ChordNames context is a part. So whilst that’s certainly quite ugly

Re: SystemStart changes after stop/startStaff - how to get it back

On 4/12/20, Thomas Morley wrote: > Over the last decades I tried again and again to find a better > workaround, with less manual work. Apparently we stumbled upon your white whale :-) > I now come up with the attached. Brilliant. Although it’s still a workaround. > To get the gaps in containe

Re: SystemStart changes after stop/startStaff - how to get it back

On 4/12/20, Thomas Morley wrote: > Hi, > The SystemStartBrace vanishes after stop/startStaff. Weird. That’s definitely an unwanted behavior (in other words, a bug). > consider the following code: > > > mus = \new Staff { R1 \break R \stopStaff s \startStaff R \break R \break R > } > > \new Staf

Re: associatedVoice in multi-staff score

On 4/4/20, Thomas Morley wrote: > At least it should be documented, probably as "known issues and warnings" The two examples in NR 2.1.2.2 seem clear: """ use the same syntax as above [that is, with \new Lyrics below \new Staff] and explicitly specify the position of the lyrics: " """ Alternativ

Re: Spacing in clef changes

On 3/19/20, Jean Abou Samra wrote: > Please tell me if you open an issue (I would like to follow the ticket). Hi Jean, you may want to open it yourself; you could tag it as "Defect" (I believe "Ugly" would be a bit strong -- there once was an "Engraving_nitpick" tag that would have been perfect,

Re: ChordNames depend on input language

On 4/28/19, Malte Meyn wrote: > How would I achieve that in 2.21.0? And am I the only one who thinks > that the input language and output language should be independently > settable? Looking more closely, it seems that the last \language setting is applied to all chords. See what happens with the

Re: gs version error in latest GUB build

On 4/3/19, Knut Petersen wrote: > An strace log that shows argv and env of execve gs would be helpfull ... Here’s a full strace log from that user, I’m not sure how to find that specific information: http://lilypond-french-users.1298960.n2.nabble.com/file/t249946/lily_strace.txt Cheers, V.

Re: gs version error in latest GUB build

On 4/2/19, Federico Bruni wrote: > As far as I can see from my installations, gs distributed in > lilypond.org recent installers is version 9.26. Nope: $ wget http://lilypond.org/download/binaries/linux-64/lilypond-2.19.83-1.linux-64.sh $ sh lilypond-2.19.83-1.linux-64.sh --tarball $ tar -tjvf

Re: gs version error in latest GUB build

On 3/31/19, Valentin Villenave wrote: > I couldn’t reproduce (but then again I’m not running Ubuntu). I also > find it odd that only some scores are reported to fail while other’s > aren’t. OK, as I suspected *all* scores do indeed fail for this user. Further information just in case:

gs version error in latest GUB build

Greetings, someone on -user-fr has reported gs crashing on some scores (for example the first incipit example from NR 2.9.6), with the following error: gs: Interpreter revision (926) does not match gs_init.ps revision (921). This looks very much like something we’ve seen recently: https://lists.

Re: Website: broken 2.21 links

On 2/10/19, David Kastrup wrote: > I think I headscratched for a while over make/website.make and did not > come up with something working when I did. OK, meanwhile, I’ve opened a tracker page: https://sourceforge.net/p/testlilyissues/issues/5477/ Cheers, V.

Re: Website: broken 2.21 links

On 2/9/19, David Kastrup wrote: > This is just broken. It should point to VERSION_STABLE and > VERSION_DEVEL which are always pointing to _existing_ versions rather > than to to-be-released versions. Huh. There seems to be a discrepancy between what create-weblinks-itexi.py does, and the way ma

Website: broken 2.21 links

Greetings, many links (particularly @rcontrib{} links) on the website point to 2.21 directories that are not online yet, as you can verify by doing: wget -r --ignore-tags=img \ --exclude-directories=doc,website,attic,download \ --reject jpg,pdf,png,css,jz,gz,sh,bz2,exe \ --accept "*.html" ht

Re: Dynamics context spawns additional contexts when polyphonic

ng you again.) Cheers, Valentin. From 8abb84c2bf30e32702ecd274df7bfa114f0d851f Mon Sep 17 00:00:00 2001 From: Valentin Villenave Date: Thu, 31 Oct 2013 21:15:06 +0100 Subject: [PATCH] Make Dynamics into a Staff-like context. This commit creates a DynamicsVoice context, and moves the former Dynamics cont

Re: Dynamics context spawns additional contexts when polyphonic

On Thu, Oct 31, 2013 at 12:24 PM, David Kastrup wrote: > First you have to figure out what you want to happen here. Do you want > two Dynamics contexts with different orientation and settings? In that > case, you'll need to provide a superior context aliased to Staff where > it can anchor those

Re: Dynamics context spawns additional contexts when polyphonic

On Thu, Oct 31, 2013 at 12:24 PM, David Kastrup wrote: > But you did not put \\ in a DynamicsStaff context, so it has no suitable > container where it could place separate Dynamics contexts. Something like that? \layout { \context { \Staff \type "Engraver_group" \name "DynamicsStaf

Re: Dynamics context spawns additional contexts when polyphonic

On Thu, Oct 31, 2013 at 6:39 AM, David Kastrup wrote: > I'm having a weird time with that report. \\ is called a Voice > separator, so it separates voices. Well, yes :-) But for example, if you put \\ in a DrumStaff context, it will create DrumVoices and not spawn brand-new regular Voice and Sta

Dynamics context spawns additional contexts when polyphonic

Greetings everybody, I’m having a weird time today with the following code: \version "2.17.30" % Also with earlier versions. \new Dynamics { a1\f << a \\ b\p >> } The first bar works as expected; in the second all hell breaks loose: notes are printed in newly-created Voice contexts,

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Sun, Dec 4, 2011 at 5:06 PM, David Kastrup wrote: >  `(module-define! (current-module) (string->symbol ,token) Wow, interesting. I had seen such things in Nicolas' code (and in LilyPond codebase), but couldn't understand what it was for. > Using module-define! beats primitive-eval.  If you wa

Re: New read/eval Scheme syntax inconsistent in handling existing code

commit: (define (foo) bar) isn't evaluated quite exactly like (define foo bar), only the former of which allows for docstrings. So I'm not sure how to properly document (define foo bar), other than in comments. Anyway. Attached is a patch that I'd suggest for the two oddities you'

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Sun, Dec 4, 2011 at 9:38 AM, David Kastrup wrote: > Apart from the rest of this ugly contraption, You mean, uglier than using eval-string? I'm not sure what a less ugly way of doing that would look like. (Perhaps using hooks, but I have yet to master that.) > there is no reason > whatsoever w

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Fri, Dec 2, 2011 at 1:59 PM, David Kastrup wrote: > I don't see why defmacro should have ceased working, so it might be > worth revisiting the problems you experienced. It's not defmacro that ceased working, it's just that I previously used the old ly:make-music-function syntax, which you chan

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Fri, Dec 2, 2011 at 10:14 AM, David Kastrup wrote: > The port-line/port-filename values that it had when reading a literal > string.  Of course, this approach would not work when we are talking > about a constructed string. [Which precisely happens to be what I'm using eval-line for in my fram

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Fri, Dec 2, 2011 at 1:05 AM, David Kastrup wrote: > The reason is that eval-string in Guile does not set > port-line/port-filename to sensible values and I use them for making > sensible error messages actually pointing to the source of the error. What would be "sensible values" here? Does it

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Thu, Dec 1, 2011 at 9:57 PM, Valentin Villenave wrote: > Unfortunately, it does not. [Oops, sent it a bit too soon.] This used to work, for instance: myvar = { b'4 } #(display "this needs to be here") #(eval-string "(define-public myvar #{ a'2 #} )" )

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Thu, Dec 1, 2011 at 12:58 PM, David Kastrup wrote: > It wouldn't have worked but you used to rely on it? This is because I tried to come up with a minimal example (my code is a tad more complex and *did* work). > Huh?  That is just the old well-known premature evaluation order timing > proble

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Fri, Nov 25, 2011 at 6:18 PM, David Kastrup wrote: > Valentin, any more news of bad effects on your scores?  Apart from the > bug that should now be fixed? OK, I've now had a chance to test the staging code, it's certainly an improvement! ... Aand I'm blocked by another bug (or unwanted behav

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Fri, Nov 25, 2011 at 6:18 PM, David Kastrup wrote: > Valentin, any more news of bad effects on your scores?  Apart from the > bug that should now be fixed? I'm having trouble connecting to the Internet these days (right now I'm using my neighbor's wifi while it lasts) so I haven't been able to

Re: New read/eval Scheme syntax inconsistent in handling existing code

On Mon, Nov 21, 2011 at 7:39 PM, David Kastrup wrote: > With all due respect, Really? Who are you and what have you done with David? :-) > I doubt that.  The reason is rather boring: my > changes broke ly:parser-include-string because I did not understand what > the pending_include whatever were

New read/eval Scheme syntax inconsistent in handling existing code

Greetings everybody, David's new code with #/$(scheme) styles does offer a lot of exciting possibilities... but it is also hugely disruptive when it comes to existing code! Consider for instance the following: \version "2.15.19" myvar = { b'4 } #(ly:parser-include-string parser "myvar = { a'2

Re: \tempo indication not printed

On Thu, Sep 1, 2011 at 4:06 PM, Reinhold Kainhofer wrote: > The issue is that the moment after the \tempo command does not have any grobs > where the tempo could be attached to. As soon as you change the s1 to a note > or rest, or if you have clef/key/timesig change at the same moment as the > \te

Re: \tempo indication not printed

On Thu, Sep 1, 2011 at 2:28 PM, Neil Puttock wrote: > See also issue 1276. Indeed. I did remember having seen such a thing, but all I could find was #1205 and #1150. Weird, though. Thanks! Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org

\tempo indication not printed

Dear all, let's make it official: I am going insane. Unless *anyone* can explain what's going on therebelow, that is. \version "2.15.9" { \time 3/4 s2. \time 2/4 s2 \tempo "Walda" \time 6/4 s1. \tempo "Waldi" \time 4/4 s1 \tempo "Waldo" s1 \time 2/4 s2_"Where's Waldo?" } Cheers, Va

Re: Lilynet down?

On Sun, Jul 31, 2011 at 9:42 PM, James Lowe wrote: > Sunday evening...I am guessing this is routine maintenance. Wow, I was doubting anyone would notice. Sorry for the downtime folks, I have migrated everything to a new server and (most importantly) I'm setting up the new Mutopia forge, which tur

Re: Possible regression in 2.13 series? "no viable configuration" warning

On Thu, Jul 7, 2011 at 3:19 PM, Dmytro O. Redchuk wrote: > Now there is 1702, "Unaesthetic beam slope", which reflects this situation, I > believe: > http://code.google.com/p/lilypond/issues/detail?id=1702 Yes, it's the one. I was worried it could go unaddressed in the 2.15 dev cycle. Thanks for

Re: tuplet number on cross-staff kneed-beam

On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnik wrote: > Hello, all -- Greetings, > First of all, I hope that I'm asking this question on the appropriate list! Since you're demonstrating a regression, I'm forwarding your message to our bug- list. > I'm trying to simplify the workaround relatin

Re: [translations] Doc: @snippets links are broken when translated

On Wed, Jun 29, 2011 at 7:42 PM, Jean-Charles Malahieude wrote: > Just because I use > @rlsrnamed{Keyboards, Claviers} > to have it labeled in French even if the target wont be translated. Clever. Then we'd probably need to harmonize this policy through the docs, since even in French the last lin

Doc: @snippets links are broken when translated

Greetings everybody, some translated doc pages have broken @snippet links; for example if you follow the link at the bottom of http://lilypond.org/doc/v2.15/Documentation/notation/expressive-marks-as-curves.de.html you'll see that it points to http://lilypond.org/doc/v2.15/Documentation/snippets/a

Slurs ignore intermediary cross-staff notes

Greetings Bug Squad, I've been looking at the tracker and known issues, but I couldn't find this one. Is this considered normal behavior? \version "2.15.3" << \new Staff = "up" { s1 } \new Staff = "down" \relative c' { c8( \change Staff = "up" c' c \change Staff = "down"

Re: Accidentals may cause odd-looking slurs

On Sat, Jun 25, 2011 at 6:57 PM, Colin Campbell wrote: > I believe this would be issue 163, Valentin. Yes, that was my first thought but #163 doesn't involve an accidental at all (in this case, the object that cause the ugly phrasing slur is another slur). There is an instance of this particular

Accidentals may cause odd-looking slurs

Greetings Bug Squad, the following snippet has been reported by someone on the -fr list; I do remember having seen that before, but I'm not sure exactly where: \version "2.14.0" \relative c''' { \ottava #1 % Bad shape a16( g'! e cis a g' e cis a a' fis d a a' fis d) % Good shape (the

Re: Possible regression in 2.13 series? "no viable configuration" warning

On Wed, Apr 20, 2011 at 4:47 PM, m...@apollinemike.com wrote: > That said, the following code still produces the same message: Greetings everybody, hi Mike, Since there's a lot of activity wrt beaming code these days, I'm wondering whether the possible regression I mentioned earlier is likely to

Re: Possible regression in 2.13 series? "no viable configuration" warning

On Tue, Apr 19, 2011 at 9:44 PM, Graham Percival wrote: > Well, the actual message (with 2.13.57) is: > warning: no viable initial configuration found: may not find good > beam slope Yep, what you said. > The cross-staff beams look a bit odd (the first note has a really > long stem). > > I'm sur

Possible regression in 2.13 series? "no viable configuration" warning

Greetings everybody, I've been pulling my hair all day long on this one, I may be getting crazy or perhaps you'll be able to reproduce this as well; Have a look at the following snippet, pretty straightforward: << \new Staff = "md" \relative c' { r4 r8 s s2 r4 r8 s s2 r4 e, r2 |

Re: Change the color of ledger lines

On Mon, Apr 18, 2011 at 12:06 PM, Xavier Scheuer wrote: > I know see the real problem: it is not possible to change the color of > ledger lines _in the middle of the score_. > > Is this a known issue? > Does it exist a workaround? How about restarting the staff, as in http://lsr.dsi.unimi.it/LSR/

Re: [tablatures] snippet "Slides in tablature", NR 2.4.1

#2 >    } >  } > } Hi Federico, hi everybody, here's a patch for the documentation accordingly to what you proposed. I'm not entirely sure it's suitable to introduce a new function (or more exactly, I'm wondering if it shouldn't rather be added to music-function.ly inst

Deprecate /cygwin/foo/bar/ online doc links?

Greetings, A French user has just posted this link to the documentation: http://lilypond.org/cygwin/release/lilypond/lilypond-doc/x/usr/share/doc/lilypond/html/Documentation/index.html It does work, but seems awfully complicated. Do we really want to maintain these URLs? How about a 301 "moved pe

Re: [tablatures] snippet "Slides in tablature", NR 2.4.1

On Sun, Apr 10, 2011 at 11:23 AM, Federico Bruni wrote: > (BTW, who maintain the LSR?) I'll have a look. Thanks! Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Nouveau projet et personne ressource

On Fri, Apr 8, 2011 at 3:21 PM, Werner LEMBERG wrote: > This is strange. At least in Austria, there is a difference between > `Großes Recht' (covering `big' things like scenic performances in > theatres) and `Kleines Recht' (everything else), and the AKM, the > Austrian sister organization of the

Re: Nouveau projet et personne ressource

On Fri, Apr 8, 2011 at 2:00 PM, m...@apollinemike.com wrote: > I'll gladly fork over my 2010 gross income. Wow, interesting (however OT). I've just had a phone call from the French author's rights management organization, saying they had collected nearly €4000 on my behalf subsequently to my firs

Re: Nouveau projet et personne ressource

2011/4/8 m...@apollinemike.com : > Will do...it does have scam written all over it, but if she wants to pay us > lots of money, I'd be happy to take one for the team so that LilyPond can > remain free. And in reverse ("she wants *us* to pay lots of money), will you take one for the team as well?

Re: Nouveau projet et personne ressource

2011/4/7 m...@apollinemike.com : > Il y a plusieurs utilisateurs francophones qui se trouvent partout dans le > monde qui seraient ravis de discuter de LilyPond avec vous.  En revanche, > nous n'avons pas l'habitude de diffuser nos numéros de téléphone sur cette > liste.  Pouvez-vous me contacte

Re: Typo in time-signature-settings.scm?

On Wed, Apr 6, 2011 at 7:07 PM, Carl Sorensen wrote: > (1.12) = (2 . 3) * (1 . 8) = (2 . 24) which is the duration of an 8th note > triplet. OK, that's what I wanted to know. > And yes, according to the rules in the references, triplets should be beamed > 3 by 3 (or every 1/4 note). > And 1/16 n

Re: Typo in time-signature-settings.scm?

On Sun, Apr 3, 2011 at 1:07 AM, Carl Sorensen wrote: > On 4/2/11 3:51 PM, "Valentin Villenave" wrote: >> Shouldn't it read "3/8, 6/8, and 8/8"? > > Yes, absolutely. > Thanks for the catch. Hi Carl, thanks! While we're talking beaming rules, I jus

Re: Chord repetition shortcut doesn't support relative mode in Scheme functions

On Mon, Apr 4, 2011 at 4:06 AM, Colin Campbell wrote: > http://code.google.com/p/lilypond/issues/detail?id=1110 > Is this a relative, or even an instance, of issue 1110? Looks very much like it indeed! Thanks Colin. Cheers, Valentin. ___ bug-lilypond

Typo in time-signature-settings.scm?

Hi Carl, hi everybody, time-signature-settings.scm, line 46 et seq.: ;;; If an exception is specified for a given beam-type, it will apply to all ;;; beams of shorter durations that don't have an individual exception, so ;;; ((1 . 8) . (3 3 2)) ;;; will cause all primary beams to

Chord repetition shortcut doesn't support relative mode in Scheme functions

Greetings everybody, hi Nicolas, I'm not sure anybody else has encountered this before (couldn't find any such reports in the tracker or in bug- archives). Have a look at the following example, where all four fragments should look the same (hint: they do not). In the first two, Lily behaves as ex

Re: Beaming rules may cause oddness when using hideNotes

On Sat, Mar 19, 2011 at 5:59 PM, Carl Sorensen wrote: > What would you like it to look like?  Can you manually beam it for us? Hi Carl, Well, ideally something like c''8.[ d''16] c''2, but even if unbeamed, I'd rather have a decent 16th note with a flag of sorts :) Thanks Phil and Xavier! Rega

Beaming rules may cause oddness when using hideNotes

Greetings everybody, I've just stumbled upon the following piece of code, and it took me a while to understand what was going wrong (although, granted, I should know better). \new Staff << \new Voice { \voiceOne \set tieWaitForNote = ##t c''16~ b''~ 8~ b''2. } \new Voice { \voiceTwo

Re: Issue 855 in lilypond: fix the command index

On Thu, Dec 23, 2010 at 12:47 AM, wrote: > it must have been a significant number of users, or one user > whom I respected. ... Wait, is it snowing in hell already? :-) Kidding. Get better! Cheers, Valentin. ___ bug-lilypond mailing list bug-lilypon

Re: Test case 42 "Two voices on staff"

On Sun, Dec 19, 2010 at 1:10 PM, Reinhold Kainhofer wrote: > Can this be added to the tracker? Sure thing: http://code.google.com/p/lilypond/issues/detail?id=1458 Cheers, Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.or

Re: Issue 1445 in lilypond: Doc: Snippet addition in NR 2.1 Vocal music

On Fri, Dec 10, 2010 at 5:17 PM, Phil Holmes wrote: > I only have the Login button when I'm not logged in.  Perhaps you still are? No, I'm not. here's the page I'm opening: https://lsr.dsi.unimi.it/list.php?type=snippet No "Login" button, and I can't modify any snippet. > If you can't get in a

Fwd: MusicXml2Ly - problem with spaces in paths and filenames

Greetings Bug Squad, here's a report that was sent to me privately (by accident I think). Could you have a look? Here's the discussion he's referring to: http://old.nabble.com/MusicXml2Ly---problem-with-spaces-in-paths-and-filenames-ts22167692.html#a22167692 Cheers! Valentin. -- Forwar

Re: 2.13.40 regtests

On Fri, Nov 26, 2010 at 8:10 PM, Phil Holmes wrote: > "Phil Holmes" wrote in message > Would anyone like me to put together a web page with them all on, to see if > it could be useful? Hi Phil, nicely done! As much as I'd hate to install mono on my computer, I'd be happy to have a look at such

Re: Redefining stencils in 'tweaks causes grobs to be printed twice

On Thu, Nov 25, 2010 at 1:06 AM, Neil Puttock wrote: > # > # > > When a DynamicLineSpanner is created, it gets its event-cause from the > dynamic grob which triggered its creation: > > 98 Dynamic_align_engraver::acknowledge_dynamic (Grob_info info) > 99 { > 100   Stream_event *cause = info.event_c

Redefining stencils in 'tweaks causes grobs to be printed twice

Greetings everybody, I'm not quite sure if this qualifies as a bug, but I can't figure out what on Earth is causing this strange behavior (maybe the tweak_engraver?): % Changing the stencil expression through the % 'tweaks alist causes a grob to be printed twice. fzz = #(let ((m (make-music

Re: Bug report

On Sat, Nov 20, 2010 at 6:48 PM, Reinhold Kainhofer wrote: > Actually, according to Gardner Read (Example 6-38 on p.93) the beams are > supposed to start at the left edge of the rest and stop at the right edge of > the rest, not in the middle as lilypond (both 2.12 and 2.13) do. Thanks! http://co

Re: 2.13.40 regtests

On Sun, Nov 21, 2010 at 1:42 PM, Phil Holmes wrote: > _However_.  Shouldn't the regtest comparison for > figured-bass-continuation-forbid.ly flag the change as well? I'm not sure I understand: do you mean that /disappearing/ errors should be flagged? Valentin. __

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Sat, Nov 20, 2010 at 12:33 AM, Graham Percival wrote: > Correctness is more important than speed. Only within reasonable limits. > If you want to improve our speed, then look into the "time" fields > in the regtest comparison.  It appears to be currently broken, but > fixing this will likely

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Fri, Nov 19, 2010 at 11:25 PM, wrote: > Unfortunately there's been a drop in performance since 2.13.36; I've > narrowed it down to Joe's fix for issue 1240 (5266aa). As you can see from > the above timings, it adds over forty minutes to both optimized and standard > builds. That's annoying.

Re: Issue 146 in lilypond: bar counters for normal bars

On Fri, Nov 19, 2010 at 3:48 PM, Alexander Kobel wrote: > (Note this is what I feel bar counters should look like, and it's similar to > what Werner implemented in the much simpler > .  For a proper enhancement, we > should have a look in some notation guid

Re: Issue 1298 in lilypond: minimum-Y-extent might be obsolete?

On Thu, Nov 18, 2010 at 5:58 AM, Keith E OHara wrote: > One affected item is a Snippet.  Fortunately, the modified snippet complies > the same under stable and development versions,  so I put it right away in > the LSR. Thanks, I've updated the snippet. I'll need to do an LSR tarball update soon.

Re: Successive Lyrics context no longer vertically aligned

On Tue, Nov 16, 2010 at 4:16 PM, Xavier Scheuer wrote: > As he mentioned also issue #127, could you check it is not the same > issue (or related). It does look like 127, but 127 isn't a regression whereas 1309 is. Until we've figured out 1309, I don't see 1401 going anywhere. Cheers, Valentin.

Successive Lyrics context no longer vertically aligned

Greetings everybody, this has been reported on the -fr list; it does look a lot like #1309 but I'm not entirely sure. % With older versions (e.g. 2.13.28), the % lyrics are printed as a single line. \score { << \new Staff { \new Voice = aa { a1 } \new Voice = bb { b1 } }

Re: Lyrics break estimation of vertical spacing

On Wed, Nov 10, 2010 at 2:01 PM, Valentin Villenave wrote: > Please forgive me for bumping this discussion, but I was wondering if > your work on the Lyrics spacing had ever been implemented and merged > into LilyPond. Oh, never mind. Just found it: http://code.google.com/p/lilypo

Re: Lyrics break estimation of vertical spacing

On Tue, Mar 30, 2010 at 2:08 PM, Boris Shingarov wrote: > Ok, it's fully functional now. I am going to format and upload a patch. Greetings Boris, Please forgive me for bumping this discussion, but I was wondering if your work on the Lyrics spacing had ever been implemented and merged into LilyP

Inconsistency: slurs attached to skips

Greetings everybody, I couldn't find this specific question discussed anywhere, but I'd appreciate if someone could point me to an existing tracker page or a former discussion on the lists. If you do \relative { c( s) } You'll see that a slur is produced, from the note to an invisible point.

Re: Please rewrite << { ... } \\ { ... } >> construct

On Mon, Nov 8, 2010 at 12:46 PM, Xavier Scheuer wrote: > We have had a discussion one year ago about a project to rewrite the >  << { ... } \\ { ... } >> Hi Xavier, isn't that the discussion I tried to sum up on http://code.google.com/p/lilypond/issues/detail?id=1316 ? Please repost your mail as

Re: enhancement request, page-breakers account for requested system spacing

On Fri, Oct 29, 2010 at 9:56 AM, David Kastrup wrote: Greetings David, > Oh, by the way: it would be nice to have an option to let Lilypond use > the same space stretching on the last page (in case it fits) than on the > last non-ragged-bottom page.  It really does not make much aesthetical > se

Re: Trills with accidentals

On Sat, Oct 30, 2010 at 11:44 AM, Graham Percival wrote: > I don't know if you're missing anything, but *I'm* missing a > Type-Scripts Priority-Medium issue about this.  Somebody should > definitely add one. There you go: http://code.google.com/p/lilypond/issues/detail?id=1373 The reason why I d

Re: Switching staves with \times looks odd

On Wed, Oct 27, 2010 at 2:50 PM, Richie Gress wrote: > I'm having a small issue here. I'm writing a score for Mutopia which > involves some beamed notes, which are in a \times 4/6 { ... } block, > switching staves like this: > \times 4/6 { \stemUp [aes c> 16.\f \change Staff="RH" \stemDown 32]

Re: Segfault with define-music-function

On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen wrote: > As near as I can tell, this code is triggering an infinite loop that fails > when the scheme heap overflows. Interesting. > arg is *not* a stream-event, it's a music-event. Indeed. But I wasn't expecting it to cause a segfault. > Segfault

Segfault with define-music-function

The following code causes a segfault. LilyPond 2.13.36, GNU/Linux x86_64. toto = #(define-music-function (parser location arg) (ly:music?) (display (ly:event-property arg 'name)) (make-sequential-music arg)) { \toto a } Also reproduced with today's git. --verbose output isn't of any help:

Re: problem with LSR 643

On Thu, Oct 21, 2010 at 9:44 AM, Werner LEMBERG wrote: > Please go ahead.  However, I don't know yet whether there is a problem > at all (at least the extenders work as advertised, so there is no > bug); maybe it can be easily fixed with people who are better > acquainted with the internals. It i

Re: \chordmode chords jumping about on PDF using Mac OSX

On Thu, Oct 21, 2010 at 3:05 AM, James Worlton wrote: > I compiled it several times (10+) and all of them came out looking the same. > Mac OSX 10.4.11 PPC. Which implies that this doesn't affect all users running Mac OSX. Or all users whose name is James. Either way, that's a relief :-) Cheers

  1   2   3   4   5   6   7   >