patch; scm/music-types.scm

[Han-Wen Nienhuys]

address@hidden writes:
> Hi guys,
> I'm having a bit of trouble filling in the descriptions for all the
> events here.  In the first place, I have no clue what some of these
> things do.

> BassFigureEvent?

Bass figure support see input/test/figured-bass (or somesuch).

> BusyPlayingEvent?

Used internally to synchronise notes and lyrics for \addlyrics.  See
lyric-combine-music-iterator.cc

> Then there are some things which I can make guesses about.  BarCheck
> obviously has something to do with |  but I don't know exactly
> what the relationship is.

| is a barcheck. You can tell from lily/parser.yy

        '|'      {

                $$ = MY_MAKE_MUSIC("BarCheck");
                $$->set_spot (THIS->here_input ());
        }

> How can I learn what these things do?  I can only think of two
> possibilities: asking a whole bunch of questions on this list, or doing
> some heavy source diving (but I lack the programming background to do
> this).

Well you could do some light source diving and ask around if you still
can't find it.

> Finally, I'm not certain who I'm writing the descriptions for.  I guess
> these docs aren't for newbies, but I can assume that people have read
> the user manual?  For example, look at my entry for ArticulationEvent or
> CrescendoEvent... is that too much information?  Too little information?
> Not the right type?

1. The point is that the 1.7 input architecture has been changed a
little to allow much more powerful Scheme functions for manipulating
and creating music. The innards of this music is stored in these
objects that are described in music-types.scm, so anyone attempting
such Scheme functions must be able to lookup what types of music there
are, and how to manipulate them.

Right now you have to do deep source diving to figure that out. If you
did that once and wrote down the results, that would save a lot of
diving for newbies :) .

The target group would be skilled users, that only need a few words to
put them on the right track.

2. To top that it would be nice to have syntax descriptions for all music
things (just how it is entered, not so much how to use it, that's a
job for a user manual), so that we always have a generated "reference
manual" for the input syntax.

3. Finally, a pointer into the reference manual and/or glossary, if
applicable, would be nice, eg. an index keyword, or a node reference.
(Maybe we should add a macro for that, eg. @usermanref{Relative
octaves}.)

4. Perhaps it would be a good idea to separate these three
   descriptions into paragraphs


"Description: Tie event produces ties between notes.

Syntax: @address@hidden ~ @var{note}} or @code{<address@hidden> ~
<address@hidden>} in \notes mode.

See also: @usermanref{Ties}, @glossaryref{Tie}"

> Here's my attempt at it, from AbortEvent to CrescendoEvent.  The
> ones that are blank are things which I couldn't guess.  I estimate
> that I could fill in about half of the remaining descriptions, if my
> earlier descriptions are the right kind of thing.

Ok, thanks. I've put it in. Some notes:

- AutoChangeMusic: used fror \autochange SOMETHING

- Beam syntax: [ ] (not \[ \])

- ContextSpeccedMusic: \context Foo=Bar SOMETHING 

(both AutoChangeMusic and ContextSpeccedMusic are a "Music wrapper",
that take a single SOMETHING music object as argument.. "Child" object
is stored in music-property 'element .)

-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen