On 2023-12-27 10:51 pm, Werner LEMBERG wrote:
Well, both `#+3` and `#-3` work, so it might be tempting to assume
that `+3` and `-3` also work (outside of `\markup`).
So does ##e+3.0 and so does #3/1 so should we be supporting those as
well?
The former? Rather not. The latter, maybe. I can
>> Well, both `#+3` and `#-3` work, so it might be tempting to assume
>> that `+3` and `-3` also work (outside of `\markup`).
>
> So does ##e+3.0 and so does #3/1 so should we be supporting those as
> well?
The former? Rather not. The latter, maybe. I can imagine that
people would like to sa
Werner LEMBERG writes:
>>> Can you imagine any other use for `+` right before numbers?
>>> Otherwise I suggest to make it work, to provide the least surprise
>>> for users.
>>
>> Do we say anywhere that `+` is a sign in LilyPond syntax? Where
>> doe
>> Can you imagine any other use for `+` right before numbers?
>> Otherwise I suggest to make it work, to provide the least surprise
>> for users.
>
> Do we say anywhere that `+` is a sign in LilyPond syntax? Where
> does the surprise come from?
Well, both `#+3` and
Werner LEMBERG writes:
>>> This works:
>>>
>>> ```
>>> { \ottava -1 c }
>>> ```
>>>
>>> while this fails:
>>>
>>> ```
>>> { \ottava +1 c'' }
>>> ```
>>>
>>> Is there a t
>> This works:
>>
>> ```
>> { \ottava -1 c }
>> ```
>>
>> while this fails:
>>
>> ```
>> { \ottava +1 c'' }
>> ```
>>
>> Is there a technical reason for it?
>
> As far as LilyPond is concerned, `+`
Werner LEMBERG writes:
> This works:
>
> ```
> { \ottava -1 c }
> ```
>
> while this fails:
>
> ```
> { \ottava +1 c'' }
> ```
>
> Is there a technical reason for it?
As far as LilyPond is concerned, `+` is not a part of numbers. Is there
a comp
This works:
```
{ \ottava -1 c }
```
while this fails:
```
{ \ottava +1 c'' }
```
Is there a technical reason for it?
Werner
Le 25/03/2022 à 15:28, Lukas-Fabian Moser a écrit :
I don't see one either, but there appear to be scores in the wild that
use them (I saw an example on the user list, which is what triggered
the original post). The question is whether we consider it fine to
start giving an error on them (it
I don't see one either, but there appear to be scores in the wild that
use them (I saw an example on the user list, which is what triggered
the original post). The question is whether we consider it fine to
start giving an error on them (it's not a fatal error, doesn't prevent
compilation of th
ere is a case for accepting it.
If we consider this change good, it should be advertised in the
Changes document. If not, it should be undone, and preferably
we'd be consistent and convert-ly would start accepting such
partial version numbers. I'm still on the fence, but given
the imm
Am 22.03.2022 um 12:57 schrieb Jean Abou Samra:
Hi,
With https://gitlab.com/lilypond/lilypond/-/merge_requests/1187,
I introduced a change that I didn't notice: something like
\version "2.23"
is now an error. It is accepted with current released versions.
On the other hand, convert-ly has alwa
On Mar 22, 2022, at 07:57, Jean Abou Samra wrote:
>
> Hi,
>
> With https://gitlab.com/lilypond/lilypond/-/merge_requests/1187,
> I introduced a change that I didn't notice: something like
>
> \version "2.23"
>
> is now an error. It is accepted with current released versions.
> On the other han
Hi,
With https://gitlab.com/lilypond/lilypond/-/merge_requests/1187,
I introduced a change that I didn't notice: something like
\version "2.23"
is now an error. It is accepted with current released versions.
On the other hand, convert-ly has always rejected such version
strings. Should we accep
ance in the
> most common case. (-> current or MR)
Clarification: (3) may be a disadvantage of the example that has been labeled
"Gould," but I don't believe that we have found a start-of-line example in
Behind Bars. I think we could address both (1) and (3) by leaving
start-o
On 15/11/20 15:14, Werner LEMBERG wrote:
> As Jonas said, this is a completely different issue, but yes, I think
> there implementing bar-centered bar numbers would need a completely
> different implementation.
IF this is seriously considered, can I throw in my thing often
encountere
On 15/11/20 14:53, Werner LEMBERG wrote:
>
>> I appreciate that you have given a nuanced response. Practically
>> speaking, the vast majority of scores only have bar numbers at the
>> beginning of a line, so I will simplistically categorise your response
>> as in f
ne definitely feels
wrong - I was taught to count rests by counting the bar number on the
last beat: 1 2 3 1 1 2 3 2 1 2 3 3 etc, so yes the bar number would
appear to apply to the wrong bar ...
Bear in mind we put rehearsal marks (including bar number marks)
centre-justified by default, so why no
t;>>> This discussion/development/enhancement — which is happening just
>>>> after a thread on the FB group about centred measure numbers — has
>>>> made me wonder if it’s possible to roll measure-centred measure
>>>> numbers into the actual BarNumber code [i
Hi all,
> Looks like my recollection was wrong here: In most *classical* scores.
> The medleys of film music that I played in (hobby) orchestras mostly
> use rehearsal marks and / or bar numbers *below* bar lines.
Yes.
>> Measure-centred bar numbers are fairly standard in film
ppening just
> > > after a thread on the FB group about centred measure numbers — has
> > > made me wonder if it’s possible to roll measure-centred measure
> > > numbers into the actual BarNumber code [instead of forcing people to
> > > (ab)use MeasureCounter]…
>
Am Sonntag, den 15.11.2020, 10:14 -0500 schrieb Kieren MacMillan:
> Hi Jonas,
>
> > I think that's a totally different topic and not actually related to
> > positioning the usual bar numbers that are above the bar line in all
> > scores that I ever played from.
lution for which that is an argument.
>
> 1. putting the bar number over the measure it belongs just makes sense
> (-> Gould)
>
> 2. The end of a measure is typically less crowded so middle-of-line bar
> numbers need less vertical shifts for collision avoidance which looks
>
> Those are included in the examples purely for the sake of completeness.
> Gould has nothing to say about such bar numbers and I would surprised if
> any scores included them.
But is it possible that they have a different alignment with the current
code? In case a user turns them on, t
Hi Jonas,
> I think that's a totally different topic and not actually related to
> positioning the usual bar numbers that are above the bar line in all
> scores that I ever played from.
Why? We’re talking about selecting the position of usual bar numbers, right? I
think the user
> This discussion/development/enhancement — which is happening just
> after a thread on the FB group about centred measure numbers — has
> made me wonder if it’s possible to roll measure-centred measure
> numbers into the actual BarNumber code [instead of forcing people
At 15:08 on 15 Nov 2020, Jonas Hahnfeld wrote:
> Am Sonntag, den 15.11.2020, 10:04 -0500 schrieb Kieren MacMillan:
>> Hi all,
>>
>> This discussion/development/enhancement — which is happening just
>> after a thread on the FB group about centred measure numbers — ha
Am Sonntag, den 15.11.2020, 10:04 -0500 schrieb Kieren MacMillan:
> Hi all,
>
> This discussion/development/enhancement — which is happening just
> after a thread on the FB group about centred measure numbers — has
> made me wonder if it’s possible to roll measure-centred measure
Hi all,
This discussion/development/enhancement — which is happening just after a
thread on the FB group about centred measure numbers — has made me wonder if
it’s possible to roll measure-centred measure numbers into the actual BarNumber
code [instead of forcing people to (ab)use
> I would very much like that LilyPond has the ability of automatically
> adjusting the horizontal position of some grobs, in particular dynamic
> signs, bar numbers, and rehearsal marks. The idea is that a large
> delta from the optimum vertical position would make LilyP
ure it belongs just makes sense
(-> Gould)
2. The end of a measure is typically less crowded so middle-of-line bar
numbers need less vertical shifts for collision avoidance which looks
better. The new implementation looks irregular and jumpy (-> current)
3. In particular at the start of a
with today's releases of LilyPond and probably did for years.
There's no added code that makes this work.
The aim of the merge request is to change the alignment of mid-staff
bar numbers. They are not shown by default and in a different message
you wrote:
> Those are included in the ex
> I appreciate that you have given a nuanced response. Practically
> speaking, the vast majority of scores only have bar numbers at the
> beginning of a line, so I will simplistically categorise your response
> as in favour of keeping LilyPond's current behaviour.
I would ve
e given a nuanced response. Practically
speaking, the vast majority of scores only have bar numbers at the
beginning of a line, so I will simplistically categorise your response
as in favour of keeping LilyPond's current behaviour.
Kevin
On Sun, Nov 15, 2020 at 07:07:03AM -0600, David Nalesnik wrote:
> Another vote for Gould. (Though does she have anything to say about
> the normally unshown measure numbers which are stranded beyond the
> line here?)
Those are included in the examples purely for the sake of completene
ilypond/lilypond/-/merge_requests/447) and would
> like to request your comments on the proposed change. There doesn't
> seem to be an established standard for aligning bar numbers (see the
> various examples posted at the merge request link for some of the
> different ways
t; > Werner
> >
>
>
Another vote for Gould. (Though does she have anything to say about
the normally unshown measure numbers which are stranded beyond the
line here?)
David
Am 15.11.2020 um 12:36 schrieb Werner LEMBERG:
I will be the first responder and say that, of the options in the
pdf, I think Gould is the most appropriate.
Yep.
+1
Werner
> I will be the first responder and say that, of the options in the
> pdf, I think Gould is the most appropriate.
Yep.
Werner
On Sun, Nov 15, 2020 at 11:02:52AM +, Kevin Barry wrote:
> - if you have a preference for one of the four, please indicate which
I will be the first responder and say that, of the options in the pdf, I
think Gould is the most appropriate.
Kevin
Hi all,
LilyPond currently aligns all bar numbers on their right side, like in
this example (output attached):
\layout {
\context {
\Score
\override BarNumber.break-visibility = #all-visible
}
}
\repeat unfold 10 { c'1 }
I have found this to be confusing for musicians d
Hi,
I had a look into the unapproved LSR-snippet "Incrementing bar numbers
in volta repeats"
lsr.di.unimi.it/LSR/Item?u=1&id=1080
Imho, the output is plain wrong.
Valentin, it's obviously your snippet, may I ask you to fix it.
For now I added [needs correction] to th
, in part
> because it visibly sets arguments apart for easy parsing [by me].
>
> Not sure if that’s useful input for you?
>
Hi Kieren, Valentin,
I've shifted my practice the opposite direction of Kieren's, I suppose: I
omit # before numbers everywhere that it's poss
On 2/21/19, David Kastrup wrote:
> baba = -.4
Indeed. That’s probably rare enough that we could get away with a
@knownissues in the right place(s), though…
Right now, the new ability to have #-less numbers (and strings,
although my recent patch changes that) isn’t documented anywhere but
Valentin Villenave writes:
> Greetings,
>
> Alongside issue #5473, I’ve started investigating whether numbers
> still require to be prefixed with #.
In music, something like -.4 has entirely different meaning than in
layout blocks. To wit:
baba = -.4
\void \displayScheme #b
Hi Valentin,
> Or, we just don’t bother and keep using (and recommending) # everywhere.
> Thoughts?
I use # everywhere I can, even where it’s not strictly necessary, in part
because it visibly sets arguments apart for easy parsing [by me].
Not sure if that’s useful input for you?
Best,
Kieren.
Greetings,
Alongside issue #5473, I’ve started investigating whether numbers
still require to be prefixed with #.
AFAICS, the only ones that still do are in markups and all markups
commands, but hardly anywhere else; which _could_ make LilyPond syntax
a tiny bit easier to grasp for new users…
Or
2018-09-16 21:28 GMT+02:00 Dan Eble :
>> Real
>> Page_breaking::page_height (int page_num, bool last) const
>> {
>> // The caches allow us to store the page heights for any
>> // non-negative page numbers. We use a negative value in the
>> // cache to s
Never mind. I only focused on half the comments.
Sorry for the noise.
Carl
Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Isnt this talking about negative page heights, not negative page numbers?
Carl
Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lily
Am 16. September 2018 21:28:26 MESZ schrieb Dan Eble :
>> Real
>> Page_breaking::page_height (int page_num, bool last) const
>> {
>> // The caches allow us to store the page heights for any
>> // non-negative page numbers. We use a negative value in the
>
> Real
> Page_breaking::page_height (int page_num, bool last) const
> {
> // The caches allow us to store the page heights for any
> // non-negative page numbers. We use a negative value in the
> // cache to signal that that position has not yet been initialized.
>
LGTM
https://codereview.appspot.com/314300043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Simon Albrecht writes:
>
>> On 13.08.2016 10:29, David Kastrup wrote:
>>> \part.1 in contrast is slightly different. I'll work on improvements by
>>> and by but at the current point of time this is not really at a "proudly
>>> announceable by snippets" state. It still h
Simon Albrecht writes:
> On 13.08.2016 10:29, David Kastrup wrote:
>> \part.1 in contrast is slightly different. I'll work on improvements by
>> and by but at the current point of time this is not really at a "proudly
>> announceable by snippets" state. It still has drawbacks and irks.
>
> It s
On 13.08.2016 10:29, David Kastrup wrote:
\part.1 in contrast is slightly different. I'll work on improvements by
and by but at the current point of time this is not really at a "proudly
announceable by snippets" state. It still has drawbacks and irks.
It seems that others as well as I have b
Thomas Morley writes:
> Hi,
>
> http://lsr.di.unimi.it/LSR/Snippet?id=1044
> "Workaround for using numbers as part of Lilypond variable names"
> is a new snippet from a member of the german forum.
>
> I'd like to reject it for several reasons:
>
> 1. Th
Hi,
http://lsr.di.unimi.it/LSR/Snippet?id=1044
"Workaround for using numbers as part of Lilypond variable names"
is a new snippet from a member of the german forum.
I'd like to reject it for several reasons:
1. There's the possibility to use `identifier.1' with newer
At 18:24 on 01 Aug 2016, Trevor Daniels wrote:
>Mark, you wrote Monday, August 01, 2016 6:03 PM
>> At 14:21 on 01 Aug 2016, Phil Holmes wrote:
>>>If you create an account on SourceForge and let us have the details,
>>>I'll add you to the tracker users.
>>
>> username: mkdev
>> email: m...@opus11
Mark, you wrote Monday, August 01, 2016 6:03 PM
> At 14:21 on 01 Aug 2016, Phil Holmes wrote:
>
>>If you create an account on SourceForge and let us have the details,
>>I'll add you to the tracker users.
>
> username: mkdev
> email: m...@opus11.net
You're now a developer AFA SourceForge is con
At 14:21 on 01 Aug 2016, Phil Holmes wrote:
>If you create an account on SourceForge and let us have the details,
>I'll add you to the tracker users.
username: mkdev
email: m...@opus11.net
Thanks!
--
Mark Knoop
___
lilypond-devel mailing list
lilypon
- Original Message -
From: "Mark Knoop"
To: "Simon Albrecht"
Cc:
Sent: Monday, August 01, 2016 12:36 PM
Subject: Re: repeating bar numbers and rehearsal marks in frenched score
At 13:22 on 01 Aug 2016, Simon Albrecht wrote:
Am 01.08.2016 um 10:49 schrieb Mark K
At 13:22 on 01 Aug 2016, Simon Albrecht wrote:
>Am 01.08.2016 um 10:49 schrieb Mark Knoop:
> > James, could you test this patch for review please?
>
> Please create a tracker issue following the CG instructions, with
> yourself as owner and Patch:new, and upload the patch for review on
> Rietve
Am 01.08.2016 um 10:49 schrieb Mark Knoop:
> James, could you test this patch for review please?
Please create a tracker issue following the CG instructions, with
yourself as owner and Patch:new, and upload the patch for review on
Rietveld. Then James will test it.
Best, Simon
At 21:21 on 31 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> OK. Attached are two patches and a test case. The patches are two
>> alternate methods of approaching the problem.
>>
>> Keep a staff alive with multiple layers
>> ---
>>
>> This changes the re
Mark Knoop writes:
> On 29/07/16 18:09, Mark Knoop wrote:
>> I still think the easiest and most logical way to do this is with
>> the Keep_alive_together_engraver.
>>
>> Prior to the fix for issue 3518 (support for temporary divisi
>> staves), the Keep_alive_together_engraver was useful only in
>
On 29/07/16 18:09, Mark Knoop wrote:
> I still think the easiest and most logical way to do this is with
> the Keep_alive_together_engraver.
>
> Prior to the fix for issue 3518 (support for temporary divisi
> staves), the Keep_alive_together_engraver was useful only in
> Frenched scores, i.e. in co
s sort
>>> of ordering, the behavior of lower numbers does not depend on that
>>> of higher numbers. Any other solution would likely need to
>>> maintain that property.
>> I still think the easiest and most logical way to do this is with the
>> Keep_alive_toge
Hello,
On 29/07/16 18:09, Mark Knoop wrote:
At 16:41 on 29 Jul 2016, David Kastrup wrote:
I remember that the decision to sort the remove-layers numerically was
based on the desire not to have logical circles: with this sort of
ordering, the behavior of lower numbers does not depend on that of
At 16:41 on 29 Jul 2016, David Kastrup wrote:
>I remember that the decision to sort the remove-layers numerically was
>based on the desire not to have logical circles: with this sort of
>ordering, the behavior of lower numbers does not depend on that of
>higher numbers. Any other so
ogical circles: with this sort of
ordering, the behavior of lower numbers does not depend on that of
higher numbers. Any other solution would likely need to maintain that
property.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
At 14:11 on 29 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> At 11:26 on 29 Jul 2016, David Kastrup wrote:
>>>Mark Knoop writes:
At 22:09 on 28 Jul 2016, David Kastrup wrote:
>What you are looking for, however, is a
>class of simple omission problems. Maybe we can solv
Mark Knoop writes:
> At 11:26 on 29 Jul 2016, David Kastrup wrote:
>>Mark Knoop writes:
>>> At 22:09 on 28 Jul 2016, David Kastrup wrote:
What you are looking for, however, is a
class of simple omission problems. Maybe we can solve this
completely differently? Like using "alignAbove
At 11:26 on 29 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> At 22:09 on 28 Jul 2016, David Kastrup wrote:
>>>What you are looking for, however, is a
>>>class of simple omission problems. Maybe we can solve this
>>>completely differently? Like using "alignAboveContext" being given
>>>the
Mark Knoop writes:
> At 22:09 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop writes:
>>> I'm sorry, I am trying to progress this and respond to your
>>> suggestions, but it would be nice to receive some proper criticism of
>>> my (working) code which amounts to more than just "I don't like
>>
At 22:09 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> I'm sorry, I am trying to progress this and respond to your
>> suggestions, but it would be nice to receive some proper criticism of
>> my (working) code which amounts to more than just "I don't like
>> it".
>
>It makes stuff m
At 13:08 on 28 Jul 2016, tisimst wrote:
>Forgive me if this is the wrong place to ask this question, but can
>the new code handle nested situations?
>
>For example, let's say we have four horns. These may appear on their
>own staff, they may appear on a combined staff (e.g., "Horns 1 & 2"),
>and th
Mark Knoop writes:
> At 21:03 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop writes:
>>> I'm also unclear as to why you feel that this is unsuitable to be
>>> done by the Keep_alive_together_engraver without further nesting.
>>> After all, the documentation for this engraver states:
>>>
>>>
y, the nesting might appear like this (using those properties):
(Top-most combined staff): Staff.make-dead-with = #'(pair-one-staff
pair-two-staff)
(Middle paired staff): Staff.make-dead-with = #'(individual-one-staff
indvidual-two-staff)
(Bottom individual staff): Staff.keep-alive-with = #
At 21:03 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> I'm also unclear as to why you feel that this is unsuitable to be
>> done by the Keep_alive_together_engraver without further nesting.
>> After all, the documentation for this engraver states:
>>
>> These spanners are then ti
Mark Knoop writes:
> I'm also unclear as to why you feel that this is unsuitable to be done
> by the Keep_alive_together_engraver without further nesting. After all,
> the documentation for this engraver states:
>
> These spanners are then tied together so that one will be removed
> only
At 19:49 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> At 17:43 on 28 Jul 2016, David Kastrup wrote:
>>>At any rate, I think the principal problem is that the
>>>Keep_alive_together_engraver is desired to keep the marks context
>>>alive with _either_ of the two voices under it. That
Mark Knoop writes:
> At 17:43 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop writes:
>>> OK, here's a patch using only the remove-layer property with these
>>> values:
>>>
>>> - #f: ignored by Keep_alive_together_engraver
>>> - -1: kept alive by any other layer
>>
>>Isn't that the same as '()
At 17:43 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> OK, here's a patch using only the remove-layer property with these
>> values:
>>
>> - #f: ignored by Keep_alive_together_engraver
>> - -1: kept alive by any other layer
>
>Isn't that the same as '() ?
Well no, because of the nex
Mark Knoop writes:
> OK, here's a patch using only the remove-layer property with these
> values:
>
> - #f: ignored by Keep_alive_together_engraver
> - -1: kept alive by any other layer
Isn't that the same as '() ?
> - integer != -1: current usage
> - unspecified: kept alive by all but ignored
At 10:52 on 28 Jul 2016, Mark Knoop wrote:
>At 09:59 on 28 Jul 2016, David Kastrup wrote:
>>It seems like an ad-hoc band-aid with limited utility. I'd rather see
>>something covering more use cases.
>
>Regardless of the merits of this solution, I not sure about it
>having limited utility. Repeatin
At 09:59 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop writes:
>> At 06:21 on 28 Jul 2016, James Lowe wrote:
>>>On 27/07/16 17:39, Mark Knoop wrote:
Once again further to this thread (see below) I've attempted a
patch (attached) to the Keep_alive_together_engraver which makes
thi
Mark Knoop writes:
> Hi James,
>
> At 06:21 on 28 Jul 2016, James Lowe wrote:
>>Hello Mark,
>>
>>On 27/07/16 17:39, Mark Knoop wrote:
>>> Once again further to this thread (see below) I've attempted a patch
>>> (attached) to the Keep_alive_together_engraver which makes this
>>> work, at least for
Hi James,
At 06:21 on 28 Jul 2016, James Lowe wrote:
>Hello Mark,
>
>On 27/07/16 17:39, Mark Knoop wrote:
>> Once again further to this thread (see below) I've attempted a patch
>> (attached) to the Keep_alive_together_engraver which makes this
>> work, at least for my use case. There might well b
Hello Mark,
On 27/07/16 17:39, Mark Knoop wrote:
Once again further to this thread (see below) I've attempted a patch
(attached) to the Keep_alive_together_engraver which makes this work, at
least for my use case. There might well be a better approach, feedback
would be appreciated.
Possibly th
Once again further to this thread (see below) I've attempted a patch
(attached) to the Keep_alive_together_engraver which makes this work, at
least for my use case. There might well be a better approach, feedback
would be appreciated.
Possibly the keep-alive-with-id property should be a string (or
James wrote Saturday, September 19, 2015 4:51 PM
> On 19/09/15 16:32, Trevor Daniels wrote:
>>
>> James wrote Saturday, September 19, 2015 4:18 PM
>>
>>> Sorry that it seems to have removed/hidden the comments. On that point,
>>> I am not seeing that problem when I edit issues, I know that oth
On 19/09/15 16:32, Trevor Daniels wrote:
>
> James wrote Saturday, September 19, 2015 4:18 PM
>
>> Sorry that it seems to have removed/hidden the comments. On that point,
>> I am not seeing that problem when I edit issues, I know that others have
>> reported it, but it hasn't been apparent to me.
James wrote Saturday, September 19, 2015 4:18 PM
> Sorry that it seems to have removed/hidden the comments. On that point,
> I am not seeing that problem when I edit issues, I know that others have
> reported it, but it hasn't been apparent to me.
Well, it should be apparent to you now. It look
herwise there is no indication there
> is any discussion. (I've done it for this one, but not for any of the
> others.)
>
> Trevor
>
> - Original Message -
> From: "pkx166h"
> To: "Ticket 509" <5...@issues.testlilyissues.p.re.sf
his one, but not for any of the others.)
Trevor
- Original Message -
From: "pkx166h"
To: "Ticket 509" <5...@issues.testlilyissues.p.re.sf.net>
Sent: Saturday, September 19, 2015 1:11 PM
Subject: [testlilyissues:issues] #509 collision nested tuplet numbers
https://codereview.appspot.com/106320046/diff/1/Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly
File
Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly
(right):
https://codereview.appspot.com/106320046/diff/1/Documentation
LGTM, save a small remark.
https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm#newcode1287
scm/define-grob-properties.scm:1287: containi
Thanks Trevor.
https://codereview.appspot.com/151230044/diff/40001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
https://codereview.appspot.com/151230044/diff/40001/Documentation/notation/spacing.itely#newcode1000
Documentation/notation/spacing.itely:10
LGTM, Valentin, apart from a trivial nit-pick.
Trevor
https://codereview.appspot.com/151230044/diff/40001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
https://codereview.appspot.com/151230044/diff/40001/Documentation/notation/spacing.itely#newcode100
1 - 100 of 279 matches
Mail list logo
