Activity for Thomas Morley
-
Thomas Morley modified ticket #5919
Make InstrumentName.X-offset more robust
-
pushed to staging as: commit 7aa052aad2f9587864052aa9d0dc9935345ea04b Author: Thomas Morley thomasmorley65@gmail.com Date: Sat Apr 18 21:59:51 2020 +0200 Add regtest for issue 5919 instrument-name-system-start-delimiter.ly commit c5b92038270966a0672eef1dfa934ff7d0c9fc43 Author: Thomas Morley thomasmorley65@gmail.com Date: Sat Apr 18 14:29:24 2020 +0200 Issue 5919 Make InstrumentName.X-offset more robust Currently system-start-text::calc-y-offset takes right end of system-start-grobs into account,...
-
Reg test diff as expected
-
New patch adding regtest https://codereview.appspot.com/553930044
-
https://codereview.appspot.com/553930044
-
Make InstrumentName.X-offset more robust
-
Make InstrumentName.X-offset more robust
-
Make InstrumentName.X-offset more robust
-
Setting SystemStart-grob style to 'brace mostly fails
-
Diff as expected. The different padding of the braces is expexted as well (coming from different padding-values for SystemStart-Bar/Brace/Bracket/Square). One could think of some generell system-start-padding returning different values wrt to 'style. Would be another issue, though.
-
Tbh, I don't understand issue 1204 and I've no idea for an automated test of other music-fonts for selected regtests, sorry. I just described what I did locally to ensure the patch works with said other fonts. All manually, though.
-
pushed to staging as: commit 73b0006674833d0cb4a9cad8f4b27b22f786a49d (HEAD -> dev/fix-brace-font, origin/staging) Author: Thomas Morley thomasmorley65@gmail.com Date: Mon Apr 13 20:48:51 2020 +0200 Reword comment in lily/system-start-delimiter.cc commit 589e73e51eccf9ac965b538d90adbf187e165037 Author: Thomas Morley thomasmorley65@gmail.com Date: Mon Apr 13 10:31:17 2020 +0200 Revert "Load only the default font for System_start_delimiter" This reverts commit 430bad24a2d15ec6600e0e780348a0caff29799b....
-
James, if you test this, it might be a good idea to test with other music-fonts as well. I.e. add \paper { #(define fonts (set-global-fonts #:music "gonville" #:brace "gonville" #:roman "Times New Roman" #:sans "Nimbus Sans,Nimbus Sans L" #:typewriter "Luxi Mono" #:factor (/ staff-height pt 20) )) } or \paper { #(define fonts (set-global-fonts #:music "lilyjazz" #:brace "lilyjazz" #:roman "lilyjazz-text" #:sans "lilyjazz-chord" #:typewriter "lilyjazz-text" #:factor (/ staff-height pt 20) )) } to...
-
Setting SystemStart-grob style to 'brace mostly fails
-
https://codereview.appspot.com/557670043/
-
First bad commit: commit 430bad24a2d15ec6600e0e780348a0caff29799b Author: Patrick McCarty pnorcks@gmail.com Date: Sun Nov 1 12:46:30 2009 -0800 Load only the default font for System_start_delimiter Now that we have Gonville-Brace as an alternative font for System_start_delimiter, we need to find the default font instead. This patch was meant to cure some problems, while using gonville-font. Though, meanwhile we have better and simpler methods to use other music-fonts, than back those days. Currently...
-
Setting SystemStart-grob style to 'brace mostly fails
-
Add #f to format in lilypond-book.itely
-
pushed to staging as: commit 31a7a1eb0078a93718248b442568d045113837ab (HEAD -> dev/add-missing-false-usage-doc, origin/staging) Author: Thomas Morley thomasmorley65@gmail.com Date: Thu Mar 12 23:36:42 2020 +0100 Issue 5843 Add #f to format in lilypond-book.itely In the definition of oly:create-toc-file a simple string is wished for the local outfilename. Thus add #f after format in: (outfilename (format "~a.toc" output-name)) https://sourceforge.net/p/testlilyissues/issues/5843/ https://coderevi...
-
Add #f to format in lilypond-book.itely
-
FWIW, an even more minimal example would be: \version "2.21.0" \layout { \context { \Staff \consists "Page_turn_engraver" } } \paper { page-breaking = #ly:page-turn-breaking } \new Voice { \bar "||" r1 b } With the same paper and layout as above, this fails as well: \new Voice { \pageBreak b }
-
related: https://sourceforge.net/p/testlilyissues/issues/5651/
-
Core dump: /lily/page-breaking.cc, Line 1052
-
duplicate of issue 5767 https://sourceforge.net/p/testlilyissues/issues/5767/
-
Confirm grob-status in input/regression/multi-measure-rest-reminder.ly
-
pushed to staging as commit 78503cb0e625e399dc4e91666b5efe0dcfb5a4ba Author: Thomas Morley thomasmorley65@gmail.com Date: Mon Feb 17 21:56:54 2020 +0100 Confirm grob-status in input/regression/multi-measure-rest-reminder.ly Oversight from Issue 5747 https://sourceforge.net/p/testlilyissues/issues/5772/ https://codereview.appspot.com/547670044
-
Manual page breaking causing assertion failure
-
I opened a new ticket: https://sourceforge.net/p/testlilyissues/issues/5767/ and set this one to abandoned
-
Assertion failure with manual pageBreak
-
Fine with me, my comments are off-topic anyway.
-
I tried to build from a branch of my local repo called "hosada-san-2-2-2020", checkout from c9134465360dfb53419f749747d28c6d04d23839 with current patch put on top. No idea about the "internal compiler error"...
-
I've put the current patch on top of released 2.19.83 (because the patch does not apply to this version, some manual adjustments were needed ... error-prone ... though it survived a locale make) Then I tried GUB: Failed target: darwin-x86::lilypond Full log attached. Maybe the patch relies on some features implemented further upstream than 2.19.83 ...
-
How to test? In the past I made some custom-installers for Arnold, ofcourse I could do the same with this patch. On my slow laptop. But recently my gub failed for master (and I haven't tried again), thus I made the installers with a patched 2.19.83. Should I do so again?
-
Manual page breaking causing assertion failure
-
Sure you didn't confuse something? In gittext I see: SUBJECT: Issue 5646: Switch to Python 3.x
-
Manual page breaking causing assertion failure
-
New patch at https://codereview.appspot.com/575600043/
-
Inline assembler fallback for _FPU_SETCW() missing in x86 platforms Issue 4943 As Issue 4943 on x86 platform compilations was triggered by missing _FPU_SETCW(), an alternate call to initiate the X87 FPU setup as an inline-assembler command is added. http://codereview.appspot.com/575600043
-
Manual page breaking causing assertion failure
-
Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries Issue 4943 As Issue 4943 on Windows compilation was triggered by missing _FPU_SETCW() in the MINGW libraries, an alternate call to initiate the X87 FPU setup as an inline-assembler command is added - for MINGW 32 Bit compilation only. http://codereview.appspot.com/577450043
-
Must be a long standing issue, I could follow it back to the oldest running version on my machine, i.e. 2.12.3. Maybe even older
-
general-column entirely drops empty stencils
-
Pushed to staging as: commit a2bb24fed40e8add5f3cdbbc2d45b1caf4579052 Author: Thomas Morley thomasmorley65@gmail.com Date: Thu Jan 9 01:55:22 2020 +0100 Issue 5655 general-column does not move empty stencils With issue 5331 general-column removed empty stencils. Better not to remove them, but simply return them unmoved, i.e. Don't apply ly:stencil-translate. This keeps them printed and still avoids the programming error Improbable offset for stencil: -inf staff space which was the reason for issue...
-
http://codereview.appspot.com/567060043
-
general-column entirely drops empty stencils
-
general-align entirely drops empty stencils
-
general-align entirely drops empty stencils
-
I just tried from: git checkout release/2.19.20-1 [...] ../configure --disable-optimising make returning: [...] In file included from /home/hermann/lilypond-git/lily/include/smobs.hh:329:0, from /home/hermann/lilypond-git/lily/include/scm-hash.hh:23, from /home/hermann/lilypond-git/lily/scm-hash.cc:20: /home/hermann/lilypond-git/lily/include/smobs.tcc: In instantiation of 'static void Smob_base<super>::init() [with Super = Scheme_hash_table]': /home/hermann/lilypond-git/lily/include/smobs.tcc:113:10:...
-
Occurs between 2.19.20 and 2.19.21. I'll try further bisecting later
-
Fix regtests about Footnote
-
Pushed to staging as: commit 2858611c6b6fafbbcaf10b42bb4338aa95b8ed88 Author: Thomas Morley thomasmorley65@gmail.com Date: Sat Dec 14 12:36:03 2019 +0100 Issue 5640 Fix regtests about Footnote Several regtest about FootnoteItem/Spanner contained overrides without specifying the context. Footnote_engraver lives in Score-context, since Issue 1773. Probably an oversight. Thus the Score-context is added to the overrides in: input/regression/footnote-auto-numbering.ly input/regression/footnote-spanner.ly...
-
Introduce breakingRehearsalMarks for line-breaking RehearsalMarks
-
Setting it to needs-work for now
-
Hi James, actually the error demonstrates /input/regression/footnote-auto-numbering-vertical-order.ly works again. It was implemented with commit 5ac2664c2207e8dfa1734d786e5c7b214b275521 Author: Mike Solomon mike@apollinemike.com Date: Fri Dec 2 08:06:13 2011 +0100 Adds a numbering-assertion-function property to the footnote grob. This allows the footnote regtests to verify that the footnotes are being numbered in the correct order. for 2.15.21 Obviously it worked back in 2.15.21 Though, with: commit...
-
Some findings by Arnold can be found at: http://lilypond.1069038.n5.nabble.com/Issue-4934-analysis-indicates-new-issue-td224851.html regrettable there is a typo: 4934 <-> 4943 in his post. I'll quote it here entirely: Hello, as I got this assertion failure on multiple scores on Win7 (on scores which I created in sequence) I did tried to analyse this problem. All my effected scores had one system per page. On the last page the system is compressed. If I apply tiny changes to the global-staff-size,...
-
I now locally changed vector_sort to vector_stable_sort in dot-column.cc. After doing so I've run make test-baseline and make check: The dots in input/regression/rest-dot-position.ly are still not consistent positioned. Thus I think that change doesn't help, at least not solely.
-
I could give it a try, but not before next weekend ...
-
Fix underline-markup to make multiple calls have nice output
-
Pushed to staging as: commit d1f8d3993c4c0ef0219c255871a3bc90daf46667 Author: Thomas Morley thomasmorley65@gmail.com Date: Mon Oct 21 11:44:36 2019 +0200 Issue 5581 Fix underline-markup to make multiple calls have nice output Amend regtest markup-commands.ly with an example for it.
-
Well see: https://sourceforge.net/p/testlilyissues/issues/5217/#125c
-
Fix underline-markup to make multiple calls have nice output
-
Got the usual Update attempt returns error code 404 from git-cl, but the label switched automatic from needs-work to patch-new
-
Fix underline-markup to make multiple calls have nice output
-
Since I've difficulties to adress David's most recent comment, I've set this one to needs-work, until I'm able to solve it or least see clear enough to ask a meaningful question.
-
Interestingly the problem happens only for quaters not for other durations. And if I extend the quater's X-extent to that of a half note with \override NoteHead.X-extent = #'(-0.0 . 1.377346) (applied to Malte's code) the clash vanish. Ofcourse this is not a workaround (the value would need adjustment for changed staff-sizes, the stem-attachment is off and likely other problems), but may point to the direction where to look for the cause of the clash. And yes, first bad commit is: commit 87eb2f9fe1be3a532675fe4b7322bbba5a60ba5c...
-
And the image for it
-
Attached the beginning of a workaround. Note: only left edge of TextSpanner is cared for, the default-stencil is added as well, red colored and slightly moved (for reference) Play around with dash-period/fraction to watch (dis-)advantages.
-
There must be typos in your example code, thus I don't understand what you want to demonstrate. Could you elaborate? Nevertheless, if you comment the lines with \override #'(full-length . #f) in my markup-code above, then the dashed-line starts/ends exactly. It ensures the line starts and ends with a dash. The dash itself is not scaled. Though the off-values (specified was 8.0) is scaled to 12.5179170455133 and 8.5914367305527 So, in one case the provided value is scaled by ~150% I wouldn't call...
-
For the already mentioned draw-dashed-line-markup one can specify full-length #f to insist on the given on/off-values. In the code below I added such a markup with full-length #f, on 0.8, off 8. (It's red colored.) Which mimics the settings for dash-fraction/period in your initial example. The markup is moved in order to start exactly where the default dashed-text-spanner-line starts. Values for that are calculated based on the spanner-stencil values. See the commented code for ly:stencil-expr. \relative...
-
Hi Werner, I disagree. The dashed line of a TextSpanner must start right after left-text. It must end right before right-text or as in your example at the target NoteColumn. (for line-breaks similar). This can't be warranted while exactly following the user-setted dash-period/fraction. Some scaling is always needed. Otherwise the dashed line will be too short or too long. In your eample: If I read out the dashed-line-settings from the 'stencil I get: %% im (dashed-line 0.1 0.672281764072063 6.05053587664857...
-
Add ly version t0 swing.ly
-
Pushed prematurely to staging as: commit 1272e45b49fb91fb5fd181b7d045a0ac4d662450 Author: Thomas Morley thomasmorley65@gmail.com Date: Sun Jun 9 14:56:41 2019 +0200 Issue 5526 Add ly version to swing.ly
-
Document bound-details (sub-)properties in line-spanner-cc for IR
-
pushed to staging as: commit cfee7a3a2634ee36b90d9ea302b41985903120b5 Author: Thomas Morley thomasmorley65@gmail.com Date: Thu May 9 22:40:10 2019 +0200 Issue 5518 Document bound-details (sub-)properties in line-spanner-cc for IR
-
New patch-set uploaded. I've copied most of the explanations from NR, but they are misleading up to to wrong regarding stencil-align-dir-y/stencil-offset. Now corrected, imho. The NR could be tackled in a separate issue. Or should I extend this one?
-
Document bound-details (sub-)properties in line-spanner-cc for IR
-
ly:version? should be public
-
Make tabChordRepeats default for TabStaff
-
There's a recent discussion on -devel about how to draw curves with more than 4 control-points. http://lilypond.1069038.n5.nabble.com/stack-smashing-detected-tt221627.html Not sure yet what to do and how ..., but I'd love to keep the possibility of entering more than the default amount of control-point without a type-checking warning here. Ofcourse ly:slur::print, etc needs 4 control-points not more or less. Thus a warning while applying ly:slur::print to a not suitable amount of control-points could...
-
Reflect new syntax in example of define-grob-properties.scm
-
pushed to staging as: commit bd05971b2a60c010f1de567fe99b97cc0e87b841 Author: Thomas Morley thomasmorley65@gmail.com Date: Sat Apr 13 13:50:40 2019 +0200 Issue 5509 Reflect new syntax in example of define-grob-properties.scm
-
Add doc-string for allowVoltaHook
-
pushed to staging as: commit d0730c389d722f2866df83206b362d235102f61c Author: Thomas Morley thomasmorley65@gmail.com Date: Sun Apr 14 11:39:26 2019 +0200 Issue 5510 Add doc-string for allowVoltaHook
-
Add doc-string for allowVoltaHook
-
pushed to staging as: commit d0730c389d722f2866df83206b362d235102f61c Author: Thomas Morley thomasmorley65@gmail.com Date: Sun Apr 14 11:39:26 2019 +0200 Issue 5510 Add doc-string for allowVoltaHook
-
Reflect new syntax in example of define-grob-properties.scm
-
Setting to 'needs-work', see my comment on Rietvled
-
Add a procedure to add slashes to Beams and straight Flags
-
Setting to 'needs-work', see my comment on Rietvled
-
Hi Malte, I've read up makelsr As opposed to your patch this one updates an already existing snippet. Thus the patch can stand alone. I think I'll run makelsr afterwards. And commit/push, if all's ok.
-
Done. Thanks.
-
Add a procedure to add slashes to Beams and straight Flags
-
The patch contains a snippet in Documentation/snippets/new Should I run scripts/auxiliar/makelsr.py ? I forgot what's our current policy...
-
The patch for this issue tries to do more than #1333 requests, thus I opened a new issue. If accepted issue 1333 should be closed.
-
Well, style should be a symbol not a string...
-
Based on my suggestion here: https://codereview.appspot.com/344160043/#msg5 you'll find an elaborated code attached.
-
Yep. Though, said snippet compiles with 2.18. Thus there's no need to put it in snippet/new, if it is present in /Documentation/snippets. So the need to run makelsr. To come out of the dilemma, would it be reasonable to commit a run of makelsr as a single patch and delay Malte's patch?
-
I thought I asked not to run makelsr? Running makelsr for patch review is silly - look how many files have changed! How can anyone know what is 'real' and what is just the makelsr? Hi James, he did because I asked to do so. I think we need some guidelines, let's discuss on devel. Cheers, Harm
-
Likely unrelated to this issue and worth another ticket... Below returns unexpected result, at least for me { \compressFullBarRests \set restNumberThreshold = 0 R1 R1 \set restNumberThreshold = 1 R1 R1 }
-
The original patch was commit f09f236f554124b3830332cfcf2c900f07197b68 Author: Patrick Schmidt PLS@patrick-schmidts-computer.local Date: Fri Sep 17 11:10:09 2010 +0200 power chord symbol Added power chord definition, symbol and command to typeset this symbol. Introducing them with \normal-size-super. There's a bit discussion here http://lilypond-s-support-for-tablatures.3383434.n2.nabble.com/Power-chords-td5524246.html#a5524246 Interestingly Patrick's first suggestion uses \super. Later it's changed...
1 >