Re: GDP: summary and directions, 11 Sep

2007-09-12 Thread Eyolf Østrem
On 11.09.2007 (17:33), Graham Percival wrote:
> Trevor Bača wrote:
> >That then leaves the question of what to do with the other stuff. What
> >about this?
> >  * Spacing: recast as a separate manual called Page Layout
> >  * Input and output: move to Program Usage
> >  * Changing defaults: move to Program Reference
> >  * Interfaces for programmers: move to Program Reference

> Nu-huh, Program Reference is "where angels fear to tread", remember.  :P

> >That would then leave the following separate books:

> ... ok, what about everybody else?  Think about it for a few minutes 
> before responding: my initial reaction was "WTF is Trevor smoking", but 
> I'm starting to think he wasn't crazy.

I've been thinking. Thoughts:
- I don't mind having chunks of varying sizes, weight, structure, or
  function. I think it's perfectly fine to have one Part with 25
  chapters and one with only one.
- But if "book" means a separate pdf file, for instance, I'm
  vehemently opposed to it.
- I also don't like the idea of shoving off Changing (and, I think,
  Interfaces) to a heading which is going to be appealing only/mainly
  to programmers. As I've argued before, these parts are only one step
  away from the basic notation (whereas working with scheme code
  directly is -- or feels like -- one or two steps further), and
  every effort should be made to encourage users to read this and thus
  to make it easily accessible -- which means: not relegate it to that
  place where Seraphs shiver.
- I have nothing against splitting off the LM as a
  separate document, but the rest should be available in one single
  file ("book"), which may have the main Parts that Trevor suggests.

> For the record, I'm still opposed to this idea, but it's now a "weak 
> reject".  I could be convinced otherwise.

In other words, this is a "weak reject" from me too, but perhaps for
different reasons than yours.

Eyolf

-- 
sugar daddy, n.:
A man who can afford to raise cain.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: GDP: summary and directions, 11 Sep ( Trevor Ba?a )

2007-09-12 Thread David Pirotte
On Wed, 12 Sep 2007 08:20:32 +0200
Mats Bengtsson <[EMAIL PROTECTED]> wrote:

>, for all people who currently prefer to download the PDF 
> version and
> do free text search in that single file.

I would prefer a single file too
david


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: GDP: summary and directions, 11 Sep ( Trevor Ba?a )

2007-09-11 Thread Mats Bengtsson



Jay Hamilton wrote:


That would then leave the following separate books:

  * Learning Manual (4 or 5 chapters)
  * Notation Reference (25 chapters)
  * Page Layout (handful of chapters)
  * Program Usage (6 chapters)
  * Program Reference (15 chapters)

  
I don't see the point of splitting into separate books, which, as Graham 
already
has pointed out, means a separate index for each book, not to mention a 
separate
PDF file, for all people who currently prefer to download the PDF 
version and

do free text search in that single file.

  /Mats


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: GDP: summary and directions, 11 Sep

2007-09-11 Thread Graham Percival

Trevor Bača wrote:

That then leaves the question of what to do with the other stuff. What
about this?

  * Spacing: recast as a separate manual called Page Layout
  * Input and output: move to Program Usage
  * Changing defaults: move to Program Reference
  * Interfaces for programmers: move to Program Reference


Nu-huh, Program Reference is "where angels fear to tread", remember.  :P


That would then leave the following separate books:


(5 books)
I think that's getting too fragmented.


...
My initial reaction was "no way; we want to make tweaking more friendly, 
not less".  But I had forgotten about the Learning Manual -- that 
clearly shows the beginning of tweaks, and (of course) more work is planned.


Hmmm...

*IF* it were easy to move Changing and Interfaces into the program 
reference, I could almost buy that.  That's a pretty big if, though.



If we renamed the Program Usage book, we _might_ be able to fit Spacing 
and Input in there.  I'm not wild about it, though.  But I definitely 
don't agree with making a separate book for Page Layout.



... ok, what about everybody else?  Think about it for a few minutes 
before responding: my initial reaction was "WTF is Trevor smoking", but 
I'm starting to think he wasn't crazy.


Please remember the following:
- HTML links between documents is cheap and easy.
- introductions belong in the Learning manual.  If you haven't skimmed 
through chapter 5, please do so.  I'm planning on a least doubling the 
material in the LM, so users will have a good idea of how things work by 
the time they finish it.  An extensive "how to read the other books" 
section will be included at the end of the LM.

- we officially have no sympathy for users who haven't read the LM.  :-)


For the record, I'm still opposed to this idea, but it's now a "weak 
reject".  I could be convinced otherwise.


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: GDP: summary and directions, 11 Sep

2007-09-11 Thread Trevor Bača
On 9/11/07, Graham Percival <[EMAIL PROTECTED]> wrote:
> If you're somewhat interested in GDP, but don't want to follow the
> 50-email monster threads, simply read any email by me that starts a subject.
>
> Not because I think my opinion is the only one that matters :).  Just
> because I'll sum up the important points, and attempt to direct future
> discussions, in emails like this.
>
>
> ALMOST-CERTAIN  (barring massive opposition, this will happen)
> ** split the Learning Manual (chapters 2-5) into a separate manual, just
> like Program Usage.

Strongly agree.


> cons: no shared index with Notation Reference.  Benefits: no shared
> index with Notation Reference.  :)besides, chapters 2-5 have hardly
> any index entries, anyway.
>
> I don't know what to do about chapter 1 (general intro, background).
> The "about this manual" will obviously stay in some form or other.  Omit
> that section from the discussion for now.  Opinions about the rest of
> chapter 1 are desired, though.
>
>
> ** combine multiple subsections into single subsections.  Something like
> an average of 3 subsections -> 1.

Strongly agree.


> Assuming there isn't significant opposition in the next 18 hours, I'll
> take a stab at creating the new merged subsections.
>
>
> ** Abandon basic/advanced/instrument/decorating/cakes division of
> notation reference.  See below as to how we do this, though.

Strongly agree. More comments below.



> NEEDS DISCUSSION
> ** should the "combined index" include entires in the "command index" ?
>   We could easily separate the "concept" index from the "combined
> index".  Would that help or hurt?

I vote for a single index.



> ( assuming that we added many more index entries; don't bother
> commenting that we don't have enough right now )
>
>
> ** combined subsections: print names of old subsections in the manual?
> For example, suppose we make a "printing repeats" section that includes
> Repeat types, Repeat syntax, Repeats and MIDI, and Manual repeat
> commands.  Do you want to only see "Printing repeats" in the table of
> contents, or do you want to see
> x.y  Printing repeats
> Repeat types
> Repeat syntax
> ...
> (without any x.y.z numbers)

I vote for the more verbose form of the TOC.



> ** Abandon decorating/cakes method of dividing the notation reference.
>
> There's sufficient support for this, but I have some remaining concerns:
> Pitch and Rhythm are more connected than Pitch and Spacing or Pitch and
> Changing defaults.
>
> Now, we could indicate this purely by the proximity of chapters -- Pitch
> is chapter 1, Spacing is chapter 27.
>
> Or, we could have a single chapter for all Notation.
> 1.  Notation
> 1.1 Pitches
> 1.2 Rhythms
> ...
> 2.  Text   (arguably as 1.25 inside Notation)
> 3.  Input and output
> 4.  Spacing
> 5.  Changing defaults
> 6.  Interfaces for programmers
>
> (exact order of the chapters to be determined)
>
> I'd rather have this kind of setup.  Yes, chapter 1 will have 25
> sections (or whatever), but IMO something like "Repeats" just shouldn't
> be at the same level as Changing defaults.

Oooh. You know what's emerging as a really nice pattern? The 24 (or
so) sections in "Notation" taken together with Text looks like it
might make an almost perfect Notation Reference. So would it be
insanely crazy to bind (metaphorically speaking) those 25 chapters
together into a single manual, cut everything else out, and call that
our Notation Reference? It sounds like it would be really beautiful.

So:

> Notation Reference
> 1 Pitches
> 2 Rhythms
> 
> 25 Text

That'd be very very cool imo.

That then leaves the question of what to do with the other stuff. What
about this?

  * Spacing: recast as a separate manual called Page Layout
  * Input and output: move to Program Usage
  * Changing defaults: move to Program Reference
  * Interfaces for programmers: move to Program Reference


That would then leave the following separate books:

  * Learning Manual (4 or 5 chapters)
  * Notation Reference (25 chapters)
  * Page Layout (handful of chapters)
  * Program Usage (6 chapters)
  * Program Reference (15 chapters)


Probably the radical idea here is elevating spacing to stauts of its
own manual. But I think it makes sense -- seems to me that I'm either
hunting notation-related grob settings xor figuring out how to move
staves and systems apart, but not both at the same time.

The coolest thing here is the possibility of a solid, 25-chapter NR.
That's slick.



-- 
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


GDP: summary and directions, 11 Sep

2007-09-11 Thread Graham Percival
If you're somewhat interested in GDP, but don't want to follow the 
50-email monster threads, simply read any email by me that starts a subject.


Not because I think my opinion is the only one that matters :).  Just 
because I'll sum up the important points, and attempt to direct future 
discussions, in emails like this.



ALMOST-CERTAIN  (barring massive opposition, this will happen)
** split the Learning Manual (chapters 2-5) into a separate manual, just 
like Program Usage.


cons: no shared index with Notation Reference.  Benefits: no shared 
index with Notation Reference.  :)besides, chapters 2-5 have hardly 
any index entries, anyway.


I don't know what to do about chapter 1 (general intro, background). 
The "about this manual" will obviously stay in some form or other.  Omit 
that section from the discussion for now.  Opinions about the rest of 
chapter 1 are desired, though.



** combine multiple subsections into single subsections.  Something like 
an average of 3 subsections -> 1.


Assuming there isn't significant opposition in the next 18 hours, I'll 
take a stab at creating the new merged subsections.



** Abandon basic/advanced/instrument/decorating/cakes division of 
notation reference.  See below as to how we do this, though.




NEEDS DISCUSSION
** should the "combined index" include entires in the "command index" ? 
 We could easily separate the "concept" index from the "combined 
index".  Would that help or hurt?


( assuming that we added many more index entries; don't bother 
commenting that we don't have enough right now )



** combined subsections: print names of old subsections in the manual?
For example, suppose we make a "printing repeats" section that includes 
Repeat types, Repeat syntax, Repeats and MIDI, and Manual repeat 
commands.  Do you want to only see "Printing repeats" in the table of 
contents, or do you want to see

x.y  Printing repeats
Repeat types
Repeat syntax
...
(without any x.y.z numbers)


** Abandon decorating/cakes method of dividing the notation reference.

There's sufficient support for this, but I have some remaining concerns: 
Pitch and Rhythm are more connected than Pitch and Spacing or Pitch and 
Changing defaults.


Now, we could indicate this purely by the proximity of chapters -- Pitch 
is chapter 1, Spacing is chapter 27.


Or, we could have a single chapter for all Notation.
1.  Notation
1.1 Pitches
1.2 Rhythms
...
2.  Text   (arguably as 1.25 inside Notation)
3.  Input and output
4.  Spacing
5.  Changing defaults
6.  Interfaces for programmers

(exact order of the chapters to be determined)

I'd rather have this kind of setup.  Yes, chapter 1 will have 25 
sections (or whatever), but IMO something like "Repeats" just shouldn't 
be at the same level as Changing defaults.



Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user