Re: Solution for including a file only once
Reinhold Kainhofer: ... > In my view there are two different kinds of include uses: > 1) To include package-like .ily files, which define additional functionality. > There many utility functions really might/should be in their own namespace, > but many definitions (and in particular all \header, \paper or \layout > blocks) > need to be at toplevel. I would be interested in conditionally including files with \paper and \header blocks, so can with a command line flag get output for "choirbook" booklets or plain a4 sheets. The common thing with this thread would be the ability to \include thoose blocks. > 2) ... ... > I think it should be as easy and straightforward to use to a non-programmer > as > possible, while allowing more complex use without making easy things harder > than necessary for easy things. Ack. Regards, /Karl --- Karl HammarAspö Data k...@aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Looking for Lilypond developer to create a special version for different music score model
Hi all, I've been using a Lilypond for a month now and I really impressed with its complex and beautiful rendering. However, I live in the country where most of the people cannot read music in notation model. Instead, we are reading music in the solfegio: do, re, mi fa, sol, la, ti. And when we write the music, we wrote it in the numeric format. For example -- 1=do, 2=re, etc. So when I wrote 1 2 3. 4 5, it really mean do, re, mi, fa, sol. We called the model as "solmisasi" -- I don't know what the term in english. Basically it was derived from the Netherland education. Now, the problem are -- most of the people are reading music in that model. Including all people in my church. When we have a choir, everybody is reading the solmisasi notation. Usually we create the score using Microsoft Word, which is a very tedious task. Or, people just simply do it in handwritten. I was trying the Lilypond and I am very excited with the data model and the possibility of creating a new rendering (which is mostly text) for the solmisasi notation. I am sure this is much more easier than writing a complete notation. I attached one example of solmisasi notation. The music is four voice, SATB. If you see the notation, I think you can understand it easily. Is there a rendering like this available? If its not -- because of the usefulness this program, I am willing to pay some $$ for the developer who wants to work on this model. Because this might be not in the roadmap of Lilypond. All sourcecode will go back to the GNU license. Its just I need somebody who understand the source code and able to change it. I'll give all the requirement. Let me know if its possible, if its done -- all church in my country will be able to use it. :-) Thanks and let me know what your thought on this one. Regards, -izak http://old.nabble.com/file/p27549135/ExampleMusic.pdf ExampleMusic.pdf -- View this message in context: http://old.nabble.com/Looking-for-Lilypond-developer-to-create-a-special-version-for-different-music-score-model-tp27549135p27549135.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
quick check of 2.13.13 mingw
I've bumped nsis to 2.4.6. Could somebody check if it still installs + uninstalls in a manner which is no worse than 2.13.12 ? http://lilypond.org/~graham/ PLEASE NOTE: I haven't tried using any of the new functions in nsis 2.4.6; I don't expect this version to be *better* than 2.13.12. If it's the same, then I consider that a victory, and will move on with 2.13.13, and will begin investigating the potential fix to the slow uninstaller some time next week. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
new smaller installers to test
I've tweaked the list of dirs to remove from share/ghostscript/Resources. The resulting files are (on average) 5 megs smaller. linux-x86 works here for me. Could we get a few tests for various OSes? http://lilypond.org/~graham/ (mingw is "mingw-new.exe", to avoid a clash with the nsis 2.4.6 binary test. The mingw-new.exe also uses 2.4.6, so if that file works for you, there's no need to test the older lilypond-blah.exe) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new smaller installers to test
On Fri, Feb 12, 2010 at 7:06 PM, Kieren MacMillan wrote: > Hi Graham, > >> Could we get a few tests for various OSes? >> http://lilypond.org/~graham/ > > Mac OS X 10.6 is aok. > It also seemed that "first compile" was almost instantaneous, as compared > with earlier upgrades -- is this a change, or am I imagining things? I would be very surprised if that was a real change, but then again, I've been surprised at cross-platform issues in the past. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new smaller installers to test
Hi Graham, > Could we get a few tests for various OSes? >http://lilypond.org/~graham/ Mac OS X 10.6 is aok. It also seemed that "first compile" was almost instantaneous, as compared with earlier upgrades -- is this a change, or am I imagining things? Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Pre-release testing
So, when I'm not doing lilypond things, I test stuff. I'm a game
tester. One thing I find very helpful is to have a short list of
things to check for when doing these kinds of quick version test. I
haven't really worked very hard on it, but here's kinda the things I
do so far when looking at checking versions:
Check LilyPad Editor
Open LilyPad Editor
Open a File with LilyPad Editor
Compile a File with LilyPad Editor
Update Syntax {b4\sustainUp a g a \sustainDown} \version "2.10.0"
Check Command-Line Options
Compile a file from the command line
Pass a simple command-line option "lilypond -o test\ file /
Applications/LilyPond.app/Contents/Resources/Welcome-to-LilyPond-
MacOS.ly"
Pass an advanced command-line option "lilypond -dpaper-size=\"a6\"
Applications/LilyPond.app/Contents/Resources/Welcome-to-LilyPond-
MacOS.ly"
Python Scripts
lilypond-book
compile a file with lilypond book
\documentclass[a4paper]{article}
\begin{document}
test
\begin{lilypond}
\relative c' { c2 a'2 \times 2/3 { f8 e d } c'2 g4 }
\end{lilypond}
\end{document}
lilypond-book --latex-program=pdflatex --pdf -o out pdflatex-lily-
book-sample.lytex
convert-ly
Update Syntax {b4\sustainUp a g a \sustainDown} \version "2.10.0"
pdf output
Check that pdf paper size is correct
Check that links open correctly
I include all of this here for feedback on how appropriate something
like this is, any things that could be missed, any things that could
be removed.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pre-release testing
On 12.02.2010, at 20:37, James Bailey wrote: … lilypond-book --latex-program=pdflatex --pdf -o out pdflatex-lily- book-sample.lytex should have been: lilypond-book --pdf -o out pdflatex-lily-book-sample.lytex …old file version… ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc compile, 2
John, Sorry for bugging you again. I still have the problem
[apparently] with incuded/generating-output.itexi.
This could be of help:
make[1]: Entering directory `/home/fravd/source/lilypond/Documentation/es'
cd ./out-www && \
texi2pdf --batch -I
/home/fravd/source/lilypond/Documentation -I
/home/fravd/source/lilypond/Documentation/./out-www -I
/home/fravd/source/lilypond/out/lybook-db/ learning.texi && \
mkdir -p
/home/fravd/source/lilypond/Documentation/./out-www/ && mv
learning.pdf /home/fravd/source/lilypond/Documentation/./out-www/learning.es.pdf
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
file:line:error style messages enabled.
%&-line parsing enabled.
entering extended mode
(./learning.texi (/home/fravd/source/lilypond/tex/texinfo.tex
Loading texinfo [version 2009-08-14.15]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/share/texmf-texlive/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 <23 July 2005>
) localization, formatting, and turning on texinfo input format.)
(./learning.aux) (/home/fravd/source/lilypond/tex/txi-es.tex
no patterns for spanish) (./macros.texi (./version.texi) (./common-macros.texi)
) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./learning.toc
[-1] [-2]) [-3] (./learning.toc) (./learning.toc) (./learning/tutorial.texi
(./included/generating-output.texi
./included/generating-output.texi:238: Argument of \ has an extra }.
@par
}
@parsemacbody ... macro->@xdef @temp {...@eatcr {#1}}
@endgroup @defmacro
l.238 @end macro
Runaway argument?
version "@w...@version{}}"^...@{^^mc' e' g' e'^...@}^^m@end example^^m...@etc.
./included/generating-output.texi:238: Paragraph ended before \ was complete.
@par
}
@parsemacbody ... macro->@xdef @temp {...@eatcr {#1}}
@endgroup @defmacro
l.238 @end macro
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc compile, 2
On Fri, Feb 12, 2010 at 08:55:10PM +0100, Francisco Vila wrote:
> Runaway argument?
> version "@w...@version{}}"^...@{^^mc' e' g' e'^...@}^^m@end example^^m...@etc.
> ./included/generating-output.texi:238: Paragraph ended before \ was complete.
I remember seeing this earlier in the week. Make sure you're
using latest git, and do a full doc build from scratch. The
problem should go away. At least, it did for me.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new smaller installers to test
Graham Percival wrote Friday, February 12, 2010 6:57 PM I've tweaked the list of dirs to remove from share/ghostscript/Resources. The resulting files are (on average) 5 megs smaller. linux-x86 works here for me. Could we get a few tests for various OSes? On Vista: Yes - the .exe is 20.5 Mb, previous versions have been c. 27 Mb. Size of installation on disk is now 68 Mb, previous versions around 83 Mb. Big improvement. Installation appeared perfectly normal. Ran lilypond-book and texi2html on pitches.itely. Output looks fine. First run took c. 2 mins to get going, second started immediately. Presumably fonts are being processed first time ?? Uninstall took exactly 10 mins, and left three files undeleted: /usr/bin/lilypad-unicode.exe /usr/share/lilypond/current/dvips/ps/lilyponddefs.ps /usr/share/lilypond/current/dvips/ps/music-drawing-routines.ps I don't know if this is a change in behaviour as I normally just delete or rename the lilypond directory. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new smaller installers to test
On Fri, Feb 12, 2010 at 10:57 AM, Graham Percival wrote: > I've tweaked the list of dirs to remove from > share/ghostscript/Resources. The resulting files are (on average) 5 > megs smaller. linux-x86 works here for me. > > Could we get a few tests for various OSes? > http://lilypond.org/~graham/ darwin-x86 and darwin-ppc work fine on clean 10.5 Leopard machines. I've noticed some warnings from Ghostscript (when using --verbose) in the past, and those are still present, so here they are for completeness: *** Warning: GenericResourceDir doesn't point to a valid resource directory. the -sGenericResourceDir=... option can be used to set this. WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap. ...though they don't seem to affect the output, so I guess they are harmless. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc compile, 2
2010/2/12 Graham Percival :
> On Fri, Feb 12, 2010 at 08:55:10PM +0100, Francisco Vila wrote:
>> Runaway argument?
>> version "@w...@version{}}"^...@{^^mc' e' g' e'^...@}^^m@end
>> example^^m...@etc.
>> ./included/generating-output.texi:238: Paragraph ended before \ was complete.
>
> I remember seeing this earlier in the week. Make sure you're
> using latest git, and do a full doc build from scratch. The
> problem should go away. At least, it did for me.
No luck, but now I am sure that the line
@\version "@w...@version{}}"
in an example of /included/generating-output.itexi is causing the
problem. Deleting it makes doc to compile well. I'll check my macros:
they could be wrong.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc compile, 2
2010/2/12 Francisco Vila :
> 2010/2/12 Graham Percival :
>> On Fri, Feb 12, 2010 at 08:55:10PM +0100, Francisco Vila wrote:
>>> Runaway argument?
>>> version "@w...@version{}}"^...@{^^mc' e' g' e'^...@}^^m@end
>>> example^^m...@etc.
>>> ./included/generating-output.texi:238: Paragraph ended before \ was
>>> complete.
>>
>> I remember seeing this earlier in the week. Make sure you're
>> using latest git, and do a full doc build from scratch. The
>> problem should go away. At least, it did for me.
>
> No luck, but now I am sure that the line
>
> �...@\version "@w...@version{}}"
>
> in an example of /included/generating-output.itexi is causing the
> problem. Deleting it makes doc to compile well. I'll check my macros:
> they could be wrong.
Now fixed in translation branch.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Helping translators do their work
Hello, I have a small suggestion. When a translator faces this commit and tries to update her translations accordingly, e600412e50db9e8ee3b9e408527322b84b946f52 Doc build: make screenshot-tutorials shared. one tends to think that only blocks of text were moved or files renamed. It is impossible, (and check scripts do not help on that) to guess that in the meantime some random lines were touched. I'd beg for you to separate moving/renaming from editing into separate commits. Updating becomes a nightmare otherwise. Thank you! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pre-release testing
On Fri, Feb 12, 2010 at 08:37:00PM +0100, James Bailey wrote:
>
> One thing I find very helpful is to have a short list of things to check
> for when doing these kinds of quick version test. I haven't really worked
> very hard on it, but here's kinda the things I do so far when looking at
> checking versions:
Nice idea! Once we've worked on this list a bit, I'll add it to
the CG release chapter.
> Open LilyPad
> Compile a File with LilyPad Editor
I believe that
input/regression/typography-demo.ly
tests all types of output. At least, it did at one point; by now
there's probably extra features which aren't included in that
file. Still, it's probably a good test, since it includes other
languages, a bunch of articulations, slurs, cross-beam staves,
etc.
If anybody wants to volunteer to track down whether it currently
includes all grobs, or wants to modify the file to add other
things to test, I certainly wouldn't object. I have no plans on
investigating or tweaking this file myself.
> Update Syntax {b4\sustainUp a g a \sustainDown} \version "2.10.0"
>
> Check Command-Line Options
> Compile a file from the command line
I wouldn't bother with these unless there's a specific reason to
think they've broken or been changed.
Granted, it depends on how much time you want to put into it. But
I think a good trade-off would be to just check one or two files
with LilyPad, unless I specifically ask about something else. I
think the remaining lilypond time would be better spent processing
bug reports, editing files on LSR, etc.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
