> I'm only familiar with a subset of C++ up to C++03. Would my lack of
> knowledge of modern C++ exclude me from being a contributor?
No. Others will review your code and suggest using new features where it is
appropriate.
> I'm also not an expert on UB in C++, although I very much want to avo
> In scores I've seen with circled tablature numbers, collisions between
> numbers and circles are avoided by shifting numbers out of a straight
> vertical column, which I suspect is quite different than how tablature is
> currently handled internally and might require significant effort to
> i
Hi,
Am Fr., 7. Okt. 2022 um 07:44 Uhr schrieb tk5wbps2--- via Discussions
on LilyPond development :
>
> I'm considering contributing to lilypond.
>
welcome to the pond
>
> The two features I propose are as follows.
>
> 1) An option to include rests in tablature (with \
I'm considering contributing to lilypond. The two features I propose are as
follows.
1) An option to include rests in tablature (with \tabFullNotation).
2) An alternative tablature full notation style that more closely resembles
standard notation note heads and stems. To my knowledge
I'm considering contributing to lilypond. The two features I propose are as
follows.
1) An option to include rests in tablature (with \tabFullNotation).
2) An alternative tablature full notation style that more closely resembles
standard notation note heads and stems. To my knowledge
attached to an empty whole rest
> > measure. Works just fine with a chord symbol attached to a single quarter
> > rest, for example, even in a measure of only quarter rests. Would a
> simple
> > modification to the musicxml2ly python file fix this? I've modified other
> &g
, for example, even in a measure of only quarter rests. Would a simple
modification to the musicxml2ly python file fix this? I've modified other
things successfully in that file so I don't mind trying on my own if anyone
has a hint. Attached are the two different cases I've mention
Hello!
It seems that musicxml2ly won't create a chordname if the corresponding
harmony element in the musicxml file is attached to an empty whole rest
measure. Works just fine with a chord symbol attached to a single quarter
rest, for example, even in a measure of only quarter rests. Wo
On 2020/05/09 18:30:04, Dan Eble wrote:
> Yes, that's what I was trying to explain.
> internal_line_count() is relevant to one branch only.
Oh, I see your point now. I thought I could get away with line_count
only, but indeed this fails to account for (hypothetical) cases where
the line-positions
On 2020/05/09 18:14:40, Valentin Villenave wrote:
> I do, however, worry about the comment before (what used to be) the
> internal_line_count() definition:
>
> // Get the line-count property directly. This is for internal use
when it is
> // known that the line-positions property is not relevant.
On 2020/05/09 12:47:29, Dan Eble wrote:
>
https://codereview.appspot.com/576090043/diff/569740045/lily/staff-symbol.cc
> File lily/staff-symbol.cc (right):
>
>
https://codereview.appspot.com/576090043/diff/569740045/lily/staff-symbol.cc#newcode116
> lily/staff-symbol.cc:116: return ly_scm2floatvec
https://codereview.appspot.com/576090043/diff/569740045/lily/staff-symbol.cc
File lily/staff-symbol.cc (right):
https://codereview.appspot.com/576090043/diff/569740045/lily/staff-symbol.cc#newcode116
lily/staff-symbol.cc:116: return ly_scm2floatvector (line_positions);
The suggested patch to exp
On 2020/05/09 01:42:54, Dan Eble wrote:
> I looked around. This is the only place I found using just the size
of the
> vector. I don't think it's worth adding and maintaining a
> Staff_symbol::line_count just for this case.
Well, it wouldn’t be "adding and maintaining" since it already exists as
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc#newcode268
lily/multi-measure-rest.cc:268: bool oneline = (!staff) ||
Staff_symbol::line_
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc#newcode268
lily/multi-measure-rest.cc:268: bool oneline = (!staff) ||
Staff_symbol::line_
On May 7, 2020, at 11:12, v.villen...@gmail.com wrote:
> No, I actually want oneline to be true . I did consider changing the
> variable name to no_multiple_lines, because that’s what it’s really
> about. I also considered adding a comment such as:
> // If there is no StaffSymbol, print MMrests on
Here's a thought.
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc#newcode268
lily/multi-measure-rest.cc:268: bool oneline = (!staff) ||
S
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc#newcode268
lily/multi-measure-rest.cc:268: bool oneline = (!staff) ||
Staff_symbol::line_
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/576090043/diff/557790043/lily/multi-measure-rest.cc#newcode268
lily/multi-measure-rest.cc:268: bool oneline = (!staff) ||
Staff_symbol::line_
On Apr 27, 2019, at 07:31, David Kastrup wrote:
>
> But we are talking about a \fermata on an _uncompressed_ multimeasure
> rest here. If the compression leaves just a single rest, placing the
> fermata does not pose a conundrum to typesetting (it may pose one to the
> musician but that's entire
On Apr 27, 2019, at 04:54, d...@gnu.org wrote:
>
> Multimeasure rests can be split into multiple rests and across lines.
> That's what makes then a Spanner rather than an Item and is the main
> cause of this complication. How are you dealing with such a split? A
> fermata
Dan Eble writes:
> On Apr 27, 2019, at 04:54, d...@gnu.org wrote:
>>
>> Multimeasure rests can be split into multiple rests and across lines.
>> That's what makes then a Spanner rather than an Item and is the main
>> cause of this complication. How are y
Multimeasure rests can be split into multiple rests and across lines.
That's what makes then a Spanner rather than an Item and is the main
cause of this complication. How are you dealing with such a split? A
fermata only makes sense on the last such rest, most text markups make
sense on
fine-music-types.scm:317: . ((description . "Articulations on
multi measure rests.")
On 2019/04/19 15:34:25, lemzwerg wrote:
multi measure → multi-measure
Yep. Same at line 338 and 329, that’ll be part of the next patch set.
Description:
add articulation support to multi measure rests
610043/scm/define-music-types.scm#newcode317
scm/define-music-types.scm:317: . ((description . "Articulations on
multi measure rests.")
multi measure → multi-measure
https://codereview.appspot.com/562710043/
___
lilypond-devel mailing list
li
I’ll change the width of 8th and 16th flags (see
https://lists.gnu.org/archive/html/lilypond-devel/2018-02/msg00107.html)
in another issue.
https://codereview.appspot.com/336590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gn
On 2018/02/23 11:41:13, Malte Meyn wrote:
Probably that won’t be enough, it has to be 7,8 → 4 and 9,10 → 5; but
the idea
is correct. Maybe I’ll replace the cond by an if and case ;)
Ah, yes, it's true that the rest height is identical for 128th/256th and
512th/1024th, therefore my "calculated
On 2018/02/23 12:09:34, pkx166h wrote:
Are we simply seeing another symptom of something I (when patch
testing) have to
now ignore?
See the thread:
https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00013.html
No. But I’ll put this patch on needs_work now because it does need wo
On 2018/02/23 11:18:38, Be-3 wrote:
On 2018/02/23 07:30:00, lemzwerg wrote:
> LGTM, thanks!
In my opinion, there's a misplacement of rest dots. Therefore,
file scm/output-lib.scm (dots::calc-staff-position)
will have to be adapted, too (see related image and comment in issue
#5277)
The
e
#5277)
Thanks for the hint! I looked for it at every single C++ file that has
to do with rests or dots but didn’t know or think about output-lib.scm
There's no appropriate code for log > 7 (the new rest glyphs)
My suggestion:
- ((= log 7) 4)
+ ((>= log 7) (- log 3));
T
On 2018/02/23 07:30:00, lemzwerg wrote:
LGTM, thanks!
In my opinion, there's a misplacement of rest dots. Therefore,
file scm/output-lib.scm (dots::calc-staff-position)
will have to be adapted, too (see related image and comment in issue
#5277)
There's no appropriate code for log > 7 (the new
LGTM, thanks!
https://codereview.appspot.com/336590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
fixed too) but
at the moment I’m not able to make doc for testing (see list).
Description:
add glyphs for 256th, 512th and 1024th flags and rests
This post on lilypond-user asks for small rhythmic values (though it
doesn’t explicitely mention rests and unbeamed/flagged notes):
https://lists.gnu.org
I suggest to update regtests ‘markup-rest.ly’ and
‘markup-rest-styles.ly’ as well.
If no glyph for a certain style is found the default is taken anyway,
but it would be nice if the new glyphs would be demonstrated via markup
as well.
Also, it deserves an entry in changes, imho.
https://codereview
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
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 beha
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
LGTM
https://codereview.appspot.com/333970043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2017/08/29 07:55:06, dak wrote:
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10
Doc
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10
Documentation/notation/simultaneous.itely:
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10
Documentation/notation/simultaneous.itely:
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10
Documentation/notation/simultaneous.itely:
On 2017/08/28 16:01:36, thomasmorley651 wrote:
On 2017/08/28 15:18:06, dak wrote:
>
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm
> File scm/scheme-engravers.scm (right):
>
>
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm#newcode121
> scm/
On 2017/08/28 15:18:06, dak wrote:
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm
File scm/scheme-engravers.scm (right):
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm#newcode121
scm/scheme-engravers.scm:121: (define-public (Merge_rests_eng
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm
File scm/scheme-engravers.scm (right):
https://codereview.appspot.com/324310043/diff/1/scm/scheme-engravers.scm#newcode121
scm/scheme-engravers.scm:121: (define-public (Merge_rests_engraver
context)
Stupid question: is ther
Reviewers: ,
Message:
Please review.
Does this engraver needs an entry via ly:register-translator like the
Measure_counter_engraver in the same file (scheme-engravers.scm)?
Description:
Let Merge_rests_engraver deal with dotted rests
Compare simple rests by their duration-length, duration-log
/simultaneous.itely:917: parts. This can be
accomplished using the merge rests engraver.
On 2017/06/12 07:40:42, thomasmorley651 wrote:
I'd use the name, i.e. "Merge_rests_engraver"
In that case I'd write
using @code{Merge_rests_engraver}
namely omitting "the".
https://co
/321930043/diff/160001/Documentation/notation/simultaneous.itely#newcode917
Documentation/notation/simultaneous.itely:917: parts. This can be
accomplished using the merge rests engraver.
I'd use the name, i.e. "Merge_rests_engraver"
https://codereview.appspo
(rests-all-unpitched rests)
This will catch not only pitched rests, but also rests where the user
has set Rest.staff-position.
I tend to agree with it, although rests where the user changed 'Y-offset
or 'extra-offset are not taken into account. We can't foresee any of
those possib
On 2017/05/27 20:03:43, horndude77 wrote:
> On 2017/05/21 17:12:26, thomasmorley651 wrote:
> > I'd like to mention another point:
> > What to do with pitched rests and rests with user-set
staff-position, merge
> them
> > automatically to the zero-position?
>
&g
On 2017/05/21 17:12:26, thomasmorley651 wrote:
> I'd like to mention another point:
> What to do with pitched rests and rests with user-set
staff-position, merge
them
> automatically to the zero-position?
If a user has explicitly set the position of a rest this should be
lypond/2015-08/msg00080.html
>
> Would it work to set 'stencil of all of the cdr to point-stencil?
Using point-stencil causes odd alignment issues with text connected to
multimeasure rests. Making them invisible doesn't have this issue.
Would that
solve the above potential probl
On 2017/05/21 17:12:26, thomasmorley651 wrote:
I'd like to mention another point:
What to do with pitched rests and rests with user-set staff-position,
merge them
automatically to the zero-position?
If a user has explicitly set the position of a rest this should be
honoured
by defau
I'd like to mention another point:
What to do with pitched rests and rests with user-set staff-position,
merge them automatically to the zero-position?
I'd say using suspendRestMerging-property is sufficient to cover this
case, but this is only me. Other opinions?
https://codereview.a
gt;(eqv? (rest-len rest-a) (rest-len rest-b)
> (mmrest-same-length (rest-eqv 'measure-count))
> (rest-same-length (rest-eqv 'duration-log)))
>
> (define (merge-mmrests rests)
> ...
>
Interesting. I didn't run into that error. I&#x
t-eqv 'measure-count))
(rest-same-length (rest-eqv 'duration-log)))
(define (merge-mmrests rests)
...
Interesting. I didn't run into that error. I'm using the latest lilydev
which is using guile 2. That could be the difference. In any case I've
removed
Looks much better -- see comments below.
https://codereview.appspot.com/321930043/diff/11/scm/scheme-engravers.scm
File scm/scheme-engravers.scm (right):
https://codereview.appspot.com/321930043/diff/11/scm/scheme-engravers.scm#newcode167
scm/scheme-engravers.scm:167: (lambda (rest) (ly
est-same-length (rest-eqv 'duration-log)))
(define (merge-mmrests rests)
...
https://codereview.appspot.com/321930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/321930043/diff/60001/ly/init.ly
File ly/init.ly (right):
https://codereview.appspot.com/321930043/diff/60001/ly/init.ly#newcode36
ly/init.ly:36: #(use-modules (scm merge-rests-engraver))
On 2017/05/18 14:15:23, david.nalesnik wrote:
I'm not sure why yo
https://codereview.appspot.com/321930043/diff/60001/scm/merge-rests-engraver.scm
File scm/merge-rests-engraver.scm (right):
https://codereview.appspot.com/321930043/diff/60001/scm/merge-rests-engraver.scm#newcode10
scm/merge-rests-engraver.scm:10: (define (rest-length rest)
This definition is
On 14 May 2017 at 06:15, Jay Anderson wrote:
>
> https://codereview.appspot.com/321930043/
>
> It was requested sometime last year that I attempt to get this into
> lilypond proper this is my attempt. It creates a scheme module for putting
> all of the merge rest functionality. I didn't see any pr
https://codereview.appspot.com/321930043/diff/60001/ly/init.ly
File ly/init.ly (right):
https://codereview.appspot.com/321930043/diff/60001/ly/init.ly#newcode36
ly/init.ly:36: #(use-modules (scm merge-rests-engraver))
I'm not sure why you are defining a separate module. The usual
proc
Passes make, make check and a full make doc.
https://codereview.appspot.com/321930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Wed, May 17, 2017 at 2:01 AM, Trevor Daniels
wrote:
>
> Did you register git-cl in your account at SourceForge and obtain a bearer
> token?
> See "Authorizing git-cl for the LilyPond issue tracker" as the next step
> in configuring git-cl
> in http://lilypond.org/doc/v2.19/Documentation/contri
Jay Anderson wrote Wednesday, May 17, 2017 7:31 AM
> Thanks. When I ran `git cl upload origin/master` it wasn't able to associate
> the patch with an issue:
> We were not able to associate this patch with a tracker issue.
> Please enter a valid tracker issue number
> (or enter nothing to create
Hi Jay, you wrote Sunday, May 14, 2017 5:15 AM
> When running git-cl it failed to create a new ticket number to track the
> issue (the instructions say I need to request access:
> http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl#configuring-git_002dcl).
> There is an existing is
https://codereview.appspot.com/321930043/
It was requested sometime last year that I attempt to get this into
lilypond proper this is my attempt. It creates a scheme module for putting
all of the merge rest functionality. I didn't see any precedent for this,
so let me know concerns. If this approa
her term for the style using church rests, "a rest bar takes the space
the
graphic symbol needs ..." (Behind Bars, p.565). Although she goes on
to
recommend against "tradition engraving," it seems that the bars should
be sized
to the rests, not the other way around.
On 2016/12/31 17:22:56, david.nalesnik wrote:
Please see
http://www.mail-archive.com/lilypond-user@gnu.org/msg117437.html
I believe I've done my part in raising the question about defaults.
I'll leave the decision to the more informed.
https://codereview.appspot.com/319910043/
___
Please see
http://www.mail-archive.com/lilypond-user@gnu.org/msg117437.html
https://codereview.appspot.com/319910043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
her term for the style using church rests, "a rest bar takes the space
the
graphic symbol needs ..." (Behind Bars, p.565). Although she goes on
to
recommend against "tradition engraving," it seems that the bars should
be sized
to the rests, not the other way around.
Se
On 2016/12/29 17:47:46, david.nalesnik wrote:
Please review. Thanks!
I haven't reviewed the code, but the description makes me wonder, is the
current behavior not a bug? Gould says "In tradition engraving," which
appears to be her term for the style using church rests, "
Reviewers: ,
Message:
Please review. Thanks!
Description:
Allow fixed spacing of symbols in church rests
By default, the symbols making up a church rest are spread to fill
the available space in a measure.
Setting the new property "church-rest-inner-padding" places symbols
at
On 2015/10/10 07:35:59, dak wrote:
On 2015/10/10 01:50:28, Dan Eble wrote:
> When I change my start_mmrest() to set "duration" instead of
"length", the bug
> in part-combine-solo-end.ly reappears. I am using
> Duration().compressed(length.main_part_).smobbed_copy() as the
duration.
Well, he
On 2015/10/10 01:50:28, Dan Eble wrote:
On 2015/10/09 06:23:09, dak wrote:
>
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode144
> lily/part-combine-iterator.cc:144: // What is the relationship
between
> "duration" and "length"? Why does
> Length
On 2015/10/10 00:36:04, Dan Eble wrote:
On 2015/10/09 06:55:02, dak wrote:
> We don't pass Moment by reference. It's a simple scalar type and
references
> reached via unsmob are rarely guaranteed to survive for long.
I'll change it to pass by value, though I don't understand why passing
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode53
lily/part-combine-iterator.cc:53: void start_mmrest (Context *c, const
Moment
On 2015/10/09 06:23:09, dak wrote:
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode144
lily/part-combine-iterator.cc:144: // What is the relationship between
"duration" and "length"? Why does
Length is a Moment, duration is a Duration. get_event_length
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode144
lily/part-combine-iterator.cc:144: // What is the relationship between
"durat
On 2015/10/09 06:55:02, dak wrote:
We don't pass Moment by reference. It's a simple scalar type and
references
reached via unsmob are rarely guaranteed to survive for long.
I'll change it to pass by value, though I don't understand why passing
by reference is a problem. When passed by val
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode146
lily/part-combine-iterator.cc:146: // get_event_length(), which reads
"length
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode146
lily/part-combine-iterator.cc:146: // get_event_length(), which reads
"length
https://codereview.appspot.com/265410043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
- Original Message -
From: "Trevor Daniels"
To: "Trevor Daniels" ; "Lily-Devel List"
; "Simon Albrecht"
Sent: Tuesday, September 08, 2015 11:04 PM
Subject: Re: Google-to-Allura port adds brackets around rests
>
> Trevor Dani
TIA
https://codereview.appspot.com/265160043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Werner LEMBERG wrote Wednesday, September 09, 2015 5:37 AM
>
>> Further to this, there are over 300 issues containing rests in
>> square brackets, of which 77 are still active (i.e. they have a
>> Status of Accepted Started or New.) So we really ought to fix those
>&g
> Further to this, there are over 300 issues containing rests in
> square brackets, of which 77 are still active (i.e. they have a
> Status of Accepted Started or New.) So we really ought to fix those
> if it is at all possible.
Has someone written to the Allura team how to
5 um 20:09 schrieb Dan Eble:
>>>>> Compare
>>>>>
>>>>> https://code.google.com/p/lilypond/issues/detail?id=1677
>>>>> https://sourceforge.net/p/testlilyissues/issues/1677/
>>>>> <https://sourceforge.net/p/testlilyissue
gt; https://code.google.com/p/lilypond/issues/detail?id=1677
>>>> https://sourceforge.net/p/testlilyissues/issues/1677/
>>>> <https://sourceforge.net/p/testlilyissues/issues/1677/>
>>>>
>>>> The latter has square brackets around rests, e.g. “[r4]
e.net/p/testlilyissues/issues/1677/
>>> <https://sourceforge.net/p/testlilyissues/issues/1677/>
>>>
>>> The latter has square brackets around rests, e.g. “[r4]” instead of “r4”.
>>
>> Oh shoot! That’s not a problem with the port, but it has been a prob
Il giorno mar 8 set 2015 alle 0:23, Trevor Daniels
ha scritto:
I don't understand what the url links in GC were supposed to do, but
whatever it was they are broken now. I've never seen links attached
to rests before, so I think this is a one-off, probably caused by
pasting
t/p/testlilyissues/issues/1677/>
The latter has square brackets around rests, e.g. “[r4]” instead of “r4”.
Oh shoot! That’s not a problem with the port, but it has been a problem
with Google adding a link to
<https://code.google.com/p/lilypond/source/detail?r=4>, which in the
sourc
eforge.net/p/testlilyissues/issues/1677/>
>>
>> The latter has square brackets around rests, e.g. “[r4]” instead of “r4”.
>
> Oh shoot! That’s not a problem with the port, but it has been a problem
> with Google adding a link to
> <https://code.google.com/p/lilypond/source/
Am 07.09.2015 um 20:09 schrieb Dan Eble:
Compare
https://code.google.com/p/lilypond/issues/detail?id=1677
https://sourceforge.net/p/testlilyissues/issues/1677/
<https://sourceforge.net/p/testlilyissues/issues/1677/>
The latter has square brackets around rests, e.g. “[r4]” instead
Compare
https://code.google.com/p/lilypond/issues/detail?id=1677
https://sourceforge.net/p/testlilyissues/issues/1677/
<https://sourceforge.net/p/testlilyissues/issues/1677/>
The latter has square brackets around rests, e.g. “[r4]” instead of “r4”.
Dan,
> Am 22. August 2015 05:19:43 MESZ, schrieb Dan Eble :
> >Can anyone offer general architectural advice for adding the option for
> >parts on the same staff to share rests when possible? I mean without
> >using \partcombine. I’d like to focus on multi-measure rests
HTH
Urs
Am 22. August 2015 05:19:43 MESZ, schrieb Dan Eble :
>Can anyone offer general architectural advice for adding the option for
>parts on the same staff to share rests when possible? I mean without
>using \partcombine. I’d like to focus on multi-measure rests first.
>Roughly, I
Dan Eble writes:
> Can anyone offer general architectural advice for adding the option
> for parts on the same staff to share rests when possible? I mean
> without using \partcombine. I’d like to focus on multi-measure rests
> first. Roughly, I guess there should be something that
Can anyone offer general architectural advice for adding the option for parts
on the same staff to share rests when possible? I mean without using
\partcombine. I’d like to focus on multi-measure rests first. Roughly, I
guess there should be something that watches for notes and rests in all
Reviewers: ,
Description:
Part combiner: Ignore skips coinciding with rests within a part
Please review this at https://codereview.appspot.com/240790043/
Affected files (+19, -14 lines):
M input/regression/part-combine-silence-mixed.ly
M scm/part-combiner.scm
Index: input/regression/part
1 - 100 of 328 matches
Mail list logo
