lilypond-devel
[Top][All Lists]
Advanced

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

Re: Universe of syntax possibilities, ONLY to skip over non-notes/chords


From: Carl Sorensen
Subject: Re: Universe of syntax possibilities, ONLY to skip over non-notes/chords
Date: Sat, 13 Nov 2010 07:32:06 -0700



On 11/13/10 5:50 AM, "David Santamauro" <address@hidden> wrote:

> 
> 
> Hi Carl,
> 
> very interesting information...
> 
> On Sat, 13 Nov 2010 03:12:40 -0700
> Carl Sorensen <address@hidden> wrote:
> 
>> 
>> An easier approach might be to write an engraver
> 
> Pardon my ignorance, but is this something like what articulate.ly[1]
> does or are you referring to some deeper, possible c++ level? E.g.,
> 
> \score {
>   \unfoldRepeats \myCustomEngraver
> }

LilyPond music exists in at least three different states.

The first state is in the form of lilypond input music expressions.  That's
what you see in the file.

The second state is in the form of scheme music expressions.  The job of the
parser is to convert lilypond music expressions into scheme music
expressions.  Most user-defined music functions are evaluated during
parsing.  Articulate is written as a music function, so it operates on music
stored as scheme music expressions.

The third state is in the form of stream events. The scheme music is
converted to stream events by iterators.  Iterators traverse the scheme
music tree in musical order, and send events to translators (engravers and
performers).  These translators create layout objects, including grobs.  In
addition to listening to events, translators can acknowledge grobs.
Engravers can be written in either C++ or scheme.

Jeff's original proposal was to create an alternate parser to deal with
input music expressions.  I don't think that's a very wise thing to do.

My response was to create a new engraver to deal with events and/or grobs.
That may be the easiest way to do it.

Your suggestion to do something like articulate as a music function would
also work.  I think it's a bit more work, because it requires one to
understand and parse the whole music expression organizations (e.g.
sequential music, simultaneous music, chords, etc.).  But it's certainly
doable.

The nice thing about using engravers is that when you get to the
stop_translation_timestep phase of the engraver, you have a list of all the
grobs taking place at that timestep.  It's the easiest way I know of to get
the music in order.

> 
> 
> Is there already a 'test' engraver that simply outputs to stdout as a
> simple prototype 

That would probably be a good idea, but one has not yet been written.

Thanks,

Carl




reply via email to

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