I like this. Maybe we ought also to make a
small change to the LM. One possible place
is where ties are introduced
http://www.lilypond.org/doc/v2.17/Documentation/learning/ties-and-slurs
As the LM does not mention drummode that's
probably all that is required.
https://codereview.appspot.com/22
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm
File scm/music-functions.scm (right):
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm#newcode780
scm/music-functions.scm:780: ;;; that don't interpret them is harmless.
does that mean that
2. 4
https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy#newcode649
lily/parser.yy:649: | FRACTION
On 2013/11/09 17:12:52, Trevor Daniels wrote:
I don't like the mixed tabs and spaces here
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm
File scm/music-functions.scm (right):
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm#newcode780
scm/music-functions.scm:780: ;;; that don't interpret them is harmless.
On 2013/11/09 18:46:30, b
Awesome!!
could you push it in a branch, so that I could read the commits in
sequence?
On 2013/11/09 19:05:29, dak wrote:
You need to use q here. Sorry, but it would not do to turn
<< \new Staff { 4 }
\new RhythmicStaff { 4 4 4 4 }
>>
into
<< \new Staff { 4 }
\new RhythmicStaf
https://codereview.appspot.com/22120043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/11/10 11:59:58, ckenneth721 wrote:
Hey
https://codereview.appspot.com/22120043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/11/10 11:48:13, janek wrote:
Awesome!!
could you push it in a branch, so that I could read the commits in
sequence?
dev/issue3648
On 2013/11/09 19:05:29, dak wrote:
> You need to use q here. Sorry, but it would not do to turn
>
> << \new Staff { 4 }
>\new RhythmicStaff { 4 4 4
On Nov 10, 2013 5:11 AM, wrote:
> On 2013/11/10 11:48:13, janek wrote:
>
>> Awesome!!
>>
>
> could you push it in a branch, so that I could read the commits in
>>
> sequence?
>
> dev/issue3648
>
> On 2013/11/09 19:05:29, dak wrote:
>> > You need to use q here. Sorry, but it would not do to tur
2013/11/10 :
> On 2013/11/10 11:48:13, janek wrote:
>> could you push it in a branch, so that I could read the commits in
>> sequence?
>
> dev/issue3648
thanks!
LGTM.
>> Good point.
>> However, what about restricting the "pitch inheritance" to the
>> current context,
>
> Like q, expansion is don
Some more thoughts about the chord issue: I agree that it sounds
somewhat icky to have repetition not extend to chords, in particular
when having a music function with a body like
#{ #music 4 4. 8 #}
and calling it with either \rhythm c or \rhythm , it will be quite
a nuisance that the first works
On 2013/11/12 10:23:56, dak wrote:
a) we don't commit ourselves either way: it is undefined what a pure
duration
after an intervening chord will do.
b) just single pitches, no chords: that's what this patch proposes.
c) also chords: this patch needs more work, supporting code must be
wri
On 2013/11/12 15:35:42, benko.pal wrote:
On 2013/11/12 10:23:56, dak wrote:
> a) we don't commit ourselves either way: it is undefined what a pure
duration
> after an intervening chord will do.
>
> b) just single pitches, no chords: that's what this patch proposes.
>
> c) also chords: this patc
2013/11/12 :
> It still would not be fun in connection with TabStaff, not repeating
> string numbers and stuff, and such repetition is really not feasible.
I don't understand what you mean here.
> Of course the problem is that we have to make a decision what to
> support:
>
> a) we don't commit
2013/11/12 :
> So this patch leaves open questions, and people might give themselves
> answers consistent with the current behavior. Overriding those answers
> later with a convert-ly rule seems unfeasible: this is really a bit too
> invasive and complex to change using convert-ly.
>
> The curren
On 2013/11/12 21:58:13, janek wrote:
2013/11/12 :
> It still would not be fun in connection with TabStaff, not repeating
> string numbers and stuff, and such repetition is really not
feasible.
I don't understand what you mean here.
> Of course the problem is that we have to make a decision
LGTM.
2013/11/13 :
> On 2013/11/12 21:58:13, janek wrote:
>>
>> 2013/11/12 :
>> > It still would not be fun in connection with TabStaff, not repeating
>> > string numbers and stuff, and such repetition is really not
>
> feasible.
>
>> I don't understand what you mean here.
>
>
>> > Of course the
17 matches
Mail list logo
