Re: Add alias in Spanish for espanol note names language (issue 6811060)

[Francisco Vila]

2012/11/4 David Kastrup :
>> Then, if we want (I think yes) to add more aliases, it can be
>> implemented better than repeating the trick for each. I can do it
>> later.
>
> Something like define-language-alias, probably.

I have uploaded a new try with two examples.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Add alias in Spanish for espanol note names language (issue 6811060)

[paconet . org]

http://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm
File scm/define-note-names.scm (right):

http://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm#newcode961
scm/define-note-names.scm:961: ;; add two native utf-8 alisases. Pairs
obey cp-like order: '(old new)
It should be 'aliases', of course.

http://codereview.appspot.com/6811060/

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

integration of chordmode in normal music

[Joram Berger]

Dear developers,

how about integrating the chordmode into normal music syntax?

Reasoning: chords are music, too. And with <…> chords are already
possible in the music input. Many modifiers like duration, alteration,
etc. are also possible with chords. So they are similar in many ways.

A solution I came up with: e.g. pitch in capital letters, like
C1 == 1
(would rely on case-sensitivity, which is not wanted, as far as I
understand.) There might be some difficulty when displaying music in
ChordNames to figure out what chord name to print.

This is just a spontaneous idea. Whether it makes sense, I don't know. I
just wanted to let you know. Feel free to just comment it as "bad idea".

Cheers,
Joram

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

easier \noBeam syntax

[Joram Berger]

Hi,

here is another (probably not so well thought) idea:

Issue: \noBeam is a quite long command if used heavily and for the
opposite feature [ and ] represent much more convenient solutions.

Possible solution: use X or ; (or any other reasonable token as a
\noBeam equivalent.

Again, this is just an idea, which might be no good one.

Cheers,
Joram

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

Re: integration of chordmode in normal music

[David Kastrup]

Joram Berger  writes:

> Dear developers,
>
> how about integrating the chordmode into normal music syntax?
>
> Reasoning: chords are music, too. And with <…> chords are already
> possible in the music input. Many modifiers like duration, alteration,
> etc. are also possible with chords. So they are similar in many ways.
>
> A solution I came up with: e.g. pitch in capital letters, like
> C1 == 1
> (would rely on case-sensitivity, which is not wanted, as far as I
> understand.) There might be some difficulty when displaying music in
> ChordNames to figure out what chord name to print.

What about c minor?

-- 
David Kastrup


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

Re: easier \noBeam syntax

[David Kastrup]

Joram Berger  writes:

> Hi,
>
> here is another (probably not so well thought) idea:
>
> Issue: \noBeam is a quite long command if used heavily and for the
> opposite feature [ and ] represent much more convenient solutions.
>
> Possible solution: use X or ; (or any other reasonable token as a
> \noBeam equivalent.
>
> Again, this is just an idea, which might be no good one.

You know \autoBeamOff ?

-- 
David Kastrup


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

Re: Various clean-ups in stems and beams. (issue 6584045)

[mike]

On 5 nov. 2012, at 00:40, aleksandr.andr...@gmail.com wrote:

> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly
> File input/regression/kievan-notation.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly#newcode12
> input/regression/kievan-notation.ly:12: c4 c4 c8 [ d8 ] c4 c2 b,\longa
> We should add an unbeamed eighth note to the regtest, since its correct
> appearance is now controlled by
> 
> note-head::calc-kievan-duration-log
> 
> Maybe something like
> 
> c4 c8 c8[ d8] c4 c2 b,\longa

Done

> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly
> File input/regression/note-head-style.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108
> input/regression/note-head-style.ly:108: \override Staff.Dots.style =
> #'kievan
> Why can't we use the new function here, e.g.,
> 
> \kievanOn
> 

\kievenOn only works on the voice level and the overrides happen on the staff 
level.

> http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly
> File ly/engraver-init.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly#newcode1150
> ly/engraver-init.ly:1150: \override Stem.length = #0.0
> It seems like we also need something like:
> 
> \override Flag.stencil = ##f
> 
> Otherwise "flags" appear on Kievan eighth notes.
> 

True. Fixed.

> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly
> File ly/property-init.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode310
> ly/property-init.ly:310: \override Stem.length = #0.0
> Also need here:
> 
> \override Flag.stencil = ##f

Also fixed.

> 
> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode323
> ly/property-init.ly:323: \revert Stem.length
> And here:
> 
> \revert Flag.stencil

Also also fixed.

Many thanks!  Will post on Rietveld tonight or tomorrow.

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

Re: integration of chordmode in normal music

[Janek Warchoł]

On Tue, Nov 6, 2012 at 9:19 PM, Joram Berger  wrote:
> Dear developers,
>
> how about integrating the chordmode into normal music syntax?

Curiously, something similar was discussed recently - see "[GLISS]
Unifying \chordmode and \notemode".
You may want to have a look; maybe you'll find a nice way to solve
ambiguities we encountered.  I'd really like to see this integration
happen.

Janek

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

Re: easier \noBeam syntax

[Joram Berger]

Am 06.11.2012 22:10, schrieb David Kastrup:
> Joram Berger  writes:
> 
>> Hi,
>>
>> here is another (probably not so well thought) idea:
>>
>> Issue: \noBeam is a quite long command if used heavily and for the
>> opposite feature [ and ] represent much more convenient solutions.
>>
>> Possible solution: use X or ; (or any other reasonable token as a
>> \noBeam equivalent.
>>
>> Again, this is just an idea, which might be no good one.
> 
> You know \autoBeamOff ?
> 

I know that.

It's no real problem, just wanted to mention it. The idea came up while
making a cheat sheet and realizing, that [ and ] have no equally short
counterpart.

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

Re: Various clean-ups in stems and beams. (issue 6584045)

[dak]

http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108

> input/regression/note-head-style.ly:108: \override Staff.Dots.style

=

> #'kievan
> Why can't we use the new function here, e.g.,
>
> \kievanOn
>



\kievenOn only works on the voice level and the overrides happen on

the staff

level.


How about making \pattern a music function taking a context
modification as argument?  Then you could write

\pattern \with { \override NoteHead.style = #'slash }
\pattern \with { \kievanOn }
\pattern \with { ... }

and just pass the context mod on to the \new Voice within \pattern.

It seems awkward to use Staff-wide overrides here.

By the way: it's frightening how fast one gets used to the new
override syntax.  I had to think really hard about whether this was
supposed to be different previously or not.  And then it seems strange
that there would have been no dot.


http://codereview.appspot.com/6584045/

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

Re: easier \noBeam syntax

[David Kastrup]

Joram Berger  writes:

> Am 06.11.2012 22:10, schrieb David Kastrup:
>> Joram Berger  writes:
>> 
>>> Hi,
>>>
>>> here is another (probably not so well thought) idea:
>>>
>>> Issue: \noBeam is a quite long command if used heavily and for the
>>> opposite feature [ and ] represent much more convenient solutions.
>>>
>>> Possible solution: use X or ; (or any other reasonable token as a
>>> \noBeam equivalent.
>>>
>>> Again, this is just an idea, which might be no good one.
>> 
>> You know \autoBeamOff ?
>> 
>
> I know that.
>
> It's no real problem, just wanted to mention it. The idea came up while
> making a cheat sheet and realizing, that [ and ] have no equally short
> counterpart.

Well, either this is due to phrasing patterns leaving isolated unbeamed
notes in which case beaming the patterns is enough, or you actually have
situations with several unbeamed notes in a row.  That is almost always
related to lyrics being reflected in beaming in which case the only safe
remedy is manually beaming everything since you can't rely on
autobeaming delivering the same results in all eternity and all styles.

So the main use case would seem to be a prettier cheat sheet.  Wasting
symbols or tokens on that seems excessive.

-- 
David Kastrup


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

Re: easier \noBeam syntax

[Janek Warchoł]

On Wed, Nov 7, 2012 at 12:10 AM, David Kastrup  wrote:
> Joram Berger  writes:
>> It's no real problem, just wanted to mention it. The idea came up while
>> making a cheat sheet and realizing, that [ and ] have no equally short
>> counterpart.
>
> So the main use case would seem to be a prettier cheat sheet.  Wasting
> symbols or tokens on that seems excessive.

lol :)
I think that \noBeam isn't used often enough to justify a shorter
syntax.  Additionally, in my opinion it's better to have non-symbollic
names for commands that make something disappear.

Janek

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

Re: easier \noBeam syntax

[Joram Berger]

Am 07.11.2012 00:10, schrieb David Kastrup:
> Joram Berger  writes:
> 
>> Am 06.11.2012 22:10, schrieb David Kastrup:
>>> Joram Berger  writes:
>>>
 Hi,

 here is another (probably not so well thought) idea:

 Issue: \noBeam is a quite long command if used heavily and for the
 opposite feature [ and ] represent much more convenient solutions.

 Possible solution: use X or ; (or any other reasonable token as a
 \noBeam equivalent.

 Again, this is just an idea, which might be no good one.
>>>
>>> You know \autoBeamOff ?
>>>
>>
>> I know that.
>>
>> It's no real problem, just wanted to mention it. The idea came up while
>> making a cheat sheet and realizing, that [ and ] have no equally short
>> counterpart.
> 
> Well, either this is due to phrasing patterns leaving isolated unbeamed
> notes in which case beaming the patterns is enough, or you actually have
> situations with several unbeamed notes in a row.  That is almost always
> related to lyrics being reflected in beaming in which case the only safe
> remedy is manually beaming everything since you can't rely on
> autobeaming delivering the same results in all eternity and all styles.
> 
> So the main use case would seem to be a prettier cheat sheet.  Wasting
> symbols or tokens on that seems excessive.
> 

I agree that it would be a waste of tokens.

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

PATCH: Countdown to 20121108

[Colin Campbell]

For 20:00 MST Thursday November 8th

Enhancement:

Issue 2949 : 
Patch: Allow (closed) scheme function calls as text scripts - R 6812088 



Ugly:
Issue 2926 
: divisioMaior 
broke - R 6778050 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: Various clean-ups in stems and beams. (issue 6584045)

[m...@mikesolomon.org]

On 7 nov. 2012, at 00:50, d...@gnu.org wrote:

> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108
>> > input/regression/note-head-style.ly:108: \override Staff.Dots.style
> =
>> > #'kievan
>> > Why can't we use the new function here, e.g.,
>> >
>> > \kievanOn
>> >
> 
>> \kievenOn only works on the voice level and the overrides happen on
> the staff
>> level.
> 
> How about making \pattern a music function taking a context
> modification as argument?  Then you could write
> 
> \pattern \with { \override NoteHead.style = #'slash }
> \pattern \with { \kievanOn }
> \pattern \with { ... }
> 
> and just pass the context mod on to the \new Voice within \pattern.
> 
> It seems awkward to use Staff-wide overrides here.
> 
> By the way: it's frightening how fast one gets used to the new
> override syntax.  I had to think really hard about whether this was
> supposed to be different previously or not.  And then it seems strange
> that there would have been no dot.
> 

I'm not exactly sure how this'd be done - if it's OK w/ you, I'll push the 
patch after a countdown and then you can propose a followup patch.  Sorry - I 
have been out of the loop for a bit and am not up-to-date on the most recent 
syntax modifications.

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

Re: Various clean-ups in stems and beams. (issue 6584045)

[aleksandr . andreev]

http://codereview.appspot.com/6584045/diff/13015/input/regression/kievan-notation.ly
File input/regression/kievan-notation.ly (right):

http://codereview.appspot.com/6584045/diff/13015/input/regression/kievan-notation.ly#newcode13
input/regression/kievan-notation.ly:13: \bar "kievan"
This needs to be:

\bar "k"

given the changes made by issue 2790.

http://codereview.appspot.com/6584045/

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

Re: Design flaw in Rest_collision

[Keith OHara]

On Mon, 05 Nov 2012 21:52:15 -0800, m...@mikesolomon.org  
wrote:


On 6 nov. 2012, at 04:51, Keith OHara  wrote:


Just to be clear, rest-collision.cc breaks the circular dependency by setting
positioning-done := true,


I'm still not sure how this breaks the dependency.  If I look up the extent of 
a rest, this will set 'Y-extent to 'calculation-in-progress for the rest.  
Then, when 'Y-extent is read again in F, it will still be 
'calculation-in-progress.  Setting 'positioning-done to #t only prevents 
calc_positioning_done by being called multiple times (say by other rests) - it 
doesn't fill in the 'calculation-in-progress for 'Y-extent.  Or am I missing 
something?



Setting 'positioning-done to #t prevents calc_positioning_done() being called 
repeatedly for the same rest in an endless cycle; that is, it breaks the cycle 
of dependency.

If the process begins with a lookup of Y-extent, then I follow what you say on 
how the chain of dependencies could lookup the same Y-extent once again, before 
reaching the end of the data-dependency chain.  The first lookup of Y-extent 
sets a trap intended to detect and stop cyclic dependencies, while the second 
lookup activates the trap.

In this case there would be no further lookups of Y-extent on the same rest, so 
we could consider this a false-positive activation of the trap.  It is probably 
wisest to keep the simple trap, even if it can have false-positives. (I argued 
before that the calculation-in-progress message should be a warning, not error.)

Do you have input that generates the "calculation-in-progress encountered..." 
message for rests?

Maybe you can arrange to have Rest_collision::force_shift_callback_rest() 
called before looking up the Y-extent of a rest.

Or, maybe we should change calc_positioning_done() to call directly 
Rest::generic_extent_callback() rather than going through the symbol lookup.  
This way, the C code would assume responsibility for preventing endless data 
dependency chains.  Your earlier suggestion about having 
Rest::generic_extent_callback() consistently ignore ledgers should work fine.

line 249 of rest.cc [...]
  SCM m = brew_internal_stencil (me, false);
and then run make check.



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

Re: Design flaw in Rest_collision

[m...@mikesolomon.org]

On 7 nov. 2012, at 09:10, Keith OHara  wrote:

> On Mon, 05 Nov 2012 21:52:15 -0800, m...@mikesolomon.org 
>  wrote:
> 
>> On 6 nov. 2012, at 04:51, Keith OHara  wrote:
>> 
>>> Just to be clear, rest-collision.cc breaks the circular dependency by 
>>> setting
>>> positioning-done := true,
>> 
>> I'm still not sure how this breaks the dependency.  If I look up the extent 
>> of a rest, this will set 'Y-extent to 'calculation-in-progress for the rest. 
>>  Then, when 'Y-extent is read again in F, it will still be 
>> 'calculation-in-progress.  Setting 'positioning-done to #t only prevents 
>> calc_positioning_done by being called multiple times (say by other rests) - 
>> it doesn't fill in the 'calculation-in-progress for 'Y-extent.  Or am I 
>> missing something?
>> 
> 
> Setting 'positioning-done to #t prevents calc_positioning_done() being called 
> repeatedly for the same rest in an endless cycle; that is, it breaks the 
> cycle of dependency.
> 

Yes, here I agree.

> If the process begins with a lookup of Y-extent, then I follow what you say 
> on how the chain of dependencies could lookup the same Y-extent once again, 
> before reaching the end of the data-dependency chain.  The first lookup of 
> Y-extent sets a trap intended to detect and stop cyclic dependencies, while 
> the second lookup activates the trap.
> 

Exactly.

> In this case there would be no further lookups of Y-extent on the same rest, 
> so we could consider this a false-positive activation of the trap.  It is 
> probably wisest to keep the simple trap, even if it can have false-positives. 
> (I argued before that the calculation-in-progress message should be a 
> warning, not error.)
> 
> Do you have input that generates the "calculation-in-progress encountered..." 
> message for rests?
> 

No, but I can make it happen fairly easily from the C++ backend.  I'll be 
posting a patch set later in the week where you'll see an exception that covers 
this case (there are none other like it in the code base).

> Maybe you can arrange to have Rest_collision::force_shift_callback_rest() 
> called before looking up the Y-extent of a rest.
> 
> Or, maybe we should change calc_positioning_done() to call directly 
> Rest::generic_extent_callback() rather than going through the symbol lookup.  
> This way, the C code would assume responsibility for preventing endless data 
> dependency chains.  Your earlier suggestion about having 
> Rest::generic_extent_callback() consistently ignore ledgers should work fine.

This is a good idea except that it'd fail for custom rest stencils.  It'd be 
great if we could drum up a generic solution.

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

Re: Various clean-ups in stems and beams. (issue 6584045)

[dak]

On 2012/11/07 05:32:40, mike7 wrote:

On 7 nov. 2012, at 00:50, mailto:d...@gnu.org wrote:



>
>


http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108

>> > input/regression/note-head-style.ly:108: \override

Staff.Dots.style

> =
>> > #'kievan
>> > Why can't we use the new function here, e.g.,
>> >
>> > \kievanOn
>> >
>
>> \kievenOn only works on the voice level and the overrides happen on
> the staff
>> level.
>
> How about making \pattern a music function taking a context
> modification as argument?  Then you could write
>
> \pattern \with { \override NoteHead.style = #'slash }
> \pattern \with { \kievanOn }
> \pattern \with { ... }
>
> and just pass the context mod on to the \new Voice within \pattern.
>
> It seems awkward to use Staff-wide overrides here.
>
> By the way: it's frightening how fast one gets used to the new
> override syntax.  I had to think really hard about whether this was
> supposed to be different previously or not.  And then it seems

strange

> that there would have been no dot.
>



I'm not exactly sure how this'd be done - if it's OK w/ you, I'll push

the patch

after a countdown and then you can propose a followup patch.  Sorry -

I have

been out of the loop for a bit and am not up-to-date on the most

recent syntax

modifications.


There are no really new syntax modifications required.  The problem with
the "OK w/ you" part is that it is simply wrong _not_ to use the
\kievanOn function in this regtest and instead copy and modify its
contents.  That way, the regtests ceases to test \kievanOn and depends
on its internals not changing.

I'll put up a git-format patch on the Google issue tracker as Rietveld
does not appear to take attachments.

http://codereview.appspot.com/6584045/

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

Re: Various clean-ups in stems and beams. (issue 6584045)

[m...@mikesolomon.org]

On 7 nov. 2012, at 09:50, d...@gnu.org wrote:

> On 2012/11/07 05:32:40, mike7 wrote:
>> On 7 nov. 2012, at 00:50, mailto:d...@gnu.org wrote:
> 
>> >
>> >
> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108
>> >> > input/regression/note-head-style.ly:108: \override
> Staff.Dots.style
>> > =
>> >> > #'kievan
>> >> > Why can't we use the new function here, e.g.,
>> >> >
>> >> > \kievanOn
>> >> >
>> >
>> >> \kievenOn only works on the voice level and the overrides happen on
>> > the staff
>> >> level.
>> >
>> > How about making \pattern a music function taking a context
>> > modification as argument?  Then you could write
>> >
>> > \pattern \with { \override NoteHead.style = #'slash }
>> > \pattern \with { \kievanOn }
>> > \pattern \with { ... }
>> >
>> > and just pass the context mod on to the \new Voice within \pattern.
>> >
>> > It seems awkward to use Staff-wide overrides here.
>> >
>> > By the way: it's frightening how fast one gets used to the new
>> > override syntax.  I had to think really hard about whether this was
>> > supposed to be different previously or not.  And then it seems
> strange
>> > that there would have been no dot.
>> >
> 
>> I'm not exactly sure how this'd be done - if it's OK w/ you, I'll push
> the patch
>> after a countdown and then you can propose a followup patch.  Sorry -
> I have
>> been out of the loop for a bit and am not up-to-date on the most
> recent syntax
>> modifications.
> 
> There are no really new syntax modifications required.  The problem with
> the "OK w/ you" part is that it is simply wrong _not_ to use the
> \kievanOn function in this regtest and instead copy and modify its
> contents.  That way, the regtests ceases to test \kievanOn and depends
> on its internals not changing.
> 
> I'll put up a git-format patch on the Google issue tracker as Rietveld
> does not appear to take attachments.
> 

Excellent - I'll copy and paste whatever you come up with into my patch.  
Thanks for taking the time to do this.

Cheers,
MS


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