Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Carl D. Sorensen



On 12/15/08 1:26 PM, "Francisco Vila"  wrote:

> 2008/12/15 Carl D. Sorensen :
>> 
>> 
>> 
>> On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:
>> 
>> 
>>> Try not to form mental models.  Use the source instead.
>> 
>> Unfortunately, not very many of us understand the source completely, and so
>> we need mental models to work in LilyPond.  Of course, our mental models
>> will be incorrect in some detail, and we'll need to revise them from time to
>> time.
> 
> I have a question for the few developers that in some degree do
> understand the source code and are able to hack it, fix bugs,
> implement new features, etc.
> 
> Is the code properly commented, so that (thinking on the future) new
> people can learn from it without having to figure out all the time
> what does each function, file etc. do? Sure, I can look at it and say,
> but I want the opinion of skilled programmers.
> 
> If not, is there any chance of this to improve?

In my opinion, the code is written sufficiently well that if you're willing
to spend the time you can eventually get up to speed.

There are very few comments, but there are good function names, good
variable names, and good consistency.

For me, the biggest thing missing is an overall sense of the architecture.
It's alluded to in Erik Sandberg's thesis, and you can kind of get it
figured out  with the source code and the ongoing discussions.  But it's
still a bit challenging to get into starting from scratch.

As far as the prospects for improving the situation, I'd say they're not
great.  It seems to me that remedying the situation would require a major
time investment, and provide no new functionality, just improved
accessibility for an unnamed future round of developers.

If we had somebody who was interested in getting into the internals and also
interested in documenting things, then I think the situation might change.
But I have no idea who that person might be.

Carl



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Trevor Bača
On Mon, Dec 15, 2008 at 6:09 PM, Patrick McCarty  wrote:

> Hi Trevor,
>
> On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača  wrote:
> >
> > * OK, so based on this understanding, can somebody please correct my
> > understanding of the parsing (not the iteration, just the parsing) of the
> > following expression (which is the same as my original example #2):
> >
> >   {
> > \new Voice {
> >   c'8 c'8 c'8 c'8
> > }
> > d'8 d'8 d'8 d'8
> >   }
> >
> > If I'm understanding how the parser works, then what should result here
> is a
> > music expression that looks like this:
> >
> >  Global
> > V
> >\new Score
> > V
> >\new Staff
> > V
> >\new Voice
> > V
> > Sequential
> > V
> > \new Voice, d'8, d'8, d'8, d'8
> >V
> > Sequential
> >V
> > c'8, c'8, c'8, c'8
> >
> >
> > If I'm counting correctly, that's 15 total nodes in the expression tree.
> > Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
> > Staff and the first \new Voice are all created implicitly.
> >
> > I know that the next part in the process is iteration. But I want to stop
> > and check my understanding here: am I understanding the output of the
> parser
> > correctly at this point?
>
> I'm pretty sure this would be the result *after* iteration.
>
> The parser output can be visualized with \displayMusic.  So your
> example would look like this, using your convention above:
>
>  Sequential
>  VV
>   \new Voice   d'8, d'8, d'8, d'8
> V
>  Sequential
> V
>  c'8, c'8, c'8, c'8
>
> After this, the iteration process starts, proceeding moment by moment
> and making sure everything is placed in the correct context.  Then you
> would end up with a tree that looks like the one you posted.  I
> believe the implicit creation of contexts happens during iteration.
>
> (I could be completely wrong, but it makes sense to me).


OK, and Han-Wen confirms what you're saying, too.

Much appreciated. Going back to look at more code now ...




-- 
Trevor Bača
trevorb...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Trevor Bača
On Mon, Dec 15, 2008 at 6:21 PM, Han-Wen Nienhuys  wrote:

> On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys 
> wrote:
>
> >> I know that the next part in the process is iteration. But I want to
> stop
> >> and check my understanding here: am I understanding the output of the
> parser
> >> correctly at this point?
> >
> > No.  the \new Staff and \new Score are created at iteration time. Look
> > for path_to_acceptable_context().
>
> and to be extra clear, it's the "Staff" and "Score" contexts that get
> created.  The expression is not modified during iteration.
>

OK, got it. Will check path_to_acceptable_context( ).



-- 
Trevor Bača
trevorb...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Han-Wen Nienhuys
On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys  wrote:

>> I know that the next part in the process is iteration. But I want to stop
>> and check my understanding here: am I understanding the output of the parser
>> correctly at this point?
>
> No.  the \new Staff and \new Score are created at iteration time. Look
> for path_to_acceptable_context().

and to be extra clear, it's the "Staff" and "Score" contexts that get
created.  The expression is not modified during iteration.


-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Han-Wen Nienhuys
On Mon, Dec 15, 2008 at 8:12 PM, Trevor Bača  wrote:

> * OK, so based on this understanding, can somebody please correct my
> understanding of the parsing (not the iteration, just the parsing) of the
> following expression (which is the same as my original example #2):
>
>   {
> \new Voice {
>   c'8 c'8 c'8 c'8
> }
> d'8 d'8 d'8 d'8
>   }
>
> If I'm understanding how the parser works, then what should result here is a
> music expression that looks like this:
>
>  Global
> V
>\new Score
> V
>\new Staff
> V
>\new Voice
> V
> Sequential
> V
> \new Voice, d'8, d'8, d'8, d'8
>V
> Sequential
>V
> c'8, c'8, c'8, c'8
>
>
> If I'm counting correctly, that's 15 total nodes in the expression tree.
> Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
> Staff and the first \new Voice are all created implicitly.
>
> I know that the next part in the process is iteration. But I want to stop
> and check my understanding here: am I understanding the output of the parser
> correctly at this point?

No.  the \new Staff and \new Score are created at iteration time. Look
for path_to_acceptable_context().

Also, you can use the \displayMusic music function to get to the parse tree.
-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Patrick McCarty
Hi Trevor,

On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača  wrote:
>
> * OK, so based on this understanding, can somebody please correct my
> understanding of the parsing (not the iteration, just the parsing) of the
> following expression (which is the same as my original example #2):
>
>   {
> \new Voice {
>   c'8 c'8 c'8 c'8
> }
> d'8 d'8 d'8 d'8
>   }
>
> If I'm understanding how the parser works, then what should result here is a
> music expression that looks like this:
>
>  Global
> V
>\new Score
> V
>\new Staff
> V
>\new Voice
> V
> Sequential
> V
> \new Voice, d'8, d'8, d'8, d'8
>V
> Sequential
>V
> c'8, c'8, c'8, c'8
>
>
> If I'm counting correctly, that's 15 total nodes in the expression tree.
> Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
> Staff and the first \new Voice are all created implicitly.
>
> I know that the next part in the process is iteration. But I want to stop
> and check my understanding here: am I understanding the output of the parser
> correctly at this point?

I'm pretty sure this would be the result *after* iteration.

The parser output can be visualized with \displayMusic.  So your
example would look like this, using your convention above:

  Sequential
  VV
  \new Voice   d'8, d'8, d'8, d'8
 V
  Sequential
 V
  c'8, c'8, c'8, c'8

After this, the iteration process starts, proceeding moment by moment
and making sure everything is placed in the correct context.  Then you
would end up with a tree that looks like the one you posted.  I
believe the implicit creation of contexts happens during iteration.

(I could be completely wrong, but it makes sense to me).

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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Carl D. Sorensen



On 12/15/08 3:12 PM, "Trevor Bača"  wrote:

> On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys  wrote:
>> On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen  wrote:
 
 
 
 On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:
 
 
>> Try not to form mental models.  Use the source instead.
 
 Unfortunately, not very many of us understand the source completely, and so
 we need mental models to work in LilyPond.  Of course, our mental models
 will be incorrect in some detail, and we'll need to revise them from time
 >> to
 time.
>> 
>> sure, but if you spend a lot of time and effort on theorizing (like
>> Trevor did), you might as well invest that time & effort into looking
>> at the source code itself.
> 
> I think both are good: wanton speculation taken together with digging through
> source.
> 
> :-)
> 
> I've been digging through source this morning ... and I'm understanding much
> better ... but still unable to resolve at least one example, which I've
> included at the end of this message.
> 
> What I've found so far:
> 
> * There are 22 -iterator.cc files with Music_iterator being the base class
> from which the others all directly (or, more usually, indirectly) inherit.
> (Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are all
> popular choices to derive from, too, but all three inherit from Music_iterator
> at base.) Concrete iterators exist to iterate over regular stuff like
> EventChord and and 'simple music' (which parser.yy makes me think means
> basically notes and rests). Iterators also exist to iterate over more complex
> music expressions like grace music, time-scaled music, voltas, and music
> expressions passed to the \unfold command. My understanding of this flock of
> iterators available in the C++ source is as a type of realization of the
> visitor pattern that separates traversal from other activities like
> calculation and modification.
> 
> * Additionally, both the comments at the head of music-iterator.hh and Erik's
> thesis make it clear that the object over which the different iterators
> iterate is a (conceptual) queue of music events *that all happen at the same
> moment*. That is, when it comes time to iterate, the first thing that happens
> is that the entire context tree (starting from the Global context and
> proceeding all the way to bottom-level voice contexts) are *prepared* for
> Moment 0; then iterators iterate over all events that happen at Moment 0 *no
> matter at which level of the context tree those different events occur*. This
> helps because I was assuming (wrongly) earlier that iteration would be a
> depth-first search starting from the root of the expression tree; if that were
> the case then each context would be visited before any of its children. But,
> in fact, section 9.4 of Erik's thesis says "One of the consequences of a
> OneTimeStep stream event, is that all contexts are visited in a post-order
> tree walk; i.e., each context is visited after all its children have been
> visited." I haven't been able to verify this in the code, however.
> 
> * I've also found that a pronouncement like "\new Voice { c'4 }" is actually
> THREE expressions. The "\new Voice" is actually a music expression all by
> itself (of type ContextSpeccedMusic). There is a
> Context_specced_music_iterator defined in an eponymous .cc file and inheriting
> from Music_wrapper_iterator. The purpose of the Context_specced_music_iterator
> is to descend to the one (and only one) child that each ContextSpeccedMusic
> like "\new Voice" music have: something like Sequential is the usual option.
> So the parser (which I only understand vaguely) decomposes "\new Voice { c'4
> }" into three expressions with "\new Voice" parsed as ContextSpeccedMusic,
> with "{ }" parsed as Sequential, with "c'4" parsed as EventChord (I think).
> Further, the parser builds the resulting music expression such that
> ContextSpeccedMusic is the parent of Sequential which is, in turn, the parent
> of EventChord.
> 
> * Also, all parsing is done before any iteration is done.
> 
> * OK, so based on this understanding, can somebody please correct my
> understanding of the parsing (not the iteration, just the parsing) of the
> following expression (which is the same as my original example #2):
> 
>   {
> \new Voice {
>   c'8 c'8 c'8 c'8
> }
> d'8 d'8 d'8 d'8
>   }
> 
> If I'm understanding how the parser works, then what should result here is a
> music expression that looks like this:
> 
>  Global
> V
>\new Score
> V
>\new Staff
> V
>\new Voice
> V
> Sequential
> V
> \new Voice, d'8, d'8, d'8, d'8
>V
> Sequential
>V
> c'8, c'8, c'8, c'8
> 
> 
> If I'm counting correctly, that's 15 total nodes in the expression tree. Eight
> atomic nodes 

Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Trevor Bača
On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys  wrote:

> On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen 
> wrote:
> >
> >
> >
> > On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:
> >
> >
> >> Try not to form mental models.  Use the source instead.
> >
> > Unfortunately, not very many of us understand the source completely, and
> so
> > we need mental models to work in LilyPond.  Of course, our mental models
> > will be incorrect in some detail, and we'll need to revise them from time
> to
> > time.
>
> sure, but if you spend a lot of time and effort on theorizing (like
> Trevor did), you might as well invest that time & effort into looking
> at the source code itself.
>

I think both are good: wanton speculation taken together with digging
through source.

:-)

I've been digging through source this morning ... and I'm understanding much
better ... but still unable to resolve at least one example, which I've
included at the end of this message.

What I've found so far:

* There are 22 -iterator.cc files with Music_iterator being the base class
from which the others all directly (or, more usually, indirectly) inherit.
(Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are
all popular choices to derive from, too, but all three inherit from
Music_iterator at base.) Concrete iterators exist to iterate over regular
stuff like EventChord and and 'simple music' (which parser.yy makes me think
means basically notes and rests). Iterators also exist to iterate over more
complex music expressions like grace music, time-scaled music, voltas, and
music expressions passed to the \unfold command. My understanding of this
flock of iterators available in the C++ source is as a type of realization
of the visitor pattern that separates traversal from other activities like
calculation and modification.

* Additionally, both the comments at the head of music-iterator.hh and
Erik's thesis make it clear that the object over which the different
iterators iterate is a (conceptual) queue of music events *that all happen
at the same moment*. That is, when it comes time to iterate, the first thing
that happens is that the entire context tree (starting from the Global
context and proceeding all the way to bottom-level voice contexts) are
*prepared* for Moment 0; then iterators iterate over all events that happen
at Moment 0 *no matter at which level of the context tree those different
events occur*. This helps because I was assuming (wrongly) earlier that
iteration would be a depth-first search starting from the root of the
expression tree; if that were the case then each context would be visited
before any of its children. But, in fact, section 9.4 of Erik's thesis says
"One of the consequences of a OneTimeStep stream event, is that all contexts
are visited in a post-order tree walk; i.e., each context is visited after
all its children have been visited." I haven't been able to verify this in
the code, however.

* I've also found that a pronouncement like "\new Voice { c'4 }" is actually
THREE expressions. The "\new Voice" is actually a music expression all by
itself (of type ContextSpeccedMusic). There is a
Context_specced_music_iterator defined in an eponymous .cc file and
inheriting from Music_wrapper_iterator. The purpose of the
Context_specced_music_iterator is to descend to the one (and only one) child
that each ContextSpeccedMusic like "\new Voice" music have: something like
Sequential is the usual option. So the parser (which I only understand
vaguely) decomposes "\new Voice { c'4 }" into three expressions with "\new
Voice" parsed as ContextSpeccedMusic, with "{ }" parsed as Sequential, with
"c'4" parsed as EventChord (I think). Further, the parser builds the
resulting music expression such that ContextSpeccedMusic is the parent of
Sequential which is, in turn, the parent of EventChord.

* Also, all parsing is done before any iteration is done.

* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):

  {
\new Voice {
  c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
  }

If I'm understanding how the parser works, then what should result here is a
music expression that looks like this:

 Global
V
   \new Score
V
   \new Staff
V
   \new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
   V
Sequential
   V
c'8, c'8, c'8, c'8


If I'm counting correctly, that's 15 total nodes in the expression tree.
Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
Staff and the first \new Voice are all created implicitly.

I know that the next part in the process is iteration. But I want to stop
and check my understanding here: am I understanding the output o

code comments (was Re: Scheme function to print out active Voice context during interpretation?)

2008-12-15 Thread demery
On Mon, Dec 15, 2008, Francisco Vila  said:

> I have a question for the few developers that in some degree do
> understand the source code and are able to hack it, fix bugs,
> implement new features, etc.
> 
> Is the code properly commented, so that (thinking on the future) new
> people can learn from it without having to figure out all the time
> what does each function, file etc. do? 

Newbie to the project, but one who has been programming since 1968, this
is something I have discussed at length with other experience programmers.
 I speak in general, have yet to delve into Lp code at all, so please
forgive if this is already covered by a project policy or perhaps a gnu
policy.

Good code commenting is a challenging skill, at its best the comments on
archived code should

  Be accurate, uptodate, not telling lies.
  Explain why someone would want to invoke the code
  Describe context for use - arguments in, side effects, value(s)
returned.
  Cite sources for non-trivial algorythms used, if original, publish a
white paper to the project which can be cited.

In many cases comments will exceed the code itself.
Line-by-line comments are sometimes useful but should give information
beyond the obvious.  In a language like postscript the expected state of
the stack is ofen a useful comment.

Some projects embed text for documentation and help files with the code
itself to encourage parallel maintenance.
-- 
Dana Emery




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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Carl D. Sorensen



On 12/15/08 2:26 PM, "Han-Wen Nienhuys"  wrote:

> 2008/12/15 Carl D. Sorensen :
>> 
> 
>> I'd say it differently:
>> 
>> EXPRESSIONS:
>>   Establish the timing of music-events relative to one another
> 
>> CONTEXTS:
>>  Provide the evaluation environment (my words, not Han-Wen's) in which all
>>  music events will be evaluated when it's time to put them in the output
>>  stream (midi file or printed page).
> 
> very well said.
> 
>> The confusion comes in because, if there is no appropriate context
>> available, when LilyPond sees a music expression it will automatically
> 
> In this case,  the order of instantation depends on the order in the
> music expression, which helps people confuse context and music
> expressions too.

But it's the order in the music stream, not the input stream, isn't it?
Otherwise, why does

{
  \new Voice="foo" {
c
  }
  d
}

result in only a single voice being instantiated, but

{
  d
  \new Voice="foo" {
c
  }
}

result in two voices being instantiated?

Thanks,

Carl 



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Han-Wen Nienhuys
2008/12/15 Carl D. Sorensen :
>

> I'd say it differently:
>
> EXPRESSIONS:
>   Establish the timing of music-events relative to one another

> CONTEXTS:
>  Provide the evaluation environment (my words, not Han-Wen's) in which all
>  music events will be evaluated when it's time to put them in the output
>  stream (midi file or printed page).

very well said.

> The confusion comes in because, if there is no appropriate context
> available, when LilyPond sees a music expression it will automatically

In this case,  the order of instantation depends on the order in the
music expression, which helps people confuse context and music
expressions too.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Carl D. Sorensen



On 12/15/08 6:25 AM, "Trevor Bača"  wrote:

> On Sun, Dec 14, 2008 at 9:10 PM, Han-Wen Nienhuys  wrote:
>> On Mon, Dec 15, 2008 at 12:18 AM, Trevor Bača  wrote:

> 
> ... even though contexts do not literally nest! (Even though their iterators
> inherit from one another.)
> 
> So, to resume, this leads to the following situation:
> 
> EXPRESSIONS:
>   * exhibit syntactic nesting
>   * do not exhibit 'visual nesting' (or, maybe, 'properties nesting')
> 
> CONTEXTS:
>   * do not exhibit syntactic nesting
>   * do exhibit 'visual nesting' / 'properties nesting'
> 
> 
> Or maybe a better way of saying it:
> 
> EXPRESSIONS:
>   * exhibit syntactic nesting
>   * do not store grob properties
> 
> CONTEXTS:
>   * do not exhibit syntactic nesting
>   * do store grob properties
> 
> 
> 
> Hm. I think I get it now. Much thanks to everyone. If anyone sees more details
> missing from my working-out process, please correct.
> 
> 
> 
> Trevor.


I'd say it differently:

EXPRESSIONS:  
   Establish the timing of music-events relative to one another

So there is no difference between
{ {c4 d} {e f} {g a}}
and
{c4 d e f g a }


Similarly, there is no difference between

{ 
  {\override myObject #'prop = #value c4 d}
  {\override myObject #'prop = #new-value e f}
  {g a}
} 

and

{ 
  \override myObject #'prop = #value c4 d
  \override myObject #'prop = #new-value e f
  g a
} 

Both expressions cause the first override to apply to the current context
starting and the moment of the note c4 and the second override to apply
starting at the moment of the note e.

Note that those overrides will apply to ALL OBJECTS OF TYPE myObject IN THE
CURRENT CONTEXT, starting at those times.

So 

<<
   { c4 d \override myObject #'prop = #value e f}
   { g4 a b c}
>>

will have the overrides applied to the e, f, b, and c, but not g4 and a.
This is because it's the music moment, not the source file relative
location, that defines the applicability of the overrides.

CONTEXTS:
  Provide the evaluation environment (my words, not Han-Wen's) in which all
  music events will be evaluated when it's time to put them in the output
  stream (midi file or printed page).
  
  All properties that matter but are not tied to a particular grob reside in
  a context that contains the grob.  They may be tied to the immediate
  context containing the grob (e.g. Voice, for NoteHead) or may come from
  a context above the current context in the heierarchy (e.g. the Staff that
  contains the Voice that contains the notehead).

The confusion comes in because, if there is no appropriate context
available, when LilyPond sees a music expression it will automatically
create a context.  And there is nothing in the input syntax that tells you
when the context will be created.  So I continue to get surprised from time
to time if I don't explicitly instantiate all contexts.

I think your discussion about "naked" music expressions is illuminating, but
also potentially confusing.  It's not naked expressions that cause the
challenge, but expressions that occur at a point in the music stream (not
the input stream) where no appropriate context exists, therefore requiring
LilyPond to create one.

So if we look at your example 2:

%%% VOICE-RESOLUTION EXAMPLE 2 %%%

\version "2.11.57"

   {
  \new Voice = "foo" {
  \override Voice.NoteHead #'color = #red
 g'8
 a'8
 b'8
 c''8
  }
  d''8
  e''8
  f''8
  g''8
   }


%%% END EX 2 %%%

Looking in music stream (not input stream) order:

1a instantiate Voice foo (this takes no musical time).  Oops, we don't have
   a Staff context to hold foo, so we'll need to create one.
1b Make an override to the notehead color (this also takes no musical time)
1c engrave g'8 (this is the first thing that takes musical time)
2 engrave a'8
3 engrave b'8
4 engrave c''8

Now we're done with the music expression explicitly created in voice "foo"

5 engrave d''8 -- and since we have a voice "foo", just keep on with it.
6 engrave e''8
7 engrave f''8
8 engrave g''8


In contrast, we have Example 2+1 Note:
%%% EX 2 + 1 NOTE %%%

   {
   c'8
  \new Voice = "foo" {
  \override Voice.NoteHead #'color = #red
 g'8
 a'8
 b'8
 c''8
  }
  d''8
  e''8
  f''8
  g''8
   }

%%% END EX 2 MOD %%%


Looking at this in music stream order we have

1.  engrave c'8.  Oops, we don't have a Voice context to engrave c'8.
Therefore we need to create a Voice context for c'8.  And since we don't
have a Staff to hold the Voice, we'll need to create a Staff context as
well.
2a. create a new Voice context called foo, and assign the next expression
   to voice foo. (no musical time)
2b. engrave g'8 in foo context
3.  engrave a'8 in foo context
4.  engrave b'8 in foo context
5.  engrave c''8 in foo context

Now I'm done with the music expression that was assigned to Voice foo.

6.  engrave d''8.  It goes in the Voice context that we were using
   before we created "f

Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Graham Percival
On Mon, Dec 15, 2008 at 09:26:15PM +0100, Francisco Vila wrote:
> Is the code properly commented, so that (thinking on the future) new
> people can learn from it without having to figure out all the time
> what does each function, file etc. do? Sure, I can look at it and say,
> but I want the opinion of skilled programmers.
> 
> If not, is there any chance of this to improve?

In my (somewhat limited) experience, no matter how good the
documentation for source code, getting involved in a large project
is always easier if you have a mentor.  There's always little
details or tricks that a person can pass along that never make it
into the source docs... and besides, a mentor can tailor his
answers directly to your questions, rather than the general info
that you'd find in documentation.

That's why I was hoping that somebody would offer to be the
Frogmeister (you can have a non-silly name if you want!).  People
willing to spend time fixing bugs would gain a mentor to guide
them towards a better understanding of the source code, and the
mentor would gain more people fixing bugs in lilypond (which in
turn leads to a better program which presumably the mentor is
using :).


Sure, we could ask a skilled developer to spend 50 hours writing
better source docs... but I don't think that's a good trade-off.
Their time is so limited, and the number of potential developers
is so small, that I think that personal mentorship is the best way
to go.  Now, if one of those new developers wants to spend 5 hours
a week carefully documenting what he's learned about the internals
while fixing bugs, I certainly wouldn't object.  But of course,
that developer needs to consider the trade-offs involved: more bug
fixes?  Writing translations?  Documenting the source code?

Cheers,
- Graham


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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Francisco Vila
2008/12/15 Carl D. Sorensen :
>
>
>
> On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:
>
>
>> Try not to form mental models.  Use the source instead.
>
> Unfortunately, not very many of us understand the source completely, and so
> we need mental models to work in LilyPond.  Of course, our mental models
> will be incorrect in some detail, and we'll need to revise them from time to
> time.

I have a question for the few developers that in some degree do
understand the source code and are able to hack it, fix bugs,
implement new features, etc.

Is the code properly commented, so that (thinking on the future) new
people can learn from it without having to figure out all the time
what does each function, file etc. do? Sure, I can look at it and say,
but I want the opinion of skilled programmers.

If not, is there any chance of this to improve?

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Han-Wen Nienhuys
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen  wrote:
>
>
>
> On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:
>
>
>> Try not to form mental models.  Use the source instead.
>
> Unfortunately, not very many of us understand the source completely, and so
> we need mental models to work in LilyPond.  Of course, our mental models
> will be incorrect in some detail, and we'll need to revise them from time to
> time.

sure, but if you spend a lot of time and effort on theorizing (like
Trevor did), you might as well invest that time & effort into looking
at the source code itself.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Carl D. Sorensen



On 12/15/08 7:18 AM, "Han-Wen Nienhuys"  wrote:


> Try not to form mental models.  Use the source instead.

Unfortunately, not very many of us understand the source completely, and so
we need mental models to work in LilyPond.  Of course, our mental models
will be incorrect in some detail, and we'll need to revise them from time to
time.

But even if we use the source, we'll have to make mental models of the
source, and those may be incorrect as well.

Maybe I'm the only person who doesn't understand the full source code, but I
doubt it.  Certainly developers should understand the source code when they
modify it, and understanding the source code is preferable to an incorrect
mental model, but the idea of documentation is to allow users to form
correct mental models about program operation WITHOUT reading the source
code.

So I believe that we SHOULD form mental models, based on the docs and our
experiences, and whenever there's a weakness in the mental model, it points
to a place to improve the docs.

Thanks,

Carl



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-15 Thread Han-Wen Nienhuys
On Mon, Dec 15, 2008 at 11:25 AM, Trevor Bača  wrote:

> 6. Lily reads the terminal close } brace. Even here, I'm willing to bet,
> Lily sees no reason to kill off the explicit named "foo" context. I bet Lily
> reads the terminal close } brace and instead simply closes off the original
> music *expression*. My guess would be that not until EOF does Lily finally
> kill off the original named "foo" context.

EOF does not play any role in this. The parsing into trees of music
expressions is done beforehand, and the iteration is not connected
directly with the input file.

Each iterator contains a pointer to the context it delivers events to.
 This pointer is actually reference counted, and a context is ended
when its reference count drops to zero.

> ==> naked { } expressions DO NOT cause contexts to be instantiated at the
> open { brace and destroyed at the close } brace.

Look for descend_to_bottom().  Generally, event chords (rests, notes,
lyrics) cause a bottom context (lyrics, voice, chordnames) to be
instantiated as child of the current context.

The iterator for { } (sequential) will change its context to the one
of its child if that child has a deeper level than the current one.
so,

  \new Staff { c d }

the iterator for 'c' will create a Voice, the enclosing iterator will
change from Staff to Voice, since Voice is deeper nested in the
context tree.

> This is a super long-winded way of me coming around to Carl's mental model:

Try not to form mental models.  Use the source instead.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Han-Wen Nienhuys
On Mon, Dec 15, 2008 at 12:18 AM, Trevor Bača  wrote:

> OK, this explanation is extremely helpful. But there's still something
> deeply wrong. Han-Wen from a bit earlier:
>
> "Note that contexts do not 'nest' as you claim in a message below.
> Voice contexts cannot contain any other context."
>
> But check this out:
>
> %%% VOICE-RESOLUTION EX 3 %%%
>
> \version "2.11.65"
> \include "english.ly"
>
> \new Voice = "foo" {
>\override Voice.NoteHead #'color = #red
>\whichContext
>c'8
>cs'8
>\new Voice = "bar" {
>   \override Voice.NoteHead #'color = #blue
>   \whichContext
>   d'8
>   ef'8
>   \new Voice = "blah" {
>  \override Voice.NoteHead #'color = #green
>  \whichContext
>  e'8
>  f'8
>  fs'8
>  g'8
>   }
>   \whichContext
>   af'8
>   a'8
>}
>\whichContext
>bf'8
>b'8
> }
>
> %%% END %%%
>
> It appears as though the voice contexts are indeed nesting ... perfectly, in
> fact!

The music expressions are nested, as you can easily see from the
syntax.  However, the contexts themselves (that the music expressions
are shipping their events to) are actually running in parallel, and
are siblings in the context tree. When you do


  \new Voice =  foo {
c4
   // *
\new Voice = bar { d4 }
e4
  }

at the location marked by * there is an iterator for the outer
expression (delivering events to Voice=foo); the moment \new Voice =
bar expression is opened, this creates an iterator pointing to
Voice=bar. The outer iterator still points to foo, but it has no
events to deliver, because the inner iterator already sends them to
bar.  The moment the final note (e4) is processed, the relevant
iterator (Event_chord_iterator, if memory serves me) inherits the
destination from its parent, so the e4 goes to foo.

The foo and bar voice contexts themselves are not nested, they are
contained in their respective Staff objects and are independent.

> And, in fact, John's new \whichContext function emits the following during
> interpretation:

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Carl D. Sorensen



On 12/14/08 7:18 PM, "Trevor Bača"  wrote:

>> 
>> In examples 1 and 2+1 note, the first music occurs without a voice being
>> defined.  Therefore, LilyPond creates (instantiates) a voice.  Voice foo is
>> then created, and limited to the notes contained in the brackets.
>> 
>> In example 2, Voice foo is created before any voice is instantiated.  Then,
>> the music that comes after the voice foo definition is just applied to the
>> existing voice foo, since there is no explicit instantiation.
> 
> OK, this explanation is extremely helpful. But there's still something deeply
> wrong. Han-Wen from a bit earlier:
> 
> "Note that contexts do not 'nest' as you claim in a message below.
> Voice contexts cannot contain any other context."
> 
> But check this out:
> 
> %%% VOICE-RESOLUTION EX 3 %%%
> 
> \version "2.11.65"
> \include "english.ly  "
> 
> \new Voice = "foo" {
>\override Voice.NoteHead #'color = #red
>\whichContext
>c'8
>cs'8
>\new Voice = "bar" {
>   \override Voice.NoteHead #'color = #blue
>   \whichContext
>   d'8
>   ef'8
>   \new Voice = "blah" {
>  \override Voice.NoteHead #'color = #green
>  \whichContext
>  e'8
>  f'8
>  fs'8
>  g'8
>   }
>   \whichContext
>   af'8
>   a'8
>}
>\whichContext
>bf'8
>b'8
> }
> 
> %%% END %%%
> 
> It appears as though the voice contexts are indeed nesting ... perfectly, in
> fact!

I would not say the the contexts nest (i.e., Voice blah is not part of Voice
bar).  But music expressions can be nested, and notes are assigned to voices
by your various music expressions.

It seems to make sense to me, once I understand that there is some monkey
business that goes on when contexts (including, but not limited to Voices)
are implicitly instantiated.

My mental model (which is based on function, not on reviewing code) is that
\new Voice = "Foo" { ... }
says "Create a new context called foo, and put all the notes in this music
expression in Voice "Foo" unless something comes along to change it."

When something comes along to change it, the notes are put in a different
Voice context.  But the new Voice context is not part of the old Voice
context.  Voice is a lowest-level context.

Carl

> 
> And, in fact, John's new \whichContext function emits the following during
> interpretation:
> 
> GNU LilyPond 2.11.65
> Processing `0303.ly  '
> Parsing...
> Interpreting music...
> Current voice is foo
> 
> Current voice is bar
> 
> Current voice is blah
> 
> Current voice is bar
> 
> Current voice is foo
> 
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `0303.ps  '...
> Converting to `./0303.pdf'...
> 
> 
> This is nesting, isn't it? (How else to explain the stickiness of the grob
> overrides?) Or have I completely lost my mind?
> 
> (Han-Wen's suggestion about looking over the iterator code makes sense and
> I'll take a look right after I get in a quick jog ... because I think I might
> go mildly insane otherwise ...)
> 
> 
>  



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Trevor Bača
2008/12/14 Carl D. Sorensen 

>
>
>
> On 12/14/08 4:34 PM, "Trevor Bača"  wrote:
>
>
> >
> > I have a pretty big stockpile of tests and sometime in the next couple of
> days
> > I'll find a way to organize them and send them over. But I'd like to
> start
> > with the pair of examples that just seems absolutely pathological to me.
> Here
> > it is:
> >
> >
> > %%% VOICE-RESOLUTION EXAMPLE 1 %%%
> >
> > \version "2.11.57"
> >
> >{
> >   \override Voice.NoteHead #'color = #red
> >   c'8
> >   d'8
> >   e'8
> >   f'8
> >   \new Voice = "foo" {
> >  g'8
> >  a'8
> >  b'8
> >  c''8
> >   }
> >   d''8
> >   e''8
> >   f''8
> >   g''8
> >}
> >
> > %%% END EXAMPLE 1 %%%
> >
> > So far, so good. In example 1, LilyPond creates two voices with one
> nested
> > inside the other. We see this because the outer eight notes are red while
> the
> > inner four notes are black.
> >
> > But now look at this:
> >
> > %%% VOICE-RESOLUTION EXAMPLE 2 %%%
> >
> > \version "2.11.57"
> >
> >{
> >   \new Voice = "foo" {
> >   \override Voice.NoteHead #'color = #red
> >  g'8
> >  a'8
> >  b'8
> >  c''8
> >   }
> >   d''8
> >   e''8
> >   f''8
> >   g''8
> >}
> >
> >
> > %%% END EX 2 %%%
> >
> > (Stop and think what you'd expect here before looking at the output.)
> >
> > Here LilyPond renders a single voice! We see this because all eight notes
> are
> > red.
> >
> > Sprinkling the new \whichContext function before the first, fourth (and
> > eighth) notes in each example (where possible) makes it clear that the
> "foo"
> > context governs only the middle four notes in the first example while
> > governing *all* eight notes in the second example.
> >
> > What on earth is going on here?
> >
> > What's so odd is that if you look at example 2 and think "OK, this is all
> just
> > a single voice because the explicitly instantiated voice 'leaks' over
> into the
> > following four notes" ... then you're in for a big surprise when you add
> just
> > a single note to the beginning of the example:
> >
> > %%% EX 2 + 1 NOTE %%%
> >
> >{
> >c'8
> >   \new Voice = "foo" {
> >   \override Voice.NoteHead #'color = #red
> >  g'8
> >  a'8
> >  b'8
> >  c''8
> >   }
> >   d''8
> >   e''8
> >   f''8
> >   g''8
> >}
> >
> > %%% END EX 2 MOD %%%
> >
> > That single note at the beginning now breaks the example into two voices
> just
> > like example 1!
> >
> > Can anyone explain what's going on here?
>
> In examples 1 and 2+1 note, the first music occurs without a voice being
> defined.  Therefore, LilyPond creates (instantiates) a voice.  Voice foo is
> then created, and limited to the notes contained in the brackets.
>
> In example 2, Voice foo is created before any voice is instantiated.  Then,
> the music that comes after the voice foo definition is just applied to the
> existing voice foo, since there is no explicit instantiation.


OK, this explanation is extremely helpful. But there's still something
deeply wrong. Han-Wen from a bit earlier:

"Note that contexts do not 'nest' as you claim in a message below.
Voice contexts cannot contain any other context."

But check this out:

%%% VOICE-RESOLUTION EX 3 %%%

\version "2.11.65"
\include "english.ly"

\new Voice = "foo" {
   \override Voice.NoteHead #'color = #red
   \whichContext
   c'8
   cs'8
   \new Voice = "bar" {
  \override Voice.NoteHead #'color = #blue
  \whichContext
  d'8
  ef'8
  \new Voice = "blah" {
 \override Voice.NoteHead #'color = #green
 \whichContext
 e'8
 f'8
 fs'8
 g'8
  }
  \whichContext
  af'8
  a'8
   }
   \whichContext
   bf'8
   b'8
}

%%% END %%%

It appears as though the voice contexts are indeed nesting ... perfectly, in
fact!

And, in fact, John's new \whichContext function emits the following during
interpretation:

GNU LilyPond 2.11.65
Processing `0303.ly'
Parsing...
Interpreting music...
Current voice is foo

Current voice is bar

Current voice is blah

Current voice is bar

Current voice is foo

Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `0303.ps'...
Converting to `./0303.pdf'...


This is nesting, isn't it? (How else to explain the stickiness of the grob
overrides?) Or have I completely lost my mind?

(Han-Wen's suggestion about looking over the iterator code makes sense and
I'll take a look right after I get in a quick jog ... because I think I
might go mildly insane otherwise ...)




>
>
> This kind of inconsistency shows up lots of times when you use automatic
> instantiation of contexts.  In order to avoid these things, I've take to
> explicitly instantiating all contexts.  (And if I used multiple books in a
> score, I'd explicitly instantiate all of them as well).
>
> 

Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread John Mandereau
Le dimanche 14 décembre 2008 à 17:41 -0700, Carl D. Sorensen a écrit :
> A while ago there was a post suggesting that we do away with all implicit
> instantiation and require users to explicitly instantiate contexts.  That
> went nowhere.

I really think this feature is worth keeping it, if you recall that ly
source are often typed by hand.


>   But I think there ought to be a statement somewhere that says
> "for complex scores, it is best to explicitly instantiate all voices".  In
> my experience, that avoids lots of confusion.

IIRC it's already mentioned in Chapter 3 "Fundamental concepts" in the
Learning Manual.  However it might be good to include examples like that
one from Trevor, to show how evil implicit context instantiation is in
complex situations.  What about creating a new LSR tag "horror"? :-D

Cheers,
John



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Carl D. Sorensen



On 12/14/08 4:34 PM, "Trevor Bača"  wrote:


> 
> I have a pretty big stockpile of tests and sometime in the next couple of days
> I'll find a way to organize them and send them over. But I'd like to start
> with the pair of examples that just seems absolutely pathological to me. Here
> it is:
> 
> 
> %%% VOICE-RESOLUTION EXAMPLE 1 %%%
> 
> \version "2.11.57"
> 
>{
>   \override Voice.NoteHead #'color = #red
>   c'8
>   d'8
>   e'8
>   f'8
>   \new Voice = "foo" {
>  g'8
>  a'8
>  b'8
>  c''8
>   }
>   d''8
>   e''8
>   f''8
>   g''8
>}
> 
> %%% END EXAMPLE 1 %%%
> 
> So far, so good. In example 1, LilyPond creates two voices with one nested
> inside the other. We see this because the outer eight notes are red while the
> inner four notes are black.
> 
> But now look at this:
> 
> %%% VOICE-RESOLUTION EXAMPLE 2 %%%
> 
> \version "2.11.57"
> 
>{
>   \new Voice = "foo" {
>   \override Voice.NoteHead #'color = #red
>  g'8
>  a'8
>  b'8
>  c''8
>   }
>   d''8
>   e''8
>   f''8
>   g''8
>}
> 
> 
> %%% END EX 2 %%%
> 
> (Stop and think what you'd expect here before looking at the output.)
> 
> Here LilyPond renders a single voice! We see this because all eight notes are
> red.
> 
> Sprinkling the new \whichContext function before the first, fourth (and
> eighth) notes in each example (where possible) makes it clear that the "foo"
> context governs only the middle four notes in the first example while
> governing *all* eight notes in the second example.
> 
> What on earth is going on here?
> 
> What's so odd is that if you look at example 2 and think "OK, this is all just
> a single voice because the explicitly instantiated voice 'leaks' over into the
> following four notes" ... then you're in for a big surprise when you add just
> a single note to the beginning of the example:
> 
> %%% EX 2 + 1 NOTE %%%
> 
>{
>c'8
>   \new Voice = "foo" {
>   \override Voice.NoteHead #'color = #red
>  g'8
>  a'8
>  b'8
>  c''8
>   }
>   d''8
>   e''8
>   f''8
>   g''8
>}
> 
> %%% END EX 2 MOD %%%
> 
> That single note at the beginning now breaks the example into two voices just
> like example 1!
> 
> Can anyone explain what's going on here?

In examples 1 and 2+1 note, the first music occurs without a voice being
defined.  Therefore, LilyPond creates (instantiates) a voice.  Voice foo is
then created, and limited to the notes contained in the brackets.

In example 2, Voice foo is created before any voice is instantiated.  Then,
the music that comes after the voice foo definition is just applied to the
existing voice foo, since there is no explicit instantiation.

This kind of inconsistency shows up lots of times when you use automatic
instantiation of contexts.  In order to avoid these things, I've take to
explicitly instantiating all contexts.  (And if I used multiple books in a
score, I'd explicitly instantiate all of them as well).

Implicit instantiation is beginner-friendly but expert-unfriendly, IMO.  It
makes less for the user to type in building a simple song, but it hides the
structure of LilyPond, and makes it unnecessarily difficult to set complex
music.

A while ago there was a post suggesting that we do away with all implicit
instantiation and require users to explicitly instantiate contexts.  That
went nowhere.  But I think there ought to be a statement somewhere that says
"for complex scores, it is best to explicitly instantiate all voices".  In
my experience, that avoids lots of confusion.

Just my 0.02.

Carl



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


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Francisco Vila
2008/12/15 Trevor Bača :
> (Stop and think what you'd expect here before looking at the output.)

You're right, one expects something different at first, but then I
remembered the "Temporary polyphonic passages" section under
http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Multiple-voices#Single_002dstaff-polyphony

here says something interesting: "Here, the first expression within a
temporary polyphonic passage is placed into the Voice context which
was in use immediately before the polyphonic passage, and that same
Voice context continues after the temporary section. Other expressions
within the angle brackets are assigned to distinct temporary voices.
This allows lyrics to be assigned to one continuing voice before,
during and after a polyphonic section"

I think this applies well to your examples, not a polyphonic
situation, but still one in which a new voice context is created and
given an internal name, in order of availability. The new Voice
without any preceding notes is the same before, during and after; the
new Voice with a preceding note is a truly new context, different from
the one which that note was in. Does it have any sense?
-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Han-Wen Nienhuys
On Sun, Dec 14, 2008 at 4:42 PM, Trevor Bača  wrote:

> [The motivation is that I'm researching the way that LilyPond determines
> which voice music events are assigned to ... from a user's perspective based
> solely on looking at input files. Voice-resolution in the example above is
> of course quite clear; voice-resolution when there are multiple anonymous
> voices, possibly in parallel, has become extremely tricky as I've written
> more and more test files, all of which I'll be happy to post if anyone else
> is interested in that sort of thing.]


That sounds like a very circumspect way to find this out.  Check out
lily/*-iterator.cc;  in particular, look for calls to

void Music_iterator::descend_to_child (Context *child_report)
void Music_iterator::set_context (..)

which explain some of the things you are seeing.

Note that contexts do not 'nest' as you claim in a message below.
Voice contexts cannot contain any other context.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread John Mandereau
Hi Trevor!
Le dimanche 14 décembre 2008 à 12:42 -0600, Trevor Bača a écrit :
> Is there a way to print out the name (or other identity) of the
> currently active voice just before any given note or rest in an input
> file?

> Does something like this exist?

I haven't found such a function in Lily sources and docs, try these two
music functions (freely inspired from barNumberCheck definition):

whichContext = #(define-music-function (parser location) ()
 (make-music 'ApplyContext 
  'origin location
  'procedure (
lambda (c)
(display
 (string-append
  "\nCurrent voice is "
  (ly:context-id c)
  "\n")

locationWhichContext = #(define-music-function (parser location) ()
 (make-music 'ApplyContext 
  'origin location
  'procedure (
lambda (c)
(display
 (ly:input-message location
  "current voice is ~a"
  (ly:context-id c))

It's also possible to make Scheme avatars of these functions, but then
they would need to take the location as an argument.

This should be added to the docs IMHO; should this be added in LSR, the
manual or the (yet to be written) docstring of applyContext?


> [The motivation is that I'm researching the way that LilyPond
> determines which voice music events are assigned to ... from a user's
> perspective based solely on looking at input files. Voice-resolution
> in the example above is of course quite clear; voice-resolution when
> there are multiple anonymous voices, possibly in parallel, has become
> extremely tricky as I've written more and more test files, all of
> which I'll be happy to post if anyone else is interested in that sort
> of thing.]

Please do :-) I guess some of these tests may be added to LSR.

Hope this helps,
John



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


Scheme function to print out active Voice context during interpretation?

2008-12-14 Thread Trevor Bača
Hi,

Is there a way to print out the name (or other identity) of the currently
active voice just before any given note or rest in an input file?

I'm thinking something like this (please pardon the faux-Scheme) ...


\new Staff <<
   \context Voice = "foo" {
   c'4
   #(print (something->string (ly:get-active-voice)))
   c'4
   }
   \context Voice = "bar" {
   d'4
   #(print (something->string (ly:get-active-voice)))
   d'4
   }
>>


... where the first print would emit the string "foo" and the second print
would emit the string "bar" as LilyPond interprets the input.

Does something like this exist?

[The motivation is that I'm researching the way that LilyPond determines
which voice music events are assigned to ... from a user's perspective based
solely on looking at input files. Voice-resolution in the example above is
of course quite clear; voice-resolution when there are multiple anonymous
voices, possibly in parallel, has become extremely tricky as I've written
more and more test files, all of which I'll be happy to post if anyone else
is interested in that sort of thing.]


Trevor.


-- 
Trevor Bača
trevorb...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel