Re: A basic question of Lilypond
Op Tue, 22 Dec 2020 09:47:38 +0100 (CET) Werner LEMBERG schreef: > I strongly suggest that you don't do that. Instead, please try to > extend Frescobaldi with a Jianpu input mode! I'm sure that Wilbert > will be happy in helping you to do that. I will! :-) -- Wilbert Berendsen (www.wilbertberendsen.nl)
Re: Text Spanner with more than two words
Op zondag 23 augustus 2009, schreef Jonathan Wilkes: > accel.---meno mosso---rit.---a tempo > > I've tried using above-staff decrescendo and setting the text as needed, > which does work, but then I have to create another layer if there are also > hairpins. I used this solution but most times I put the texts in the other layer (\new Voice) and the hairpins in the music layer. best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: severe chord repetition problem
Op zondag 06 december 2009 schreef David: > That, in turn, means that the more brainpower is invested in Lilypond to > make it do "the right thing", the harder it gets for Lilypond-reading > programs to get it right as well. I second this. My program Frescobaldi has a LilyPond parser that can understand music (transpose pitches etc.) but when the semantics of "q" are moving, it is difficult for such a parser to understand music (e.g. play notes when the cursor moves across them). (I still have a little doubt if "q", although it can save much typing, really contributes to a good, stable and clear LilyPond syntax.) The typing problem can also be resolved in editors: in Frescobaldi there is a shortcut (Ctrl+;) that repeats the last entered chord. with many regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: severe chord repetition problem
Op maandag 07 december 2009 schreef David: > The editor needs to be suitably clever to have this work properly in > \relative mode. Ok, should be sufficient to remove octave indicators > from the first chord note, so this is probably not overly hard. Yes Frescobaldi does exactly this :-), and it copies short-hand articulations (like -. etc) Frescobaldi also can read relative music (it can transpose both relative and absolute music fragments, and also convert between relative and absolute input, auto-detecting the pitch language (by looking at the \include statements :-) ) But let it be clear: if LilyPond changes, it is no problem for me to adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have Frescobaldi support it. many regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Grand LilyPond Input Syntax Stabilization (GLISS) webpage
Op zaterdag 02 januari 2010 schreef Trevor: > Looks promising. Nice overview of the issues. > I'll be happy to be part of the discussions when > they start. Same for me! I really love LilyPond (both the program and the project), and stabilizing the syntax will make it more stable and professional. I could imagine one other addition to the list of topics in Scope and Limitation: - the values that are used as arguments to common used overrides. Sometimes they are a symbol (e.g. #'around), sometimes a predefined variable referring to a Scheme value or object (e.g. #LEFT, #all-visible ). The main trouble is that for novice users it is not clear when there should be an apostrophe and when not. best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (bug?) irregular lyrics distance in 2.13.10
Op donderdag 14 januari 2010 schreef Joe: > So it should just be a matter of finding the > right default for minimum-distance. From my experimentation, 3.2 is a fine default value I think. 3 is a little tight, 3.5 a little "white" :) Thanks for the very fine vertical spacing controls! best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [wishlist] enhancing text spanners
Op maandag 24 mei 2010 schreef Stemby:
> Hi,
> could you provide an option to syllabify the words like in this example?
>
> http://img337.imageshack.us/img337/214/textspanner.png
It is already possible by abusing the DynamicTextSpanner:
\relative c' {
\set crescendoSpanner = #'text
\set crescendoText = "ri"
c1\<
\set crescendoText = "te"
d\<
\set crescendoText = "nu"
e\<
\set crescendoText = "to"
\once \override Voice.DynamicTextSpanner #'dash-period = #-1
f\<
g1\!
}
I also use this for things like poco - - a - - poco - - cres - - cen - - do
etc.
best regards,
Wilbert Berendsen
--
Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/
Nederlands LilyPond forum: http://www.lilypondforum.nl/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
keep LilyPond process running in sort of "server mode"
Hi, some time ago there has been some discussion about a way to run LilyPond once and keep it running, waiting for a filename to compile. I think it was a special .ly file containing Scheme code that was started and ran all the init stuff, then waited for the name of a .ly file to process (via a socket, pipe or stdin, don't remember). After processing the file, the process would remain running and waiting for another filename to process. Just like specifying multiple files on the lilypond command line, all init files are read only once. This could speed up repeated compiles of LilyPond files inside (e.g.) Frescobaldi. Does anybody know more about this? (LSR currently does not respond) With TIA, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep LilyPond process running in sort of "server mode"
Op Do, 5 augustus, 2010 13:01, I wrote: > Hi, > > some time ago there has been some discussion about a way to run LilyPond > once and keep it running, waiting for a filename to compile. I think it > was a special .ly file containing Scheme code that was started and ran all > the init stuff, then waited for the name of a .ly file to process (via a > socket, pipe or stdin, don't remember). > > After processing the file, the process would remain running and waiting > for another filename to process. Just like specifying multiple files on > the lilypond command line, all init files are read only once. This could > speed up repeated compiles of LilyPond files inside (e.g.) Frescobaldi. Well, I found out about ly:parse-file which seems to be able to do the job. Now on to implement a simple protocol to talk to a running Scheme procedure which reads a filename and calls ly:parse-file on the file and then reports back a "failed" or "succeeded" status... I probably should use a socket or a named pipe... With best regards, Wilbert Berendsen Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
First stab at merge-rests-on-positioning
Op dinsdag 17 augustus 2010 schreef Xavier:
> On Fri, Jun 11, 2010 at 3:27 PM, Xavier Scheuer wrote:
>> Could you implement the possibility:
>> \override RestCollision #'positioning-done =
>> #merge-rests-on-positioning described in
>> http://lsr.dsi.unimi.it/LSR/Item?id=336
>> _directly_ into LilyPond?
>
> Graham wrote: Patches will be reviewed.
This is my first stab at this. It just uses the code in LSR336 but provides a
few convenience commands.
The major limitation is that multimeasure rests are not yet taken into
account: they are simply moved to the central staff position, whether they
occur in both voices or not.
AFAICT MultiMeasureRest objects do not take part in some collision. Is there a
way to get the other one in the other voice in a staff? Then I could write a
function to assign to the 'Y-offset property of the MMrest.
If the MMrests function well, this file could be added to the ly/ directory of
lilypond, it could then be included if people want to use the functionality.
best regards,
Wilbert Berendsen
--
Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/
Nederlands LilyPond forum: http://www.lilypondforum.nl/
%{
Based on http://lsr.dsi.unimi.it/LSR/Snippet?id=336
Merges rests that occur on the same moment inside a staff with two voices.
Usage:
\include "merge-rests"
\layout {
\mergeRests
}
or inside the music:
\new Staff <<
\relative c' {
\mergeRestsOn %% in one of the voices if sufficient
c4 d e f g r r2
}
\\
\relative c' {
a4 b c d e r r2
}
>>
TODO:
- Fix MultiMeasureRests, currently they are always shifted to the center staff
position.
How to find out if there are two MultiMeasureRests at the same moment?
%}
\version "2.12.3"
#(define (rest-score r)
(let ((score 0)
(yoff (ly:grob-property-data r 'Y-offset))
(sp (ly:grob-property-data r 'staff-position)))
(if (number? yoff)
(set! score (+ score 2))
(if (eq? yoff 'calculation-in-progress)
(set! score (- score 3
(and (number? sp)
(<= 0 2 sp)
(set! score (+ score 2))
(set! score (- score (abs (- 1 sp)
score))
#(define (merge-rests-on-positioning grob)
(let* ((can-merge #f)
(elts (ly:grob-object grob 'elements))
(num-elts (and (ly:grob-array? elts)
(ly:grob-array-length elts)))
(two-voice? (= num-elts 2)))
(if two-voice?
(let* ((v1-grob (ly:grob-array-ref elts 0))
(v2-grob (ly:grob-array-ref elts 1))
(v1-rest (ly:grob-object v1-grob 'rest))
(v2-rest (ly:grob-object v2-grob 'rest)))
(and
(ly:grob? v1-rest)
(ly:grob? v2-rest)
(let* ((v1-duration-log (ly:grob-property v1-rest 'duration-log))
(v2-duration-log (ly:grob-property v2-rest 'duration-log))
(v1-dot (ly:grob-object v1-rest 'dot))
(v2-dot (ly:grob-object v2-rest 'dot))
(v1-dot-count (and (ly:grob? v1-dot)
(ly:grob-property v1-dot 'dot-count -1)))
(v2-dot-count (and (ly:grob? v2-dot)
(ly:grob-property v2-dot 'dot-count -1
(set! can-merge
(and
(number? v1-duration-log)
(number? v2-duration-log)
(= v1-duration-log v2-duration-log)
(eq? v1-dot-count v2-dot-count)))
(if can-merge
;; keep the rest that looks best:
(let* ((keep-v1? (>= (rest-score v1-rest)
(rest-score v2-rest)))
(rest-to-keep (if keep-v1? v1-rest v2-rest))
(dot-to-kill (if keep-v1? v2-dot v1-dot)))
;; uncomment if you're curious of which rest was chosen:
;;(ly:grob-set-property! v1-rest 'color green)
;;(ly:grob-set-property! v2-rest 'color blue)
(ly:grob-suicide! (if keep-v1? v2-rest v1-rest))
(if (ly:grob? dot-to-kill)
(ly:grob-suicide! dot-to-kill))
(ly:grob-set-property! rest-to-keep 'direction 0)
(ly:rest::y-offset-callback rest-to-keep)))
(if can-merge
#t
(ly:rest-collision::calc-positioning-done grob
mergeRestsOn = {
\override Staff.RestCollision #'positioning-done = #merge-rests-on-positioning
\override Staff.MultiMeasureRest #'Y-offset = #0
}
mergeRestsOff = {
\revert Staff.RestCollision #'positioning-done
\revert Staff.MultiMeasureRest #'Y-offset
}
mergeRests = \layout {
\context {
\Staff
\override RestCollision #'positioning-done = #merge-rests-on-positioning
\override MultiMeasureRest #'Y-offset = #0
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: First stab at merge-rests-on-positioning
Op dinsdag 17 augustus 2010 schreef Wilbert: > This is my first stab at this. It just uses the code in LSR336 but provides > a few convenience commands. I have updated the file and now it also support multi-measure rests. I have attached the new file on issue 1228: http://code.google.com/p/lilypond/issues/detail?id=1228 best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Merging rests
Op maandag 13 september 2010 schreef bart: > I have found a way to merge rests when there are two voices on one stave, > but which evolve as one voice, to limit clutter on the score on this page : > http://lsr.dsi.unimi.it/LSR/Item?id=336 . > > It is very usefull indeed, but isn't there a more general way to merge > rests. It's a lot of code for a task, that I think is often needed. This > code is limited to two voices, but I already have a score laying around > here with three voices. I know about hiding rests, but then I'll have to > change the position of the remaining rests to the center of the staff, > like the example of the snippet shows. I'm quite a beginner, so I think > that's pretty advanced stuff already. > > Any ideas for an alternative to the snippet? Yes, I created an alternative that also merges multimeasure rests. It is at http://code.google.com/p/lilypond/issues/detail?id=1228 and an updated version at http://code.google.com/p/lilymusic/source/browse/trunk/include/merge-rests.ily This include file could be added to LilyPond. It still has the limitation that it only supports two voices. best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly fails on 2.11.40
Op dinsdag 19 februari 2008, schreef Graham Percival:
> Using GUB, on OSX, but I haven't changed my setup ("Notes for OSX on
> the command-line") since .39.
>
>
> tsubasa:~/tmp gperciva$ convert-ly -e foo.ly
> convert-ly (GNU LilyPond) 2.11.40
> Processing `foo.ly'...
> Traceback (most recent call last):
> File
> "/Users/gperciva/Apps/LilyPond.app/Contents/Resources/bin/convert-ly",
> line 307, in ? main () File
> "/Users/gperciva/Apps/LilyPond.app/Contents/Resources/bin/convert-ly",
> line 301, in main do_one_file (f) File
> "/Users/gperciva/Apps/LilyPond.app/Contents/Resources/bin/convert-ly",
> line 234, in do_one_file (last, result) = do_conversion (infile.read
> (), from_version, to_version) File
> "/Users/gperciva/Apps/LilyPond.app/Contents/Resources/bin/convert-ly",
> line 171, in do_conversion if convertrules.error_file: AttributeError:
> 'module' object has no attribute 'error_file' tsubasa:~/tmp gperciva$
Same here. There is no 'error_file' attribute in the convertrules module.
best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
LilyKDE: http://lilykde.googlecode.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly fails on 2.11.40
Op dinsdag 19 februari 2008, schreef John Mandereau: > Oops, my bad, I forgot to check that convert-ly used error_file from > convertrules. Fixed in Git. Great, thanks! BTW: it is undocumented that convert-ly can read stdin (and write stdout). If given a --from version, convert-ly reads succesfully from stdin. But if not given a --from version, the guessing function tries to read the file as well, but does not reckon with stdin (`-' filename). It would be nice if reading from stdin would also be supported by the guess function (the file is read into memory anyway). good stdin/stdout/stderr functionality is nice for integrating convert-ly in editing environments (which I'm doing for LilyKDE). thanks, best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly version
Hi, it seems that convert-ly changes the version of the converted document to the latest version convertrules.py contains a rule for. Would it not be better if it changes the version to the current version of lilypond/convert-ly? So the document looks really up-to-date (even it only the \version number changed). best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly version
Op dinsdag 19 februari 2008, schreef Mats Bengtsson: > Wilbert Berendsen wrote: > > Hi, > > > > it seems that convert-ly changes the version of the converted document to > > the latest version convertrules.py contains a rule for. > > > > Would it not be better if it changes the version to the current version > > of lilypond/convert-ly? So the document looks really up-to-date (even it > > only the \version number changed). > > This is usually done (by hand) every time a new major stable version is > released. One argument against your proposal is that if you run > convert-ly -e *.ly then you can look at the modification time of each file > to see if it was changed or not, whereas if we implement your proposal then > all files will be updated even though nothing except for the \version line > has changed. Ok, that's very valid. I'm perfectly fine with the current behaviour (I run convert-ly from my LilyKDE IDE, using stdin and stdout, and when there is no output, I don't replace the editor buffer with the empty output.). Maybe a --force option could be added to force output of the file, with the \version set to the current version. But it's not important. best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Geting the list of MIDI instrument names
Hi, I'm looking for a stable way to get the list of supported MIDI instrument names from LilyPond, by running lilypond -e with a scheme expression to do just that (and not print a regular ps/pdf file). It's for my plugin that could offer a nice help window to quickly assign a midi instrument to a staff. Of course I could just include the list verbatim in my plugin, or even try to parse midi.scm myself :-O but I just wonder if there would be an elegant way to get the list... best regards! Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Geting the list of MIDI instrument names
Op dinsdag 19 februari 2008, schreef Mats Bengtsson: > Reinhold Kainhofer wrote: > > Of course, the lilypond-way is much better than my pure-scheme code... > > Yes and no! If you use ly:message, the printouts will appear on stderr > (or in the .log file if you use lilypond -dgui ...) and will be mixed with > some other printouts, whereas if you use display, then the printouts > appear on stdout and can therefore easily be separated from the other > log printouts. Thank you all. I /might/ settle on just replicating the list (because I don't expect any changes to it). But it is a nice possibility and it avoids duplicating information/code etc. best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NoteCollision vs NoteColumn
the 2.11.41 docs say that NoteCollision uses note-collision-interface, so I would think that: \once\override Staff.NoteCollision #'ignore-collision = ##t would work. But it doesn't. But when I use: \once\override Staff.NoteColumn #'ignore-collision = ##t then it works; collisions are ignored. could this be a bug in the docs? best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NoteCollision vs NoteColumn
Op dinsdag 26 februari 2008, schreef Graham Percival: > On Tue, 26 Feb 2008 16:03:00 +0100 > > Wilbert Berendsen <[EMAIL PROTECTED]> wrote: > > the 2.11.41 docs say that NoteCollision uses > > note-collision-interface, so I would think that: > > Where? Please give a specific subsection. http://lilypond.org/doc/v2.11/Documentation/user/lilypond-internals/NoteCollision best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ LilyKDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parenthesizing rests
Op woensdag 26 maart 2008, schreef Aaron Dalton:
> I've done some archive searching but there does not appear to be any
> solution. How does one parenthesize rests? I'm preparing a number of
> transcriptions that will eventually be formally published (with Lilypond
> credited as the engraver) and need to be able to show editorial rests as
> well as pitches. I am having the same problems outlined in the list
> archives.
I have no solution, but grepping/looking in the sources I found both
references to:
to_boolean (me->get_property ("parenthesized"))
as well as:
to_boolean (ev->get_property ("parenthesize"))
note the "d" at the end :)
In music-functions-init.ly the property name 'parenthesize is used.
Which one is correct and could that be the cause of rests not working?
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
[version 0.4.9 is out today, with new Konqueror servicemenu]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Why does LilyPond delete the PDF first?
Hi, in scm/backend-library there is (line 114-115): (if (access? pdf-name W_OK) (delete-file pdf-name)) Why is the PDF deleted (instead of just truncated on write)? It breaks the PDF watching feature of KDE, because KDE looses the watch on the file because it is deleted. When the file is recreated, it has a different inode number, and other attributes on the former PDF are lost as well. Commenting or deleting the two lines does not seem to do any harm on my system, and it fixes greatly the behaviour of KPDF and Okular. best regards, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why does LilyPond delete the PDF first?
Op woensdag 11 juni 2008, schreef Reinhold Kainhofer: > Am Mittwoch, 11. Juni 2008 schrieb Carl D. Sorensen: > > LilypondTool works properly with JPedal under windows. As long as JPedal > > is not the active window, the pdf can be properly written. If JPedal is > > the active window, then you get a write error on the pdf. > > BTW, kpdf works exactly the other way round: Instead of locking the pdf > file and preventing any changes while the file is viewed, it explicitly > allows changes while a file is open, watches it and reloads the file if a > change is detected. This is what lilypond breaks by explicitly deleting the > file. I think KPDF doesn't even keep the file handle open after all contents have been read and parsed. It just keeps watching the file for changes to its mtime, and reopens the file if it is updated. In http://code.google.com/p/lilypond/issues/detail?id=635 I added a very small patch to scm/backend-library.scm that just deletes the PDF as always when run on windows, but not on other platforms. best regards! Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why does LilyPond delete the PDF first?
Dag Risto Vääräniemi, op woensdag 11 juni 2008, schreef je: > Could you test on Linux what happens, if a pdf is opened with > Acrobat (Reader) and you re-compile the file? On Linux there is no problem with writing to the PDF file while Acrobat Reader is displaying it. best regards! Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: csorensen fork of lilypond
Op woensdag 18 juni 2008, schreef Carl D. Sorensen:
> for i in fret-props:
> if re.search (i, str):
> stderr_write ('\n')
When you only look for plain strings (as is the case), you could write:
for i in fret_props:
if i in str:
stderr.write ... etc
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
rewrote convertrules.py with a decorator
Hi, just for fun I rewrote convertrules.py (of current git) so that it uses a simple decorator function. Instead of the double procedure (function, and then calling conversions.append()) : def conv(str) # manipulate str return str conversions.append((version, conv, message)) you can now simply write: @rule (version, message) def conv(str) # manipulate str return str This makes more clear what parameters belong to the conversion function, and you do not need to type the conversions.append(( )) command each time. The decorator function does simply the conversions.append() so nothing changes otherwise. The conversions list with the convertrules is just the same as before. I fixed a few missing slashes in non-raw strings as well. No translatable strings have been changed. I verified (by diffing the output of repr() on both lists) that the conversions list is the same as in the old situation. Maybe this patch makes convertrules.py more readable and even more maintainable! best regards, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ convertrules-decorator.patch.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rewrote convertrules.py with a decorator
Op vrijdag 20 juni 2008, schreef Han-Wen Nienhuys: > This is an excellent idea. However, did you test this? AFAIK, the > decorator needs to accept the function as input argument. I tested it and it worked, I even verified that it really builds the same conversions list. :) The function rule() returns another function that accepts the function as argument. This is because the decorator function itself also needs to accept arguments (version and message). This is the decorator function: def rule (version, message): return lambda f: conversions.append ((version, f, message)) You could write this as: def rule (version, message): """this function needs to return a function that is called with the function as argument""" def deco (function): conversions.append ((version, function, message)) return deco but the above version is shorter :-) best regards, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alignment of metronome marks
Op maandag 23 juni 2008, schreef Reinhold Kainhofer:
> I have now commited my patch that allows text to be included directly into
> the \tempo commands, i.e.
> \tempo 4=120
> \tempo "Allegro" 4=120
> \tempo "Allegro"
> \tempo \markup{\italic \medium "Allegro"}
This is great! I will update LilyKDE so that it's score wizard (which already
can create a tempo mark using some rehearsalmark tweaking) uses the new
feature if the user's LilyPond is recent enough.
> I haven't updated the docs (1.6.3.1 Metronome marks), though.
>
> One thing I noticed is that the regression test
> input/regression/metronome-marking.ly says:
>
>"The marking is left aligned with the time signature, if there is one."
>
> Unfortunately, this is not true, the metronome marking is now always
> aligned with the following note... Is this a bug/regression?
This is also true for Rehearsal marks. I always set their break-align by hand,
and then even have to offset half a staff space more.
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
convertrules.py with decorator update for today's git
This is an updated patch for the convertrules.py script, rewritten using a decorator (rationale and info at http://lists.gnu.org/archive/html/lilypond-devel/2008-06/msg00163.html ) best regards! Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ convertrules-decorator-28jul08.patch.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] add LilyKDE to Text Editor Support
Hi,
this patch adds LilyKDE to the list in Text Editor support (AU 2.2).
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
--- setup.itely 2008-04-29 00:06:17.0 +0200
+++ /home/wilbert/Desktop/setup.itely 2008-07-01 13:19:27.0 +0200
@@ -197,6 +197,19 @@
@end example
[EMAIL PROTECTED] LilyKDE
[EMAIL PROTECTED] LilyKDE
+
[EMAIL PROTECTED]://lilykde.googlecode.com/,LilyKDE} is a plugin for KDE's
+text editor @uref{http://kate-editor.org/,Kate}. It has a powerful Score
+Wizard to quickly setup a LilyPond document and an embedded PDF viewer.
+
+LilyKDE can use @uref{http://www.volny.cz/smilauer/rumor/,Rumor},
+so music can entered by playing on a MIDI keyboard.
+
+Other features are lyric hyphenation and running LilyPond on multiple files
+at once from within the KDE file manager.
+
@node Point and click
@section Point and click
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convertrules.py with decorator update for today's git
Op woensdag 2 juli 2008, schreef Han-Wen Nienhuys:
> I already wrote a comment about this before, but I strongly doubt that
> this does anything useful.
The useful thing is dat a conversion rule now forms a single entity: version,
message and conversion function.
The current structure of convertrules.py is a bit error-prone: the function
definition comes first and then the conversions.append method adds the
version, a pointer to the latest definition of 'conv' and a message the the
conversions list.
My proposal is to use a decorator (we're requiring Python 2.4 anyway) so the
version a conversion function applies to is clearly connected with the
function and the message it outputs.
> Have you tested this at all?
Yes: I verified that the decorator based code just builds the same list in the
conversions variable as the old code by diffing the repr() output of both
lists.
This is just a proposal to make convertrules.py look better, more clear and
probably a little bit easier to maintain. Because you wrote in your first
answer "This is an excellent idea" I kept up maintaining it. If it gets
rejected, no problem, the old code works equally well. But IMHO, using a
decorator is a perfect fit for convertrules.py.
To summarize: with a decorator a conversion rule is really a single entity:
snip---
@rule ((1, 2, 3), _("convert foo to bar"))
def conv(str)
str = str.replace('foo', 'bar')
return str
snip---
in the old code, those are separated, and the conversion.append() command is
repeated every time instead of hiding that implementation detail:
snip---
def conv(str)
str = str.replace('foo', 'bar')
return str
conversions.append(((1, 2, 3), conv, _("convert foo to bar")))
snip---
best regards!
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convertrules.py with decorator update for today's git
Op woensdag 2 juli 2008, schreef Han-Wen Nienhuys: > I know what a decorator is - I'm sorry for thinking it didn't work, > but the code is a bit obtuse, and I got confused by > > return lambda f: conversions.append ((version, f, message)) > > which stores the conv function, but then will also redefine the conv > function to None. Essentially it does > > def dec(f): > return None > > @dec > def f(x): > return 1 > > print f > > => > > None Yes, the function is not returned by the decorator because it needs not to be stored in 'conv'; it would be overwritten anyway by the next rule. (In the current situation the value of conv also changes after every function redefinition). > Can you document this more clearly so it does not look so strange? Ok. Does everybody like the syntax of a rule like this? > Also the patch should look like a proper commit, with description > prepended and your name attached as author. I don't know exactly how to do that, but I'll try to find out :) cheers, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] add LilyKDE to Text Editor Support
Op dinsdag 1 juli 2008, schreef Wilbert Berendsen:
> Hi,
> this patch adds LilyKDE to the list in Text Editor support (AU 2.2).
And now as a proper Git patch.
cheers, (learning more every day!)
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
From 8768e1ceb1c6319abc7d64eb43854c01ffb3d703 Mon Sep 17 00:00:00 2001
From: Wilbert Berendsen <[EMAIL PROTECTED]>
Date: Wed, 2 Jul 2008 18:50:53 +0200
Subject: [PATCH] This patch adds LilyKDE to the list in Text Editor support (AU 2.2).
---
Documentation/user/setup.itely | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/user/setup.itely b/Documentation/user/setup.itely
index 868dbf6..ed08e90 100644
--- a/Documentation/user/setup.itely
+++ b/Documentation/user/setup.itely
@@ -197,6 +197,19 @@ svn co http://macromates.com/svn/Bundles/trunk/Bundles/Lilypond.tmbundle/
@end example
[EMAIL PROTECTED] LilyKDE
[EMAIL PROTECTED] LilyKDE
+
[EMAIL PROTECTED]://lilykde.googlecode.com/,LilyKDE} is a plugin for KDE's
+text editor @uref{http://kate-editor.org/,Kate}. It has a powerful Score
+Wizard to quickly setup a LilyPond document and an embedded PDF viewer.
+
+LilyKDE can use @uref{http://www.volny.cz/smilauer/rumor/,Rumor},
+so music can entered by playing on a MIDI keyboard.
+
+Other features are lyric hyphenation and running LilyPond on multiple files
+at once from within the KDE file manager.
+
@node Point and click
@section Point and click
--
1.5.2.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convertrules.py with decorator
[gzipped to make it small enough for the devel list] Attached a (hopefully properly git-formatted) patch. I built and tested again, just to be sure, and it works well. I documented the decorator function and wrote the code a bit less obtuse :-) This just makes convertrules.py look better. Every rule is now a single entity. I separated each rule with two blank lines. best regards! Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ 0001-This-patch-changes-convertrules.py-so-that-it-uses-a.patch.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly...
Op dinsdag 8 juli 2008, schreef Stan Sanderson:
> ...is not my friend.
>
> Mac OS 10.4.11, PPC, Lilypond 2.11.51
>
> convert-ly fails with the following messsage
>
> > Traceback (most recent call last):
> > File "/Applications/LilyPond.app/Contents/Resources/bin/convert-
> > ly", line 43, in ?
> > import convertrules
> > File "/Applications/LilyPond.app/Contents/Resources/share/
> > lilypond/current/python/convertrules.py", line 49
> > @rule ((0, 1, 9), _ ('\\header { key = concat + with +
> > operator }'))
> > ^
> > SyntaxError: invalid syntax
Are you using Python 2.4 or newer? I thought configure already requires Python
to be 2.4 or higher. The decorator syntax needs at least Python 2.4.
try:
$ python --version
to determine your Python version.
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
dead link in lilypond.org/web/about/faq
Hi, in http://lilypond.org/web/about/faq under "How do I learn the syntax" there's a link to http://lilypond.org/doc/stable/Documentation/user/lilypond.html#Tutorial that does not work; it should be: http://lilypond.org/doc/stable/Documentation/user/lilypond/Tutorial best regards! Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch to fix compile
Op maandag 29 september 2008, schreef Patrick McCarty: > -\include "gregorian-init.ly" > +\include "gregorian.ly" would that also be a candidate for a conversion rule? best regards, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch to fix compile
Op maandag 29 september 2008, schreef Valentin Villenave: > Oh, this was already implemented. Stupid me. Oh, and me sorry! best regards, Wilbert Berendsen -- LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
typo in midi.scm ?
Hi,
in midi.scm in 2.12.2 and 2.13.0 there is this line (line 106):
("guitar harmo(dinics" . ,(- 32 1))
this looks like a typo to me! (Caused by touching a laptop touchpad during
typing?)
I found this while equipping Frescobaldi with MIDI instrument name
autocomplete :-)
best regards,
Wilbert Berendsen
--
Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond.org/web/documentation still shows 2.10 as latest stable
Hi, http://lilypond.org/web/documentation still shows 2.10 as latest stable if NL (Netherlands) is the preferred language (even though the page is in English). best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
position of staccato dots if above stems
When I have 2 or more voices on a staff, it can occur that staccato dots are placed at the stem-side of the note instead of close to the note head. Shouldn't in this case the dots be placed centered above the stems rather than the note head? Because I have some heavily sloped 8-note beams, where the staccato dots are placed almost inside the beam. If the staccato dots would be placed inline with the stems, they would not run into the beam. (See picture, the output is untweaked default output of version 2.11.6). If the placing is intended then it is maybe a little bug that the beams are note taken into account? kind regards, and thanks for this wonderful program, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi staccato-dots-in-beam.png Description: PNG image ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ties go a bit haywire, bug in 2.11.26
Hi all,
I try to minimise the lilypond input to get the tie bug in 2.11.26 that I
mentioned on the user list.[1]
With this input:
\version "2.11.26"
\paper { line-width = 7 \cm }
\score {
\new Staff {
1
}
}
the middle tie in the second bar is too long and sticks out at both the left
and right ends. This gets disturbing when there are many ties and linebreaks
(as can be seen in [1]).
I have researched a bit:
- the right chord must have a second so that a note moves to the right (remove
the d'' and the ties are correct)
- a low note in the right chord causes thet stacking to be different (e.g.
remove all notes c' from the chords and the ties are correct, because the
lower notes are in different horizontal positions)
- when the music is displayed in its default spacing the tie is correct (e.g.
remove the line-width statement)
- also: when quarter notes instead of whole notes are used the ties are
correct.
It seems: the tie that is too long, is drawn as if the a' in the fourth bar is
horizontally placed when there would not be a c' below.
This bug hit me while typesetting an organ piece[2] into lilypond.
[1] http://lists.gnu.org/archive/html/lilypond-user/2007-06/msg00198.html
[2] http://www.wilbertberendsen.nl/mouvement (here still a Mup version that
will be replaced when the lily ties are right ;-))
with best regards, Wilbert Berendsen
PS I am really impressed with the advances in LilyPond. Since lily 1.2 or so,
every two or three years I tried to switch to LilyPond (from Mup) but got
stuck in the syntax, little annoyances (mainly text-music overlaps) in the
layout etc. But this time I really am switching over! Somehow the context
stuff is now quite clear to me and the layout has improved much in the latest
releases. The layout is imho better than Mup (that is also quite good, very
fast and well developed and supported!), but the flexibility of LilyPond
leaves all other contenders at an immense distance... :)
So yet again a big Thank You to all devs for this great program. I'll try to
learn scheme and to understand the Lily source so I can help out the coming
years with some bug fixing maybe... I already know some python, C and C++...
PS2: maybe the point and click links should default to off because the PDF's
are almost 8 to 10 times bigger with point and click on :)
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
new mup2ly script; require which python version?
I am currently writing a new mup2ly script in python (to import Mup files in LilyPond). The preprocessor part is already finished and works very well. But for the mup reading routines it would be nice if I could use yes-no regexp patterns (i.e. conditional matches based on previous matches). That would however require Python 2.4. Is that acceptable or should I try to keep the script working with 2.3? (the currently required Python version) - to make it possible to add it to LilyPond once the script is usable? Best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new mup2ly script; require which python version?
Op dinsdag 26 juni 2007, schreef Jan Nieuwenhuizen: > Yes. Looking at configure.in, we already require python 2.4 for some > scripts. Great! all the best, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
todays git: staffs printing on top of each other
Hi,
I updated to todays git because of the fix for issue 375. But a new bug is
present which causes staffs to print on top of each other when there is more
than 1 page and there are slurs in the lowest staff that are broken to the
next line. Sometimes I get 'programming error: insane spring constant'.
The following snippet illustrates the bug in git as of Tue Jul 10 14:42:30
CEST 2007:
\version "2.11.27"
\score {<<
\new PianoStaff <<
\new Staff { \repeat unfold 36 { c'1 }}
\new Staff { \clef bass \repeat unfold 36 { d1 }}
>>
\new Staff { \clef bass \repeat unfold 36 { f,8) r4 r r e,8( } }
>>}
The repeats are to fill more than a page, because only then this bug kicks in.
Should I report as a bug? Or should I just wait for .28 and see if the bug is
present still?
Another small gripe is that the bar numbers are a bit too far off the staff
brace, compared to vanilla 2.11.27.
With best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: todays git: staffs printing on top of each other
Op vrijdag 13 juli 2007, schreef Joe Neeman: > On Tuesday 10 July 2007 22:45, Wilbert Berendsen wrote: > > Hi, > > > > I updated to todays git because of the fix for issue 375. But a new bug > > is present which causes staffs to print on top of each other when there > > is more than 1 page and there are slurs in the lowest staff that are > > broken to the next line. Sometimes I get 'programming error: insane > > spring constant'. > > Thanks, this is fixed in git. Great! > > Another small gripe is that the bar numbers are a bit too far off the > > staff brace, compared to vanilla 2.11.27. > > Is this still true in git head? Does running with -ddebug-skylines show > that the BarNumber is being pushed up to avoid a collision? The barnumbers look OK now, thanks! with best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: barnumbers far off (was Re: todays git: staffs printing on top of each other)
Hi, sorry for double posting my previous message.
Op vrijdag 13 juli 2007, schreef Wilbert Berendsen:
> Will try to make a small
> example with debug skylines.
Attached a .ly with a PNG. The barnumbers are only too far with a PianoStaff,
not with a single staff score.
best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
\version "2.11.27"
\paper { ragged-right = ##t }
\new PianoStaff <<
\new Staff {c d e f \break c d e f}
\new Staff {c d e f \break c d e f}
>>
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
barnumbers far off (was Re: todays git: staffs printing on top of each other)
I'm sorry, I think I screwed a bit up (still learning git). Without noticing I compiled my own branch with the tie bug repaired. Now I learnt how to use git checkout -f to undo local changes and get the latest master. The staffs printing on top of each other are fixed, but the barnumbers are still a bit too far to the top-left of every system. Will try to make a small example with debug skylines. best regards! Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo won't produce desired output
Op maandag 16 juli 2007, schreef Neil Puttock:
> Hello,
>
> I'm trying to typeset a whole-bar tremolo in 3/8 time, but it's producing
> incorrect output.
>
> \version "2.10.25"
> \paper { ragged-right = ##t }
> \relative c' {
> \time 3/8
> \repeat tremolo 6 { c32 e32 }
> }
This looks like a bug, still present in 2.11.27.
When I change it to
\paper { ragged-right = ##t }
\relative c' {
\time 2/8
\repeat tremolo 4 { c32 e32 }
}
i.e. just make it a 2/8 instead of a 3/8 the output is correct. So there is
some calculation mistake regarding the dots/beams somewhere.
Met vriendelijke groet,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
tie to short when clef change at end of system?
I saw that a tie is not drawn upto the barline if there is a clef change in
another staff. I think it is OK to end the tie when there is a clef change at
the end of a system in the same staff, but that it is more beatiful to extend
the tie a bit more if a clef change occurs in another staff. (I used 2.11.27
from todays git HEAD). Should I file this as a (li'l) bug?
\version "2.11.27"
\paper { ragged-right = ##t }
\score {<<
\new Staff { a'1~ \break a' }
\new Staff { c'4 d' e' f' \clef bass g a b c }
>>}
best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
bar number positioning influenced by clef change at end of previous system
Adding to the bar number positioning soap, I found today that the positioning
of bar numbers somehow is dependend on clef changes at the end of the
previous system (in a different staff):
\version "2.11.27"
\score {\new PianoStaff <<
\new Staff {
\repeat unfold 7 { c' d' e' f' }
}
\new Staff {
c' d' e' f' \clef bass \break
c d e f \break
c d e f c d e f \clef treble \break
c' d' e' f' c' d' e' f' \break
c' d' e' f'
}
>>}
yields attached results. When there is a clef change in the previous system
the bar number is printed at a nice distance, otherwise to far off.
with best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: installation error with current git
Op zondag 5 augustus 2007, schreef Werner LEMBERG: > John, can you fix this, please? I'm using texinfo 4.8, in case this > is of importance (which I don't believe). Same problem here, with same texinfo version. best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lyrics auto - extender?
When adding lyrics to a voice, lilypond recognizes melisma's and tied notes, etc. and aligns syllabes accordingly. Wouldn't it be possible to automagically add extenders where the syllabe is visually shorter than the melisma or tied note? Now I have to manually add extenders (` __ ') and they seem sometimes to slightly influence the spacing (2.11.32). Would this be user-programmable? w best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
instrument names in some contexts (was: Re: Padding around instrument names)
Op zondag 19 augustus 2007, schreef Reinhold Kainhofer:
> While we are at it: Is there any way to vertically center the
> "instrumentName" for a ChoirStaff, GrandStaff or StaffGroup? Here is an
> example snippet that does not work (the instrument name is shown at the
> top, not vertically centered):
>
> \version "2.11.30"
> \new ChoirStaff \relative
> <<
> \new Staff { c1 \break c1 }
> \new Staff { c1 \break c1 }
> \set Staff.instrumentName = "Choir"
> \set Staff.shortInstrumentName = "Ch."
>
>
>
> If I use a PianoStaff and set PianoStaff.instrumentName, then the
> instrument name is vertically centered:
>
> \version "2.11.30"
> \new PianoStaff \relative
> <<
> \new Staff { c1 \break c1 }
> \new Staff { c1 \break c1 }
> \set PianoStaff.instrumentName = "Piano"
> \set PianoStaff.shortInstrumentName = "P."
>
>
>
> But I haven't been able to achieve the same for other multi-staves staff
> types. In particular
>
> \version "2.11.30"
> \new ChoirStaff \relative
> <<
> \new Staff { c1 \break c1 }
> \new Staff { c1 \break c1 }
> \set ChoirStaff.instrumentName = "Choir"
> \set ChoirStaff.shortInstrumentName = "Ch."
>
>
> does not print any instrument names.
Isn't it a good idea to add the instrument_name_engraver by default to the
ChoirStaff, GrandStaff and StaffGroup contexts?
Met vriendelijke groet,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
point and click, pdf size
to add to the discussion about PDF size: Maybe it's a good idea to turn point and click off by default. It is of most use while editing, but published PDF's are four to six times larger than without. My recent Bach-chorals[1] are 1548877 byte with, and 253525 bytes without point and click. Editing environments could be configured to call lilypond with -dpoint-and-click. (A special 'Publish' button could then export a PDF without the point and click urls.) Quite now and then I encounter large lilypond files on the web with all the embedded textedit:// urls; people apparently don't know about the possibility to turn it off (while it IS in the docs :-) best regards, Wilbert Berendsen [1] http://www.wilbertberendsen.nl/node/408 -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: instrument names in some contexts
Op maandag 10 december 2007, schreef Mats Bengtsson: > Wilbert Berendsen wrote: > > Isn't it a good idea to add the instrument_name_engraver by default to > > the ChoirStaff, GrandStaff and StaffGroup contexts? > > Sure! There is a little issue with the instrumentName in e.g. the ChoirStaff: when there are lyrics below the bottom-most staff, but not above the top staff (which is often the case) the Instrument Name is not exactly vertically centered in front of the system start brace, but appears to be too low (because the lyrics context below the bottom staff is also taken into account). Having the instrument_name_engraver in the ChoirStaff is useful for double-choir music, etc. (a little OT:) > Why not go one step further and remove the PianoStaff context > completely. > By now, the only difference compared to a GrandStaff is the > Instrument_name_engraver > which exists in the PianoStaff context, but not in GrandStaff. Yes, but I think the PianoStaff should stay, there may be small adjustments (e.g. concerning kneed cross staff beams etc) that distinguish the PianoStaff. Also I think it is a very clear name for a staffgroup with a clear purpose. (I could imagine the GrandStaff being removed instead...) Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
baseline-skip: how to change default and possibly alter default value in LilyPond.
I think the default baseline-skip of 3 is too large, and I often use 2.5. But I have to specify that using \override in each and every \markup. Is there a way to set it to a different default value? It is set in ly/paper-defaults.ly in text-font-defaults, but I don't know how to just set the value for baseline-skip without erasing the other parameters. Commit a1337246e82cb83334b7af43e432a89d8c89c157 Wed, 9 Mar 2005 changed the default value from 2 to 3. Wouldn't it make sense to change the baseline-skip default value to 2.5 or 2.7 (or so?). w best regards, and really loving Lilypond, but struggling with git (but that's my problem:) Wilbert -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond .ly Mime-type ?
Hello, I would like to add the *.ly filetype to environments like KDE, so .ly files are recognized by the file managers and get a nice icon by default. Is there a MIME-Type defined for *.ly ? I could imagine: text/lilypond (1) text/lilypond-source (2; idea found in [1] ) text/x-lilypond (3) text/x-lilypondsrc (4) text/vnd.lilypond.source (5) with a slight preference for (3). [1] http://www.mail-archive.com/lilypond-devel%40gnu.org/msg06889.html Are there other special file extension conventions and name schemes wrt LilyPond that are somehow official and should be recoqnized like *.ly ? Like *.itely, etc. Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond .ly Mime-type ?
Op zaterdag 15 december 2007, schreef Wilbert Berendsen: > Hello, > > I would like to add the *.ly filetype to environments like KDE, so .ly > files are recognized by the file managers and get a nice icon by default. > > Is there a MIME-Type defined for *.ly ? I could imagine: > > text/lilypond (1) > text/lilypond-source (2; idea found in [1] ) > text/x-lilypond (3) > text/x-lilypondsrc (4) > text/vnd.lilypond.source (5) > > with a slight preference for (3). > > [1] http://www.mail-archive.com/lilypond-devel%40gnu.org/msg06889.html Hm, replying to self: i stumbled upon http://www.mail-archive.com/lilypond-devel%40gnu.org/msg12600.html which also goes with text/x-lilypond ... if nobody objects, I will propose that one for KDE. > Are there other special file extension conventions and name schemes wrt > LilyPond that are somehow official and should be recoqnized like *.ly ? > Like *.itely, etc. > > > Met vriendelijke groet, > Wilbert Berendsen Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad error message
Op dinsdag 18 december 2007, schreef Francisco Vila:
> Hello. The following score
> (...)
> Results in:
>
> /usr/local/lilypond/usr/share/lilypond/current/scm/chord-entry.scm:39:11:
> In procedure construct-chord in expression (scm-error (quote
> chord-format) "construct-chord" ...):
> /usr/local/lilypond/usr/share/lilypond/current/scm/chord-entry.scm:39:11:
> Spurious garbage following chord: #
>
> This is a very poor error message, IMO. You don't know where is the
> problem in your score.
first line should be
acordes = \chordmode { f4/a }
instead of
acordes = \chordmode { f/a4 }
But the error message is VERY confusing :)
Met vriendelijke groet,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad error message
Op woensdag 19 december 2007, schreef Francisco Vila: > If I only knew what "Spurious garbage" means... freedict gives spurious -> espurio and interglot gives garbage -> immondices / ordures ménagères :-) Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
automagically add lyrics extender when a melisa is busy?
Hi, in lyrics-engraver.cc I can see how the self-alignment-X is adjusted for lyrics under a melisma. but would it be possible to automagically add extenders in such cases? e.g. if autoAddExtenders == ##t ? or can the lyrictext object not be modified anymore at the moment the lyrics are engraved. I often need to type (copy/paste) the lyrics for each voice, because the only difference (in polyphonic music) are the extenders. It would be very nice to add them automagically if they are desired (e.g. below melismata of a certain length). Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
incipit and SystemStartBrace/Bracket etc.
With some trial and error I managed in the D.5.1 ancient music template to move the SystemStartBracket (using #'extra-offset) towards the end of the incipit so that it is placed at the beginning of the modern notation. Attached an image. I'm sure with \startStaff and \stopStaff I can tweak the looks of the incipit even more to my liking. But the placing of the SystemStartBracket is tricky, because the layout of the first system might change, and then the bracket would print in a wrong place. Another aproach (recenly but also earlier mentioned in mailing list) would be embed \score inside instrumentName, but then the vertical alignment is a bit tricky, dependend on extent of lyrics in the incipit, etc. Isn't there a more direct way to get a systemstart in the middle of a score? Using some \systemStart or \restart command? (Many years I used mup, which has a restart command to do just that.) Clefs/Time/Key signatures could then also automatically be printed again without having to force fullsize clef changes etc. I'm already trying to add this option myself (delving into scm/ and lily/) but could use some help/hints :) with best regards, and a happy new year, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
syntax colored lilypond code in docs?
Hi, just for fun and to help some friends I'm hacking up a Dutch language Lily toot at http://www.wilbertberendsen.nl/cursus_lilypond . It's still in progress. I create the syntax colored Lilycode HTML with Kate (KDE's editor). But while busy I thought it would be nice to have (not too intrusive) colored HTML in the Lilypond.org documentation. The syntax highlighting should be added automagically, i.e. no *.itely files should be changed, just the build process should add the highlighting somehow, using some python script that could even get its words from the lily sourcecode like the .vim files. I started trying to find where to begin, but: does Texinfo support colors? If it does, can @verbatim still be used? If not, how would I get a colored PDF? (Is that desired anyway?) I'm quite proficient in HTML, but not in texinfo/dvi etc. But the nicest option would be have colored lilypond input in the PDF as well. w best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: syntax colored lilypond code in docs?
Hi Valentin, op vrijdag 18 januari 2008, schreef je: > 2008/1/18, Wilbert Berendsen <[EMAIL PROTECTED]>: > > I create the syntax colored Lilycode HTML with Kate (KDE's editor). But > > while busy I thought it would be nice to have (not too intrusive) colored > > HTML in the Lilypond.org documentation. The syntax highlighting should be > > added automagically, i.e. no *.itely files should be changed, just the > > build process should add the highlighting somehow, using some python > > script that could even get its words from the lily sourcecode like the > > .vim files. > > Another possibility would be to use a simple JavaScript function to > automatically color the code on the client side: perhaps you would be > interested in having a look at the following script I adapted a few > months ago, in an attempt to make a LilyPond web editor: > http://valentin.villenave.info/lilypond/ > > I implemented the full LilyPond API in regexps; then it is colored > using a simple CSS sheet. That's very interesting! I was already thinking about javascript highlighting. It could be even simpler as the lilypond web pages are read only. A single .js file would need to be included and it would automagically highlight the examples in the Lilypond manual. Which will make it more readable, I think. Esp. the difference between official commands and user commands. cheers, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
dutch translation Re: syntax colored lilypond code in docs?
Hi, John, op vrijdag 18 januari 2008, schreef je: > Cool! Have you also considered translating official docs? Jan and me > have set up a translation infrastructure that makes translated manuals > (Learning Manual, Notation Reference and Application Usage) available in > HTML and PDF, very visible on lilypond.org thanks to automatic language > selection, also available in docs tarball; all HTML pages have easy > switching between languages, incremental/partial translation of a manual > is possible, and updating translations is made easy with some Python > scripts. Let me know if you're interested :-) Yes, I'm interested but I really have not much time (busy musician jobs and two lovely children). I did much translation work in the past (mainly KDE and Scribus) but not any more atm. But an official Dutch Lilypond manual would be very nice, and I'd be willing to help lift it off... w best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fonts mangling
Op zaterdag 26 januari 2008, schreef Werner LEMBERG: > > > font_family: parmesan22.45 > > > font_identifier: parmesan22.45 > > > [...] > > > > > > Font family, name and identifier should be 23, right? > > > > Yes, I think so, for backwards compatibility. Will look at it soon. > > Thanks for investigation! > > This is fixed now in the git repository. Great, thanks! Fixes also 565. Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fonts mangling
Op zondag 20 januari 2008, schreef John Mandereau: > I've experienced problems with latest clean build of Git branch master, > with new mf->pfb conversion by mf2pt1: dynamics and time signatures are > sometimes printed with some Helvetica font instead of feta-alphabet. Same here, and also the system start braces are too long: entered a bug about it. http://code.google.com/p/lilypond/issues/detail?id=565 Probably related. Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
version in commit 3b7d631201dca7902620d79e83b7e37141040af3
diff --git a/ly/property-init.ly b/ly/property-init.ly -\version "2.10.0" +\version "2.7.38" shouldn't that be 2.11.38 ? w best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \times -> \tuplet (was Re: Issue 566 in lilypond: showStaffSwitch -> \staffSwitchOn)
Op maandag 28 januari 2008, schreef Trevor Daniels: > I too oppose this as a mandatory change, and the > creation of an alias. \times does exactly what > the word 'times' implies and not what 'tuplet' > would imply. The change would lead to still greater > confusion, with new users writing the fraction > upside-down. I wrote this also in the tracker: I have no problem with \times. I read \times 2/3 as 'duration times two-third' (dur * 2/3), while in \tuplet the fraction would be less clear. Also when applying \times to a long music fragment (rendering many tuplets), \times keeps its meaning, while I think 'tuplet' stands for a single bracketed group of notes. Concluding, I would say: You use the \times command to create tuplets :-) just my €0.02, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch for scm/editor.scm to add KDE (Kate) support.
Please find attached a patch that adds support for kate (KDE's editor) to
lilypond-invoke-editor . (Kate: http://kate-editor.org/)
Kate numbers lines starting with 0, so I had to add some code to decrease the
line number in the textedit:// url by one. The special string %(line-1)s is
replaced with the line number minus one.
with best regards,
Wilbert Berendsen
--
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi
--- scm/editor.scm 2007-09-19 14:50:18.0 +0200
+++ /home/wilbert/Desktop/editor.scm 2008-01-30 08:01:55.0 +0100
@@ -8,6 +8,7 @@
;; Also for standalone use, so cannot include any lily modules.
(use-modules
+ (ice-9 format)
(ice-9 regex)
(srfi srfi-13)
(srfi srfi-14))
@@ -37,6 +38,7 @@
("gedit" . "gedit +%(line)s %(file)s")
("jedit" . "jedit -reuseview %(file)s +line:%(line)s")
("syn" . "syn -line %(line)s -col %(char)s %(file)s")
+("kate" . "kate --use --line %(line-1)s --column %(column)s %(file)s")
("lilypad" . "lilypad +%(line)s:%(char)s %(file)s")))
(define (get-command-template alist editor)
@@ -66,8 +68,9 @@
(command
(re-sub "%\\(file\\)s" (format #f "~S" file-name)
(re-sub "%\\(line\\)s" (format #f "~a" line)
- (re-sub "%\\(char\\)s" (format #f "~a" char)
- (re-sub
- "%\\(column\\)s" (format #f "~a" column)
- (slashify template)))
+ (re-sub "%\\(line-1\\)s" (format #f "~d" (- (string->number line) 1))
+ (re-sub "%\\(char\\)s" (format #f "~a" char)
+ (re-sub
+ "%\\(column\\)s" (format #f "~a" column)
+ (slashify template
command))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for scm/editor.scm to add KDE (Kate) support.
Op woensdag 30 januari 2008, schreef Wilbert Berendsen: > > Kate numbers lines starting with 0, so I had to add some code to decrease > the line number in the textedit:// url by one. The special string > %(line-1)s is replaced with the line number minus one. Well, I now discover Kate from KDE3 starts line and col numbering at 0, but Kate from KDE4 starts numbering lines and cols with 1. Lilypond's textedit:// URIs on the other hand, start line numbers with 1 and col and char numbers with 0. (If I understand correctly.) So I guess I better add a textedit protocol wrapper to KDE, so that it automagically converts the textedit:// uris to a correct call to Kate. If I can get the texteditprotocol handler part of KDE, it can abstract away the differences in line and col counting. Met vriendelijke groet, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Point and click for Lilypond in KDE (was: Re: patch for scm/editor.scm to add KDE (Kate) support.)
Because of the differences in Kate line numbering between KDE 3 and 4 I think it's better to handle the invocation of the editor inside KDE, bypassing lilypond-invoke-editor. So the patch I sent to lily-devel is not necessary. I created two very small files that do the job. Both are attached, with a README. Hopefully this will once become a simple LilyPond/KDE package, with a nice helper plugin for Kate I'm trying to create. with best regards, Wilbert Berendsen -- http://www.wilbertberendsen.nl/ "You must be the change you wish to see in the world." -- Mahatma Gandi ktexteditservice Description: application/shellscript [Protocol] exec=ktexteditservice %u protocol=textedit input=none output=none helper=true listing= reading=false writing=false makedir=false deleting=false Icon=txt Class=:local Lilypond Point and Click for KDE (3.x and 4.x) == Nederlandse uitleg (English see below): 1. Plaats textedit.protocol in de KDE-services map, bijvoorbeeld ~/.kde/share/services/ of /usr/share/services/. 2. Plaats ktexteditservice ergens in het systeempad, bijvoorbeeld ~/bin/ of /usr/local/bin/ en maakt het uitvoerbaar: chmod +x ktexteditservice Maak nu een Lilypond-bestand aan in Kate. Laat Lilypond een PDF aanmaken, open deze in KPDF en klik in de PDF op een muzieknoot. Voilá! English: 1. Put textedit.protocol somewhere in the KDE services directory, for example in ~/.kde/share/services/ or /usr/share/services/. 2. Put ktexteditservice somewhere in the system PATH, for example in ~/bin/ of /usr/local/bin/ and make it executable: chmod +x ktexteditservice Now create a .ly file with Kate. Run Lilypond and open the resulting PDF with KPDF. Click on music notes and see the cursor jump to the correct location! Note: Kate from KDE3 uses a different line numbering scheme than Kate from KDE4. Please (un)comment the corresponding lines in ktexteditservice. Contact: Wilbert Berendsen <[EMAIL PROTECTED]> http://www.wilbertberendsen.nl/ Wed Jan 30 15:35:23 CET 2008 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's with the spacing code?
Op donderdag 30 september 2010 schreef David: > With the current code, a score that used to take 5 pages now takes 8, > really really spaced out. > > I don't see that we can release a version of Lilypond that takes up > horrifically more space than the previous not-skyline-based code. > > Making use of the skyline instead of the bounding box should never lead > to results taking more space. Strange, in my experience the spacing (esp vertically) is tighter and less pages are used most times. (An engraving of all Goudimel psalms takes 141 pages in 2.13.10 and only 131 in 2.13.35.) May be something else is going on in your score? A long time ago I had very strange horizontal spacing problems (with large gaps) that went away when I used --disable-optimising at the ./configure command line. best regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.18.0 released
Op Mon, 30 Dec 2013 17:50:09 +0100 David Kastrup schreef: > > Some of you might have seen this on the lilypond-announce list, but I > repeat it here since not everybody may read the announce list. The > big announcement to all the non-LilyPond lists will happen in a few > days if we don't get major complaints. > > Here it goes: > > We are proud to announce the release of GNU LilyPond 2.18.0 - the new > stable release. LilyPond is a music engraving program devoted to > producing the highest-quality sheet music possible. It brings the > aesthetics of traditionally engraved music to computer printouts. Congratulations! What a nice gift at the last minute of 2013! I won't be able to support all the new syntax in Frescobaldi 2.0.13 (which will be released tomorrow) but will follow suit a.s.a.p. best wishes and many thanks, Wilbert -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
converting LilyPond score to XML
Friends,
there have been some efforts in the past to convert LilyPond music to
XML. One of the approaches would be to convert the LilyPond music tree
to XML and be able to process it with other tools, which could read the
XML and convert it to MusicXML or other XML music formats.
I have now written a script that can be included in a LilyPond file and
has functions that can map LilyPond score, music and markup objects
etc. to XML, which is written to the current output port (standard
output).
The script is here[1] and there is some documentation included and also
visible here[2].
[1]
https://github.com/wbsoft/python-ly/blob/master/ly/xml/xml-export.ily
[2]
http://python-ly.readthedocs.org/en/latest/ly.xml.html#the-xml-export-ily-file
Usage example:
\include "/path/to/xml-export.ily"
\displayLilyXML { c d e f }
The XML closely mimics the LilyPond music structure. Markup objects are
also properly converted, as are pitches, durations, moments, stencils,
generic scheme lists, strings, numbers, pairs, symbols etc.
If you are interested in output the LilyPond music structure in XML
format, please test and experiment with this. Note that it is not
MusicXML or another XML format, but just the LilyPond music in XML
notation. This could be further processed or analyzed with other tools.
I am planning to make the XML output as complete and well-structured as
possible. In the documentation I describe how the XML is structured. It
currently supports \score (and all the music and markup, (even scores
inside markup!), but I want to add \book and \bookpart support, and
support for \layout, \paper etc.
(Reason for writing this was that I am trying to design an intermediate
tree-structured storage for parsed LilyPond code in
python-ly/Frescobaldi. I decided to look at how LilyPond itself stores
the music and to possibly mimic that in the python-ly/Frescobaldi
parser.)
best wishes,
Wilbert Berendsen
Frescobaldi and python-ly developer
--
Wilbert Berendsen
(http://www.wilbertberendsen.nl)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
converting LilyPond score to XML
Friends,
there have been some efforts in the past to convert LilyPond music to
XML. One of the approaches would be to convert the LilyPond music tree
to XML and be able to process it with other tools, which could read the
XML and convert it to MusicXML or other XML music formats.
I have now written a script that can be included in a LilyPond file and
has functions that can map LilyPond score, music and markup objects
etc. to XML, which is written to the current output port (standard
output).
The script is here[1] and there is some documentation included and also
visible here[2].
[1]
https://github.com/wbsoft/python-ly/blob/master/ly/xml/xml-export.ily
[2]
http://python-ly.readthedocs.org/en/latest/ly.xml.html#the-xml-export-ily-file
Usage example:
\include "/path/to/xml-export.ily"
\displayLilyXML { c d e f }
The XML closely mimics the LilyPond music structure. Markup objects are
also properly converted, as are pitches, durations, moments, stencils,
generic scheme lists, strings, numbers, pairs, symbols etc.
If you are interested in output the LilyPond music structure in XML
format, please test and experiment with this. Note that it is not
MusicXML or another XML format, but just the LilyPond music in XML
notation. This could be further processed or analyzed with other tools.
I am planning to make the XML output as complete and well-structured as
possible. In the documentation I describe how the XML is structured. It
currently supports \score (and all the music and markup, (even scores
inside markup!), but I want to add \book and \bookpart support, and
support for \layout, \paper etc.
(Reason for writing this was that I am trying to design an intermediate
tree-structured storage for parsed LilyPond code in
python-ly/Frescobaldi. I decided to look at how LilyPond itself stores
the music and to possibly mimic that in the python-ly/Frescobaldi
parser.)
best wishes,
Wilbert Berendsen
Frescobaldi and python-ly developer
--
Wilbert Berendsen
(http://www.wilbertberendsen.nl)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: converting LilyPond score to XML
Op Wed, 4 Feb 2015 15:40:42 -0700 (MST) MarcM schreef: > Have you seen > https://github.com/openlilylib/ly2xml/wiki/musicXML-export-in-Frescobaldi ? Yes! Peter Bjuhr is working on that, and that in fact caused me to undertake writing this Lily->LilyXML conversion script. Because in Frescobaldi/Python-ly, we currently use our own parser which can not understand music created from Scheme. When we let LilyPond create an XML tree, we can process that further and have viable MusicXML export. Wilbert -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code
Op Sun, 08 Feb 2015 17:26:45 +0100 Urs Liska schreef: > * MusicXML should definitely be considered in the context of actual > development taking place in the Frescobaldi context. At least it > should be harmonized with that effort. And: same question as > above: Are Reinhold Kainhofer and Mike Solomon actually available > as mentors? I am not sure if the MusicXML effort such as implemented by Python-ly (and used in Frescobaldi) really can compete with an in-LilyPond solution. Frescobaldi (and also the ly command provided by the python-ly[1] package), currently understands LilyPond music (i.e. music written in LilyPond syntax, not built by Scheme functions) and is able to export that to MusicXML. [1] https://github.com/wbsoft/python-ly We do this by having our own LilyPond parser (that also powers the syntax highlighting in Frescobaldi) and building a tree-structured music expression from it and Peter Bjuhr added code to build a MusicXML document from that music structure, which works quite well. We are extending this to a route where LilyPond itself parses the file and builds the score, music expressions etc, and converts this to a "LilyXML" document[2]. We can then read the XML in a python module and convert it to MusicXML. But we still only use the music input expression, not any output of the layout and engraving process. This is in development. [2] https://github.com/wbsoft/python-ly/blob/master/ly/xml/xml-export.ily see also http://python-ly.readthedocs.org/en/latest/ly.xml.html#the-xml-export-ily-file However, the effort described on the LilyPond Google Summer of Code page goes much further: it not only builds the basic XML document but also adds the layout information created by the engraving process, which is much more advanced, as it takes advantage of LilyPond's excellent layout. So I think people should not hesitate to build an excellent MusicXML exporting function in Lilypond, as the python-ly/Frescobaldi effort will not be able to use the layout information from LilyPond, but just the music (like the Midi output, but in a more advanced way of course) Wilbert -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is the Dutch LilyPond Forum/email list defunct?
Op Mon, 16 Mar 2015 12:12:43 + James schreef: > That the URL for the Dutch 'forum' is not working. > > http://www.lilypondforum.nl/ > > I'd like to remove this link if the URL is really no longer available. It is dead indeed, I'm sorry. -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
conflict ly module in ly2video and python-ly (was Re: Frescobaldi 2.18 install problems on KXStudio)
Dear Adam and Colin, Op Wed, 11 Mar 2015 09:03:16 -0600 Colin Campbell schreef: > Nailed it, Wilbert! It seems that I must be the first person to > install python-ly as well as Adam Spiers' ly2video. That's a really > cool utility which takes a .ly project, compiles to MIDI and > ultimately gives an AVI file with the score scrolling past over the > synchronised MIDI. It turns out that the ly module in ly2video is an old version of the same ly module I wrote for Frescobaldi, which now is in python-ly. I added this as an issue in the ly2video tracker https://github.com/aspiers/ly2video/issues/56, and I'm willing to help changing ly2video to use the new ly module, which is actively maintained and stable. Best regards! Wilbert -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme->basic xml (Re: Ekiga chat)
I wrote a script that transforms a LilyPond scheme music expression to XML. https://github.com/wbsoft/python-ly/blob/master/ly/xml/xml-export.ily How it works is explained at http://python-ly.readthedocs.org/en/latest/ly.xml.html This may be useful as a first step. I will probably use roughly the same type of XML structure when parsing LilyPond source to an XML structure using the ly.lex parser. -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Encoding of LilyPond console output
Hi all, When dealing with files and directories with accented letters (non-ASCII filenames) I came across a number of small issues, which I need to handle correctly in Frescobaldi, my LilyPond compagnion. Everything boils down to the question in which encoding the 8bit console output of LilyPond is presented. I was always assuming that this was UTF-8, which worked correctly on Linux. I.e. both filenameswith accented letters and translated messages (such as French, with many accented letters) always showed up correctly in the LilyPond console output. Which is read by Frescobaldi as an 8bit bytestream and decoded into unicode strings using the UTF-8 encoding. Then, on Windows, I discovered that filenames do not use UTF-8 encoding, but rather 'mbcs' or something like that (what is returned by sys.getfilesystemencoding() in Python). So I changed Frescobaldi to use that encoding when reading LilyPond console output, but then we discovered that translated messages (such as the French ones) with accented characters do show in a garbled encoding (clearly showing something like UTF-8 displayed as Latin1). So again I changed Frescobaldi, and now it reads the console output byte stream and parses that for file references (such as: file.ly:12:3: error: blabla) and decodes those filenames using the filesystem encoding, and the rest using UTF-8. This seems to work well: file references are correctly parsed and messages are readable still. Only some other messages from LilyPond that show filenames, like "processing `file.ly'...", show the filename in a wrong encoding, because the filename is written as-is in the filesystem encoding, intermingled in a message encoded as UTF-8. This can also be seen on the Windows console (both CMD and the Git bash console). So everything thrown together: is my analysis of the mixed output encodings LilyPond uses on stdout and stderr correct? And in line with this: can LilyPond be made more aware of this, and use the same encoding for all output (correctly encoding filenames)? Or am I wrong? With many regards and best wishes to all for the new year! Wilbert -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Point and Click also into the MIDI file
Op Thu, 29 Mar 2012 08:41:18 + (UTC) Silvio Ardito schreef: > Dear Sirs, > I am developing a Midi music player, using the .mid and .pdf > generated by lilypond with the \pointAndClickOn, for educational > purpose. > > Others players "invent" the music score from the .mid, not a true > music score. > > If the same informations, line and column, are in the midi file, it > is possible, playing the midi, to link .mid and .pdf . > > The suggested format is using the meta-text message like: > > FF 01 LL # POINTANDCLICK > > where: > LLlength > # identifies the point and click > POINTANDCLICK the same informations on .pdf This would also be extremely nice for Frescobaldi. -- Wilbert Berendsen (http://www.wilbertberendsen.nl) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
