Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Carl . D . Sorensen]

LGTM.

Thanks!


https://codereview.appspot.com/315130043/

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

Re: guile-2.0 and debian

[Thomas Morley]

2016-11-29 19:34 GMT+01:00 Antonio Ospite :
> On Mon, 28 Nov 2016 10:11:35 +0100
> Thomas Morley  wrote:
>
>> 2016-11-25 23:19 GMT+01:00 Antonio Ospite :
>>
>> > In the mean time I started to write a TODO list of the missing pieces:
> [...]
Another one for the TODO-list

This fails:

m字 = { c'1 }
m² = { c'1 }
\new Staff \m字
\new Staff \m²

error: unknown escaped string: `\m字'
\new Staff
   \m字
error: unknown escaped string: `\m²'
\new Staff
   \m²

I think we discussed it already, but can't find it at the moment.
LilyPond never supported those stuff for ly-identifiers explicitely,
iirc it worked more by accident. So I'm not sure it's worth an entry
in the TODOs.

Cheers,
  Harm

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

Re: website: texinfo macros for both ID and classes

[Paul]

On 12/05/2016 12:35 PM, Graham Percival wrote:


On Mon, Dec 05, 2016 at 11:49:27AM -0500, Paul wrote:

For the website I'm thinking about adding a macro that can create a div with
both an ID and classes.

Why?  What problem would this solve?


That there's no way to create a div that has both an Id *and* one or 
more classes.  Currently you'd have to create two nested divs one with a 
class and one with an id (ugh).



This would be good to have in general and more intuitive for
those used to html.

I'm not convinced.


As someone who knew html and went through the process of figuring out 
how to contribute to the LilyPond website, I would have found it more 
intuitive and useful to have.  There was a point where a div with both 
Id and class was needed and there was no way to do it even though this 
is the most basic and common thing in html.


I'm just trying to smooth out a point of friction that I encountered, 
but sure, there are probably other priorities.



Before changing the underlying texinfo macros, much less the build
system or language used (which is not what Paul is suggesting, but
I know that those ideas are out there), I'd like to see somebody
make an honest effort at working on the CSS.


Well, I have already been doing that and plan to continue to work on the 
website as my time allows.



In particular, to make the website look acceptable on small
screens.  This would take 2-5 hours, depending on how familiar
that person is with CSS and web browser testing.

I don't think that's too much to ask.  If nobody is prepared to
even do that much, then we certainly don't want them to spend time
and effort on larger redesigns that may never be completed.  I'm
available to mentor this task.


I can't take this on at the moment given my other constraints and 
commitments.  (I suspect it would take more than 2-5 hours and might 
involve more than changing the CSS, but maybe I'm overestimating it.)


Cheers,
-Paul


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

Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Carl Sorensen]

On 12/5/16 10:28 AM, "lilypond-devel on behalf of Graham Percival"
 wrote:

>On Mon, Dec 05, 2016 at 09:24:54AM +0100, Urs Liska wrote:
>> 
>> If this intends to codify the website being tied to the documentation I
>> don't really like that.
>
>The website *is* tied to the documentation.  That decision was
>made in 2009, and the reasons are just as valid today.

I believe you when you say this.  But I am having a hard time finding a
record of the decision.  I expected to find it in the CG under
Administrative Policies or under Website work.  I couldn't find it either
place.  Can you help me find a pointer to the discussion and/or the
decision rationale?

Thanks,

Carl


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

Re: website: texinfo macros for both ID and classes

[Graham Percival]

On Mon, Dec 05, 2016 at 11:49:27AM -0500, Paul wrote:
> For the website I'm thinking about adding a macro that can create a div with
> both an ID and classes.

Why?  What problem would this solve?

> This would be good to have in general and more intuitive for
> those used to html.

I'm not convinced.

Before changing the underlying texinfo macros, much less the build
system or language used (which is not what Paul is suggesting, but
I know that those ideas are out there), I'd like to see somebody
make an honest effort at working on the CSS.

In particular, to make the website look acceptable on small
screens.  This would take 2-5 hours, depending on how familiar
that person is with CSS and web browser testing.

I don't think that's too much to ask.  If nobody is prepared to
even do that much, then we certainly don't want them to spend time
and effort on larger redesigns that may never be completed.  I'm
available to mentor this task.

Cheers,
- Graham

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

Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Graham Percival]

On Mon, Dec 05, 2016 at 09:24:54AM +0100, Urs Liska wrote:
> 
> If this intends to codify the website being tied to the documentation I
> don't really like that.

The website *is* tied to the documentation.  That decision was
made in 2009, and the reasons are just as valid today.

- Graham

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

Re: Is Anyone Working on a Better Tablature Algorithm?

[Carl Sorensen]

On 12/4/16 9:55 AM, "Thomas Morley"  wrote:

>2016-12-04 17:20 GMT+01:00 Carl Sorensen :
>>
>>
>> On 12/3/16 1:56 PM, "lilypond-devel on behalf of christopher-heckman"
>> > ccheck...@gmail.com> wrote:
>>
>>>Other tweaks are possible, and that's where I'd like to have some
>>>feedback.
>>>If you play guitar, enter something and test the tablature for
>>>playability.
>>>If you feel the playability is bad for some reason, let me know.
>>
>> Is there any reason not to replace the current tablature algorithm with
>> this algorithm?
>
>Too  much TODOs currently

I agree that it's not yet ready to replace the current algorithm.  I was
thinking more of when it's done.



>>It seems that we'd just need to add the properties to the
>> context properties of the TabStaff.
>
>This would be likely one of the TODOs.

We could add a context property to the TabStaff and FretBoards contexts
that is note-to-fret-procedure.  It would then use whichever procedure was
desired to convert notes to tabs.

In that way, we wouldn't replace the current determine-frets function.
We'd just have the alternative to call another function.

That seems like the best long-term way of implementing it, rather than
using a music function.

Thanks,

Carl


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

website: texinfo macros for both ID and classes

[Paul]

For the website I'm thinking about adding a macro that can create a div 
with both an ID and classes.  This would be good to have in general and 
more intuitive for those used to html.  For example:


  @macro div {ID, CLASSES}
  @html
  
  @end html
  @end macro

Used like so:

  @div {an-id,first-class second-class}


Currently we have divId and divClass that could be replaced by such a macro.

  @div {an-id}  -->   

  @div {,first-class second-class}  -->   


Unfortunately there seems to be no conditionals in texinfo macros so I 
don't see a way to avoid the empty id="" and class="" in that scenario.  
To avoid that we would have to keep divId and divClass and add 
divIdClass.[0]  But I think having one macro for divs would be simpler 
and easier for contributors, which might be the best variable to 
optimize for.


If we did this for divs it would make sense to do the same for spans and 
our current spanClass.


Thoughts?

[0] Maybe pluralize divIdClasses and divClasses to make it clear that 
you can have more than one.


-Paul


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

Re: preparing LilyDev for guile-v2-work branch

[Federico Bruni]

Il giorno ven 2 dic 2016 alle 23:53, Thomas Morley 
 ha scritto:

no clue what's causing the error for you.

I just checked again with the following command-sequence (nothing 
unusual):


git checkout remotes/origin/dev/guile-v2-work
git checkout -b dev/guile-v2-work-test
sh autogen.sh --noconfigure
mkdir -p build/
cd build/
../configure --enable-guile2
make -j5

Success!

Top in remotes/origin/dev/guile-v2-work is:
commit 645edd5a37a6c4fc0e5e15490681bd113a4162bb
Author: Antonio Ospite 
Date:   Tue Nov 22 16:25:01 2016 +0100

XXX reset the locale when building index.html


Sorry being of not more help,


Thanks for checking.

Everything fine after deleting build/ and starting again. I should have 
tried it before asking here..
Probably the problem was that the first time I run configure without 
the --enable-guile2 option.


Anyway, I think that I'll upload today LilyDev 4.2.
Probably the next one will be built from Stretch and it will have a new 
version number (5.0), as suggested by Antonio in another thread.





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

Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[Urs Liska]

Am 05.12.2016 um 09:05 schrieb gra...@percival-music.ca:
> Looks good to me, especially with Trevor's suggestion.
>
>
> https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi
>
> File Documentation/contributor/website-work.itexi (right):
>
> https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi#newcode21
>
> Documentation/contributor/website-work.itexi:21: maintenance effort and
> ensures the contents of the website to be
> (proposed modification by Trevor):
>
> - ensures the contents of the website to be
> - up to date with the rest of the documentation.
> + ensures the website content is consistent
> + with the rest of the documentation.
>
> https://codereview.appspot.com/315130043/

If this intends to codify the website being tied to the documentation I
don't really like that.

The description itself is good, though.



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

Re: Is Anyone Working on a Better Tablature Algorithm?

[christopher-heckman]

Okay, here we go ...


Thomas Morley-2 wrote
> from your initial posts I expected you'd rewrite the current
> noteToFretFunction, i.e. 'determine-frets'. Instead your 'chTab' is a
> music-function, still relying on 'determine-frets'. 

For the moment, this is easier to do. I didn't want to wreck my copy of
Lilypond, and I didn't particularly like the idea of rewriting
determine-frets, and not changing what works already.

And, as I mentioned, it's only a beta.


> Up to now I took only a very quick glance over the code. That said, we
> have context-properties for some of those settings. I'd  recommend to use
> them. 

This is my first big Lilypond project. I'm also learning Scheme for the
first time.

I agree about the context settings. There are too many ways to tweak this,
and the user might want tab that does certain things.


> Others are not documented sufficiently, like 'track-tabs'. (I don't
> understand what "best tabs" are.)

Those are Scheme variable names. Seriously, though, "track-tabs" is the
number of tablatures to create; if it's set to 4, that means chTab actually
finds the four best ways to tab the music.


> In general I'd prefer more comments why you do what inline. Otherwise
> you'll likely find not many people diving deeper into it. 

This is based on the algorithm in Chuanjun He's doctoral thesis: "An Expert
System for Guitar Sheet Music to Guitar Tablature". Most of the whys are
following what he did there.


> It fails for ...

Okay, I'll do a walk-through in about a week (which is why I posted it; it
works for my examples). Final Exams are coming up here at ASU.


> Even if I set 'use-open-strings' true. 

Since chTab doesn't refer to that property, I'm not surprised.


> With this example: 
> 
> mus = { 
>   f4\1 f\2 f\3 f' 
>  }
> 
> My settings for the strings are simply ignored. 

I went back and forth about this, and I decided that chTab would just ignore
the strings that are already set. There's no guarantee that they will
produce usable tablature, like in: 

{ f16\1 f'\1 f\1 }

In a future edition, chTab might generate about a dozen tablatures and look
to see if one matches the strings already selected, and then ignores them if
there isn't one.


> Too many errors

This occurred to me while coding. For instance, it does no error-checking.
There might not be any suitable tablatures for a particular piece, or notes
that are too high or too low to play, where an error message should be
returned (along with a graceful (?) exit). Once again, it's a beta. And will
probably remain a beta for a while.

One last question. You aren't by chance the Thomas Morley who used to teach
at Georgia Tech, are you?




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Is-Anyone-Working-on-a-Better-Tablature-Algorithm-tp196422p197611.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 CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[graham]

Looks good to me, especially with Trevor's suggestion.


https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi
File Documentation/contributor/website-work.itexi (right):

https://codereview.appspot.com/315130043/diff/1/Documentation/contributor/website-work.itexi#newcode21
Documentation/contributor/website-work.itexi:21: maintenance effort and
ensures the contents of the website to be
(proposed modification by Trevor):

- ensures the contents of the website to be
- up to date with the rest of the documentation.
+ ensures the website content is consistent
+ with the rest of the documentation.

https://codereview.appspot.com/315130043/

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

Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

[graham]

Reviewers: ,

Message:
Suggestion from Karlin High, modified by Simon Albrecht.  Please review.

Description:
Doc CG 6.1: Add caveat on website work

Please review this at https://codereview.appspot.com/315130043/

Affected files (+19, -2 lines):
  M Documentation/contributor/website-work.itexi


Index: Documentation/contributor/website-work.itexi
diff --git a/Documentation/contributor/website-work.itexi  
b/Documentation/contributor/website-work.itexi
index  
588d705f1b4facfbd11797a6122b95aae935d2b4..6e858f0c56788fafb4ab342c63787791c8099731  
100644

--- a/Documentation/contributor/website-work.itexi
+++ b/Documentation/contributor/website-work.itexi
@@ -14,8 +14,25 @@
 @section Introduction to website work

 The website is @emph{not} written directly in HTML;
-instead, the source is Texinfo, which is then generated into HTML,
-PDF, and Info formats.  The sources are
+instead it is autogenerated along with the documentation through a
+sophisticated setup, using Texinfo source files.  Texinfo is the
+standard for documentation of GNU software and allows generating
+output in HTML, PDF, and Info formats, which drastically reduces
+maintenance effort and ensures the contents of the website to be
+up to date with the rest of the documentation.  This makes the
+environment for improving the website rather different from common
+web development.
+
+If you have not contributed to LilyPond before, a good starting
+point might be incremental changes to the CSS file, to be found at
+@uref{http://lilypond.org/css/lilypond-website.css} or in the
+LilyPond source code at @file{./Documentation/css/lilypond-website.css}.
+
+Large scale structural changes tend to require familiarity with
+the project in general, a track record in working on LilyPond
+documentation as well as a prospect of long-term commitment.
+
+The Texinfo source file for generating HTML are to be found in

 @example
 Documentation/web.texi



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