Re: Fwd: MusicXML

[Urs Liska]

Hi David,

nice to read that. 

I think coming to GSoC with an idea is more important than the listed mentor 
availability. Continuing on the Scheme/XML track would be very rewarding.

However, for some reasons I'd try to go into a more generic direction. This 
could be very suitable for integration with other projects.

I'll get back to you in a few days.

Best
Urs



Am 18. Februar 2016 03:07:40 MEZ, schrieb David Garfinkle 
:
>Hi there!
>
>Hope everyone had a lovely new year. School has kept me busy, but I'm
>still
>interested in continuing work on the MusicXML project that I started
>over
>the summer. I just caught up in mailing-list readings for the topic, so
>I
>think I'm correct in assuming that it hasn't been added to the code
>base
>yet, or edited, and that I can continue working locally without risk of
>re-doing work that has already been done by someone else.
>
>I'm also thinking about doing another summer of GSoC, but am undecided
>on
>what I should work on. I could continue with XML export, or I could
>work on
>a different project suggestion. As far as I know from Urs' compilation,
>there are three other project ideas (adding glyph variants, extending
>ScholarLY library, and adding chord structures) which have a primary
>mentor. On one hand, it would be beneficial to knock a more serious
>dent
>into MusicXML and kick down the door for easier contribution. On the
>other
>hand, it seems like the other three projects are less sprawling and it
>would be nice to see a definite conclusion to an issue or idea.
>Thoughts?
>
>In any event, I'm happy to continue working on MusicXML in whatever
>capacity I am able.
>
>Best,
>David
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Fwd: MusicXML

[David Garfinkle]

Hi there!

Hope everyone had a lovely new year. School has kept me busy, but I'm still
interested in continuing work on the MusicXML project that I started over
the summer. I just caught up in mailing-list readings for the topic, so I
think I'm correct in assuming that it hasn't been added to the code base
yet, or edited, and that I can continue working locally without risk of
re-doing work that has already been done by someone else.

I'm also thinking about doing another summer of GSoC, but am undecided on
what I should work on. I could continue with XML export, or I could work on
a different project suggestion. As far as I know from Urs' compilation,
there are three other project ideas (adding glyph variants, extending
ScholarLY library, and adding chord structures) which have a primary
mentor. On one hand, it would be beneficial to knock a more serious dent
into MusicXML and kick down the door for easier contribution. On the other
hand, it seems like the other three projects are less sprawling and it
would be nice to see a definite conclusion to an issue or idea. Thoughts?

In any event, I'm happy to continue working on MusicXML in whatever
capacity I am able.

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

Re: hyphen syntax

[Dan Eble]

On Feb 17, 2016, at 18:17 , David Kastrup  wrote:
> 
> I think the main problem we should aim to solve is that the occasional
> user just does not remember what's what.  __ is a lyric extender, -- is
> a lyric hyphen, _ is a non-syllable-separating space, - is a normal
> dash, ~ is an undertie.

- as a lyric hyphen and __ as a lyric extender are both highly mnemonic.

~ is consistent with ties in the music.

There are probably multiple alternatives to _ that would not be so easily 
confused with __.
For example, “”.  It’s tricky, but it’s also systematic in its own way.
— 
Dan


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

(OT) Re: hyphen syntax

[Simon Albrecht]

On 17.02.2016 23:22, Noeck wrote:

I think many of you know the fun you can have with
backslashes and escaping (as inhttp://xkcd.org/1638/).


Funny site :-) Also see that one:  – particularly 
applies to Schemers…


Best, Simon

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

Re: hyphen syntax

[David Kastrup]

Noeck  writes:

> Hi Simon,
>
>> You should have come back to the entire quote: ‘And I think the double
>> items suit the advanced functionality better (advanced in comparison to
>> printing a hyphen character from a font).’ I didn’t mean ‘advanced’ in
>> the sense of ‘only for advanced users’ or ‘rare’.
>
> I know. I'm sorry to misuse the quote a bit. Your sentence just made me
> want to write what I was thinking before – even though it did not fully
> fit to your statement.
>
>> But three characters versus four characters to type doesn’t seem enough
>> of a difference to justify the change.
>
> That might well be true. I am undecided myself. I think I like the
> single hyphen (syl - la - ble) still ;)

I think the main problem we should aim to solve is that the occasional
user just does not remember what's what.  __ is a lyric extender, -- is
a lyric hyphen, _ is a non-syllable-separating space, - is a normal
dash, ~ is an undertie.  All of the single-character entities will
become part of the syllable they are in (even if they are alone), the
double characters however augment the previous syllable.

That's sort of systematic, except that the system is not explained
anywhere.

-- 
David Kastrup

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

Re: Doc: NR renamed New spacing area node (issue 283350043 by pkx1...@gmail.com)

[pkx166h]

On 2016/02/17 18:45:24, tisimst wrote:

Minor punctuation suggestion, otherwise LGTM.



https://codereview.appspot.com/283350043/diff/1/Documentation/notation/spacing.itely

File Documentation/notation/spacing.itely (right):



https://codereview.appspot.com/283350043/diff/1/Documentation/notation/spacing.itely#newcode2882

Documentation/notation/spacing.itely:2882: example;
Should be "example:" (i.e., with a colon and not a semicolon)?


Yes. Fixed.

https://codereview.appspot.com/283350043/

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

Re: hyphen syntax

[Noeck]

Hi Simon,

> You should have come back to the entire quote: ‘And I think the double
> items suit the advanced functionality better (advanced in comparison to
> printing a hyphen character from a font).’ I didn’t mean ‘advanced’ in
> the sense of ‘only for advanced users’ or ‘rare’.

I know. I'm sorry to misuse the quote a bit. Your sentence just made me
want to write what I was thinking before – even though it did not fully
fit to your statement.

> But three characters versus four characters to type doesn’t seem enough
> of a difference to justify the change.

That might well be true. I am undecided myself. I think I like the
single hyphen (syl - la - ble) still ;)

Cheers,
Joram

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

Re: hyphen syntax

[Simon Albrecht]

On 17.02.2016 23:22, Noeck wrote:

Or to come
back to the quote I started with: IMHO a lyric hyphen is not advanced.


You should have come back to the entire quote: ‘And I think the double 
items suit the advanced functionality better (advanced in comparison to 
printing a hyphen character from a font).’ I didn’t mean ‘advanced’ in 
the sense of ‘only for advanced users’ or ‘rare’.

‘-’ prints a hyphen.
‘--’ checks how much space is available, and inserts either nothing, a 
short hyphen, a full hyphen or multiple hyphens for longer stretches.
If we were discussing ‘syl-la-ble’ instead of ‘syl -- la -- ble’ now, 
this would be a relevant advantage, since one would have to type one 
character instead of four. [Of course, this would force us to use 
quotes, if any literal hyphens were to occur inside a word.]
But three characters versus four characters to type doesn’t seem enough 
of a difference to justify the change.


Best, Simon

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

Re: LilyPond as a service

[David Kastrup]

Urs Liska  writes:

> I know this has been discussed in various flavors over the years, but I
> need to raise the issue once more. Please note that this actually
> encloses two questions.
>
> Would it be possible to make LilyPond work in a server mode where the
> whole Guile environment is loaded only once and the running server would
> be listening and accepting files to compile (or maybe piped .ly input or
> even Scheme music expressions)?

Shrug.  LilyPond already compiles multiple independent files/sessions
per invocation or our documentation would need even longer to build.

It's not really involved.  You just need to replace/amend the file
handling loop in lily.scm.  See how -dgui is implemented in that file.

> How fundamentally would one have to turn LilyPond's architecture
> upside down for this? Is this conceptually impossible, just difficult
> or simply too big to have been tackled so far?

Nobody cared.

> Is this a task that could *somehow* be estimated in developer
> weeks/months if one would dream of a paid developer?

A few days for the proof-of-concept implementation once you find someone
interested in sockets etc.  The actual effort, like with almost any
functionality, is not limited.  There is always one more thing you want
done.

For TeX, Jonathan Fine implemented the "TeX daemon" which does something
similar.  Nobody apart from him himself actually ended up using this
significantly (there is some web site for typesetting mathematics with
plain TeX which he programmed, or at least was).  He has a talent to rub
people the wrong way but nevertheless this kind of "shave off some more
startup time" thing apparently never was quite worth it to people.  I am
not sure whether current TeX engines are compiled for providing the
socket option still.

tex --help
[...]
-ipcsend DVI output to a socket as well as the usual
  output file
-ipc-start  as -ipc, and also start the server at the other end
[...]

Still there.  I don't even think that he created that option.  I think
he only used it, and it was originally needed for TeXshop or some other
GUI on the old MacOS.

-- 
David Kastrup

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

Re: hyphen syntax

[Noeck]

Hi,

Am 17.02.2016 um 17:54 schrieb Simon Albrecht:
> And I think the double items suit the advanced functionality better

I thought about this when Dan wrote his first mail, but I wanted to keep
my comment short. I think many of you know the fun you can have with
backslashes and escaping (as in http://xkcd.org/1638/). So it is a good
idea to use rare expressions for special functionality to avoid escaping
to get back to the original thing (\ or -).

But the hyphen is just the most natural thing in a lyricmode
environment. People asked on this list about it and also in scores
online I see people using single hyphens because they are just natural.
Some try 'a - b', realize it uses 3 notes and then go for 'a- b'.
Technically, soft hyphens would be nice (U+00AD) but who wants to enter
that (and its invisible in the code).

My impression of LilyPond is: The core functionality is very cleverly
designed and very concise, just think about { a4:16-.->\f( }. One could
have invented something like \notemode {
a1/4\tremolo{1/16}\staccato\accent\dynamic{f}\startSlur }. This was only
obtained by defining the reasonably shortest syntax for the most
frequent items.

So I agree with the sentiment I read from Dan's first mail: The single
hyphen would be natural to separate syllables. For the rare case of a
literal single hyphen, I think "-" is a fair way to get it. Or to come
back to the quote I started with: IMHO a lyric hyphen is not advanced.

Just my comment.
Joram

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

Re: LilyPond as a service

[tisimst]

On Wed, Feb 17, 2016 at 2:51 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n187406...@n5.nabble.com> wrote:

> I'm sorry but I don't get this.
> Urs
>
>
> Am 17.02.2016 um 22:48 schrieb Abraham Lee:
>
> > This sounds a lot like lilybin.com 
>

You know what, I probably jumped the gun a little. lilybin.com does do LaaS
(LilyPond as a Service), but not quite in the way you were describing.
Sorry for the noise.




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LilyPond-as-a-service-tp187403p187407.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyPond as a service

[Urs Liska]

I'm sorry but I don't get this.
Urs


Am 17.02.2016 um 22:48 schrieb Abraham Lee:
> This sounds a lot like lilybin.com ...
>
> - Abraham
>
> On Wed, Feb 17, 2016 at 2:45 PM, Urs Liska  > wrote:
>
> I know this has been discussed in various flavors over the years,
> but I
> need to raise the issue once more. Please note that this actually
> encloses two questions.
>
> Would it be possible to make LilyPond work in a server mode where the
> whole Guile environment is loaded only once and the running server
> would
> be listening and accepting files to compile (or maybe piped .ly
> input or
> even Scheme music expressions)?
>
> I assume this could provide significant improvements in a number
> of use
> cases.
>
> How fundamentally would one have to turn LilyPond's architecture
> upside
> down for this? Is this conceptually impossible, just difficult or
> simply
> too big to have been tackled so far?
>
> Is this a task that could *somehow* be estimated in developer
> weeks/months if one would dream of a paid developer?
>
>
> ###
>
> A second idea is not directly related but would rely on the first. If
> LilyPond *could* run as a server, would there be a chance to keep the
> parsed document (i.e. not the engraving) in memory?
> This may seem nonsensical, but if I'm not mistaken this would open up
> the possibility to recompile a document with changed edition-engraver
> mods. As these could also comprise skipTypesetting commands this would
> make it possible to recompile an arbitrary excerpt (e.g. the current
> system) of a score while tweaking, without LilyPond having to
> parse the
> whole score over and over again.
>
> Same questions as above: conceptually possible at all, any estimate on
> the size of such an endeavour?
>
> Thanks
> Urs
>
> ___
> 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

Re: LilyPond as a service

[Abraham Lee]

This sounds a lot like lilybin.com...

- Abraham

On Wed, Feb 17, 2016 at 2:45 PM, Urs Liska  wrote:

> I know this has been discussed in various flavors over the years, but I
> need to raise the issue once more. Please note that this actually
> encloses two questions.
>
> Would it be possible to make LilyPond work in a server mode where the
> whole Guile environment is loaded only once and the running server would
> be listening and accepting files to compile (or maybe piped .ly input or
> even Scheme music expressions)?
>
> I assume this could provide significant improvements in a number of use
> cases.
>
> How fundamentally would one have to turn LilyPond's architecture upside
> down for this? Is this conceptually impossible, just difficult or simply
> too big to have been tackled so far?
>
> Is this a task that could *somehow* be estimated in developer
> weeks/months if one would dream of a paid developer?
>
>
> ###
>
> A second idea is not directly related but would rely on the first. If
> LilyPond *could* run as a server, would there be a chance to keep the
> parsed document (i.e. not the engraving) in memory?
> This may seem nonsensical, but if I'm not mistaken this would open up
> the possibility to recompile a document with changed edition-engraver
> mods. As these could also comprise skipTypesetting commands this would
> make it possible to recompile an arbitrary excerpt (e.g. the current
> system) of a score while tweaking, without LilyPond having to parse the
> whole score over and over again.
>
> Same questions as above: conceptually possible at all, any estimate on
> the size of such an endeavour?
>
> Thanks
> Urs
>
> ___
> 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

LilyPond as a service

[Urs Liska]

I know this has been discussed in various flavors over the years, but I
need to raise the issue once more. Please note that this actually
encloses two questions.

Would it be possible to make LilyPond work in a server mode where the
whole Guile environment is loaded only once and the running server would
be listening and accepting files to compile (or maybe piped .ly input or
even Scheme music expressions)?

I assume this could provide significant improvements in a number of use
cases.

How fundamentally would one have to turn LilyPond's architecture upside
down for this? Is this conceptually impossible, just difficult or simply
too big to have been tackled so far?

Is this a task that could *somehow* be estimated in developer
weeks/months if one would dream of a paid developer?


###

A second idea is not directly related but would rely on the first. If
LilyPond *could* run as a server, would there be a chance to keep the
parsed document (i.e. not the engraving) in memory?
This may seem nonsensical, but if I'm not mistaken this would open up
the possibility to recompile a document with changed edition-engraver
mods. As these could also comprise skipTypesetting commands this would
make it possible to recompile an arbitrary excerpt (e.g. the current
system) of a score while tweaking, without LilyPond having to parse the
whole score over and over again.

Same questions as above: conceptually possible at all, any estimate on
the size of such an endeavour?

Thanks
Urs

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

Re: hyphen syntax

[Simon Albrecht]

On 17.02.2016 18:24, tisimst wrote:

On Wed, Feb 17, 2016 at 10:16 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n187386...@n5.nabble.com> wrote:


On 17.02.2016 18:02, tisimst wrote:

I've always wondered why the
LyricHyphen doesn't actually use the hyphen from the LyricText font

rather

than a dashed line. I realize that doing that would reduce the
customizability of the dash (i.e., length, thickness, dash-period,

etc.),

but it might it immediately look more homogeneous regardless of the font
used because they are designed to match each other. Not a big deal, just
curious.

And I should like if there were an option to take these hyphens from a
text font, since in some fonts/music engraving styles they are slanted
or wavy (like ~) and it would be great to have a means of doing that.


That's exactly what I meant, if that wasn't clear.


Yes, you were. I only wanted to add my thoughts.

Best, Simon

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

Re: Doc section name change proposition

[James Lowe]

Hello,

On 17/02/16 17:16, Phil Holmes wrote:
- Original Message - From: "Abraham Lee" 


To: "LilyPond Development Team" 
Sent: Wednesday, February 17, 2016 4:35 PM
Subject: Doc section name change proposition



Docs Team,

I noticed this a while back, but I thought I might as well bring it up.
Subsubsection 4.5.2  in NR is called "New spacing area", but the 
command it

introduces is called "\newSpacingSection". In favor of not changing the
command name, can we rename the section to match the command? In other
words, I am wondering if anyone is against changing the section name to
"New spacing section"?

On the other hand, is it conceivable that \newSpacingSection should be
renamed instead? I have no problem with that either.

Thanks everyone!
- Abraham



To me, calling the section of the documents "New spacing section" 
sounds better English.


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

--
James

---

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE


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

Re: Doc section name change proposition

[tisimst]

On Wed, Feb 17, 2016 at 10:17 AM, Phil Holmes-2 [via Lilypond] <
ml-node+s1069038n18738...@n5.nabble.com> wrote:

> - Original Message -
> From: "Abraham Lee" <[hidden email]
> >
> To: "LilyPond Development Team" <[hidden email]
> >
> Sent: Wednesday, February 17, 2016 4:35 PM
> Subject: Doc section name change proposition
>
>
> > Docs Team,
> >
> > I noticed this a while back, but I thought I might as well bring it up.
> > Subsubsection 4.5.2  in NR is called "New spacing area", but the command
> > it
> > introduces is called "\newSpacingSection". In favor of not changing the
> > command name, can we rename the section to match the command? In other
> > words, I am wondering if anyone is against changing the section name to
> > "New spacing section"?
> >
> > On the other hand, is it conceivable that \newSpacingSection should be
> > renamed instead? I have no problem with that either.
> >
> > Thanks everyone!
> > - Abraham
>
>
> To me, calling the section of the documents "New spacing section" sounds
> better English.
>

Sounds just fine to me, too.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Doc-section-name-change-proposition-tp187377p187396.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: hyphen syntax

[tisimst]

On Wed, Feb 17, 2016 at 10:16 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n187386...@n5.nabble.com> wrote:

> On 17.02.2016 18:02, tisimst wrote:
> > I've always wondered why the
> > LyricHyphen doesn't actually use the hyphen from the LyricText font
> rather
> > than a dashed line. I realize that doing that would reduce the
> > customizability of the dash (i.e., length, thickness, dash-period,
> etc.),
> > but it might it immediately look more homogeneous regardless of the font
> > used because they are designed to match each other. Not a big deal, just
> > curious.
>
> And I should like if there were an option to take these hyphens from a
> text font, since in some fonts/music engraving styles they are slanted
> or wavy (like ~) and it would be great to have a means of doing that.
>

That's exactly what I meant, if that wasn't clear.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/hyphen-syntax-tp187210p187389.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc section name change proposition

[Phil Holmes]

- Original Message - 
From: "Abraham Lee" 

To: "LilyPond Development Team" 
Sent: Wednesday, February 17, 2016 4:35 PM
Subject: Doc section name change proposition



Docs Team,

I noticed this a while back, but I thought I might as well bring it up.
Subsubsection 4.5.2  in NR is called "New spacing area", but the command 
it

introduces is called "\newSpacingSection". In favor of not changing the
command name, can we rename the section to match the command? In other
words, I am wondering if anyone is against changing the section name to
"New spacing section"?

On the other hand, is it conceivable that \newSpacingSection should be
renamed instead? I have no problem with that either.

Thanks everyone!
- Abraham



To me, calling the section of the documents "New spacing section" sounds 
better English.


--
Phil Holmes 



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

Re: hyphen syntax

[Simon Albrecht]

On 17.02.2016 18:02, tisimst wrote:

I've always wondered why the
LyricHyphen doesn't actually use the hyphen from the LyricText font rather
than a dashed line. I realize that doing that would reduce the
customizability of the dash (i.e., length, thickness, dash-period, etc.),
but it might it immediately look more homogeneous regardless of the font
used because they are designed to match each other. Not a big deal, just
curious.


And I should like if there were an option to take these hyphens from a 
text font, since in some fonts/music engraving styles they are slanted 
or wavy (like ~) and it would be great to have a means of doing that.


Best, Simon

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

Re: hyphen syntax

[David Kastrup]

Simon Albrecht  writes:

> On 17.02.2016 15:58, David Kastrup wrote:
>> Dan Eble  writes:
>>
 >>On Feb 17, 2016, at 05:18 , Jean-Charles
 >> Malahieude wrote:
 >>
 >>Le 14/02/2016 20:41, Dan Eble a écrit :
> >>>Are there technical limitations that require typing a double hyphen
> >>>to hyphenate lyrics?  Why not just one?
> >>>
 >>
 >>Technically, I don't know. But, in terms of coherence, I would leave
 >>it as it is:
 >>
 >>one hyphen is treated as one syllable, just like one underscore
 >>"skips" one (group of) note
>>> >
>>> >But is it useful for a bare hyphen to be treated as a syllable?  I
>>> >don’t recall having seen any examples of that.
>> It is rather common for skipping syllables in multiple stanzas since an
>> isolated - is equivalent to " ".
>
> It’s an isolated _ (underscore) you mean.

I do mean an isolated dash, I am just wrong about it.

-- 
David Kastrup

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

Re: hyphen syntax

[tisimst]

On Wed, Feb 17, 2016 at 9:54 AM, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n187380...@n5.nabble.com> wrote:

> On 17.02.2016 15:58, David Kastrup wrote:
>
> > Dan Eble<[hidden email]
> >  writes:
> >
> >>> >>On Feb 17, 2016, at 05:18 , Jean-Charles Malahieude<[hidden email]
> >  wrote:
> >>> >>
> >>> >>Le 14/02/2016 20:41, Dan Eble a écrit :
>  >>>Are there technical limitations that require typing a double
> hyphen
>  >>>to hyphenate lyrics?  Why not just one?
>  >>>
> >>> >>
> >>> >>Technically, I don't know. But, in terms of coherence, I would leave
> >>> >>it as it is:
> >>> >>
> >>> >>one hyphen is treated as one syllable, just like one underscore
> >>> >>"skips" one (group of) note
> >> >
> >> >But is it useful for a bare hyphen to be treated as a syllable?  I
> >> >don’t recall having seen any examples of that.
> > It is rather common for skipping syllables in multiple stanzas since an
> > isolated - is equivalent to " ".
>
> It’s an isolated _ (underscore) you mean. A dash is indeed treated as a
> syllable.
> I think _if_ we wanted to use - instead of --, we’d have to do the same
> kind of change for lyric extenders, else it would be inconsistent. And I
> think the double items suit the advanced functionality better (advanced
> in comparison to printing a hyphen character from a font).
>

Funny you should mention that because I've always wondered why the
LyricHyphen doesn't actually use the hyphen from the LyricText font rather
than a dashed line. I realize that doing that would reduce the
customizability of the dash (i.e., length, thickness, dash-period, etc.),
but it might it immediately look more homogeneous regardless of the font
used because they are designed to match each other. Not a big deal, just
curious.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/hyphen-syntax-tp187210p187381.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: hyphen syntax

[Simon Albrecht]

On 17.02.2016 15:58, David Kastrup wrote:

Dan Eble  writes:


>>On Feb 17, 2016, at 05:18 , Jean-Charles Malahieude  wrote:
>>
>>Le 14/02/2016 20:41, Dan Eble a écrit :

>>>Are there technical limitations that require typing a double hyphen
>>>to hyphenate lyrics?  Why not just one?
>>>

>>
>>Technically, I don't know. But, in terms of coherence, I would leave
>>it as it is:
>>
>>one hyphen is treated as one syllable, just like one underscore
>>"skips" one (group of) note

>
>But is it useful for a bare hyphen to be treated as a syllable?  I
>don’t recall having seen any examples of that.

It is rather common for skipping syllables in multiple stanzas since an
isolated - is equivalent to " ".


It’s an isolated _ (underscore) you mean. A dash is indeed treated as a 
syllable.
I think _if_ we wanted to use - instead of --, we’d have to do the same 
kind of change for lyric extenders, else it would be inconsistent. And I 
think the double items suit the advanced functionality better (advanced 
in comparison to printing a hyphen character from a font).


Best, Simon

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

Re: When to start patch review

[Urs Liska]

Am 17.02.2016 um 17:47 schrieb Simon Albrecht:
>> Waiting for a patch like that to pass before review is pointless if
>> there is going to be a reluctance or even refusal to allow it to make
>> it to master in the end.
>>
>> However, is there a particular reason for this question? 
>
> No, just a thought I had. And what you say is good, so it’s clear now.
>
> Best, Simon
>

Starting review before the status is set to review just keeps a certain
risk that a test failure might make your reviewing work obsolete.

Urs

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

Re: When to start patch review

[Simon Albrecht]

On 17.02.2016 09:42, James Lowe wrote:

On 16/02/16 21:34, Simon Albrecht wrote:

Hello,

actually it would make sense to only start Rietveld review _after_ 
testing, i.e. when the tracker issue is set to Patch:review – 
wouldn’t it?


Full make doc errors are always forgivable, as are unexpected reg test 
diffs, but I do get irked when a patch doesn't even pass make (or 
cannot even apply to current master) when it is obvious that the dev 
hasn't really even tried to make sure it works before submission for 
*full* testing.


The assumption is therefore, (I guess, as someone who doesn't code), 
that a dev should know what they are doing and have at least run 
'make' - which exercises the patch to a certain degree and will catch 
most of the obvious Texinfo syntax mistakes - before they submit. My 
full patch testing then just exercises the reg test and the full doc 
build.


Also, (speaking as *the* person that does 'all' the patch testing - 
other volunteers are always welcome to chip in BTW), it can save me 
time if someone has already spotted something obvious before I get 
round to testing; in that case I won't even bother and just set the 
patch back to needs_work (with comment on the tracker) - it just 
depends on how convenient it is for me at the time and if the comments 
in Rietveld are 'gentle discussion' type comments or not.


For example, if some dev puts up a patch and another dev then looks at 
that patch and sees that it breaks all the 'conventions' (or whatever 
term you want to use) with LP's syntax or design philosophy then I may 
not bother to test.


Waiting for a patch like that to pass before review is pointless if 
there is going to be a reluctance or even refusal to allow it to make 
it to master in the end.


However, is there a particular reason for this question? 


No, just a thought I had. And what you say is good, so it’s clear now.

Best, Simon

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

Doc section name change proposition

[Abraham Lee]

Docs Team,

I noticed this a while back, but I thought I might as well bring it up.
Subsubsection 4.5.2  in NR is called "New spacing area", but the command it
introduces is called "\newSpacingSection". In favor of not changing the
command name, can we rename the section to match the command? In other
words, I am wondering if anyone is against changing the section name to
"New spacing section"?

On the other hand, is it conceivable that \newSpacingSection should be
renamed instead? I have no problem with that either.

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

Re: hyphen syntax

[David Kastrup]

Dan Eble  writes:

>> On Feb 17, 2016, at 05:18 , Jean-Charles Malahieude  
>> wrote:
>> 
>> Le 14/02/2016 20:41, Dan Eble a écrit :
>>> Are there technical limitations that require typing a double hyphen
>>> to hyphenate lyrics?  Why not just one?
>>> 
>> 
>> Technically, I don't know. But, in terms of coherence, I would leave
>> it as it is:
>> 
>> one hyphen is treated as one syllable, just like one underscore
>> "skips" one (group of) note
>
> But is it useful for a bare hyphen to be treated as a syllable?  I
> don’t recall having seen any examples of that.

It is rather common for skipping syllables in multiple stanzas since an
isolated - is equivalent to " ".

-- 
David Kastrup

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

Re: hyphen syntax

[Dan Eble]

> On Feb 17, 2016, at 05:18 , Jean-Charles Malahieude  wrote:
> 
> Le 14/02/2016 20:41, Dan Eble a écrit :
>> Are there technical limitations that require typing a double hyphen
>> to hyphenate lyrics?  Why not just one?
>> 
> 
> Technically, I don't know. But, in terms of coherence, I would leave it as it 
> is:
> 
> one hyphen is treated as one syllable, just like one underscore "skips" one 
> (group of) note

But is it useful for a bare hyphen to be treated as a syllable?  I don’t recall 
having seen any examples of that.

> one double-hypen (which may output several dashes depending of the length of 
> a melisma) separates syllables of a same word, like a double-underscore draws 
> a line indicating the last syllable has to last over serveral notes.

I think it should be reversed.  It is more convenient to use the shorter symbol 
for the more common case.  To specify a hard hyphen in a compound word, I would 
prefer something like this.

  Jean \hh Charles Mal - a - hieu - de
  (apologies if it's wrongly broken)

I’m not advocating \hh especially, just using it as a placeholder.

And if someone really wanted a hyphen character as a syllable, could they not 
use “-“?
--
Dan


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

Re: hyphen syntax

[Jean-Charles Malahieude]

Le 14/02/2016 20:41, Dan Eble a écrit :

Are there technical limitations that require typing a double hyphen
to hyphenate lyrics?  Why not just one?



Technically, I don't know. But, in terms of coherence, I would leave it 
as it is:


one hyphen is treated as one syllable, just like one underscore "skips" 
one (group of) note, and I will type my first-name Jean- Char -- les or 
"Jean -" Char -- les since it's a composed word,


one double-hypen (which may output several dashes depending of the 
length of a melisma) separates syllables of a same word, like a 
double-underscore draws a line indicating the last syllable has to last 
over serveral notes.



Cheers,
Jean-Charles

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

Re: Doc: CG Updated section 1.3 - experienced devs (issue 287110043 by pkx1...@gmail.com)

[pkx166h]

Thanks for reviewing Simon.


https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi
File Documentation/contributor/introduction.itexi (right):

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode120
Documentation/contributor/introduction.itexi:120: Google's Reitveld code
review tool.
On 2016/02/16 21:32:12, simon.albrecht wrote:

This should read Rietveld.
Strictly speaking, it doesn’t _belong_ to Google IIUC. But given the

close links

this is probably a legit simplification :-)


Done.

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode133
Documentation/contributor/introduction.itexi:133: @item @strong{GIT
branches}:
On 2016/02/16 21:32:12, simon.albrecht wrote:

The official capitalisation is ‘Git’, I think.


Done.

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode147
Documentation/contributor/introduction.itexi:147: translation patches
directly to it aswell.
On 2016/02/16 21:32:12, simon.albrecht wrote:

as well – two words.


Done.

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode157
Documentation/contributor/introduction.itexi:157: files) between
released stable and unstable versions as well as checked
On 2016/02/16 21:32:12, simon.albrecht wrote:

Why the parens?


No idea. Fixed.

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode176
Documentation/contributor/introduction.itexi:176: on the issue tracker;
also see @ref{Issues}.
On 2016/02/16 21:32:12, simon.albrecht wrote:

‘see also’?


See also the dog.

Also see the dog.

No, that doesn't make sense grammatically (at least in English it
doesn't).

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode194
Documentation/contributor/introduction.itexi:194: more discussion is
needed, left at @code{Patch-review}.  In all cases
On 2016/02/16 21:32:12, simon.albrecht wrote:

Could this use @itemize?


No I don't think so. There are enough on this page already and this
single @item encapsulates everything in that 'single' step.

https://codereview.appspot.com/287110043/diff/20001/Documentation/contributor/introduction.itexi#newcode216
Documentation/contributor/introduction.itexi:216: compromise we have
found.}
On 2016/02/16 21:32:12, simon.albrecht wrote:

I’d prefer the former wording, except of course for the wrong time

span.

Starting a sentence with 'Yes' bothers me in technical writing. Does
code 'reach' or 'get merged into'? Also trying to remove 'emotive' words
(like 'unfortunate') which may not always be obvious to non-native
speakers or those that do not speak as good English as you obviously do.
I probably need a comma instead of a full stop.

OK I have re-written this slightly.

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

Re: When to start patch review

[James Lowe]

Simon,

On 16/02/16 21:34, Simon Albrecht wrote:

Hello,

actually it would make sense to only start Rietveld review _after_ 
testing, i.e. when the tracker issue is set to Patch:review – wouldn’t it?


Full make doc errors are always forgivable, as are unexpected reg test 
diffs, but I do get irked when a patch doesn't even pass make (or cannot 
even apply to current master) when it is obvious that the dev hasn't 
really even tried to make sure it works before submission for *full* 
testing.


The assumption is therefore, (I guess, as someone who doesn't code), 
that a dev should know what they are doing and have at least run 'make' 
- which exercises the patch to a certain degree and will catch most of 
the obvious Texinfo syntax mistakes - before they submit. My full patch 
testing then just exercises the reg test and the full doc build.


Also, (speaking as *the* person that does 'all' the patch testing - 
other volunteers are always welcome to chip in BTW), it can save me time 
if someone has already spotted something obvious before I get round to 
testing; in that case I won't even bother and just set the patch back to 
needs_work (with comment on the tracker) - it just depends on how 
convenient it is for me at the time and if the comments in Rietveld are 
'gentle discussion' type comments or not.


For example, if some dev puts up a patch and another dev then looks at 
that patch and sees that it breaks all the 'conventions' (or whatever 
term you want to use) with LP's syntax or design philosophy then I may 
not bother to test.


Waiting for a patch like that to pass before review is pointless if 
there is going to be a reluctance or even refusal to allow it to make it 
to master in the end.


However, is there a particular reason for this question?

--
James

---

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE


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