Re: [frogs] [PATCH] : Supply missing documentation strings in music-function-init.ly

[Carl Sorensen]

Neil already pushed it yesterday.

Thanks,

Carl


On 10/26/09 12:47 PM, "Ian Hulin"  wrote:

> Neil Puttock wrote:
>> 2009/10/25 Ian Hulin :
>>> Thanks for the feedback, Neil.  Is this OK to push now?
>> 
>> Sure is.
>> 
>> Thanks,
>> Neil
> Woo-hoo, green light! Could someone with the relevant privileges push
> this to the main git repository, please?
> 
> Cheers,
> 
> Ian



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

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Carl Sorensen]

On 10/26/09 1:47 PM, "Ian Hulin"  wrote:

> Carl Sorensen wrote:
>> 
>> 
>> On 10/23/09 5:52 PM, "Ian Hulin"  wrote:
>> 

>> 
>>> \bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
>>> structure.  I have used this so we can we could eventually allow users to do
>>> stuff like the following (controlling the names used to open the midi files
>>> is
>>> not part of the current patch).
>>> \book {
>>> \bookOutputName "My-Homeland"
>>> \score {
>>>\bookOutputName "Vysehrad"
>>>   music-declarations ...
>>>   \midi{
>>>   % midi file gets written to Vysehrad.mid(i)
>>>   }
>>>   \layout{
>>>   }
>>>\bookOutputNameRevert
>>> }
>>> \score {
>>> \bookOuputName "Vltava"
>>> ...
>>> \midi {
>>> % midi file is written to Vltava.mid(i)
>>> }
>>> }
>>> .
>>> .
>>> . 
>> 
>> This code doesn't demonstrate the need for \bookOutputNameRevert; the same
>> thing would happen if the \bookOutputNameRevert were omitted, as far as I
>> can tell.
>> 
> 
> Consider this in one file Smetana.ly:
> 
> ;;  Music for Má Vlast
> \book {
> \bookOutputName "My-Homeland"
> \score {
> \bookOutputName "Vyšehrad"
> ...
> }
> \score {
> \bookOutputName "Vltava"
> ...
> }
> %%   three more \score blocks setting the output name
> \score {
> \bookOutputName "Blanik"
> ...
> }
> }
> 
> ;; Music for "Bartered Bride Overure"
> \book {
> % No \bookOutputName here
> % Until scoping for \book blocks is sorted out,
> % this block will get output to Blanik.pdf and Blanik.midi.
> \score {
> ...
> }
> }  
> 

Yes, I understand the issues with (the lack of) scoping of bookOutputNames.

But where in this example would you put \bookOutputNameRevert (or
\bookOutputNameUsePrevious)?

If you put it after the the last score in My-Homeland,  then I guess it
would go to the default values again.

It seems to me the problem could easily be resolved here by just giving a
bookOutputName to Bartered Bride Overture (and if one is using
bookOutputName in some of the books, it seems reasonable to use it for all
of the books).  It also seems that one could just set it to "" in order to
use the default, and there wouldn't be a need for a separate revert.

Also, following on with the discussion we had on the earlier message, if
every \book block initializes the bookOutputName to the default value, that
implements a scoping rule, IIUC.

HTH,

Carl



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

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Graham Percival]

On Mon, Oct 26, 2009 at 03:53:55PM -0600, Carl Sorensen wrote:
> 
> On 10/26/09 3:09 PM, "Graham Percival"  wrote:
> 
> > No!  Having \set vs. \setBlahBlah is a nightmare for newbies.
> > Sorry, my brain is fried at the moment, so I have no alternative
> > suggestions.
> 
> The problem is that Ian wants to really have a revert option (and we can't
> use revert either, because of confusion with \revert).
> 
> \bookOutputSuffix
> \bookOutputName
> \bookOutputNameUsePrevious  (I hate the english of this, but it sorts where
> it belongs and it captures the intent).

I like these.  And it fits with some proposals for GLISS, which
will start when GUB or the new website is finished.

Cheers,
- Graham


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

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Carl Sorensen]

On 10/26/09 3:09 PM, "Graham Percival"  wrote:

> On Mon, Oct 26, 2009 at 12:11:55PM -0600, Carl Sorensen wrote:
>> 
>> On 10/23/09 5:52 PM, "Ian Hulin"  wrote:
>> 
>>> music-functions-init.ly adds three new functions
>>> * \bookOutputSuffix - to set the output suffix for the \book block
>>> * \bookOutputName - to set output filename for the current \book block
>>> * \bookOuptutNameRevert - to restore the the output filename to the value
>>> prior to that of the last \bookOuputName call.
>> 
>> I think these functions should be named
>> 
>> \setBookOutputSuffix
>> \setBookOutputName
>> \revertBookOutputName
> 
> No!  Having \set vs. \setBlahBlah is a nightmare for newbies.
> Sorry, my brain is fried at the moment, so I have no alternative
> suggestions.

You're right, of course.

The problem is that Ian wants to really have a revert option (and we can't
use revert either, because of confusion with \revert).

How about

\useBookOuptutSuffix
\useBookOutputName
\usePreviousBookOutputName

or 

\bookOutputSuffix
\bookOutputName
\bookOutputNameUsePrevious  (I hate the english of this, but it sorts where
it belongs and it captures the intent).

Carl



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

Re: Need interface/data structure design advice

[Carl Sorensen]

On 10/26/09 1:41 PM, "David Kastrup"  wrote:

> 
> 
> Hi,
> 
> I am working on accordion register symbol typesetting right now.  Up to
> now, there are some font elements in the font, and some basic hackish
> stuff in the snippets.
> 
> Right now I am stuck in the interfaces.  The focus right now is discant
> registers, other registers have similar concerns.
> 
> Now here is the basic data I have to deal with:
> 
> The register symbols have a basic symbol, and they have dots that are on
> or off.
> 
> (cf http://en.wikipedia.org/wiki/Accordion_reed_ranks__switches
>  >)
> 
> The German page
> http://de.wikipedia.org/wiki/Register_(Akkordeon)> has quite a few
> more details with regard to naming schemes.
> 
> The dots correspond to reed banks.  For some accordions, there are
> unusual reed banks (and dots), so the user should be able to add dot
> coordinates and corresponding data.

I'd lean towards something like

bank-properties , an alist containing the properties of a bank:

((x-offset . bank-x-offset)
 (y-offset . bank-y-offset)
 (pitch-offset . bank-pitch-offset)
 (midi-intsrument . bank-midi-instrument))

By making it an alist, any of the properties can be left out and filled in
by default, and the order of the properties doesn't matter.  It's the way
most LilyPond properties are set.

Alternatively, bank-properties could be a list:

(bank-x-offset bank-y-offset bank-pitch-offset bank-midi-instrument)

This has less typing, but makes ordering important.  It also requires
non-standard accessor functions to get particular values, whereas the alist
can use standard LilyPond accessor functions (like chain-assoc-get).

The available banks would then be an alist of banks and bank-properties:
(define my-available-banks
'((bank1 . ((x-offset . x-offset1)
(y-offset . y-offset1)
(pitch-offset . pitch-offset1)
(midi-instrument . midi-instrument1)))
  (bank2 . ((x-offset . x-offset2)
(y-offset . y-offset2)
(pitch-offset . pitch-offset2)
(midi-instrument . midi-instrument2)))
  (bank3 . ((x-offset . x-offset3)
(y-offset . y-offset3)
(pitch-offset . pitch-offset3)
(midi-instrument . midi-instrument3)

And it's really straightforward to add an additional bank.


> 
> For each dot, there will be a set of coordinates where to draw it on the
> accordion symbol, a default midi instrument and a default pitch
> adjustment: accordions have reed banks that are one octave off, but they
> also have reed banks that are only a few cents off-pitch, usually with a
> linear tuning curve (linear in cents/semitone, with the lower notes
> being more cents off and the higher less).
> 
> So we want a default midi instrument per reed bank, with an optional
> fine-tuning (translated in pitch bend).
> 
> Now to registers: a register is a combination of reed banks (and dots on
> the symbol).  A register has a name.  I don't think that cleverness is
> warranted for pulling apart register names like "101" or "MM" or
> whatever else: the combinations are few enough that it is fine not to
> pick apart those strings but just use them as identifier for one
> register each.

Here I'd have a register that's a list of the banks that apply:

(bank1 bank3 bank7)

accordion-registers would then be an alist that contains all of the
available registers:

(define my-accordion-registers
'((register1 . (bank1 bank3 bank7))
  (register2 . (bank2))
  (register3 . (bank4 bank6))
  (register4 . (bank 5

Again, it's really straightforward to add an additional register.

An accordion could be defined as an alist containing available banks and
available registers:

(define my-accordion
  '((available-banks . my-available-banks)
(available-registers . my-accordion-registers)))


One could either define a set of different accordions, each with the
appropriate banks and registers; or define a full set of accordion banks and
accordion registers that cover all possible accordions.

> 
> Registers should have an override regarding the used midi instruments in
> order to adapt them to available patches.

I'm not sure what this means, so I can't really comment on it.
> 
> Now there is an additional complication: if the lowest used reed bank is
> not at nominal pitch (namely either 16" or 4"), notation and sound are
> not in accord.  It is common to write at pitch and affix an "8" or more
> wordy equivalent at the top or bottom (depending on whether to play one
> octave lower or higher than written) of the register symbol to indicate
> that one should play one octave higher/lower in order to get pitch.  If
> this octavation (in playing) is dissolved, there is "loco" at the next
> register symbol.
> 
> So usually the register symbol should interact in some manner with
> \ottava specs.  Accordions are usually limited enough in range not to
> need ottava notation in addition to registration: 

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Graham Percival]

On Mon, Oct 26, 2009 at 12:11:55PM -0600, Carl Sorensen wrote:
> 
> On 10/23/09 5:52 PM, "Ian Hulin"  wrote:
> 
> > music-functions-init.ly adds three new functions
> > * \bookOutputSuffix - to set the output suffix for the \book block
> > * \bookOutputName - to set output filename for the current \book block
> > * \bookOuptutNameRevert - to restore the the output filename to the value
> > prior to that of the last \bookOuputName call.
> 
> I think these functions should be named
> 
> \setBookOutputSuffix
> \setBookOutputName
> \revertBookOutputName

No!  Having \set vs. \setBlahBlah is a nightmare for newbies.
Sorry, my brain is fried at the moment, so I have no alternative
suggestions.

Cheers,
- Graham


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

Re: documentation: unreadable html tables

[Graham Percival]

On Mon, Oct 26, 2009 at 07:18:54AM -0700, -Eluze wrote:
> 
> Graham Percival-3 wrote:
> > The languages involved are perl, texinfo, and html.  In
> > particular, the documentation is written in texinfo; a perl script
> > (called texi2html) interprets the texinfo files, and outputs html.
> > 
> i have some experience with html; texinfo and perl are fully new to me!
> furthermore i am working on windows - hope this is not a problem!?

Working on windows will be no problem.

> > The first step is to reproduce the problem in a small example.
> > Try making a tiny texinfo file, which contains the same kind of
> > table as in pitches.itely.  I think it's a @multitable, but I'm
> > not 100% certain.
> 
> i will need to know where i can download this file from!

Please see the Contributor's Guide, particularly the section about
windows git.

> altogether i think it will take me some time to get familiar with these new
> components and surroundings!
> if anybody could advise a practical tutorial both for texinfo and perl this
> could help a lot.

You don't need a lot of texinfo; a seven-line file should be fine
for your testing.  As for perl, there are many tutorials on the
internet devoted to it.

Cheers,
- Graham


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

Re: [PATCH] Fix typo in build script

[Graham Percival]

Thanks, applied.

Cheers,
- Graham

On Mon, Oct 26, 2009 at 01:13:17PM +0100, Francisco Vila wrote:
> Hello,
> 
> this patch fixes a potential bug in scripts/build/grand-replace.py
> 
> -- 
> Francisco Vila. Badajoz (Spain)
> www.paconet.org
> www.csmbadajoz.com

> From f253378959983a4777c8169f0011eda5413c5c4e Mon Sep 17 00:00:00 2001
> From: Francisco Vila 
> Date: Mon, 26 Oct 2009 13:05:50 +0100
> Subject: [PATCH] Fix Spanish filename typo in update script.
> 
> ---
>  scripts/build/grand-replace.py |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/build/grand-replace.py b/scripts/build/grand-replace.py
> index dc0697d..abd67ba 100644
> --- a/scripts/build/grand-replace.py
> +++ b/scripts/build/grand-replace.py
> @@ -46,7 +46,7 @@ copied_files = [
>  'txi-de.tex',
>  'txi-en.tex',
>  'txi-fr.tex',
> -'txi-sf.tex',
> +'txi-es.tex',
>  ]
>  
>  def main ():
> -- 
> 1.5.6.3
> 

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



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

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Ian Hulin]

Carl Sorensen wrote:



On 10/23/09 5:52 PM, "Ian Hulin"  wrote:


init.ly - Add new parser variables book-output-suffix and book-filename
initialized as #f and empty queue/stack structure.

music-functions-init.ly adds three new functions
* \bookOutputSuffix - to set the output suffix for the \book block
* \bookOutputName - to set output filename for the current \book block
* \bookOuptutNameRevert - to restore the the output filename to the value
prior to that of the last \bookOuputName call.


I think these functions should be named

\setBookOutputSuffix
\setBookOutputName
\revertBookOutputName


You're probably right.  It's just that in music-functions-init the 
source likes to group all the functions alphabetically, and this was a 
way of getting all the related things together.


It's a shame we haven't got a way of declaring generic functions with 
the parser so you could code  \bookCommand \OutputSuffix "mysuffix". 
Well, I suppose we have if you imitate what \markup does in the parser 
but I'm not going to go there...


So I'll go with your suggestions.





\bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
structure.  I have used this so we can we could eventually allow users to do
stuff like the following (controlling the names used to open the midi files is
not part of the current patch).
\book {
\bookOutputName "My-Homeland"
\score {
   \bookOutputName "Vysehrad"
  music-declarations ...
  \midi{
  % midi file gets written to Vysehrad.mid(i)
  }
  \layout{
  }
   \bookOutputNameRevert
}
\score {
\bookOuputName "Vltava"
...
\midi {
% midi file is written to Vltava.mid(i)
}
}
.
.
.  


This code doesn't demonstrate the need for \bookOutputNameRevert; the same
thing would happen if the \bookOutputNameRevert were omitted, as far as I
can tell.



Consider this in one file Smetana.ly:

;;  Music for Má Vlast
\book {
\bookOutputName "My-Homeland"
\score {
\bookOutputName "Vyšehrad"
...
}
\score {
\bookOutputName "Vltava"
...
}
%%   three more \score blocks setting the output name
\score {
\bookOutputName "Blanik"
...
}
}

;; Music for "Bartered Bride Overure"
\book {
% No \bookOutputName here
% Until scoping for \book blocks is sorted out,
% this block will get output to Blanik.pdf and Blanik.midi.
\score {
...
}
}   




lily-library.scm has changes to the filename generating code in
print-book-with to pick up the current values of the new parser variables if
set before using the current output-suffix or result of a call to
ly:parser-output-name.
The routine to get the name now uses as combination of the current output name
and output suffix value to at as a key for the internal a-list of filenames
being written to during a compilation.

lily-guile.hh, lily-guile.cc and parser.yy have code that I would like to use
to re-initialize book-output-suffix and book-filename to initial values on
encountering the end of a \book block, but  I've hit a dead-end currently in
this  as the code I tried to use in parser.yy negates the effect of calling
the new functions altogether.  If anyone with more experience of how bison
works has any better ideas as to how do this I'd be interested in hearing
them.


It would seem to me (this is a relatively poorly informed opinion) that
setting them to the initial values at the *start* of a book block would be a
more sane way to do it that to reset them at the end of a book block.  Or is
there something I'm missing?


D'oh, I was getting blown away by having to learn Bison and work out 
what was doing what, with which, to what, when, and by whom. . .


I'll try it out.



HTH,


Thank, you, yes it does,

Cheers,
Ian


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

Need interface/data structure design advice

[David Kastrup]

Hi,

I am working on accordion register symbol typesetting right now.  Up to
now, there are some font elements in the font, and some basic hackish
stuff in the snippets.

Right now I am stuck in the interfaces.  The focus right now is discant
registers, other registers have similar concerns.

Now here is the basic data I have to deal with:

The register symbols have a basic symbol, and they have dots that are on
or off.

(cf http://en.wikipedia.org/wiki/Accordion_reed_ranks_&_switches>)

The German page
http://de.wikipedia.org/wiki/Register_(Akkordeon)> has quite a few
more details with regard to naming schemes.

The dots correspond to reed banks.  For some accordions, there are
unusual reed banks (and dots), so the user should be able to add dot
coordinates and corresponding data.

For each dot, there will be a set of coordinates where to draw it on the
accordion symbol, a default midi instrument and a default pitch
adjustment: accordions have reed banks that are one octave off, but they
also have reed banks that are only a few cents off-pitch, usually with a
linear tuning curve (linear in cents/semitone, with the lower notes
being more cents off and the higher less).

So we want a default midi instrument per reed bank, with an optional
fine-tuning (translated in pitch bend).

Now to registers: a register is a combination of reed banks (and dots on
the symbol).  A register has a name.  I don't think that cleverness is
warranted for pulling apart register names like "101" or "MM" or
whatever else: the combinations are few enough that it is fine not to
pick apart those strings but just use them as identifier for one
register each.

Registers should have an override regarding the used midi instruments in
order to adapt them to available patches.

Now there is an additional complication: if the lowest used reed bank is
not at nominal pitch (namely either 16" or 4"), notation and sound are
not in accord.  It is common to write at pitch and affix an "8" or more
wordy equivalent at the top or bottom (depending on whether to play one
octave lower or higher than written) of the register symbol to indicate
that one should play one octave higher/lower in order to get pitch.  If
this octavation (in playing) is dissolved, there is "loco" at the next
register symbol.

So usually the register symbol should interact in some manner with
\ottava specs.  Accordions are usually limited enough in range not to
need ottava notation in addition to registration: the keyboard for piano
accordions tends to go from f to a''', really big ones e to c.
Chromatic button accordions are a bit more impressive, mine has notes
from a, to bes, so some possible use for ottava changes that are not
directly related to register changes is there: those would likely use
ottava brackets independent of the current register.

It is common to have different registers for different repeats and write
that out.  That would be nice to have in Midi.  However, it is also
common to have different dynamics for different repeats, and Lilypond
has no way to deal with that right now IIRC.  So that's a different
topic and should likely be addressed in the context of repeats without
special consideration of accordions.

Ok, all this verbage: there need to be ways to specify the available
reed banks, their dot layout, their midi impact and audible octave.
Registers have a reed bank combination and a sounding octave of the
lowest reed bank, and should have an override for the chosen midi
output.

This situation is principally the same in bass registrations for free
bass, and with some modifications for standard bass
(cf. http://www.accordions.com/index/art/stradella.shtml>) where
some reed banks are used for chords, and some for single bass notes
(usually sounding the chord banks as well through mechanical couplers).

So the same mechanisms for tweaking, dot layout specification, register
naming, midi impact, and use should apply.

What kind of data structure can I use such that one can tweak with a
reasonable interface?

-- 
David Kastrup



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

Re: [frogs] [PATCH] : Supply missing documentation strings in music-function-init.ly

[Ian Hulin]

Neil Puttock wrote:

2009/10/25 Ian Hulin :

Thanks for the feedback, Neil.  Is this OK to push now?


Sure is.

Thanks,
Neil
Woo-hoo, green light! Could someone with the relevant privileges push 
this to the main git repository, please?


Cheers,

Ian
>From 48d7cf640be9b78b398bc61d00aedbaa795cf540 Mon Sep 17 00:00:00 2001
From: Ian Hulin 
Date: Sun, 25 Oct 2009 22:42:37 +
Subject: [PATCH] [PATCH] Add missing documentation strings in property-init.ly and
  music-functions-init.ly.

---
 ly/music-functions-init.ly |   22 --
 ly/property-init.ly|   10 +-
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index 718615a..4283157 100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -449,7 +449,7 @@ or @code{\"GrobName\"}")
 %% because music identifiers are not allowed at top-level.
 pageBreak =
 #(define-music-function (location parser) ()
-   (_i "Force a page break. May be used at toplevel (ie between scores or
+   (_i "Force a page break. May be used at toplevel (i.e. between scores or
 markups), or inside a score.")
(make-music 'EventChord
 	   'page-marker #t
@@ -584,13 +584,16 @@ parenthesize =
 
 partcombine =
 #(define-music-function (parser location part1 part2) (ly:music? ly:music?)
-		(make-part-combine-music parser
-	 (list part1 part2)))
+   (_i "Take the music in @var{part1} and @var{part2} and typeset so that they share a staff.")
+   (make-part-combine-music parser
+			(list part1 part2)))
 
 pitchedTrill =
 #(define-music-function
(parser location main-note secondary-note)
(ly:music? ly:music?)
+   (_i "Print a trill with @var{main-note} as the main note of the trill and
+print @var{secondary-note} as a stemless note head in parentheses.")
(let*
((get-notes (lambda (ev-chord)
 		 (filter
@@ -622,8 +625,12 @@ pitchedTrill =
 
 quoteDuring =
 #(define-music-function
-  (parser location what main-music)
-  (string? ly:music?)
+   (parser location what main-music)
+   (string? ly:music?)
+   (_i "Indicate a section of music to be quoted.  @var{what} indicates the name
+of the quoted voice, as specified in an @code{\\addQuote} command.
+...@var{main-music} is used to indicate the length of music to be quoted;
+usually contains spacers or multi-measure rests.")
   (make-music 'QuoteMusic
 	  'element main-music
 	  'quoted-music-name what
@@ -803,7 +810,10 @@ tweak =
 
 unfoldRepeats =
 #(define-music-function (parser location music) (ly:music?)
-		  (unfold-repeats music))
+   (_i "Force any @code{\\repeat volta}, @code{\\repeat tremolo} or
+...@code{\\repeat percent} commands in @var{music} to be interpreted
+as @code{\\repeat unfold}.")
+   (unfold-repeats music))
 
 
 
diff --git a/ly/property-init.ly b/ly/property-init.ly
index 4983506..a73848e 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -278,7 +278,9 @@ phrasingSlurNeutral = \revert PhrasingSlur #'direction
 % dash-patterns (make-simple-dash-definition defined at top of file)
 phrasingSlurDashPattern =
 #(define-music-function (parser location dash-fraction dash-period)
-  (number? number?)
+   (number? number?)
+   (_i "Set up a custom style of dash pattern for @var{dash-fraction} ratio of
+line to space repeated at @var{dash-period} interval.")
   #{
  \override PhrasingSlur #'dash-definition =
$(make-simple-dash-definition dash-fraction dash-period)
@@ -301,10 +303,16 @@ phrasingSlurSolid =
 
 pointAndClickOn  =
 #(define-music-function (parser location) ()
+   (_i "Enable generation of code in final-format (e.g. pdf) files to reference the
+originating lilypond source statement;
+this is helpful when developing a score but generates bigger final-format files.")
(ly:set-option 'point-and-click #t)
(make-music 'SequentialMusic 'void #t))
+
 pointAndClickOff =
 #(define-music-function (parser location) ()
+   (_i "Suppress generating extra code in final-format (e.g. pdf) files to point
+back to the lilypond source statement.")
(ly:set-option 'point-and-click #f)
(make-music 'SequentialMusic 'void #t))
 
-- 
1.6.0.4

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

Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Carl Sorensen]

On 10/23/09 5:52 PM, "Ian Hulin"  wrote:

> init.ly - Add new parser variables book-output-suffix and book-filename
> initialized as #f and empty queue/stack structure.
> 
> music-functions-init.ly adds three new functions
> * \bookOutputSuffix - to set the output suffix for the \book block
> * \bookOutputName - to set output filename for the current \book block
> * \bookOuptutNameRevert - to restore the the output filename to the value
> prior to that of the last \bookOuputName call.

I think these functions should be named

\setBookOutputSuffix
\setBookOutputName
\revertBookOutputName


> \bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
> structure.  I have used this so we can we could eventually allow users to do
> stuff like the following (controlling the names used to open the midi files is
> not part of the current patch).
> \book {
>     \bookOutputName "My-Homeland"
>     \score {
>        \bookOutputName "Vysehrad"
>           music-declarations ...
>           \midi{
>           % midi file gets written to Vysehrad.mid(i)
>           }
>           \layout{
>           }
>        \bookOutputNameRevert
>     }
>     \score {
>         \bookOuputName "Vltava"
>         ...
>         \midi {
>         % midi file is written to Vltava.mid(i)
>         }
>     }
> .
> .
> .  

This code doesn't demonstrate the need for \bookOutputNameRevert; the same
thing would happen if the \bookOutputNameRevert were omitted, as far as I
can tell.

> 
> lily-library.scm has changes to the filename generating code in
> print-book-with to pick up the current values of the new parser variables if
> set before using the current output-suffix or result of a call to
> ly:parser-output-name.
> The routine to get the name now uses as combination of the current output name
> and output suffix value to at as a key for the internal a-list of filenames
> being written to during a compilation.
> 
> lily-guile.hh, lily-guile.cc and parser.yy have code that I would like to use
> to re-initialize book-output-suffix and book-filename to initial values on
> encountering the end of a \book block, but  I've hit a dead-end currently in
> this  as the code I tried to use in parser.yy negates the effect of calling
> the new functions altogether.  If anyone with more experience of how bison
> works has any better ideas as to how do this I'd be interested in hearing
> them.

It would seem to me (this is a relatively poorly informed opinion) that
setting them to the initial values at the *start* of a book block would be a
more sane way to do it that to reset them at the end of a book block.  Or is
there something I'm missing?

HTH,

Carl



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

Re: documentation: unreadable html tables

[-Eluze]

Graham Percival-3 wrote:
> 
> The languages involved are perl, texinfo, and html.  In
> particular, the documentation is written in texinfo; a perl script
> (called texi2html) interprets the texinfo files, and outputs html.
> 
i have some experience with html; texinfo and perl are fully new to me!
furthermore i am working on windows - hope this is not a problem!?


> The first step is to reproduce the problem in a small example.
> Try making a tiny texinfo file, which contains the same kind of
> table as in pitches.itely.  I think it's a @multitable, but I'm
> not 100% certain.
> 
i will need to know where i can download this file from!


> 
> Verify that running texi2html 1.82 on your tiny texinfo file
> produces the bad output.  Then have a look at the output and see
> what exactly you want to change -- is it just removing the 
> tags?  Would it look better if there was some  attribute
> being set?  etc.
> 
> Then you need to figure out how to get texi2html to produce the
> output you want to see.  As it happens, texi2html is relatively
> easy to extend (it's in perl, you can replace any of its built-in
> fuctions easily, etc).  We *could* just add a special "overriding"
> function to our texi2html init script, but in this case I'd
> recommend getting your fix integrated into texi2html itself.  This
> won't help us with 1.82, but when texi2html 1.84 comes out, it'll
> have the fix.
> 
> 
> I really hope that you'll take this up; we could really use
> somebody who's familiar with texi2html.  We have a few problems
> with our texi2html init scripts, and there's other parts of those
> scripts that work well, but I think other texi2html users could
> benefit from (like the sectioning-by-numbers), so it would be nice
> if we could send a patch for this upstream.
> 
altogether i think it will take me some time to get familiar with these new
components and surroundings!
if anybody could advise a practical tutorial both for texinfo and perl this
could help a lot.


> If you're not familiar with perl... well, it's not as easy to
> learn as python, but I'd still say that it's on the "easy" side of
> programming languages.  It's much easier than scheme!  :)
> 
> Cheers,
> - Graham
> 
cheers
-Eluze

-- 
View this message in context: 
http://www.nabble.com/documentation%3A-unreadable-html-tables-tp26037552p26060704.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.



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

[PATCH] Fix typo in build script

[Francisco Vila]

Hello,

this patch fixes a potential bug in scripts/build/grand-replace.py

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com
From f253378959983a4777c8169f0011eda5413c5c4e Mon Sep 17 00:00:00 2001
From: Francisco Vila 
Date: Mon, 26 Oct 2009 13:05:50 +0100
Subject: [PATCH] Fix Spanish filename typo in update script.

---
 scripts/build/grand-replace.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/build/grand-replace.py b/scripts/build/grand-replace.py
index dc0697d..abd67ba 100644
--- a/scripts/build/grand-replace.py
+++ b/scripts/build/grand-replace.py
@@ -46,7 +46,7 @@ copied_files = [
 'txi-de.tex',
 'txi-en.tex',
 'txi-fr.tex',
-'txi-sf.tex',
+'txi-es.tex',
 ]
 
 def main ():
-- 
1.5.6.3

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

Re: Issue 872 in lilypond: Changes split-page has broken images

[John Mandereau]

Le samedi 24 octobre 2009 à 17:13 +, codesite-nore...@google.com a
écrit :
> We don't *have* to discuss it as a tracker issue,

Especially when it's not necessary, as Google Code sends text emails
with horrible indentation, or rather I'm not able to fill Google Code
tracker form in a way to avoid such horrible indentation.


> Maybe those aren't good reasons... I have no objection to keeping such TODO  
> items to
> myself in the future, if that's desired.

What about the wiki for this kind of stuff?


> Anyway, for this specific issue: if changes.tely is a non-splitted manual,  
> then the
> html page from general/manual.itexi @section Changes  will overwrite the  
> non-splitted
> version of changes.itely.  I figured that the simplest way to fix this  
> would be to
> make Changes a split manual, thereby putting changes-one-page.html in the  
> main doc
> source output, and also giving us changes/index.html.

How ugly, this gives two almost identical HTML documents
changes-one-page.html and changes/index.html.


> There was also an issue with the xref produced by @rchanges{Top,blah}  
> inside general,
> that has to do with the broken html refs that I'm avoiding with that  
> disgusting find
> | xargs sed trick.

One purpose of postprocess_html is avoiding messing with make and shell
to do such tricks.


> In general (umm, I mean, "as a summary", not anything to do with  
> general.texi), I'd
> like to avoid manual-specific hacks; I like the idea of only having two  
> types of
> manuals: general.texi, which goes in the top output dir, and all the other  
> manuals,
> which are all treated the same.

There are two distinct documentation targets: online (lilypond.org) and
offline (downloadable docball).

As for the offline target, I don't understand why you want to make
General go at the top output dir: why should the directory structure
match the hierarchy between HTML Info manuals?  The only grounds I can
see for doing so would be
- navigating directories/typing URL by hand,
- reading the URL to see where you are because the docs structure is not
obvious from the HTML pages themselves.

I hope we put enough effort into the usability of our docs and new web
site so these grounds are not valid.

As for the online docs, we want
- the website in lilypond.org/web (IIRC you suggested lilypond.org,
which changes nothing to the issue)
- the docs in lilypond.org/doc/vX.Y/

Moving HTML output of General one directory up suits none of the two
targets, so it should be abandoned.  However, we should generate each
output of General twice, removing for the offline target the download
page and other pages that make sense only for the online web site; I'm
willing to take over this, but not for the to-be-dead build system.


> Long-term, I think it would be nice to have the older Changes in the same  
> document,
> but I haven't thought through all the issues involved in doing this.
> (namely, what
> happens if the syntax changes from 1.4 to 1.8, then again from 1.8 to 2.13  
> -- how do
> we generate the picture for the changes-1.8 page?)

Let's not have a headache for this :-)


> Now that I think about it some more, I'm leaning towards abandoning the  
> idea entirely.

I second this.  It's (and it should be with the new web site) easy to
see changes for each new stable branch from the page Documentation from
the web site.

Best,
John


signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tracking patches

[Marek Klein]

Hi,
I will do it.
-- 
Marek Klein
http://gregoriana.sk

2009/10/26 Graham Percival 

> Could we get a volunteer to keep track of patches?  The idea is that
> whenever somebody sends a patch, if nobody does anything to it within,
> say, 3 days, you add it to the google issue tracker.  If you already
> read the mailists, I estimate it will take 1 hour each month.
>
> That's not much time to volunteer, but it could make a *huge*
> difference for new contributors.  It's really discouraging when you
> submit something, nobody replies, and you're left wondering if your
> email client ate the patch or if everybody hates you or something.
>
> Absolutely no programming skills or understanding of the patch in
> question is required; anybody capable of recognizing the English word
> "patch" can do this job!
>
> Cheers,
> - Graham
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

tracking patches

[Graham Percival]

Could we get a volunteer to keep track of patches?  The idea is that
whenever somebody sends a patch, if nobody does anything to it within,
say, 3 days, you add it to the google issue tracker.  If you already
read the mailists, I estimate it will take 1 hour each month.

That's not much time to volunteer, but it could make a *huge*
difference for new contributors.  It's really discouraging when you
submit something, nobody replies, and you're left wondering if your
email client ate the patch or if everybody hates you or something.

Absolutely no programming skills or understanding of the patch in
question is required; anybody capable of recognizing the English word
"patch" can do this job!

Cheers,
- Graham


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

NEWS/changes entry for font switching

[Graham Percival]

Could we get an entry in Documentation/changes.tely  about the font
switching?  I guess we can't show an actual example of it working
(unless we make the new font required for compiling lilypond), but it
would be nice to have a bullet point about this, at least.

Cheers,
- Graham


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

Re: line breaks and broken beams

[Werner LEMBERG]

Ping!


Werner


==


From: Werner LEMBERG 
Subject: Re: line breaks and broken beams
Date: Sun, 27 Sep 2009 16:08:31 +0200 (CEST)

> 
>>> What's the reason that line breaks are by default forbidden if
>>> there is a broken beam crossing the bar line, and that you have to
>>> set the `breakable' flag manually to override it?
>>>
>>> BTW, it is very unpleasant that lilypond doesn't emit any kind of
>>> warning if it produces an overlong staff caused by that issue.  It
>>> silently accumulates unbreakable bars and happily walks out of the
>>> right margin.  I would consider this behaviour a bug.
>>
>> +1.
>>
>> (I've always felt this way, too.)
> 
> Then let's drop the IMHO unfounded limitation of not breaking at beams
> crossing a barline.
> 
> 
> Werner


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

Re: support of `to-barline' property in \Dynamics

[Werner LEMBERG]

Ping!


Werner


==


From: Werner LEMBERG 
Subject: support of `to-barline' property in \Dynamics
Date: Fri, 25 Sep 2009 21:06:18 +0200 (CEST)

> I think something like the following patch should be applied so that
> the \Dynamics context supports the `to-barline' property of hairpins.
> However, I haven't tested whether it has any negative side effects.
> 
> 
> Werner
> 
> 
> ==
> 
> 
> --- engraver-init.ly.old2009-09-16 22:22:31.0 +0200
> +++ engraver-init.ly2009-09-25 21:03:23.0 +0200
> @@ -350,6 +350,7 @@
>\name Dynamics
>\alias Voice
>\consists "Output_property_engraver"
> +  \consists "Bar_engraver"
>\consists "Piano_pedal_engraver"
>\consists "Script_engraver"
>\consists "New_dynamic_engraver"
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel


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