Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Carl Sorensen]

On 4/7/17 2:15 PM, "lilypond-devel on behalf of David Kastrup"
 wrote:

>"Trevor Daniels"  writes:
>
>>One argument in favor of \voicify would be that \voices sounds like
>setting a state rather than modifying a music expression.  It would be a
>bit more talkative to say something like
>
>\withVoices 1,3,4
><< \\ \\ >>
>
>rather than
>
>\voices 1,3,4
><< \\ \\ >>
>
>So I'm not completely happy with \voices though all in all it's probably
>still my favorite.
>
>I did not come up with "voicify" all on my own: the internal function
>for doing << \\ \\ >> was named like that before, so I just added a
>user-level command using the same verbiage.
>
>If we ever add a command for changing the default,
>
>\defaultVoices ...
>
>would definitely be less awkward than
>
>\defaultVoicify ...
>or
>\defaultVoicification ...

How about 

\voiceOrder 

and 

\defaultVoiceOrder

?

Thanks,

Carl


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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David Kastrup wrote Friday, April 07, 2017 9:07 PM


> "Trevor Daniels"  writes:
> 
>> David, you wrote Thursday, April 06, 2017 4:54 PM
>>
>>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>>> sure whether or not \voicify should not be \voices or \voicing or
>>> \voicings instead, possibly making for nicer compounds like that.
>>> 
>>> I mean, something like
>>> 
>>> \voices 1,3,4 ...
>>
>> Although you later argued cogently against compounds like \voicesUp I
>> think \voices is a better choice than \voicify anyway, simply because
>> it expresses its operation more clearly (not sure what meaning the word
>> "voicify" would trigger in the mind - in Google it enables voice dictation;
>> in Twitter it applies a filter, for example).  
>>
>> In other words \voices stands better than \voicify on its own merits.
> 
> I'll not stop the countdown for now but am going to commit with this
> change unless we get a conflicting view in which case it would make
> sense to stop the countdown and gather more opinions, possibly from the
> user list.

OK.  Happy to wait to see what others think, or, if there's no further
input, to defer to your preference.
 
> Not sure what to name input/regression/voicify.ly instead, though.
> "voicify.ly" is clearly referring to the command, "voices.ly" is much
> more ambiguous.  But at least it is not taken yet.

Well, lots of the regression tests have compound names.
"reordering-voices-in-parallel-construct.ly or something
similarly descriptive would be fine.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Urs Liska]

Am 07.04.2017 um 22:07 schrieb David Kastrup:
> "Trevor Daniels"  writes:
>
>> David, you wrote Thursday, April 06, 2017 4:54 PM
>>
>>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>>> sure whether or not \voicify should not be \voices or \voicing or
>>> \voicings instead, possibly making for nicer compounds like that.
>>>
>>> I mean, something like
>>>
>>> \voices 1,3,4 ...
>> Although you later argued cogently against compounds like \voicesUp I
>> think \voices is a better choice than \voicify anyway, simply because
>> it expresses its operation more clearly (not sure what meaning the word
>> "voicify" would trigger in the mind - in Google it enables voice dictation;
>> in Twitter it applies a filter, for example).  
>>
>> In other words \voices stands better than \voicify on its own merits.
> I'll not stop the countdown for now but am going to commit with this
> change unless we get a conflicting view in which case it would make
> sense to stop the countdown and gather more opinions, possibly from the
> user list.

I think \voices is good.

>
> Not sure what to name input/regression/voicify.ly instead, though.
> "voicify.ly" is clearly referring to the command, "voices.ly" is much
> more ambiguous.  But at least it is not taken yet.

No idea, but I agree it's a glitch.
Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Leave of offliness

[Thomas Morley]

2017-04-07 17:24 GMT+02:00 David Kastrup :
>
> Hi folks,
>
> tomorrow morning I'll be leaving for my annual climbing trip in Italy
> (not that I could afford it but there is no point in postponing all
> living until death).  If past years are an indication, I won't have
> Internet access until Sunday evening (because when we'll arrive at the
> pension tomorrow, there will be nobody there who could register me, and
> of course on Sunday I'll be climbing during the day).
>
> So if people want to rely on my chaperoning skills for possible staging
> branch emergencies, they'll probably cause the least disruption by
> waiting until then for pushing stuff.
>
> Later,
>
> --
> David Kastrup



Enjoy and have fun!!

All the best,
  Harm

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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[David Kastrup]

"Trevor Daniels"  writes:

> David, you wrote Thursday, April 06, 2017 4:54 PM
>
>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>> sure whether or not \voicify should not be \voices or \voicing or
>> \voicings instead, possibly making for nicer compounds like that.
>> 
>> I mean, something like
>> 
>> \voices 1,3,4 ...
>
> Although you later argued cogently against compounds like \voicesUp I
> think \voices is a better choice than \voicify anyway, simply because
> it expresses its operation more clearly (not sure what meaning the word
> "voicify" would trigger in the mind - in Google it enables voice dictation;
> in Twitter it applies a filter, for example).  
>
> In other words \voices stands better than \voicify on its own merits.

One argument in favor of \voicify would be that \voices sounds like
setting a state rather than modifying a music expression.  It would be a
bit more talkative to say something like

\withVoices 1,3,4
<< \\ \\ >>

rather than

\voices 1,3,4
<< \\ \\ >>

So I'm not completely happy with \voices though all in all it's probably
still my favorite.

I did not come up with "voicify" all on my own: the internal function
for doing << \\ \\ >> was named like that before, so I just added a
user-level command using the same verbiage.

If we ever add a command for changing the default,

\defaultVoices ...

would definitely be less awkward than

\defaultVoicify ...
or
\defaultVoicification ...

-- 
David Kastrup

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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[David Kastrup]

"Trevor Daniels"  writes:

> David, you wrote Thursday, April 06, 2017 4:54 PM
>
>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>> sure whether or not \voicify should not be \voices or \voicing or
>> \voicings instead, possibly making for nicer compounds like that.
>> 
>> I mean, something like
>> 
>> \voices 1,3,4 ...
>
> Although you later argued cogently against compounds like \voicesUp I
> think \voices is a better choice than \voicify anyway, simply because
> it expresses its operation more clearly (not sure what meaning the word
> "voicify" would trigger in the mind - in Google it enables voice dictation;
> in Twitter it applies a filter, for example).  
>
> In other words \voices stands better than \voicify on its own merits.

I'll not stop the countdown for now but am going to commit with this
change unless we get a conflicting view in which case it would make
sense to stop the countdown and gather more opinions, possibly from the
user list.

Not sure what to name input/regression/voicify.ly instead, though.
"voicify.ly" is clearly referring to the command, "voices.ly" is much
more ambiguous.  But at least it is not taken yet.

-- 
David Kastrup

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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David, you wrote Thursday, April 06, 2017 4:54 PM

> You could try separate commands \voicifyUp and \voicifyDown .  I am not
> sure whether or not \voicify should not be \voices or \voicing or
> \voicings instead, possibly making for nicer compounds like that.
> 
> I mean, something like
> 
> \voices 1,3,4 ...

Although you later argued cogently against compounds like \voicesUp I
think \voices is a better choice than \voicify anyway, simply because
it expresses its operation more clearly (not sure what meaning the word
"voicify" would trigger in the mind - in Google it enables voice dictation;
in Twitter it applies a filter, for example).  

In other words \voices stands better than \voicify on its own merits.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add guile-config-1.8 etc. searching (issue 320830043 by truer...@gmail.com)

[Marco Atzeri]

On 05/04/2017 17:43, James wrote:

On Wed, 5 Apr 2017 14:13:43 +0200
Marco Atzeri  wrote:


On 05/04/2017 10:27, thomasmorle...@gmail.com wrote:

LGTM

https://codereview.appspot.com/320830043/



Detection is fine, but another piece is missing (tested on 2.19.58) :


This is not current master.

2.19.58 was 'released' 9 days ago. We're now in the testing process
for what will be 2.19.59.

Also note that the Tracker state for this issue is in 'Review' -
implying that it passed all the basic checks (including a Reg test and
a full make doc).

https://sourceforge.net/p/testlilyissues/issues/5115

Regards

James



You are right.

when building with

commit e9ae1cb3b093498ccb9d5f7348c755a3243bbccc
Author: Thomas Morley 
Date:   Sun Mar 19 14:29:04 2017 +0100

Issue 5108 Let configure find all needed files with guile-2.2

plus the proposed patch the build was fine on cygwin 64bit
and correctly detect latest guile 1.8

Regards
Marco

(cygwin package maintainer for guile and lilypond)






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

Re: Add scriptExceptions property/convenience functions (issue 324740043 by david.nales...@gmail.com)

[dak]

On 2017/04/07 18:27:25, david.nalesnik wrote:


I see no way to make a context property holding exceptions work with

the system

in place.  (Which is why I set the patch to needs work.)



I'll work on putting an override system in place.


Ugh.  I actually don't have all that good of an idea just which override
should override what in what situation.  The user will likely expect his
last override to make a difference, but when expections and base grob
are in different data structures, "last" cannot be determined.

https://codereview.appspot.com/324740043/

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

Re: Add scriptExceptions property/convenience functions (issue 324740043 by david.nales...@gmail.com)

[david . nalesnik]

On 2017/04/07 17:30:25, dak wrote:

On 2017/04/05 15:55:38, david.nalesnik wrote:
> On 2017/04/05 15:47:19, pkx166h wrote:
> > Do you want this tested?
> >
> > I cannot see any tracker issue for this.
> >
> > Or is this just some work-in-progress design before you have a

patch for

> testing
> > proper?
> >
> > James
>
> It's associated with Issue 4276.
>
> It would be great if you could test this.
>
> I do think that some discussion is in order over the relative merits

of this

> context-property approach vs. the tweaking approach linked to in the
description
> of 4276.
>
> Thanks!



My personal take on this would be to allow overriding, say, \override
Script.accent.padding = #2.0 .  And maybe that's where all of the

script

definitions should be in the first place.


Yes, I've considered just this syntax and believe it would be best.

The context-property method breaks down because of the way
create_script_from_event in lily/script-engraver.cc negotiates between
properties listed in scriptDefinitions (or, by extension, in the
property scriptExceptions added by the patch) on the one hand, and
properties from the grob-definition of Script/possibly introduced by
user overrides on the other.

The user expectation would be that any property they put in
scriptExceptions should have an effect, but that's not the case because
of the fragile way create_script_from_event creates its property lists.
Values for 'staff-padding are thrown out, because the value in the
grob-description of Script (0.15) is an acceptable value
(ly:dimension?).  Values for 'rotation are also thrown out -- here
because the default value is unset, meaning '(), which is an acceptable
value for 'rotation because the property takes a list!

I see no way to make a context property holding exceptions work with the
system in place.  (Which is why I set the patch to needs work.)

I'll work on putting an override system in place.

https://codereview.appspot.com/324740043/

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

Re: Add scriptExceptions property/convenience functions (issue 324740043 by david.nales...@gmail.com)

[dak]

On 2017/04/05 15:55:38, david.nalesnik wrote:

On 2017/04/05 15:47:19, pkx166h wrote:
> Do you want this tested?
>
> I cannot see any tracker issue for this.
>
> Or is this just some work-in-progress design before you have a patch

for

testing
> proper?
>
> James



It's associated with Issue 4276.



It would be great if you could test this.



I do think that some discussion is in order over the relative merits

of this

context-property approach vs. the tweaking approach linked to in the

description

of 4276.



Thanks!


My personal take on this would be to allow overriding, say, \override
Script.accent.padding = #2.0 .  And maybe that's where all of the script
definitions should be in the first place.

https://codereview.appspot.com/324740043/

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

Re: Leave of offliness

[Carl Sorensen]

Thanks, David.

Enjoy your climbing!

Carl


On 4/7/17 9:24 AM, "lilypond-devel on behalf of David Kastrup"
 wrote:

>
>Hi folks,
>
>tomorrow morning I'll be leaving for my annual climbing trip in Italy
>(not that I could afford it but there is no point in postponing all
>living until death).  If past years are an indication, I won't have
>Internet access until Sunday evening (because when we'll arrive at the
>pension tomorrow, there will be nobody there who could register me, and
>of course on Sunday I'll be climbing during the day).
>
>So if people want to rely on my chaperoning skills for possible staging
>branch emergencies, they'll probably cause the least disruption by
>waiting until then for pushing stuff.
>
>Later,
>
>-- 
>David Kastrup
>
>___
>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

Leave of offliness

[David Kastrup]

Hi folks,

tomorrow morning I'll be leaving for my annual climbing trip in Italy
(not that I could afford it but there is no point in postponing all
living until death).  If past years are an indication, I won't have
Internet access until Sunday evening (because when we'll arrive at the
pension tomorrow, there will be nobody there who could register me, and
of course on Sunday I'll be climbing during the day).

So if people want to rely on my chaperoning skills for possible staging
branch emergencies, they'll probably cause the least disruption by
waiting until then for pushing stuff.

Later,

-- 
David Kastrup

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

Re: [patch] Add a work to "we wrote" list

[Han-Wen Nienhuys]

This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404.
I think you mean https://paconet.org/tesis/tesis.pdf ?

On Thu, Apr 6, 2017 at 10:24 AM, Francisco Vila  wrote:
> Hello,
>
> this adds my PhD thesis to the list in the web. Sorry for not
> uploading the patch in a more formal way; I can not recall if I've
> done it anytime. I'm willing to, however.
>
> I'll be relatively unreachable for a week. See you on 04/13
>
> Best,
> --
> Francisco Vila. Badajoz (Spain)
> paconet.org , csmbadajoz.com
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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