Discussions on LilyPond development

headers Erlend Aasland | 1 Feb 2006 03:16

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

On Wednesday 01 February 2006 13.43, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > I have a feeling that \relative hacks is something very relevant (I
> > believe that shorthands such as the \interpolate{} thing can be very
> > valuable in the hands of an experienced lily user). The important thing
> > is that \relative should recurse into the parameters, not the return
> > value, of a function.
>
> the problem I have with this is that every other construct (eg. \times,
> \transpose) works directly. We can have "delayed" evaluation of music
> functions, but then every other construct needs to be done lazily too.
>
> Can you see a way to achieve that?

Yes, just represent those commands as music functions internally. E.g., 
\transpose creates a MusicFunction expression, with a list of two pitches and 
one Music as its 'elements (or 'arguments, I haven't decided yet), and 
'to-music-callback is set to ly:music-transpose (or rather, to a wrapper 
around that function).

--

-- 
Erik

Erik Sandberg wrote:
> I have a feeling that \relative hacks is something very relevant (I believe 
> that shorthands such as the \interpolate{} thing can be very valuable in the 
> hands of an experienced lily user). The important thing is that \relative 
> should recurse into the parameters, not the return value, of a function.

the problem I have with this is that every other construct (eg. \times, 
\transpose) works directly. We can have "delayed" evaluation of music 
functions, but then every other construct needs to be done lazily too.

Can you see a way to achieve that?

--

-- 
  Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

On Monday 30 January 2006 01.01, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > It could maybe be fixed by viewing variables as zero-parameter functions
> > somehow (but it would require "declaring" them globally before using
> > them).
>
> It's still a large change. I'm not yet convinced that getting cute
> \relative hacks is worth the breakage, and doing it from
> toplevel-music-functions does not seem very elegant to me.

I have a feeling that \relative hacks is something very relevant (I believe 
that shorthands such as the \interpolate{} thing can be very valuable in the 
hands of an experienced lily user). The important thing is that \relative 
should recurse into the parameters, not the return value, of a function.

My initial idea was to do a pure hack, where the partcombine function would 
insert a \relative c' around its arguments (guessing that the previous note 
was a c'), and then use a to-relative-callback which transposed the return 
value if the guess was incorrect. That hack is a lot dirtier, and it only 
works for functions that are 'linear' in transposition (i.e., functions f 
such that \transpose p1 p2 \f mus = \f \transpose p1 p2 mus).

An alternative is to hard-code \relative into the parser, always remembering 
the last entered pitch. That'd however be rather inelegant, and break 
backward compatibility.

I haven't figured out _anything_ except the new local variable assignment 
thing, that would break by postponing function calls to after parsing. (this 
is a good reason to make a final decision pretty soon, before 2.8)

With some minor chanes, the postponing of function calls would also make it 
possible to create recursive music expressions:

% music function written in quasi-code
func = #(lamda (m) (if (> (highest-pitch m) c'') (d''8) (\transpose c d \m)))
\forwardDeclare "foo"
foo = \relative { c8 \func \foo c8 }

=> foo = { c'8 d' e' fis' gis' ais' bis' cisis'' d'' cisis'' bis' ais' gis' 
fis' e' d' c' }

I'm not sure if this kind of feature would ever be useful, though.

It would also be possible to could construct a \for function with a rather 
clean syntax, something like:

\forwardDeclare "i"
\for "i" { c d e f} { e \i e e}
=> { { e c e e } { e d e e } {e e e e } {e f e e } }

A similar function can be written already, but it will have to work in a 
slightly different way, and the usefulness of the command is limited as long 
as \relative doesn't recurse into function parameters.

--

-- 
Erik

On 31-Jan-06, at 12:55 AM, Erik Sandberg wrote:

> BTW, is the meaning of the word 'indent' well-known among 
> non-programmers? In

Excellent point!  I think I'll reformat the whole chapter 4 with this 
distinction (programmers vs. non-programmers) in mind.

> - The outer braces should be << >> (using {} generates incorrect 
> output)

Thanks, fixed.

> - The following is a bit misleading:
>       \context Staff = singer <<
>         \context Voice = vocal { \melody }
>         \lyricsto vocal \new Lyrics { \text }
>>>
> The lyrics context is not part of the Staff context,

Really?  That's a pity; it would help to keep things simple.  Anyway, 
thanks!  I didn't know that.

> The correct way would be:
>
>       \context Staff = singer <<
>         \context Voice = vocal { \melody }
>>>
>       \new Lyrics \lyricsto vocal { \text }

Thanks, fixed in CVS.

> (I think there's a minor pedagogical point in saying \new Lyrics before
> \lyricsto, since the \new Lyrics really isn't a relevant argument of 
> the
> music function, and because all other contexts start with context 
> names)
>
> You could of course use \addlyrics instead.

I still haven't used lyrics -- what do you recommend?  We should 
probably use the same thing here as we do in the Example templates... 
what should those ones be?

Cheers,
- Graham

Erik Sandberg wrote:
> Yes, just represent those commands as music functions internally. E.g., 
> \transpose creates a MusicFunction expression, with a list of two pitches and 
> one Music as its 'elements (or 'arguments, I haven't decided yet), and 
> 'to-music-callback is set to ly:music-transpose (or rather, to a wrapper 
> around that function).

OK, so we create all music expressions/events as "Music promises", which 
expand into Music objects via some function as soon as they are 
inspected, but have \relative deal with music-promises directly?

I think there should be a fool-proof (forced from the C++ side) way to 
make sure that all Music objects are instantiated in a 'delayed' way.

Nicolas, what do you think?   I think that, in a sense, \relative would 
be analogous to a Scheme macro, and the rest would be like function calls.

Hmm, maybe we should even take the distinction to the extreme: have both 
music functions and music macros. Nicolas?

Regarding the \parallelMusic: we should make sure that noone uses

  \parallelMusic #'(A B)

to define identifiers inside music expressions. We could just leave this 
aspect undocumented, or put a big warning sign that this will change in 
the near future.

--

-- 
  Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

Erik Sandberg wrote:
> Yes, just represent those commands as music functions internally. E.g., 
> \transpose creates a MusicFunction expression, with a list of two pitches and 
> one Music as its 'elements (or 'arguments, I haven't decided yet), and 
> 'to-music-callback is set to ly:music-transpose (or rather, to a wrapper 
> around that function).
> 

just for the record, I think that this will be post 2.8 stuff. I have 
some plans for reorganizing the input format, and this would also fit 
nicely for the 3.0 release.

--

-- 
  Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

The first thing I see in NEWS.html are bad images: All lilypond music
examples are cropped incorrectly at the left side!  This is really bad
advertisement, especially for newcomers.  Any chance that this gets
fixed?

    Werner

From: Werner LEMBERG <wl <at> gnu.org>
Subject: bad images in NEWS.html
Date: Thu, 02 Feb 2006 07:20:19 +0100 (CET)

> The first thing I see in NEWS.html are bad images:

To be more specific, I mean this file:

  http://lilypond.org/doc/v2.7/Documentation/topdocs/NEWS.html

     Werner

Citerar Han-Wen Nienhuys <hanwen <at> xs4all.nl>:

> Erik Sandberg wrote:
> > Yes, just represent those commands as music functions internally. E.g., 
> > \transpose creates a MusicFunction expression, with a list of two pitches
> and 
> > one Music as its 'elements (or 'arguments, I haven't decided yet), and 
> > 'to-music-callback is set to ly:music-transpose (or rather, to a wrapper 
> > around that function).
> 
> OK, so we create all music expressions/events as "Music promises", which 
> expand into Music objects via some function as soon as they are 
> inspected, but have \relative deal with music-promises directly?

The way I view it, only functions and variables would need to be "promises".

> I think there should be a fool-proof (forced from the C++ side) way to 
> make sure that all Music objects are instantiated in a 'delayed' way.

Interesting idea, but I don't understand it fully (how would \relative
instantiate music, if the C++ code prohibits that?).

> Nicolas, what do you think?   I think that, in a sense, \relative would 
> be analogous to a Scheme macro, and the rest would be like function calls.
> 
> Hmm, maybe we should even take the distinction to the extreme: have both 
> music functions and music macros. Nicolas?

Sounds like a sound idea. Apart from \relative, it would be nice to also have
\score, \include, \header etc. as macros.

In this case, IWBN if a ly file always was a single music expression in a
sense,
so one would in principle be allowed to place braces around the top-level ly
file, like:

{ foo = { c d e }
\score {
  \foo
  \header {...}
}
}

I this kind of syntax would make it possible to improve the language in the
future; I'm thinking of making a \lambda music function (not macro) possible.

There's the question of whether function parameters should have some kind of
parentheses around them. It _might_ be possible to introduce \lambda without
requiring this, there is however a risk of dirt in the grammar.

> Regarding the \parallelMusic: we should make sure that noone uses
> 
>   \parallelMusic #'(A B)
> 
> to define identifiers inside music expressions. We could just leave this 
> aspect undocumented, or put a big warning sign that this will change in 
> the near future.

Well, we could just even hard-code the command into the parser for now
(prohibiting people from using it).

It would be nice if we could have a discussion on post-3.0 syntax before
releasing 2.8: This would increase the possibilities to do some wise
intermediate syntax changes for 2.8, similar to the 1.6->1.8->2.0 chord syntax
changes. (seems that you already have done this with \score syntax, but we
might need more, depending on the plans for 3.0)

Erik

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28

126	May 2013
467	April 2013
586	March 2013
364	February 2013
337	January 2013
380	December 2012
337	November 2012
834	October 2012
1175	September 2012
876	August 2012
905	July 2012
579	June 2012
568	May 2012
589	April 2012
688	March 2012
825	February 2012
1049	January 2012
727	December 2011
784	November 2011
635	October 2011
1148	September 2011
1282	August 2011
1306	July 2011
840	June 2011
454	May 2011
508	April 2011
643	March 2011
752	February 2011
772	January 2011
733	December 2010
676	November 2010
654	October 2010
399	September 2010
350	August 2010
424	July 2010
471	June 2010
583	May 2010
497	April 2010
444	March 2010
414	February 2010
629	January 2010
892	December 2009
715	November 2009
300	October 2009
651	September 2009
1078	August 2009
986	July 2009
685	June 2009
539	May 2009
368	April 2009
380	March 2009
337	February 2009
468	January 2009
734	December 2008
417	November 2008
382	October 2008
469	September 2008
531	August 2008
399	July 2008
287	June 2008
367	May 2008
327	April 2008
249	March 2008
211	February 2008
239	January 2008
227	December 2007
213	November 2007
238	October 2007
446	September 2007
190	August 2007
140	July 2007
93	June 2007
88	May 2007
163	April 2007
156	March 2007
258	February 2007
526	January 2007
428	December 2006
297	November 2006
231	October 2006
164	September 2006
159	August 2006
167	July 2006
384	June 2006
436	May 2006
420	April 2006
299	March 2006
313	February 2006
185	January 2006
138	December 2005
126	November 2005
193	October 2005
145	September 2005
369	August 2005
243	July 2005
340	June 2005
367	May 2005
321	April 2005
286	March 2005
362	February 2005
280	January 2005
177	December 2004
354	November 2004
274	October 2004
357	September 2004
223	August 2004
206	July 2004
123	June 2004
191	May 2004
213	April 2004
359	March 2004
257	February 2004
226	January 2004
42	December 2003
44	November 2003
47	October 2003
153	September 2003
141	August 2003
133	July 2003
109	June 2003
72	May 2003
49	April 2003
20	March 2003
11	February 2003
34	January 2003
101	December 2002
56	November 2002
89	October 2002
207	September 2002
226	August 2002
199	July 2002
186	June 2002
148	May 2002
149	April 2002
49	March 2002

Re: Build fails because of No. hack

Re: music function refactoring

Re: music function refactoring

Re: music function refactoring

Re: review new info on file layout

music macros?

Re: music function refactoring

bad images in NEWS.html

Re: bad images in NEWS.html

Re: music macros?