Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Han-Wen Nienhuys ezt írta (időpont: 2020. febr. 8., Szo 21:44): > > > If we construct the grace note grobs in a > special pass, there is nothing to synchronize them across staves. You could > have two-handed piano music where the left and right hand do grace notes in > a synchronized way. I don't

Re: GSoC 2020 update, July 18

in ancient (ars subtilior) notation there actually are noteheads with two stems (which may also be flagged differently), called "dragma". a picture search for "dragma ars subtilior" returned poor images; one not entirely useless is https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573

Re: GSoC 2020 update, July 18

Thanks. Lukas, that's what I looked for! On the next page there are dragmas with flags on both stem and ones with flags only on the down stem. Lukas-Fabian Moser ezt írta (időpont: 2020. júl. 21., K, 11:32): > > Hi Pál, > > > in ancient (ars subtilior) notation there actually are noteheads with

Re: GSoC 2020 update, July 18

should be able to find it via something like OLL's \smuflglyph > command once I'm done with GSoC. Otherwise, this would probably be a good > idea for a separate feature request. > > Hope this helps, > Owen > > On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál wrote

Re: Repeat alternative count

\alternative volta 3 { ... } ? Dan Eble ezt írta (időpont: 2020. aug. 29., Szo, 15:37): > > Is there a use case for specifying the number of times to reuse a repeat > alternative in a way that \unfoldRepeats could honor? Right now, it reuses > the first alternative enough times to reach the re

Re: ancient convert rules

FWIW, I ran a grep on my files, and the oldest version is 2.4.4; there are also several 2.9, 2.10 and 2.11 ones. I admit I rarely touch old files, but sometimes that happens. James Lowe ezt írta (időpont: 2020. aug. 30., V, 16:32): > > On 30/08/2020 14:38, Jonas Hahnfeld wrote: > > To make the s

Re: ancient convert rules

Hi Jonas, > I think I found a solution that works equally well as it did when > running convert-ly with Python 2. Please see the second commit of > https://gitlab.com/lilypond/lilypond/-/merge_requests/365 for what I > tested. I tested this branch (my first try with GitLab, I hope I got it right)

Re: tie over clef change

David Kastrup ezt írta (időpont: 2020. szept. 27., V, 22:01): > > Hans Åberg writes: > > >> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser wrote: > >> > >>> I seem to remember that even in Bach's B minor mass (where E12 was not > >>> yet a thing) there is an enharmonic tie (or at least tonal repet

Re: guile libraries

There's a quick path for an underperforming lilypond: sudo apt install guile-2.2-dev. The slow path for good performance is installing guile-1.8 from its git repository, which I never did. Al Rice ezt írta (időpont: 2021. márc. 15., H, 18:36): > > Greetings, > > My name is Al. I am a retied des

Re: Please review Pygments lexer and style

Jean Abou Samra ezt írta (időpont: 2021. jún. 24., Cs, 20:17): > I'll style \longa in bold too. \longa is a duration, like 2 in c2; on the other hand 3 in \repeat \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is arguably a duration, but... p

Re: add some rarely used mensural clefs (issue 330120043 by benko....@gmail.com)

>> Please review this at https://codereview.appspot.com/330120043/ > > > Does this have a tracker or do we need to create one? > > I couldn't see one immediately. no, I'm struggling with it. seems this is my first contribution since leaving google code. (and I had the same regression you had with

Re: add some rarely used mensural clefs (issue 330120043 by benko....@gmail.com)

2017-09-05 22:17 GMT+02:00 Benkő Pál : >>> Please review this at https://codereview.appspot.com/330120043/ >> >> >> Does this have a tracker or do we need to create one? >> >> I couldn't see one immediately. > > no, I'm struggling with i

Re: add some rarely used mensural clefs (issue 330120043 by benko....@gmail.com)

> I saw that Phil gave you write access now. However to save you and > everyone time I created > > https://sourceforge.net/p/testlilyissues/issues/5184 > > for you and have tested the patch. Thank you, Phil and James! I could finish git-cl configuration, and hope that next time everything goes s

Re: add some rarely used mensural clefs (issue 330120043 by benko....@gmail.com)

> I am updating the doc to include these new clefs (and add all ancient > clefs to appendix A10 I wanted to look at it, but you beat me -- thanks a lot! p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lily

Re: add some rarely used mensural clefs (issue 330120043 by benko....@gmail.com)

All, >> Phil, whatever you can offer to help. I know nothing about Ancient music >> typesetting and was just basing my additions on what was already in the >> NR. I had asked a few years ago for some help with the Ancient music NR >> section oh, sorry, I missed it. I'm glad to help (I guess that

Re: NR: Update Clef styles Appendix (issue 324420043 by pkx1...@gmail.com)

Hello James, > I took a bit of time to educate myself with Ancient notation and have, > hopefully, picked the correct note styles now. > > Should I use the red 4-line-staff for the rest of the examples or just > for the Gregorian clefs? Just for the Gregorian clefs. Mensural clefs, as the C-clef

Re: issue 3208: MMRs for > 1 m. only count m. (issue 333340043 by lilyp...@maltemeyn.de)

2018-01-06 17:48 GMT+01:00 : > On 2018/01/04 19:48:36, benko.pal wrote: >> >> is there an example where a single measure rest looks different standing >> alone >> than one in an expanded multi-measure rest of odd measures? > > Not in Gould’s “Behind Bars”, neither in Gardner Read’s “Music > notat

Re: vertical position of Rests and MMRs

2018-01-17 13:21 GMT+01:00 David Kastrup : > Malte Meyn writes: > >> Hi list, >> >> I need some advice on how to deal with breve and longer rests. While I >> tried to fix issue 3208 (correct choice of rest glyphs for MMRs) I >> also “fixed” vertical position of the rest glyphs for shorter rests, >

Re: New LilyPond contributor: Basia Mroczek

Ubuntu 16.04 should be OK, I use that too. Though it's a lng time I tried a make check. p Carl Sorensen ezt írta (időpont: 2018. nov. 23., P, 19:10): > > I recommend that you start by building on LilyDev, rather than on your own > system. You can set up LilyDev in a VM, and make sure that

Re: stack smashing detected

David Kastrup ezt írta (időpont: 2019. ápr. 25., Cs, 16:46): > > Thomas Morley writes: > > > Background: I'm exploring whether it would be feasible to draw higher > > order bezier-curves, splitting them in cubic ones. you can't split a Bezier curve into lower order ones, only approximate. > So

Re: stack smashing detected

Thomas Morley ezt írta (időpont: 2019. ápr. 25., Cs, 18:57): > > > So usually your goals would be better served by > > > allowing _multiple_ cubic beziers in a row with suitable continuity of > > > derivatives (and thus some aspects of the control points) provided > > > automagically. > > > > whic

Re: stack smashing detected

Hi Andrew, > That's a good book, but it is copyright 2002 Academic Press. So it is not > freely distributable. > > Generally speaking, since the lilypond community is strongly committed to > open source and its philosophy, suggesting violations of copyright are not > highly regarded. I am sorry

Re: stack smashing detected

Thomas Morley ezt írta (időpont: 2019. ápr. 28., V, 15:13): > > Am Fr., 26. Apr. 2019 um 20:06 Uhr schrieb Benkő Pál : > > the book I learned Bézier and B-splines from: > > http://www.cin.ufpe.br/~mdlm/files/Farin-5a_edicao.pdf > > Thanks for the hint. > More tha

Re: misplaced-note-head bug (issue 5303)

David Kastrup ezt írta (időpont: 2019. júl. 4., Cs, 18:16): > > "Phil Holmes" writes: > > > - Original Message - > > From: "Lukas-Fabian Moser" > >> > >> Questions: > >> > >> a) How to decide which fix is "better"? (My guess that using floats > >> might pose the danger of rounding errors

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by hanw...@gmail.com)

ezt írta (időpont: 2020. jan. 31., P, 11:55): > > > https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc > File lily/parse-scm.cc (right): > > https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc#newcode77 > lily/parse-scm.cc:77: const Input *hi = &ps->sta

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

Janek Warchoł ezt írta (időpont: 2020. febr. 6., Cs, 0:32): > > I'll try to speak only on the most pressing points to avoid bloating the > discussion unnecessarily. > > I stopped contributing to LilyPond about 6 years ago. One cause of that > change was that I got a job and suddenly had much less

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

David Kastrup ezt írta (időpont: 2020. febr. 6., Cs, 14:38): > > Benkő Pál writes: > > > Janek Warchoł ezt írta (időpont: 2020. > > febr. 6., Cs, 0:32): > >> > >> I'll try to speak only on the most pressing points to avoid bloating the > &

Re: lilypond-2.19.84

the News section at lilypond.org dates 2.19.84 to 2019. can I (or anyone else) push a fix to staging? Jean-Charles Malahieude ezt írta (időpont: 2020. febr. 6., Cs, 18:46): > > Hi, > > Please find a new tarball for LilyPond at > > http://lilypond.org/download/source/v2.19/lilypond-2.19.84.tar.gz

Re: 'blackpetrucci' stem attachment

blackpetrucci was introduced by me to support coloratio. the intent was to change just the noteheads; I just didn't know I had to do anything beyond defining new noteheads. I'm using it on a (sort of) daily basis, but didn't notice. p Werner LEMBERG ezt írta (időpont: 2022. jan. 15., Szo, 20:05

Re: Ancient repeat sign

Hi Dan, Dan Eble ezt írta (időpont: 2022. febr. 6., V, 21:32): > > https://www.pinterest.ca/pin/560909328587237881/ > > The sections of this work seem to be separated with a kind of repeat sign. > > A :|||: B :|||: C :||: D :|: > > Q. Do I understand correctly that this is performed AA

Re: SMuFL name mapping update, 17 March

Hi Owen, first: thanks for this work. Owen Lamb ezt írta (időpont: 2022. márc. 17., Cs, 16:42): > > Hi all, > > I've finished mapping the last five glyph categories: Mensural, > Neomensural, Petrucci, Solesmes, and Kievan. Of those, only the Mensural > and Neomensural glyphs provided much troubl

Re: SMuFL name mapping update, 17 March

Hi Owen, Owen Lamb ezt írta (időpont: 2022. márc. 19., Szo, 7:38): > > Hi Benkő, > > On 3/17/22 10:05, Benkő Pál wrote: > > re the longest rests: > 1. a perfect longa rest and a maxima rest are not the same; > 2. a perfect longa rest should take three spaces (l

Re: pygment regex question,Re: pygment regex question

Jean Abou Samra ezt írta (időpont: 2022. nov. 25., P, 18:05): > > Le 25 nov. 2022 à 17:54, Werner LEMBERG a écrit : > > OK, but shouldn't this be rather > > (-?\d+|\\longa|\\breve)\.* > > then? > > Why not. If you want to be even more precise on what you want to match: > > -\d+|((\d+|\\breve|\\lo

Re: Explicit default duration?

Jean Abou Samra ezt írta (időpont: 2023. jan. 22., V, 23:45): > > On 22/01/2023 23:38, David Kastrup wrote: > > > > There are situations where sticking with the default duration may make > > sense when something looking like (or being) an explicit duration may > > follow. > > > > Like when switchi

Re: Multiple clefs in one Staff

David Kastrup ezt írta (időpont: 2023. okt. 27., P, 11:46): > > Werner LEMBERG writes: > > >> Inspired by > >> > >> > >> Should we be offering something like that? > > > > What exactly do you m

Re: completion disturbed by other staff (issue 1082)

hi all, attached a patch fixing the issue. the cause of the problem was note_dur being less than left_to_do_, as noted in the comment I added. the fix itself is the following part: - if (nb.main_part_ && nb < note_dur.get_length ()) + if (nb.main_part_ && nb < left_to_do_) the remaining bit s

Re: completion disturbed by other staff (issue 1082)

hi all, updated the patch fixing the issue and attached an example where the previous version failed. > the cause of the problem was note_dur being > less than left_to_do_, as noted in the comment I added. > > the fix itself is the following part: > -  if (nb.main_part_ && nb < note_dur.get_lengt

Re: completion disturbed by other staff (issue 1082)

hi Neil, >> updated the patch fixing the issue and attached >> an example where the previous version failed. > > LGTM. > > A few minor nitpicks: > > +      /* > +       note that note_dur may be strictly less than left_to_do_ > +       (say, if left_to_do_ == 5/8) > +      */ > > This comment woul

Re: completion disturbed by other staff (issue 1082)

attached the updated patch for 1082. thanks, p patch16 Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: authors+contributors list

> Any new / new-ish contributors, please check: >  http://lilypond.org/website/authors.html > > The basic breakdown is: > - if you have git access, you're a developer > - if you don't, you're a contributor > - developers shouldn't appear in the contributor list > - developers can pretty much pick t

span-bar problem

hi list, I have the following problem: in ancient music there are no real ledger lines, but the staff is expanded by lines, spanning more notes (or rests). LilyPond can do that with StaffSymbol #'line-positions, but when I combine it with a score laid out in mensurstrich format, I can see that ex

Re: Lilypond's internal pitch representation and microtonal notation

> In algebraic terms, choose a neutral n between m and M. The total pitch > system will be i m + j M + k n, where i, j, k are integers. But the staff > system only has the pitches i' m + j' M. When taking the difference with the > staff note, reducing the degree to 0, and taking away the sharps/fla

Re: Lilypond's internal pitch representation and microtonal notation

2010/9/22 Hans Aberg : > On 21 Sep 2010, at 21:31, Benkő Pál wrote: > >>> In algebraic terms, choose a neutral n between m and M. The total pitch >>> system will be i m + j M + k n, where i, j, k are integers. But the staff >>> system only has the pitches i'

Re: @lilypond[fragment] question

> Nope.  My pet name for Ancient music is "the disaster that nobody > cares about fixing". I do care (well, I am nobody and even I don't care for chant) and have my pet issues, but I really don't know what other issues there are - searching for "ancient" in the issues list gives a very short list

coloratio, black mensural notation

hi list, the attached patch adds noteheads needed for black mensural notation (BMN) and coloratio in white mensural notation (WMN). note that it's just the noteheads: in both BMN and coloratio sections in WMN a fourth note looks like a flagged half note. I could reach this look by the following f

Re: [PATCH] coloratio, black mensural notation

hi Valentin, >> the attached patch adds noteheads needed for black mensural notation (BMN) >> and coloratio in white mensural notation (WMN). >> >> note that it's just the noteheads: in both BMN and coloratio sections >> in WMN a fourth note looks like a flagged half note. > > Werner, do you want

Re: [PATCH] coloratio, black mensural notation

hi all, > Regarding the quality of the patch: It's just fine.  However, I can't > say anything about the details since my knowledge of mensural notation > is very limited.  Especially the `sM2semimensural' in `parmesan20' > (which I'm currently looking at after applying the patch locally) > looks

Re: Issue 1268 in lilypond: [PATCH] span-bar problem

hi Joe, >> do you think my patch is a good start? > > Yes, but you need to be careful about what happens when bar-size is set. > Currently, your patch will break (for example) input/regression/drums.ly > because it ignores bar-size. well, I admit I haven't run regtests, but I did now and (having

Re: Issue 1268 in lilypond: [PATCH] span-bar problem

hi Joe, >>> Comment #9 on issue 1268 by joeneeman: [PATCH] span-bar problem >>> http://code.google.com/p/lilypond/issues/detail?id=1268 >>> >>> I've tracked the problem down to Bar_line::compound_barline, >>> which tries to >>> center the bar line around the center of the staff >>> (see lines 119

Re: C++ question

hi Mike, > class MyClass { > typedef int (*happy)(int a, int b, int c); > > happy foo > happy bar; > happy baz; > } > > Is there a way to define foo, bar, and baz with the same typedef in the c++ > file or do I have to enumerate all the arguments for the function definition > à la > > int baz (i

Re: regtests about very small differencies

hi Janek and all, > There's a much easier way: set staff-size to something really big. > > I suggest that we adopt this as an official policy: fixes for > easy-to-overlook things should be documented by regtests using > big/enormous font-size (e.g. between 30 and 100, depending on issue). note th

Re: line_count fixes (issue 6211047)

hi Keith, 2012/7/10 : > > http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc > File lily/bar-line.cc (right): > > http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc#newcode151 > lily/bar-line.cc:151: Real const gap_to_find = (1.0 + 3 * staffline) / > staff_space; > P

Re: Syntax change proposal:

> I should have spotted this, but I've never used octave checks. > I suppose others might ... :( I have to use it for argus in music functions which duplicate that parameter. e.g. I have a function perfect which transforms a4. to a4. ~ a8., and in relative mode it transforms a'4. to a'4. ~ a'8.,

Re: Issue 1320: Scheme bar line interface (issue 6305115)

Marc, please don't throw the whole 2533 issue stuff out; look at the newer version at http://codereview.appspot.com/6431044 p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 1320: Scheme bar line interface (issue 6305115)

2012/7/26 Marc Hohl : > Am 26.07.2012 10:31, schrieb Keith OHara: > >> On Thu, 26 Jul 2012 00:51:56 -0700, wrote: >> >>> Marc, please don't throw the whole 2533 issue stuff out; look at the >>> latest version at >>> http://codereview.appspot.com/6431044 >>> in particular bar-line.cc and repeat-sig

Re: line_count related patches in a single commit for review (issue 6419064)

hi Marc, 2012/8/7 Marc Hohl : > Am 07.08.2012 11:20, schrieb benko@gmail.com: > >> the post-1320 version. Marc, please consider patch set 2 for bar-line >> related changes. >> >> http://codereview.appspot.com/6419064/ >> > OK. Are there specific regression tests covering the repeat dots? > I

Re: line_count related patches in a single commit for review (issue 6419064)

hi Marc, > I noticed that your patch didn't include the changes > in bar-line.scm – was that intentional? > The new regtests are already in master; I didn't compile > the regtests, but surely they look strange without the > changes in the colon stencil routine? yes; I want to work on it. I'll le

Re: line_count related patches in a single commit for review (issue 6419064)

Marc, Keith, all, here is an intermediate report on how I stand with bar lines, find attached a newer version. Keith, I hope I fixed lyrics-bar.ly. Marc, there are still differences from the c++ version: 1. in repeat-sign.ly the thick-lined staff has now the dots outside of staff, while the c++

Re: line_count related patches in a single commit for review (issue 6419064)

hi all, >> Keith, I hope I fixed lyrics-bar.ly. > > > Yes, it comes out nicely. > > >> 1. in repeat-sign.ly the thick-lined staff has now the dots >>outside of staff, while the c++ version had it inside - >>there may be a difference how line-thickness is handled. > > > The latest Scheme ve

Re: Run fixcc + astyle2.02.1 (issue 6477062)

>>> lily/include/skyline.hh:58: list *const result); >>> I'd like to see the const removed (top-level const on function parameter >>> types are ignored), but that may be the target of another patch. > > Not exactly correct: they are not part of the function signature (like > "result" isn't), but th

Re: Assertion failure

2012/8/28 m...@mikesolomon.org : > Hey all, > > With --disable-optimisation passed to configure, Janek's score at: > > www.mikesolomon.org/tota-pulchra.zip > > fails with the assertion failure on line 252 of the current grob-property.cc > > assert (value == SCM_EOL || value == marker); > > I starte

Re: Assertion failure

FWIW I checked 2.15.32 (the \version of tota-pulchra.ly), and the assert is triggered there too. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Help with make syntax

> info: $(INFO_FILES) > @echo export LILYPOND_DATADIR=$(LILYPOND_DATADIR) > @echo export PYTHONPATH=$(PYTHONPATH) > > which sends stuff to the terminal during a make doc run. I've read the make > manual but still can't decide whether this actually does anything, or merely > echoes information to t

Re: preliminary GLISS discussions

>> The real question is whether is a need to do things like >> >> ligatures = { \[ s1 \] \[ s1 \] } >> \new Voice << \melody \ligatures >> >> >> you'd have to ask jurgen reuter who wrote basically all the ancient >> notation support. > > It would work to do > > ligatures = { s1\[ s1\]\[ <

Re: [GLISS] differentiating pre/post/neutral commands

>>> How come the pianists don't have it in the score then? >> >> Because pianists work with two dimensions on the paper, not one? > > Actually, after some thinking, I believe to remember that I've seen > such a shorthand in printed scores also: It's simply a stem without > the chord. At least ther

Re: [GLISS] delimiters, interpretation context, confusion (was: how to make decisions?)

> I'd say we could have a movable do for this purpose: > \movableDo { \key d \major do re mi fa sol la si do } == \key d > \major d e fis g a b cis d we have it, called transpose. and we really need all features of transpose to tell the octave correctly. p

Re: remove top-level const's from declarations (issue 6501096)

> Could you elaborate on why we want this? I seem to have misunderstood your qouted comment http://codereview.appspot.com/6477062/#msg5 > Do the consts fail to > compile with some compiler, or are they only supposed to be > included in the C++ files, or...? I faintly remember a version of MSVC++

Re: gerrit - does it allow writing commits using a web interface?

>> Can someone please explain me very slowly why we don't simply use >> Git as intended? >> >> Have you noticed that git patches are already in e-mail form? > > Additional two disadvantages of this approach that come to my mind: > - how would you review a patch so monstrous as Mike's skylines? > -

Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)

ok, thinking about a new patch. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)

2012/9/9 Keith OHara : > On Sat, 08 Sep 2012 15:26:21 -0700, wrote: > >> do we want to support >> - NR 2.5.1 style 2-line percussion staves (setting both line-count and >> staff-space to 2 instead of setting just line-positions to (-2 2))? >> - default TabStaff's (even line-count, 1.5 staff-space)

Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)

plainchant definitely has no bar lines; I guess it has no repeat signs as well, but if it has, it's (still guessing) another glyph LilyPond doesn't know. I'm fine with not distinguishing four-line plainchant and four-line tablature. ___ lilypond-devel m

Re: simplify previous patch-set by special casing 2-line staves (issue 6506090)

> This works, although in surprising ways. > > It was a challenge for me to figure out why the tests in > 'repeat-sign.ly' come out as they do. I was very surprised by the lines > marked "dots in outer spaces" and "dots outside" and assume we would > prefer more centered placement. that's sort of

Re: simplify previous patch-set by special casing 2-line staves (issue 6506090)

>> "dots in outer spaces" was inspired by your comment >> http://codereview.appspot.com/6488097#msg7 > > I was talking about a tab staff with larger staff-space, but with just > two staff-positions for each line. > > Anyone writing #'line-positions = #'(-10 -2 6 14) would be planning to > put a lot

line_count issues

hi David, I saw you marked line_count related issues for backport. is that my task, yours or common? what should or can I do? at the moment there's one line_count related issue I know and want to work on: multimeasure rests in nonstandard staves, see http://code.google.com/p/lilypond/issues/detai

Re: line_count issues

2012/9/18 David Kastrup : > Benkő Pál writes: > >> hi David, >> >> I saw you marked line_count related issues for backport. >> is that my task, yours or common? > > Mine. > >> what should or can I do? > > I was actually planning to contact

Re: [GLISS] non-timed or non-musical events "z" "y"

2012/9/24 Keith OHara : > Graham Percival percival-music.ca> writes: > >> Although mathematicians and programmers are quite >> comfortable with contains with 0 items inside them, this is not a >> particularly intuitive concept (just look at the concept of zero >> in the history of mathematics!)

Re: [GLISS] non-timed or non-musical events "z" "y"

2012/9/24 David Kastrup : > Benkő Pál writes: >> does anybody has a similar way (not a function) of marking just the first >> note with a cautionary accidental? > > This is probably somewhat tongue-in-cheek, but try > > > { > \key fis\major > dis

Re: Feature request

2012/9/25 David Kastrup : > But if I remember correctly, beam subdivision is a > multi-level problem, not just two-level. yes, see the attachment to http://code.google.com/p/lilypond/issues/detail?id=2361 ___ lilypond-devel mailing list lilypond-devel@g

Re: Doc: Improve documentation of \glissando. (issue 6529043)

> This example shows a beam extending from a stem to the > final note of the glissando. Is this correct, or would > it be better to suppress the beam? I made some Bartók and Xenakis scans, see https://docs.google.com/folder/d/0B7AjGy5hUKtAeWtkdHdfN0l4bm8/edit such beams can be seen in 0162.jpeg a

Re: [talk] easy tuplets

> Well, "music argument after left-out optional argument" at the current > point of time means "closed music". It is likely a safe bet that we > rarely need a single note for a tuplet, so it is not much of a problem, > and I am chugging away at getting the "closed music" thing scrapped, but > that

Re: [proposal] easy triplets and tuplets - Draft 2

>>> The normal setting is to have four notes in a full 3/4 bar. >> >> That would be \times 3/4 rather than \times 6/4, right? > > Exactly. four quarters, yes; four eigths are 6/4, and that's what I've seen. regarding the \tuplet shorthand: I would hate "\tuplet n" meaning not "\tuplet n/1" but "

Re: [proposal] easy triplets and tuplets - Draft 3

2012/10/9 Francisco Vila : > When I learned how to read music, triplets were taught to me as > "always shrinking" groups and you see a "3" but there is an implicit > "2" so we have 3:2. Only the numerator is printed by convention. > > Thus, if you write > > \times 2/3 { b16 b b b b b } > > or > >

Re: [proposal] easy triplets and tuplets - Draft 3

2012/10/9 David Kastrup : > The concept used for printing/grouping tuplets is different than the > concept used for scaling the time. That's what makes \times such a > confusing interface. > > The pure scaling alone is available as \scaleDurations. I have no beef > with it using 2/3 as input, and

Re: [proposal] easy triplets and tuplets - Draft 3

2012/10/9 David Kastrup : > Benkő Pál writes: > >> 2012/10/9 David Kastrup : >>> I don't really think that people consider \times and \scaleDurations as >>> closely related (and their naming choice is also totally different), so >>> I don'

Re: [GLISS] turning strings to symbols

2012/10/12 David Kastrup : > "Trevor Daniels" writes: >> I'm less concerned than Werner about the inconsistency of the >> tweak syntax. The context needs to be specified only rarely, and >> it is a small price to pay for the enormous gain. > > Well, strictly speaking we are getting hosed at the l

Re: Naming _another_ lacking puzzle piece

2012/10/13 David Kastrup : > > In ly/music-functions-init.ly I see code like the following: > > crossStaff = > #(define-music-function (parser location notes) (ly:music?) > (_i "Create cross-staff stems") > #{ > \override Stem #'cross-staff = #cross-staff-connect > \override Flag #'style =

Re: Fix extra spacing in Kievan notation (issue 6684051)

> The presence of a long syllable in the lyrics makes the left_col->extent > larger than spring.min_distance(). Manipulating the SpacingSpanner > properties has no effect -- the extraneous space is still there. long syllables are a general problem, see Janek's GSoC list, it shouldn't be solved thi

Re: prevent collision of ligatures and next note (issue 6740046)

>> in C++ there should be a good reason to pass complex structures like >> std::vector by value, not by reference to const; in this case >> there's no such reason, pass-by-reference works perfectly. > > Ah, so this is a by-the-way fix. Can it be in a separate commit, please? it is; I meant to not

Re: prevent collision of ligatures and next note (issue 6740046)

>> > Ah, so this is a by-the-way fix. Can it be in a separate commit, please? > >> it is; I meant to note it but forgot, sorry. is there interest in pushing >> such >> multi-commit patches to some dev branch? > > If there is, people should ask. Substructuring an issue into several > logical com

Re: fix representation switching from line-position to staff-space (issue 6778050)

2012/10/27 : > On 2012/10/27 20:34:35, benko.pal wrote: > >> I want staves with line-positions like (-2 0 2 4) work. > Why would somebody specify (-2 0 2 4) with the expectation that the > results should be identical to (-3 -1 1 3)? Why would he not specify > (-3 -1 1 3) in the first place then?

Re: What happened to staging?

2012/10/30 David Kastrup : > Marc Hohl writes: > >> Hello list, >> >> yesterday, I pushed my two outstanding patches to staging >> and IIRC Benkő Pál has pushed two patches just before me. >> >> Now it looks as if origin/staging is in the same state

Re: fix representation switching from line-position to staff-space (issue 6778050)

2012/10/30 David Kastrup : > Benkő Pál writes: > >> 2012/10/27 : >>> On 2012/10/27 20:34:35, benko.pal wrote: >>> >>>> I want staves with line-positions like (-2 0 2 4) work. >> >>> Why would somebody specify (-2 0 2 4) with the expectati

Re: Issue 2966 - Patch-push

hi, > someone up to push it for me? > > http://code.google.com/p/lilypond/issues/detail?id=2966 > https://codereview.appspot.com/6850073/ happily; could you send me the patch(es)? p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.

Re: 2.17.10 regtests

all, 2013/1/13 Phil Holmes : > I've just whiled away a happy few minutes looking at the regtests. There > are quite a number of changes, I think mostly based on Mike's latest > horizontal skylining. There are some that concern me in particular: > > ambitus-with-ligature.ly: I don't know why ther

Re: How should tupletSpannerDuration actually work?

2013/1/12 Phil Holmes : > - Original Message - From: "David Kastrup" > To: > Sent: Saturday, January 12, 2013 10:25 AM > Subject: How should tupletSpannerDuration actually work? > > > >> >> I have a hard time considering the output of >> >> > > > --

Re: 2.17.10 regtests

2013/1/14 Phil Holmes : > Surely the bracket should not be visible by default if you're setting > mensural notation? Should not the \remove Ligature_bracket_engraver be > removed automatically for mensural notation? it is removed in MensuralVoice, but hey, this is just a regtest: ambitus is not

Re: fix handling of grace notes to shorten preceding tied notes correctly (issue 7108043)

2013/1/15 : > https://codereview.appspot.com/7108043/diff/1/lily/include/audio-item.hh#newcode90 > lily/include/audio-item.hh:90: virtual string to_string () const; > It seems fine to have the debug-output helper to_string(), but why make > it a virtual member function? Unless the compiler is a l

Re: vertical positioning of full measure rests

hi all, > Hello, it seems, that the vertical positioning works great for rests (r) but > bad > for full measure rests (R). > > Please have a look on > > http://thread.gmane.org/gmane.comp.gnu.lilypond.general/78355 I'm working on this. p ___ lilypond-

Re: [gmane.comp.gnu.lilypond.general] Re: Transposing instruments

all, 2013/1/30 David Kastrup : > > Ok, sorry for the bottom quote, but I'd like to get the context into the > developer list. > > Shouldn't we have a command > > \transposing f { ... } > > (better naming suggestions welcome) that does transposition and Midi > correction in lockstep? Is anybody wi

Re: [gmane.comp.gnu.lilypond.general] Re: Transposing instruments

2013/1/30 David Kastrup : > Benkő Pál writes: > >> all, >> >> 2013/1/30 David Kastrup : >>> >>> Ok, sorry for the bottom quote, but I'd like to get the context into the >>> developer list. >>> >>> Shouldn't we h

  1   2   3   >