[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDP: summary and directions, 11 Sep

From: Trevor Bača
Subject: Re: GDP: summary and directions, 11 Sep
Date: Tue, 11 Sep 2007 17:18:22 -0500

On 9/11/07, Graham Percival <address@hidden> 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.

> ** 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.


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]