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

[Benkő Pál]

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 if that exists in practice, but it is one of
> the reasons for the current approach.
>

IIRC the flower motif of the Turangalila symphony is notated just like
that.  It's a simple note-for-note example; I'll try to find more complex
examples.

p

>

Re: GSoC 2020 update, July 18

[Benkő Pál]

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/f82a66af9573ba3cf431b0b1986f07e8
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video
https://www.youtube.com/watch?v=wd3ouxA9p-o

Owen Lamb  ezt írta (időpont: 2020. júl. 20., H, 22:27):
>
> On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys  wrote:
>
> > I don't understand why we need 2 properties here. What benefit do we
> > get relative to a single property?
> >
>
> Well, you got me there! Originally, I was under the impression that a
> notehead grob may at some point have two stems attached to it, i.e. when it
> is merged from two noteheads in opposite directions. A closer look has
> revealed that this is not the case: when this happens, there are still two
> noteheads present, and one of them is merely made transparent.
>
> That leaves only one small reason to keep the new properties: I figured it
> would make things easier for the user. SMuFL provides two variants of a
> stem attachment point from the start, so the stem-attachment property would
> have to do one of two things:
>
>- Return either the upwards variant for up-stems, or the downwards
>variant translated around the center into a pseudo-upwards position for
>down-stems. This would ensure you always get an up-stem-flavored
>coordinate, so that moving it to the right always means moving it away from
>the stem, and vice versa, just the way things have worked in the past.
>However, this isn't terribly intuitive and requires a double transformation
>to get from the original down-stem metadata to a final stem position, which
>could introduce rounding errors.
>- Return the up-or-down variant from metadata unchanged. This is easier
>to implement and understand and removes the need to transform
>unnecessarily, but it comes at the cost of having to check a grob's
>direction every time you want to make sense of the property.
>
> With the two new properties, the user would be able to specifically
> redefine -up and -down anchors from the get-go. This, I figured, would make
> Scheme scripts cleaner and easier to read and write. However, given the
> fact that a notehead grob will only ever have one stem attachment point,
> this argument doesn't have a lot of weight anymore.
>
> In short, thank you for pointing this out! If no one objects, I'll remove
> the extra properties.
>
> --Owen

Re: GSoC 2020 update, July 18

[Benkő Pál]

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
> > 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/f82a66af9573ba3cf431b0b1986f07e8
> > (staff three, the black block between two red block in the first half
> > of the staff); or see the youtube video
> > https://www.youtube.com/watch?v=wd3ouxA9p-o
>
> See also the examples given in Apel, the first of which being
>
> https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
>
> Best
> Lukas
>

Re: GSoC 2020 update, July 18

[Benkő Pál]

I just raised it to show that SMuFL may evolve so (if musicology's
interpretation of dragmae change so) that separate properties of up
and down stem attachment points may come handy.  you may well have far
stronger counterarguments, of course.

Owen Lamb  ezt írta (időpont: 2020. júl. 22., Sze, 1:57):
>
> Thanks for the tip, Benkő!
>
> At the moment, I think these sort of double stems are outside of my project's 
> scope. A two-stemmed black dragma is present in SMuFL as a pre-composed note 
> (mensuralBlackDragma), but Emmentaler does not have a glyph for it and 
> LilyPond does not specifically support double-stemming single notehead grobs. 
> All I am in charge of at the moment is taking how LilyPond currently handles 
> glyphs and adapting it to the SMuFL specification, and that's keeping my 
> hands full enough at the moment.
>
> If you need it, I think the basic version of such a glyph can currently be 
> simulated by using two notehead grobs, something like this:
>
> dragma =
> #(define-music-function (music)
>(ly:music?)
>#{
>  \override Staff.Stem.length = 4
>  <<
>\override NoteColumn.direction = #UP
>#music
>\\
>\override NoteColumn.direction = #DOWN
>#music
>  >>
>  \revert Staff.Stem.length
>#})
>
> \score {
>   \new Staff {
> \override Staff.NoteHead.style = #'petrucci
> \dragma { g'4 a'2 }
> b'4 \dragma b' a' c''
>   }
> }
>
> I can't vouch for the flags looking right, but it's something.
>
> If you want to use the precomposed glyph as it is found in another SMuFL 
> font, you 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:
>>
>> 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
>> > > 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/f82a66af9573ba3cf431b0b1986f07e8
>> > > (staff three, the black block between two red block in the first half
>> > > of the staff); or see the youtube video
>> > > https://www.youtube.com/watch?v=wd3ouxA9p-o
>> >
>> > See also the examples given in Apel, the first of which being
>> >
>> > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
>> >
>> > Best
>> > Lukas
>> >

Re: Repeat alternative count

[Benkő Pál]

\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 repeat count.  If so, does 
> anyone want to suggest a syntax?  Here's my entry.
>
> \repeat volta 40 {
>   …
> } \alternative {
>   { … }
>   \repeat alternative 3 { … }
>   { … }
> }
>
> Good? Bad? Meh?
> —
> Dan
>
>

Re: ancient convert rules

[Benkő Pál]

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 story short: Can we maybe instead drop any rules older than
> > 2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
>
> I don't know.
>
> While it is more than 10 years ago, I seem to recall a lot of stuff on
> Mutopia where there are LP files to use are from much older than 2010.
>
> I think at the very least we should perhaps 'flag' anything (either as a
> warning or as an error) for users that might have needed to convert
> something that we have removed because of backward compatibility if they
> tried to use such a convert-ly file. Rather than look like it has worked
> until they try to compile it with the later code and then get an error
> and open a bug report (if you see what I mean).
>
> James
>
>

Re: ancient convert rules

[Benkő Pál]

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)
with some old examples of mine, and your branch at least creates
something usable, as opposed to current master, which just errors out.

thanks,
Pal

Re: tie over clef change

[Benkő Pál]

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 repetition?)
> >>> in the transition from "Confiteor" to "Et expecto".  I mean, that
> >>> transition is a tonal center nightmare anyway.
> >>>
> >> In bar 138:
> >>
> >> 
> >>
> >> Basically that is an example of enharmonic equivalence of diminished
> >> 7th chords: The tonal centre in the preceding bars is clearly d (d
> >> major with hints of d minor), so the diminished chord in bar 138 is
> >> most probably first heard as f♯-a-c-e♭ (with expected resolution to
> >> g minor), but is then being re-interpreted (and written) as
> >> f♯-a-b♯-d♯, resolving to c♯ major functioning as a dominant to f♯
> >> minor.
> >> My point is: Even without E12 tuning, this is clearly an example of
> >> fully exploited enharmonic equivalence used as a "wormhole" in an
> >> otherwise purely diatonic tonal system. There can be no question
> >> that this is semantically a tie.
> >>
> >> (One might raise the objection that, maybe, when performing the
> >> piece, a slight adjustment in intonation might be needed in the
> >> transition from c to b♯. But this can also happen for bona fide ties
> >> in purely diatonic music, so that does not yield an argument against
> >> the tie being a tie.)
>
> The tonal center collapse is done purely vocally in an a cappella
> passage and when the instruments come back in, it's in a resurrection
> key and instrument groups (like brass) that are typical for it.
>
> Really, you need to listen to it before sorting it into the context of
> its period.  This passage is completely out of whack with its time while
> it is arrived at from a grandiosely conservative fugue in full ars
> antiqua.
>
> Here is a link  to a
> Herreweghe version.  The piano extract displayed in parallel would
> suggest that there is, after all, an instrumental part even in the 2:30
> and finally 3:00 (or so) locations which is a bit surprising to me since
> I remember how we fought keeping the intonation in line so that the
> resurrection trumpets could fall right in.  I cannot hear instruments
> there right now but I have only builtin speakers at low volume right now
> so I may be wrong about that.

Not purely a cappella, since the continuo group plays throughout,
including (a) keyboard instrument(s) playing the complete chords (in
whatever temperament c and his are the same key).

Re: guile libraries

[Benkő Pál]

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 design engineer.  15 years embedded in
> assembly followed by 20 in the Windows environment programming C and its
> derivatives.  Since retiring I moved all my development machines to
> linux and started looking at opensource projects to keep my hand in.  I
> am also an aspiring musician and have used Finale, MuseScore and
> lilypond with Frescobaldi to a great extent.
>
> I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
> all".  I get the error:
>
> /usr/bin/ld: cannot find -lguile
>
> Should be a simple thing to set a path to the guile 1.8 libraries -
> but I cannot find them, either.
>
> Would someone be so kind as to offer some advice on compiling lilypond?
>
> Thanks,
>
> Al
>
>
>

Re: Please review Pygments lexer and style

[Benkő Pál]

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)

[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 it.  seems this is my first contribution since
leaving google code.
(and I had the same regression you had with your arabic.ly modification.)

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 it.  seems this is my first contribution since
> leaving google code.

I set up a sourceforge account, my username is benkopal. someone
please grant me write access.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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 smoothly.
Pal

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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/lilypond-devel

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

[Benkő Pál]

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 would mainly
be explaining things about ancient notation).

>> as it really is looking rather odd and has not had any of the
>> tidying up work that I did with Graham all those years ago because only
>> a few people knew enough to know what was wrong or could be improved.
>>
>> I assumed (incorrectly as it turned out) that the #'mensural value was
>> generic for all ancient music types and that it was the clef
>> name/settings that made the output 'Gregorian' vs 'Mensural'. :)

It's the notehead style: vaticana, medicaea, solesmes and hufnagel are
for gregorian, mensural, neomensural and petrucci for mensural music.
I'm not at all sure about kievan -- it seems mensural, but I may well
be mistaken.

>> Although there are a lot of diffs, they are mainly just cut/paste edits
>> so if you can give me some broad education on what values I need to use
>> for a given set of keys sigs that should be enough than you go through
>> every single edit line by line.
>> I ordered the clefs as they appeared in the scm file rather than any
>> alphabetical or notational style order.

I think that's a good order.

>> I figured it would be easier to
>> correct someone's work than get a developer to do the edits themselves,
>> so have at it, let me know what I need to change.
>>
>> To save you (and anyone else who may want to help) you can download what
>> the table looks like when it is compiled from here:
>>
>> https://cloud.woelkli.com/s/dBGXat0NEGVoy5C
>>
>> This is just that Clef section in the appendix so it is a small PDF.

Grouping and ordering is fine.

>> Otherwise tell me what I need to fix or what is not correct etc.
>>
>> If you think removing notes would be better (in this appendix) then I
>> can simply use 'spacers' (or if lilypond-book allows it, nothing at
>> all).
>>
>> James
>
>
> I'll have a look at sending you some suggested changes tomorrow - I'm in all
> day so this will be something to work on.
>
> I think the notes add some value, since they show where middle C is with the
> relevant clef.

Agreed.
p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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-clefs witness,
assume five line staves.

> https://cloud.woelkli.com/s/dBGXat0NEGVoy5C

The modified link is almost perfect, just two nits to pick:
- hufnagel-do-fa is misaligned (both the c and f should be on line, as
if hufnagel-do3-fa1) -- this may be a bug elsewhere.
- petrucci-f5 is duplicated.

Thanks,
Pal

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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
> notation”. They both don’t mention compressed rests in combination with
> longer measures.
>
> I’ve got the impression that neither LilyPond’s current behaviour nor my
> suggested patch are optimal. I’ve sent this question to some major music
> publishers, maybe they can help ;)

Great, I hope some of those will reply.  My entirely irrelevant
preferences lean towards the current behaviour; I expect it matches
Bach's practice (relevant principles of mensural notation were sort of
known), but I know it doesn't match modern printing.  Of Werner's
examples I prefer the Saint-Saëns one (do the same as for common bar
lengths as 4/4 or 3/8, but mark every single full measure rest by an
explicit "1") to the NBA one (I expect they avoid printing a
multi-measure rest of odd length, and instead of a 7 bar rest they
print a 6-bar multi-measure rest and a standalone single full measure
rest; if that's really so, it would be quite a big nuisance to
implement in LilyPond).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: vertical position of Rests and MMRs

[Benkő Pál]

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,
>> ia. e. I made the behaviour of Rests and MultiMeasureRests more
>> consistent. But this breaks some regtests (breve and longer rests in
>> TabStaff).
>>
>> Then I opened issue 5258 (correct vertical positioning of breve/longa
>> rest glyphs both for Rests and MMRs). This would fix these broken
>> regtests if I knew how to solve it (see discussion for my unsuccessful
>> attempts).
>>
>> How should I proceed?
>>
>> 1. try to change the patch for 3208 so that it doesn’t touch vertical
>> positions and leave this completely for later (not only 5258 but
>> another issue because half and shorter rests are *really* ugly at the
>> moment)

errrm, which are those other issues?  are those *really* uglier with
the 3208 patch than without?

>> 2. push the patch for 3208 (it’ll be counted down on Jan 19) and live
>> with the regression until 5258 is fixed
>> 3. push the patch for 3208 and decide that this regression isn’t that
>> bad because breve rests always look ugly in TabStaff
>> 4. let 3208 wait and try to make a patch which fixes both 3208 and
>> 5258 at the same time
>>
>> https://sourceforge.net/p/testlilyissues/issues/3208/
>> https://codereview.appspot.com/335410043
>>
>> https://sourceforge.net/p/testlilyissues/issues/5258/
>> [no patch for 5258 uploaded yet]
>
> An additional question is what to do regarding vertical repositioning
> with regard to _pitched_ rests.  I have argued in the past that we
> should leave any user-specified pitch completely alone and not try
> shifting it to grid positions even in the case of half and whole rests.
>
> There is some merit to that stance (and it probably should be available
> at least as an option) but it's less than great when one is actually
> working with transposed notes/themes/parts.

The whole argument was quite ramified, starting in
https://sourceforge.net/p/testlilyissues/issues/2109/
ramifying into e.g.
https://sourceforge.net/p/testlilyissues/issues/2249/
touching the transpose problem, and
https://sourceforge.net/p/testlilyissues/issues/2783/
(quite long, demonstrating that quite many stuff that look unrelated
at first sight are actually related)
and some more.

I expect pitched rests to be exactly where pitched and use a function
to fix the transposition problem.  I hope my
mensural-and-modern-from-common-source and mensural-canon-handling
functions still work.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New LilyPond contributor: Basia Mroczek

[Benkő Pál]

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 all goes well.  
> Then, if you still want to, you can try to get it building on your own system.
>
> Personally, I gave up trying to keep lilypond building on my system and just 
> use LilyDev for my development.
>
> Carl
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stack smashing detected

[Benkő Pál]

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 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.

which is called B-splines.  is it possible to use (cubic) B-splines directly?

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stack smashing detected

[Benkő Pál]

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.
> >
> > which is called B-splines.  is it possible to use (cubic) B-splines 
> > directly?
>
> B-splines are also mentioned in one of the linked sources, but
> currently can't deal with them. I'll continue exploring ;)

it's well worth exploration; otherwise you'll just end up with something poorer.
the book I learned Bézier and B-splines from:
http://www.cin.ufpe.br/~mdlm/files/Farin-5a_edicao.pdf

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stack smashing detected

[Benkő Pál]

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 to sound like a curmudgeon, but I think this is 
> an important principle related to intellectual property.

> Having said that, I thank you for your recommendation and I believe I shall 
> buy that text, of which I was unaware.

Agreed.  I actually hesitated between sending this link or just
recommending the book, but since the link is on the first page of
google hits, I thought there's not much difference.  I should have
added an explicit caveat like "look into it then buy it, please, as
it's not free".

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: stack smashing detected

[Benkő Pál]

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 than 500 pages ... phh

oh, strictly speaking you'll need only about 40: first read the
chapters about Bézier curves to pick up terminology and style, then
jump to B-spline curves.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 adding up until something bad
> >> happens - probably only for huge chords comprising hundreds of notes,
> >> but I'd tend to favor the solution with rounding.)
> >
> >
> > I would think that rounding the int and keeping lastpos as an integer
> > would be less invasive and I would do that.
>
> It would be less invasive, the question is what the right thing would
> be.  Anybody have an idea whether non-integer positions can sensibly be
> employed here for, say, chromatic notation systems having three
> positions per staff-line?  Or is that all integer in that case?

I'd translate such notation to line-positions like '(-6 -3 0 3 6) and
keep integer positions for note heads; don't know whether there are
other systems out there.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

 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->start_;
> On 2020/01/31 10:49:13, benko.pal wrote:
> > I understand (and like) adding the const, but can't understand
> changing the
> > reference to pointer even after reading the whole discussion.
>
> the change from & to * here is merely syntactical.

of course it is; but to me it's nearer to obfuscation than to cleanup.

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

[Benkő Pál]

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 time. But it was not
> the only cause; it would have been possible for me to contribute at least a
> little. The reason I did not was that participating in the development had
> been too emotionally draining to endure. In my experience LilyPond has
> (used to have?) huge inertia (disproportionate to the size of the project).
> I mean (more or less, please consider this to be an approximation) that
> when I tried doing things that didn't clearly align with the views of a
> person with most authority (for the last few years David has been this
> person) I had felt *unwelcome* and my personal impression was that they
> were "blocked". It was very difficult to get some things done.

You seem to be impatient.  In late 2011 LilyPond broke my renaissance
scores (with a fix that uncovered decade old latent bugs --
assumptions that were false since long, though probably true when the
code was first written), and to get them right took me a _year_ of
issues, reviews, reversions, misunderstandings, messing up the
submission process and my breaking other people's scores several times
(to get just a glimpse, take a look at issue 2783).  I thought that my
patches were obviously trivial bug fixes, but to keep LilyPond
operational, I (or rather, we, with David and Keith) had to think
about the design, not only particular lines of code.  When my last
commit reached master in late 2012, it was quite different (and far
better) than when I first submitted it.  and the process taught me
that David is arguable and well worth respecting.

> Since David has more time available that many of us (who have a
> non-LilyPond job), and apparently limiting email volume is not a high
> priority for him.

I'd describe this as David taking great pains to express himself
unambiguously, knowing well the communication problems.

I'm inactive as contributor because renaissance notation is stable,
and when some rare need arises, I can handle them by user level scheme
coding.  a CoC wouldn't make me more willing to contribute.
Contributing to LilyPond is hard, because it's a complex piece of
software with a long and complex history; people most interested in it
are musicians.

Pal

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

[Benkő Pál]

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
> >> 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 time. But it was not
> >> the only cause; it would have been possible for me to contribute at least a
> >> little. The reason I did not was that participating in the development had
> >> been too emotionally draining to endure. In my experience LilyPond has
> >> (used to have?) huge inertia (disproportionate to the size of the project).
> >> I mean (more or less, please consider this to be an approximation) that
> >> when I tried doing things that didn't clearly align with the views of a
> >> person with most authority (for the last few years David has been this
> >> person) I had felt *unwelcome* and my personal impression was that they
> >> were "blocked". It was very difficult to get some things done.
> >
> > You seem to be impatient.  In late 2011 LilyPond broke my renaissance
> > scores (with a fix that uncovered decade old latent bugs --
> > assumptions that were false since long, though probably true when the
> > code was first written), and to get them right took me a _year_ of
> > issues, reviews, reversions, misunderstandings, messing up the
> > submission process and my breaking other people's scores several times
> > (to get just a glimpse, take a look at issue 2783).  I thought that my
> > patches were obviously trivial bug fixes, but to keep LilyPond
> > operational, I (or rather, we, with David and Keith) had to think
> > about the design, not only particular lines of code.  When my last
> > commit reached master in late 2012, it was quite different (and far
> > better) than when I first submitted it.  and the process taught me
> > that David is arguable and well worth respecting.
>
> Arguable and well worth respecting does not really help with regard to
> the cost in emotional energy contributing has.  If the summary
> impression is "David makes contributing to LilyPond a hair-pulling
> nightmare but...", then for most people reading on after the "but" is
> only worth their trouble if they are in a hair-pulling nightmare already
> and need to get out of it.

that year also taught me that difficulties in contributing to LilyPond
stem not from people but from the complexity of the problem, and we
can't expect contributors to see all those complexities.
I broke other people's score with the best intentions, and when they
complained, they did it most courteously by providing a Minimal
Example, which, at first sight, looked to me contortions made on
purpose to tease me.  they used LilyPond for notations I never dreamed
of, but to them those LilyPond features are much more important than
faking a Petrucci print.

Re: lilypond-2.19.84

[Benkő Pál]

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
>
>
> Cheers,
> --
> Jean-Charles Malahieude
>

Re: 'blackpetrucci' stem attachment

[Benkő Pál]

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):
>
> > > On lilypond-user-fr, a user wonders about this:
> > >
> > > \version "2.23.6"
> > >
> > > {
> > >\override NoteHead.style = #'petrucci
> > >c'8
> > >\override NoteHead.style = #'blackpetrucci
> > >c'8
> > > }
> > >
> > >
> > > If you zoom on the output, you can see that the attachment
> > > point for blackpetrucci is not centered horizontally.
> > > Is this on purpose?
> >
> > The NR for 2.22 [1] says the Petrucci note heads are centered on the
> > stems.  It also shows that black Petrucci is not centered on the
> > stems.
> >
> > I assume this is not intentional.
>
> Jürgen, please have a look.
>
>
> Werner

Re: Ancient repeat sign

[Benkő Pál]

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 AAA BBB CCD?

Yes.  (sort of.)  (also, I've read Jürgen's e-mail and listened to
that performance, but I still think that the music is to be repeated.)

> Q. Is this the most obvious way to code it?
>
> {
>   \repeat volta 3 \A
>   \repeat volta 3 \B
>   \repeat volta 2 \C
>   \repeat volta 1 \D
> }

Yes.  (sort of.)

the glyph is quite flexible, as anything in ancient notation.  The
last time I met a repeat sign was in Josquin's Missa L'homme armé
sexti toni, where the top part of the Et resurrexit is to be repeated
four times.  Three codices mark this in three ways:
the Chigi codex, page 197v marks it as _three_ points on both sides of
_two_ bars taking up three spaces (plus and minus half):
https://digi.vatlib.it/view/MSS_Chig.C.VIII.234
another Vatican codex, page 31v marks it as
.||.
 ||
 ||.
(but the lower left dot may be missing only because scarceness of space):
https://digi.vatlib.it/view/MSS_Capp.Sist.41
a Jena codex splits the movement, there's a pagebreak, so two
repetitions are in page 205v, two more on 206v, both marked as three
dots on both sides of two bars; the bars are not longer than three
spaces:
https://collections.thulb.uni-jena.de/rsc/viewer/HisBest_derivate_4510/BE_1047_0173.tif

p

Re: SMuFL name mapping update, 17 March

[Benkő Pál]

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 trouble, but as always, extra pairs
> of eyes are encouraged to spot typos and other mistakes or give
> suggestions throughout the database.
>
> The link to my work: https://wolfgangsta.github.io/emmentaler-bravura/
>
> Low priority issues (Nice to do, but can wait until after GSoC integration):
> * noteheads.[ud]M2: It would be nice if the stems weren't hardcoded.

+1

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 (like current
emmentaler rests.M3mensural), not four (as, I fear, the bravura
mensuralRestLongaPerfecta implies)
3. a maxima rest consists of two (or three) longa rests, similar to
rests.M3neomensural, so much that theoretically one can't tell a
maxima rest from two (three) longa rests.  renaissance version of
multimeasure rests use groups of longa rests at different staff
positions, like
https://upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Ockeghem_Prolationum_Kyrie.jpg/220px-Ockeghem_Prolationum_Kyrie.jpg

I can't check right now, but I think LilyPond doesn't use longa glyphs
in ligatures: longae are drawn by adding stems to brevis glyphs.

p

Re: SMuFL name mapping update, 17 March

[Benkő Pál]

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 (like current
> emmentaler rests.M3mensural), not four (as, I fear, the bravura
> mensuralRestLongaPerfecta implies)
> 3. a maxima rest consists of two (or three) longa rests, similar to
> rests.M3neomensural, so much that theoretically one can't tell a
> maxima rest from two (three) longa rests.  renaissance version of
> multimeasure rests use groups of longa rests at different staff
> positions, like
> https://upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Ockeghem_Prolationum_Kyrie.jpg/220px-Ockeghem_Prolationum_Kyrie.jpg
>
> OK. Then I think rests.M3neomensural should be given the SMuFL name 
> neomensuralRestMaxima, and shouldn't be an alternate of anything. (It seems 
> like a bad idea that both the longa perfecta and the maxima are labeled with 
> the M3 duration in LilyPond, when in fact they aren't interchangeable...)

I agree with the naming; I'm confused about potential implications of usage.

> I can't check right now, but I think LilyPond doesn't use longa glyphs
> in ligatures: longae are drawn by adding stems to brevis glyphs.
>
> Terminology gets a bit muddled around here. To clarify, are you talking about 
> the glyph-on-glyph ligatures found throughout the SMuFL specification, or the 
> note-on-note ligatures characteristic of mensural notation?

the latter.  I haven't realized the ambiguity (the existence of
ligatura variants of clefs should have made me think a bit though).

thanks again,
Pal

Re: pygment regex question,Re: pygment regex question

[Benkő Pál]

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|\\longa)\.*)

if someone really wants to touch that, please note that \maxima too is
a duration.
p

Re: Explicit default duration?

[Benkő Pál]

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 switching pitches (or to rest) but not wanting to change the
> > default duration.
> >
> > Like
> >
> > \drums { tamb 4. 8 4 r | 4. 8 4 r }
> >
> > in situations where there _isn't_ something like | to put between r and
> > 4. (here).
>
> My knee-jerk reaction is a bit of skepticism on an explicit
> default duration being more ergonomic than just repeating the
> previous duration.

My knee-jerk reaction is "how these modern musicians keep forgetting
those highly unergonomical durations \breve, \longa, \maxima and their
dotted versions!"

> Instead of "|", "{}" might just work.

They do for my use case, thanks a lot!

p

Re: Multiple clefs in one Staff

[Benkő Pál]

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 mean with 'offering'?
>
> Provide it as core functionality called with dedicated commands.
>
> > Having this functionality is certainly useful for Piano music.
> > However, it's quite rare, and an LSR snippet should be sufficient
> > (possibly integrated into LilyPond's documentation).
>
> I see that you have shown an example that repeats the clef for every
> measure.  If that's the convention, the approach in my code is not
> likely helpful.

another example is the first movement of Ligeti's String quartet no2,
bars 25-35 (cello playing harmonics sul III while holding a C sul IV)
https://youtu.be/rMd6EEqukWo?t=75
where every bar has _both_ clefs.
(I can't hide my embarrassment seeing that the bass clef doesn't act
as an f-clef.)

Re: completion disturbed by other staff (issue 1082)

[Benkő Pál]

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 simplifies initialisation of left_to_do_
while also puts it early enough to be used in the changed condition.

p


patch13
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: completion disturbed by other staff (issue 1082)

[Benkő Pál]

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_length ())
> +  if (nb.main_part_ && nb < left_to_do_)

the condition is reverted to the original, but do_nothing_until_
is set unconditionally.

> the remaining bit simplifies initialisation of left_to_do_
> while also puts it early enough to be used in the changed condition.
>
> p
>


patch14
Description: Binary data


patch15
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: completion disturbed by other staff (issue 1082)

[Benkő Pál]

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 would be better placed first in this block.
>
> +++ b/input/regression/completion-heads-polyphony-complex.ly
>
> This test is very similar to the existing one, so it would be fine to
> call it completion-heads-polyphony-2.ly.
>
> +\version "2.12.0"
>
> "2.13.22"
>
> +Complex completion heads may be fooled by polyphony with a different rhythm.
>
> Please change this to something which explains that the polyphony in
> this test works properly.

what about "Versions up to 2.13.21 got complex completion heads wrong
in polyphonic environment"?

thanks for all the suggestions; I agree with all and will do it,
but only in June, as my computer broke.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: completion disturbed by other staff (issue 1082)

[Benkő Pál]

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

[Benkő Pál]

> 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 their own title/description/email/web
>
> AFAIK, we haven't been keeping track of this for the past 4-5 months,
> so I expect to have a few gaps.

I'm listed in both Current contributors (as Pál Benkő) and in
Previous Contributors (as Pal Benko),  someone please
remove the latter one.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

span-bar problem

[Benkő Pál]

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 extent of the mensurstriche are miscomputed
(as if the involved staves kept their centre).
see the attached example.

I 'fixed' this by the attached patch, but that
does not solve the whole problem: now the extents
are right, but the absolute position is as if the
uppermost staff kept its centre - which is fine as
long as there's no extra line there.

I believe this is caused by Span_bar::print having
a different common refpoint than the context the
result is used in, but I couldn't track it further.
any help and hint is welcome.

p


spantest.ly
Description: Binary data


patch17
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lilypond's internal pitch representation and microtonal notation

[Benkő Pál]

> 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/flat (a
> multiple of M - m), there will result a multiple n - m or n - M.

a minor point: wouldn't it be clearer to use d (degree) and a (alteration)
instead of M and m?  d should be a second, i.e. M (or m), while a should
be the augmented prime, i.e. M - m.
then multiples of d gives the staff system (very roughly equivalent to
the diatonic scale), linear combinations of d and a would give the usual
chromatic system (all notes that can be notated with sharps and flats),
and for microtonal and exotic music one should use (one or several) n.

anyway, I'm a big fan of using such a system: I've tried Pythagorean
and meantone MIDI-output by defining alterations, and MIDI was all
right, but the score had all the naturals which weren't defined to
be exactly zero (i.e. all except a); your system distinguishes nicely
between pitch systems and tuning (thoretical pitch and its physical
frequency).

Pál

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lilypond's internal pitch representation and microtonal notation

[Benkő Pál]

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' m + j' M. When taking the difference with
>>> the
>>> staff note, reducing the degree to 0, and taking away the sharps/flat (a
>>> multiple of M - m), there will result a multiple n - m or n - M.
>>
>> a minor point: wouldn't it be clearer to use d (degree) and a (alteration)
>> instead of M and m?  d should be a second, i.e. M (or m), while a should
>> be the augmented prime, i.e. M - m.
>> then multiples of d gives the staff system (very roughly equivalent to
>> the diatonic scale), linear combinations of d and a would give the usual
>> chromatic system (all notes that can be notated with sharps and flats),
>> and for microtonal and exotic music one should use (one or several) n.
>
> I think this is what LilyPond has now, using d and M in E12 originally.

I think not.  I didn't mean to replace the whole of your system
by d and a, only M and m.  similarly to your P5-P8 example,
(1  0)(d) = (M)
(1 -1)(a)   (m)

> But it becomes complicated when adding pitches. If one has seconds s_1, ...,
> s_k, then there is an accidental for each difference s_j - s_i and each s_i
> - s_j. With just m, M and n, one gets besides sharp M-m, flat m-M, also n-m,
> n-M, m-n, M-n. All four are used in Turkish music, but this system can
> handle it algebraically by adding just one second n.

well, the two systems are equivalent, as M and m can be expressed by d and a:
M = d, m = d-a (and n is common to both).  I just think that d and a suits
better to classical music than M and n.

> In this system, d can always be computed. So it is not needed as a variable
> to carry around.

I just meant it as another base in the modulus (or free Abelian group)
of intervals - I see your original proposal as a suggestion to replace
the current physical pitch based representation (which is essentially
a one dimensional vector space over the reals) to a theoretically
correct interval based representation (a modulus over the integers,
of dimension at least two, but incremented for microtonal purposes).

> Another motivation is musical. One is typically not playing the accidental
> but the neutral interval. So it is easier to describe the music using
> seconds. An example of playing an accidental is major chord followed by a
> minor chord. But it is still more convenient to think of the minor chord
> built up by a minor and a major third rather than an alteration of the major
> chord. When playing the minor chord it has no relation to the major chord.

I'm not sure I got it - the minor third IS an alteration of the major third,
isn't it?

>> anyway, I'm a big fan of using such a system: I've tried Pythagorean
>> and meantone MIDI-output by defining alterations, and MIDI was all
>> right, but the score had all the naturals which weren't defined to
>> be exactly zero (i.e. all except a); your system distinguishes nicely
>> between pitch systems and tuning (thoretical pitch and its physical
>> frequency).
>
> Yes, this is another point. If creating music with these linear combinations
> of seconds, one can plug in values later, and it is easy to retune the
> piece. This is so because the staff system was created to admit different
> tunings.
>
> There is another part how to compute these seconds, which we have not yet
> come to. Traditionally, a system is defined by the pure fifth P5 = m+3M and
> the octave P8 = 2m+5M.

yes; in my terms, P5 and P8 forms a base equivalent to M and m (or d and a);
in fact, for transposition purposes, this may be the best choice.

> Writing a matrix equation
>  (1 3)(m) = (P5)
>  (2 5)(M)   (P8)
> the intervals of m and M can be computed by inverting the matrix on the left
> hand side.

and we all know that m = 3P8 - 5P5, M = 2P5 - P8:
matrix inversion in musical terms!

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: @lilypond[fragment] question

[Benkő Pál]

> 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 and none of it is related to mensural notation;
I'd love to hear about them.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

coloratio, black mensural notation

[Benkő Pál]

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 functions:

#(define (nota-colorata music)
  (let (
(es (ly:music-property music 'elements))
(name (ly:music-property music 'name))
  )
   (if (equal? name 'EventChord)
(let* ((note (first es))
   (dur (ly:music-property note 'duration))
   (dl (ly:duration-log dur))
 )
 (if (> dl 1)
  (set! music (shift-duration-log
   (ly:music-compress music (ly:make-moment 2 1))
   1 0)
   music))

notaColorata =
#(define-music-function (parser location mus) (ly:music?)
  (music-map nota-colorata mus))

I hope there is a better solution.

the next step is using all this;
I've tried adding a new note head style - I believe this
is right, considering colored - uncolored changes in
WMN, but I may well be wrong.

I also have support for these in ligatures (notes can
be colored/uncolored independently - even the two notes
of a flexa can have different color), but I'd like to
sort out the above issues first.

thanks,
Pal


black.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] coloratio, black mensural notation

[Benkő Pál]

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 me to upload this patch on Rietveld (or possibly
> to the bug tracker)?
>
>> I could reach this look by the following functions:
>>
>> #(define (nota-colorata music)
>>  (let (
>>    (es (ly:music-property music 'elements))
>>    (name (ly:music-property music 'name))
>>  )
>>   (if (equal? name 'EventChord)
>>    (let* ((note (first es))
>>           (dur (ly:music-property note 'duration))
>>           (dl (ly:duration-log dur))
>>         )
>>     (if (> dl 1)
>>      (set! music (shift-duration-log
>>                   (ly:music-compress music (ly:make-moment 2 1))
>>                   1 0)
>>   music))
>>
>> notaColorata =
>> #(define-music-function (parser location mus) (ly:music?)
>>  (music-map nota-colorata mus))
>>
>> I hope there is a better solution.
>
> I'm not sure exactly what you're trying to achieve (I know nothing
> about mensural notation), but is changing the rhythm a desired
> side-effect? Whenever I want a black note head, I use something much
> simpler (but arguably hackish):
>
> #(define (nota-colorata music)
>  (let ((es (ly:music-property music 'elements))
>   (name (ly:music-property music 'name)) )
>  (if (equal? name 'EventChord)
>   (let* ((note (first es)))
>      (set! (ly:music-property note 'tweaks)
>            (acons 'duration-log 4
>                   (ly:music-property note 'tweaks)
>  music))

as in CPP notes shorter than a quarter are created by
attaching flags to a quarter note, in BMN notes shorter
than a half are created by attaching flags to a half note;
look at the table in
http://en.wikipedia.org/wiki/Mensural_notation#Note_values

so a fourth and a half note are not distinguished by note head
look, but by flag count (and all flagged note values have
one more flag than common, i.e. an eighth note has two).
I looked for a method for tweaking
- how many flags are on the stem
- what is the note head (strictly speaking there's no need
  for a separate quarter note head in BMN),
but I didn't found any.
so the purpose of my function is to have a note that lasts
as long as dictated by duration, but looks as if it were just
the half, i.e. turns 4 into 8*2, 8 into 16*2, etc (but leaves
2, 1, \breve etc. intact);
this way alignment of parts and midi output are correct.

thanks,
p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] coloratio, black mensural notation

[Benkő Pál]

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 very strange, and I've never seen a similar note shape before.
> But I suspect this is my lack of knowledge.

thanks, Werner.
I'll try to compile a list of online facsimiles.
semicolored notes are really very rare, but I've already seen such notes.
(a semicolored note can be seen as consisting of two smaller notes,
one uncolored, one colored; theoretically one could use semicoloration
to color the first half, but I have never seen such an example -
that's why I didn't implement it).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 found and
fixed an unrelated error) I can see no unintended change (i.e. drums.ly
works as before).

actually I don't know what to expect with changed bar-size - I attached
two more tests: spantest1 is a modification of my original spantest, and
the result looks the same;
spantest3 is a modification of spantest2, and it's consistent,
perhaps even good.

>> I removed the center setting code and that
>> (with my patch still active) made my example perfect;
>> however, the attached complementary test (with bar
>> lines only within staff, not between them) failed,
>> but it's perfect with current center setting
>> (independently whether my original patch is active or not).
>
> Since Bar_line::compound_barline is used in both BarLine and SpanBar, you
> will need to find some solution that works for both cases. It won't be as
> simple as just enabling or disabling the centering code.

oh, uh.  thanks for this hint as well; I'll investigate.
p


spantest1.ly
Description: Binary data


spantest3.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 and below).

>> thanks for the hint.
>> 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 think extent shouldn't be computed from size
as it loses information, but the other way round.

AFAICS the intent of the span bar code is to draw lines
not between staves but from line to line, and my patch
reverts this.
of course there's no difference in general, but there is
if bar lines are to have different extent than that of
their staff; and there is a further difference whether
the bar is shorter or longer than the staff: if longer,
there may be no point in using span bars at all; if
shorter, then perhaps span bars are better placed just
between staves (see spantest5.ly).

I still don't know exactly how should spantest3 behave
(spantest5 makes me feel it works acceptably), neither
what should happen if different bar types are connected
(see spantest4.ly - I hope this is farthest from a real
world case of all my tests).

>>> I removed the center setting code and that
>>> (with my patch still active) made my example perfect;
>>> however, the attached complementary test (with bar
>>> lines only within staff, not between them) failed,
>>> but it's perfect with current center setting
>>> (independently whether my original patch is active or not).

>> Since Bar_line::compound_barline is used in both BarLine and SpanBar, you
>> will need to find some solution that works for both cases. It won't be as
>> simple as just enabling or disabling the centering code.

I moved the centering code from compound_barline to print,
and this way all regtests are OK and all my spantests are
good or at least acceptable.

standalone patch attached.
p


patch18
Description: Binary data


spantest4.ly
Description: Binary data


spantest5.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: C++ question

[Benkő Pál]

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 (int a, int b, int c) { return a + b + c; }

no.  foo, bar and baz are _defined_ in the header as pointers to
function (and not declared as functions of given signature).
you can use them like

int lily (int i, int n, int t)
{
  return i + n * t;
}

struct pond
{
  static int lily (int i, int n, int t) { return i *n + t; }
};

foo = &lily;
bar = &pond::lily;
baz = foo;

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: regtests about very small differencies

[Benkő Pál]

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 that setting staff-size and font size is not exactly the same.
depending on the issue one or other method may be clearly better
than the other or one.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line_count fixes (issue 6211047)

[Benkő Pál]

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ál, see new issue 2648 on the tracker.

thanks for making me aware; I'll look at it in the evening.

> The various meanings of staff-space are tricky.
> Probably the wisest thing is to reverse this part of the patch for
> version 2.16, and try again in the 2.17 versions.

I don't mind either way; I hope I can sort this particular problem out quickly.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Syntax change proposal:

[Benkő Pál]

> 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., which is not what I want, so I
write \perfect a=4.
(I guess it can be written so that the octave check is unneeded, but...)

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)

[Benkő Pál]

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)

[Benkő Pál]

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-sign.ly.
>>>
>>> I really don't mind if your patch goes before mine (it would even be
>>> better - why push a change to a file that is to be thrown out by the
>>> next commit), but I do mind that (some of) those cases work right, and
>>> unfortunately I'm far less fluent in Scheme than in C++.
>>>
>>
>> I had suggested that Marc incorporate pending changes to the bar-line code
>> if he is confident in them,
>> but it does seem cleaner make one commit a simple re-implementation of C
>> to Scheme, with the same functionality.
>>
>> He is not really throwing out the issue-2533 stuff, because that stuff is
>> not in the code base at the moment.
>>
>> You will just have to cooperate with Marc or another Scheme programmer, if
>> the re-implementation goes in first.  If it really turns out to be harder
>> for the group to modify the code in Scheme than it was in C, then the
>> reason
>> for Marc's patch would prove to be wrong and we can just go back to C.
>
> I had already implemented Páls work on repeat signs *before* his patch
> was reverted, so reimplementing this in scheme should be straightforward.
>
> ... and wait until you see what will be possible with barlines when part 2
> of issue 1320 is out ;-) Stay tuned!

ok, thanks in advance to everyone!

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 think they should be included in this patch.

yes.

> If you want to cover all by one patch, I can send the changes
> in bar-line.scm to you and you put them into your patch.
>
> What do you think?

good idea, but in the end this patch may be split into four and then
the bar-line changes would go as a separate patch anyway.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 let you know how I stand.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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++ version had it inside -
   there may be a difference how line-thickness is handled.
2. calc_bar_extent had some code in c++ to enlarge the
   bar line for a very narrow (e.g. single line) staff;
   ly:bar-line::calc-bar-extent corresponds to an earlier version.

continuing,
p


0001-Rewriting-Benko-P-ls-algorithms-concerning-the-repea.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 version you sent uses the correct staff line thickness.
> The last C version you posted used the layout line thickness, for bar lines
> and span bars.

thanks for spotting, I use Marc's Scheme code now.

> The gap you require to set the dot, dot-y-length + line-thickness + 2 * 0.75
> line-thickness,
> includes a lot of space for the gaps on each side of the dot, when the staff
> lines are thick.  You might be happy with a rule to ensure a minimum
> proportion of white-space  1.2( dot-y-length + line-thickness )

ok, I applied this (and did a bit of restructuring to keep
lyrics-bar.ly the way we like).
I also changed those regtests that show where's the change of dot placement
inside or outside staff.
I have now four commits: regtest changes plus one change
in three (sort of unrelated) functions each in bar-line.scm
(colon, extent and line-span computation).
what review process do you prefer/suggest?
one review per commit or review in one, push in four?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>>> 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 they are relevant in the actual function, uh,
> declaration?  I mean the thing when the function body follows.

it's the definition.  I agree that it's relevant there, but here
I talk about the declaration (the thing in the .h file) only.

>> Good idea!  However, that would be a more intelligent
>> modification, which doesn't fit with fixcc's mandate.  At the
>> moment I just want to move forward with the automatic formatting.

agreed.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Assertion failure

[Benkő Pál]

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 started a git bisect but have no clue when the first good commit is - it 
> hits this failure at least as far back as June 20th.
>
> I'm a bit short on time but could someone do some snooping to try and figure 
> out what the problematic commit is?

if no one beats me, I'll have a go at it tonight.
p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Assertion failure

[Benkő Pál]

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

[Benkő Pál]

> 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 the terminal.  Could a make-guru explain, and propose
> an alternative syntax which does the same thing without the terminal output?

it merely echoes information.  the @ is needed to not echo twice (without that,
make would first announce what it will do, i.e. "echo export ...", then do the
actual echo, i.e. "export ...").  to silence the echo, just remove
those two lines.
(the rule itself is, of course, needed.)

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: preliminary GLISS discussions

[Benkő Pál]

>> 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\]\[ <>\] }
>
> If we say "that's ugly", it's not like the situation would be any
> different with () [] \(\)

I'd do
ligatures = { s2\[ s2\] s2\[ s2\] }

(but I never did such a thing and don't intend to do in the future.
I use ligatures and the "push different things in a common Voice"
idiom extensively, but never together.)

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>>> 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 there are a bunch of hand-written scores printed
> by various publishers (from the 70ies and 80ies) which contain them.

there's also percent repeat (ok, it can't handle changes in duration).
btw I'd use music functions for repeating chords, not q (with articulations,
whatnot in separate variables channeled into the same Voice).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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++ mishandling these, i.e.
handling foo (int) and foo (int const) as different signatures,
which was particularly annoying with virtual members.
I fear these const's can mislead developers not absolutely
up-to-date with all the exact details of the c++ standards.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>> 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?
> - it's hard/impossible to compare different versions of the patch.

I believe a nontrivial patch can't be directly reviewed anyway,
only after git am.  and in this case a patch can contain several commits
that can be reviewed individually.

p

___
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)

[Benkő Pál]

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)

[Benkő Pál]

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)?
>>
>> if we want to support both of those without changing dot size,
>> calculations cannot be based on line-positions only, staff-space must be
>> considered.
>
> I suggest you consider both the gaps between line-positions (prefer gap of 2
> staff-positions)
> and the full range of line-positions (prefer to have repeat dots within the
> staff)

I can see two possibilities:
1. special casing two-line staves.
   simple but will fail for staves with a big space in the middle but
otherwise dense.
2. implement a more complicated algorithm.
   the current one looks for a good place
   - starting from the centre
   - going up and down strictly synchronised
   - stopping at the first convenient point.
   instead we can try
   - starting from the outside
   - going inwards very loosely synchronised
   - scoring several paths
   - choosing the best.
   smells like a huge can of worms.

> If someone writes tablature and wants a staff-space = 2 for some reason, he
> probably want the repeat dots in their usual positions. (His choice on
> whether to also increase the dot size.)

is dot size customizable currently?  if so, we must include some regtests.

> If someone writes 2-line percussion somewhat more narrow, he will probably
> want the repeat dots inside the staff.

I still lean towards special casing 2-line staves.

p

___
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)

[Benkő Pál]

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 mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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 all right, I meant them to surprise,
i.e. to show the limits of the implementation.
"dots in outer spaces" was inspired by your comment
http://codereview.appspot.com/6488097#msg7
"dots outside" now changed behaviour and is accordingly relabelled to
"dots in middle".  as I hinted at in
http://codereview.appspot.com/6488097#msg8
I'm afraid improving this would more than such a contorted case is worth.

> The case "dots in outer spaces" is
> different from a four-line staff in that the user indicates eight
> scale-steps will fit between lines; if eight scale steps fit legibly,
> two repeat dots will also fit.

well, we know exactly whether two dots fit or not, but the current
issue arose just from that: though they fit, the user wants them outer.
as a theoretical consideration, I think repeat sign is a matter of the
staff and the dots, not the scale steps represented by the stafflines.
(are there chromatic or microtonal notations where these steps are
smaller than a third?)

> You could simplify at this point, and work entirely in staff-positions,
> until the end where you build the stencil.  I also suggest using a rule
> "prefer dots in tight spaces to dots completely outside the staff"
> rather than the special case for 2-line staves.

that rule is implemented by patch set two.  otherwise I think this
simplification is oversimplification as it cannot distinguish

\override #'line-count = #2

from

\override #'line-count = #2
\override #'staff-space = #2

then, if staff-space is taken into account, dot size must also be, see
http://code.google.com/p/lilypond/issues/detail?id=2648
and anyway that simplification buys us no more than replacing
gap-to-find by a constant.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>> "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 of pitches in those eight staff-positions between the middle
> lines, and will be surprised that LilyPond considers that not enough
> room for repeat dots.
>
> More likely, someone might have removed the center line from a 5-line
> staff
>   #'line-positions = #'(-4 -2 2 4)
> for some unusual instrument, and will not like the change.
>
> But, if anyone complains, we can insert 0 into 'folded-staff
>
>
>> (are there chromatic or microtonal notations where these steps are
>> smaller than a third?)
>
> seems crazy to me, but people do it,
> 
>
>
>> I think this
>> simplification is oversimplification as it cannot distinguish
>>
>> \override #'line-count = #2
>>
>> from
>>
>> \override #'line-count = #2
>> \override #'staff-space = #2
>
> Why do you want to distinguish these two cases?

because (maybe depending on set-global-staff-size and
layout-set-staff-size) the latter has enough room for two
dots, the former hasn't.  and that brings me back to my
main argument: I can't guess why the user chose a
specific way of manipulating the staff and how (s)he
interprets it, I also don't know at that point why the staff
space is that big as is (staff-size, set-global-staff-size,
layout-set-staff-size), but I know exactly whether one
or two dots have enough room or not.

I admit that the request to restore the look of the original
repeat sign of a TabStaff makes all that not enough.

I also think that users would be surprised that

\override #'staff-space = #0.5

and

\override #'line-positions = #'(-2 -1 0 1 2)

makes the repeat sign look different, even if they know that
pitches are at different places - but who thinks that the dots
of a repeat sign mark pitches?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

line_count issues

[Benkő Pál]

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/detail?id=2783#c36

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: line_count issues

[Benkő Pál]

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 you in private about this.  I am in
> the somewhat unfortunate situation of having admitted the line_count
> changes into 2.16.0 where they cause changes including definite
> regressions for some previous behavior, regressions that are not
> continuing into 2.18.  The task I am faced with is to bring 2.16.1 into
> a state where its behavior cures the regressions in 2.16.0 without
> creating a divergence.
>
> The goal is to be sure that people upgrading from 2.14.2 to 2.16.1 to
> 2.18.0 will not have to change some things for the first upgrade, and
> change it back again for the second one.  So 2.16.1 should not veer off
> the course only to get back.  For 2.16.0, I failed in that endeavor.
>
> The patches I have marked "Backport" are those that I have to take into
> consideration when deciding how to best fix that failure in 2.16.1.  I
> won't take material into 2.16.1 that has not previously been released in
> an unstable release and seen some exposure.  And I have to guess at the
> likelihood that it will be reversed or partly reversed before 2.18.
>
> The simplest course would be to reverse all the line_count material to
> 2.15.40 behavior.  However, there are definitely some things (like the
> time signature stuff) where I am reasonably sure they'll stick around in
> this form (because not much else makes sense as we figured out), so
> moving forward from 2.16.0 rather than backward makes sense.
>
> For other things, I just don't know yet.

how can I help?
I can try my regtests with 2.14; I can also create some new ones.
and that reminds me to something I wanted but forgot to ask: can
a new regtest be versioned to an old one (or it must be added per
the current version)?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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!)

as a mathematician and programmer I find it natural that a chord
may be empty, but I'm confused by it having zero duration -
I'd have thought that duration is the property of the chord,
not of its elements.

>> This would allow people to write either:
>>   { c'1\< <>\! }
>>   { c'1\< z\! }
>> The non-timed null event z would be inserted after the previous
>> note (the c'1) is finished.
>
> I avoided s1*0 (maybe I subconsciously felt it was cheating) but find <>
> extremely useful

+1

> and use it a lot.  <>\pp^"pizz." \repeat unfold 3 c'4

great to know!  so long I used <> only at the end of an expression, and
just recently I've struggled with such repeats.
does anybody has a similar way (not a function) of marking just the first
note with a cautionary accidental?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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
>   dis4
>   \once\accidentalStyle teaching
>   \repeat unfold 7 cis
> }
>
>
> But maybe it would make sense checking the available accidental styles
> anyway: perhaps you actually want a different one throughout.

indeed; what I actually want is a blend of default and neo-modern:

{
  \repeat unfold 4 fisis8
  \repeat unfold 4 fis8 |
  \repeat unfold 4 f8
}

I'd like to get the sharp as in default, i.e. with a prepended natural,
and have a natural before the first f as in neo-moder.  I'm happy to
write it manually, but
\repeat unfold 4 f!8
puts a natural before all notes, so currently I have

{
  \repeat unfold 4 fisis8
  \repeat unfold 4 fis8 |
  f!8 \repeat unfold 3 f8
}

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Feature request

[Benkő Pál]

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@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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 and 0164.jpeg
(the former has examples for avoiding such stems too, using flags).

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [talk] easy tuplets

[Benkő Pál]

> 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's still a month left at least.

does a tremolo count as single note (see the Debussy examples earlier)?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>>> 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 "\tuplet n/2" or something else
(but that probably means only that I wouldn't use that shorthand).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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
>
>   \times 4/6 { b8 b b }
>
> this is mathematically perfect but the number you are asking to be
> printed is a confusing "3" and a confusing "6" respectively.

the first is not confusing: it makes sure to read
b16[ b] b[ b] b[ b]
instead of
b16[ b b] b[ b b].

I think I've actually seen such a triplet in Ligeti's Requiem;
will look tonight.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 I would have trouble coming up with a
> justification of using 3/2 here, actually seeing little point in doing
> so.  One could use something like \compressMusic 3/2 but I don't see
> much of a motivation for that.
>
> But with tuplets, the concept is not really "scale duration by x" but
> rather "n to m notes" including all the necessary visual changes, and
> \times, including its argument style, expresses this concept poorly.
>
> 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't think that there will be much of an opportunity confusing the
> behavior of \scaleDurations with \tuplet.

I, for one, consider \times a visually enhanced variant of \scaleDurations.
regardless how it's written, to me both mean metric change (and metric
is represented poorly in graphic anyway).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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't think that there will be much of an opportunity confusing the
>>> behavior of \scaleDurations with \tuplet.
>>
>> I, for one, consider \times a visually enhanced variant of \scaleDurations.
>> regardless how it's written, to me both mean metric change (and metric
>> is represented poorly in graphic anyway).
>
> Do you feel that the changed fraction gender of \tuplet would be a
> potential source of confusion for you in the light of your view of
> \scaleDurations?

definitely not, I'm fine with the \tuplet proposal, it mimics better the
engraved representation.  BTW do we still have \compressMusic or
only \scaleDurations?

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [GLISS] turning strings to symbols

[Benkő Pál]

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 latest when \tweak
> supports tweaking nested properties.  The problem with \tweak is that
> the syntax really leaves no good place for an optional grob spec.
>
> We basically have
>
> \tweak property-path value music
>
> We can't fit an optional argument before "value" as value can take on
> _any_ value and thus will fit the optional argument.  We can't put it
> _separately_ before property-path since property-path will fit fine
> there as well.  Fitting it before music currently means a restricted
> form of music, and then we have
>
> \tweak color #red Accidental cis
>
> which is not all too hot.  So I see really only two reasonably
> consistent solutions that both involve _not_ using \tweak for the
> grobbed variant:
>
> \tweakGrob Accidental color #red cis
>
> or
>
> \single \override Accidental color = #red cis
>
> since the latter is now available.  It is just more effort both for
> LilyPond and the user.

that last one makes me enthusiastic!
(and apologies for not reading the patch - the time I can spend with
LilyPond source is limited and needed for other projects.)

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Naming _another_ lacking puzzle piece

[Benkő Pál]

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 = #'no-flag
>   $notes
>   \revert Stem #'cross-staff
>   \revert Flag #'style
> #})
>
> There is a problem with that: in terms of stack operations, \override
> and \revert are not opposing pairs: \override is pop+push (so that
> multiple overrides in a row don't accrue cruft), \revert is pop.  So the
> net effect of this sequence is "pop", while it should be neutral.
>
> In the Scheme layer, we have the distinction between
> make-grob-property-set (corresponding to user command \override, pop+push)
> make-grob-property-override (not available as user command, just push)
> make-grob-property-revert (corresponding to user command \revert, just pop)
>
> So we need something like
>
> crossStaff =
> #(define-music-function (parser location notes) (ly:music?)
>   (_i "Create cross-staff stems")
>   #{
>   \temporary\override Stem #'cross-staff = #cross-staff-connect
>   \temporary\override Flag #'style = #'no-flag
>   $notes
>   \revert Stem #'cross-staff
>   \revert Flag #'style
> #})
>
> and, as a corrollary, \temporary\whatever and \undo\whatever will be a
> proper push/pop pair.
>
> Now I find \temporary a fitting name.  It is just a bit cumbersome to
> type.  \interim is hardly shorter, \adhoc seems a bit less descriptive.
>
> Opinions?  It might also be possible to do
>
> \temporary { \override Stem #'cross-staff = #cross-staff-connect
>  \override Flag #'style = #'no-flag }
>$notes
>
> and have this apply matching push/pop pairs around $notes.  It certainly
> would at least cater for the most common need of a non-first-popping
> push.  Perhaps we don't need both (at the current point of time, we
> don't have either, and the naming is inconsistent with
> make-grob-property-*), but as the crossStaff example shows, we need at
> least one of those options.

as a programmer I want a single push and wouldn't mind if pop+push
were two operations; I can't tell what a musician wants.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

> 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 this way.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>> 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 note it but forgot, sorry.  is there interest in pushing such
multi-commit patches to some dev branch?

> As for the commit message, it you changed it, i don't see the new one.
> You may want to try updating your git-cl with Julien Rioux's changes -
> they improve description handling and other things.

will look at it.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

>> > 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 commits is good style and makes things easier afterwards, but
> only few people will actively prefer reviewing changes in a branch over
> using Rietveld, so you can save yourself the trouble of creating a
> public branch unless someone asks for it.

I meant opening a Rietveld issue with all changes and an
announcement of a dev branch with several commits.

> Just make sure that every commit leaves the tree in compilable state.

of course.  I've verified that the pass-by-reference commit didn't
change the regtests.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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?  How is something "working" when
> it nullifies what the user is trying to do?

clefs: when specifying (-4 -2 0 2), you can use \clef alto or similar
to get a c-clef on the third line.  in other words: when I want to
LilyPond-ize ancient music using four- or six-line staff, the expected
representation is a standard staff reduced or expanded by a line.

I may well imagine that for some drumming applications the best
choice is a staff spaced by three, e.g. (-4 -1 2 5), because this way
every pitch in the range used is unambiguously assigned to a staff
line.  symmetrizing such a staff of even lines won't work at all.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: What happened to staging?

[Benkő Pál]

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 as master,
>> that is, the patches are no longer visible.
>>
>> What happenend to staging?
>
> I reset it upon James' request since he had pushed bad material.  Since
> his material was just at the top of staging, I found nothing wrong with
> doing that, expecting no significant consequences for anybody else.
>
> Looking at staging right now, it would seem that I messed this operation
> up, indeed rewinding the state fully to master rather than just backing
> out the problematic patch by James.
>
> James appears to have recommitted the work of his that I backed out too
> much.  I'll cherry-pick yours and Pál's changes back into staging, but
> probably the "pushed to staging as xxx" commits should be corrected in
> the wake of that.

thanks!
p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 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?  How is something "working" when
>>> it nullifies what the user is trying to do?
>>
>> clefs: when specifying (-4 -2 0 2), you can use \clef alto or similar
>> to get a c-clef on the third line.  in other words: when I want to
>> LilyPond-ize ancient music using four- or six-line staff, the expected
>> representation is a standard staff reduced or expanded by a line.
>
> And?  Why would looking at the line_count property then yield a wrong
> result?  You are specifying a missing line in the line positions, but
> the overriden line count would still lead to the same positioning of
> clefs.  Which would be exactly what was wanted.

sorry, David, I'm lost.  (-4 -2 0 2) and (-3 -1 1 3) yield different alto clefs,
I expect that, and that's why I prefer overriding line-positions to line-count.

>> I may well imagine that for some drumming applications the best
>> choice is a staff spaced by three, e.g. (-4 -1 2 5), because this way
>> every pitch in the range used is unambiguously assigned to a staff
>> line.
>
> A drum staff is not exactly going to need an alto clef.  Or a
> divisioMaior line.

agreed.  I meant this to be an independent argument to handle
asymmetric staves more gracefully, as such staves may need
rests, time signatures, repeat signs, slurs, and those would look
best like in tablature (= a staff with staff-space = 1.5).  this patch
is an independent element of a set of several such patches.
(it started as one patch, then got reverted as a whole.)

> I really have a hard time seeing just _what_ improvements we get over
> the 2.14 behavior.  Is there any _real_ _existing_ problem that now
> works better than before?

I never use divisioMaior, so can't speak about that.
I had real existing problems with rests which launched
me on this crusade against line_count a year ago.
time signatures don't work the 2.14 way, as you admitted in
http://code.google.com/p/lilypond/issues/detail?id=2783#c35

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2966 - Patch-push

[Benkő Pál]

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.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.17.10 regtests

[Benkő Pál]

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 there is now a bracket ligature
> above the notes

see
http://code.google.com/p/lilypond/issues/detail?id=3037#c5
an improved (?) regtest is at
http://code.google.com/p/lilypond/issues/detail?id=3037#c10
or
https://codereview.appspot.com/7103052

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How should tupletSpannerDuration actually work?

[Benkő Pál]

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
>>
>>
>
>
> 
>
>
>> \version "2.16.0"
>>
>> \relative c' {
>>  \set tupletSpannerDuration = #(ly:make-moment 1 2)
>>  \times 2/3 { c8 d e f g a g f e d c d }
>>  \set tupletSpannerDuration = #(ly:make-moment 1 4)
>>  \times 2/3 { c4 d e f g a g f e d c d }
>> }
>>
>
>
> 
>
>
>>
>> useful:

the tuplet bracket over the crotchets is what the client asked for,
so while I too consider it useless, there may be not too much
to do about it.

the first example is more serious, it shows a shortcoming of
default beaming: it can't distinguish between sextuplet and
(subdivided) triplet (contrary to the NOTE in the header of
time-signature-settings.scm).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.17.10 regtests

[Benkő Pál]

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 used in mensural notation (engraving ambitus
with mensural noteheads or Gregorian pes ligature, anyone?).
the closest real-life example would be engraving an ambitus
and incipit for a modern edition of a renaissance piece, I think.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 lot smarter than
> me, that would seem to require a pointer to the actual function be
> stored in every Audio_note object.  Then every user would need extra
> memory for every note, but would get no benefit.

no, pointer to the actual function is stored in a per-type (not
per-object) table,
the object stores a single pointer to the per-type function table,
and that pointer is needed anyway for a type with virtual members.
(btw I thought without checking that to_string is inherited from a
(very low level) base and now I can't easily check whether it's
really so - is it?)

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: vertical positioning of full measure rests

[Benkő Pál]

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-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 willing to count how _often_ this
> question pops up, and how often people get confused trying to get score
> and Midi to look and sound right?
>
> It is not all that hard to explain, but it is one thing that new users
> and helpful experienced users should not be wasting hours with.  And
> make no mistake, they are.

I think we have to keep the two parameters to distinguish between
transposing written c' to sounding f (standard horn notation in treble clef)
or f' (standard horn notation in bass clef).

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Benkő Pál]

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 have a command
>>>
>>> \transposing f { ... }
>>>
>>> (better naming suggestions welcome) that does transposition and Midi
>>> correction in lockstep?  Is anybody willing to count how _often_ this
>>> question pops up, and how often people get confused trying to get score
>>> and Midi to look and sound right?
>>>
>>> It is not all that hard to explain, but it is one thing that new users
>>> and helpful experienced users should not be wasting hours with.  And
>>> make no mistake, they are.
>>
>> I think we have to keep the two parameters to distinguish between
>> transposing written c' to sounding f (standard horn notation in treble clef)
>> or f' (standard horn notation in bass clef).
>
> Wouldn't that be covered by using
> \transposing f (notation in treble clef, written c' is f) vs
> \transposing f' (notation in bass clef, written c' is f') ?

yes, of course, sorry for the confusion.
p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel