Re: Issue 4345 in lilypond: Patch: Part combiner: allow a2 chords
Dear Kristof, Am 2015-04-20 um 11:16 schrieb Kristof Bastiaensen: I have a hard time to believe that anyone actually uses the part combiner seriously, but please prove me wrong. I'm using the partcombiner with all my orchestral scores. For an example see my edition of Schubert's Stabat Mater D.383: https://gitlab.com/edition-kainhofer/0002_schubert_stabatmater_d383/blob/master/out/Schubert_StabatMater_D383_Score_Full.pdf Of course, I had to frequently override the partcombiner's decisions using \partcombineApart, \partcombineChordsOnce, etc., but that's to be expected from any kind of automatic decision system (be it strictly rule-based as the current partcombiner, or heuristics-based as your version). Best regards, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com/ * Open Tools, Software Development, http://www.open-tools.net/ * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staff ends before \clef, \time and \key
Dear David,
Thank you for the hint with break-align-symbols, which works much better
than the suggestion on the user list to simply use "s8" to prolong the
staff (but introduces other issues, like a \mark "seque Terzetto"
stretching the staff lines after the final time change)...
So, basically, you are saying that this is not a regression from 2.18 to
2.19, but rather an intended change? In that case, I will refrain from
submitting a bug report.
Thanks again and best regards,
Reinhold
Am 2015-04-07 um 18:59 schrieb David Kastrup:
Reinhold Kainhofer writes:
Hi all,
It's been quite a while since I last used LilyPond, and I finally
decided to wrap up the last, huge edition I was working on for quite a
while.
Here is the first issue I'm running into:
If I end a piece with a \bar "||" and after that only want to indicate
a key/clef/time change, the staff lines stop with the bar line. A
typical use case is in a work with multiple movements to indicate
"attacca" to the next movement, which is written as a separate
\score. Minimal example:
\version "2.19.19"
\relative c'' {
c4 a b c
\bar"||"
\key f \major \time 3/4
}
Output PDF is attached.
I should probably mention that the snippet works just fine in Lilypond
2.18. Only Lilypond 2.19 breaks.
Any idea how to keep the staff lines alive until the key/time/clef change?
That sounds like issue 660
https://code.google.com/p/lilypond/issues/detail?id=660>.
Try
\override Staff.StaffSymbol.break-align-symbols = #'(time-signature
key-signature staff-bar break-alignment)
The default is just #'(staff-bar break-alignment) and the staff will
reach to the first encountered element in the list.
This might warrant some better documentation I suppose.
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com/
* Open Tools, Software Development, http://www.open-tools.net/
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Staff ends before \clef, \time and \key
Hi all,
It's been quite a while since I last used LilyPond, and I finally
decided to wrap up the last, huge edition I was working on for quite a
while.
Here is the first issue I'm running into:
If I end a piece with a \bar "||" and after that only want to indicate a
key/clef/time change, the staff lines stop with the bar line. A typical
use case is in a work with multiple movements to indicate "attacca" to
the next movement, which is written as a separate \score. Minimal example:
\version "2.19.19"
\relative c'' {
c4 a b c
\bar"||"
\key f \major \time 3/4
}
Output PDF is attached.
I should probably mention that the snippet works just fine in Lilypond
2.18. Only Lilypond 2.19 breaks.
Any idea how to keep the staff lines alive until the key/time/clef change?
Thanks,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com/
* Open Tools, Software Development, http://www.open-tools.net/
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version "2.19.19"
\relative c'' {
c4 a b c
\bar"||"
\key f \major \time 3/4 \clef "bass" {}
}
staff_end.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Job
Dear all, As you might have noticed, I got quiet a while ago. The main reasons were that I have recently startet at a new job with the Austrian Financial Market Authority, adn that my focus in my spare time has also shifted away from creating scores to performing and to developing plugins for the VirtueMart webshop. I have still been following the lists for the past few weeks, but as it turns out, my spare time gets even more scarce, so I'll probably also unsubscribe from the LilyPond lists. I wish you all the best. LilyPond is an awesome project, and it was a lot of fun to be part of if. But I simply don't have the time any more to work on it. I will keep working with it (after all, my SO is a cello teacher...) and hope to stay up to date with it. If there pops up anything where you'd like my input, please CC me and I'll try to help as far as I can. Best regards, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * VirtueMart Plugins, http://www.open-tools.net * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
Regarding MusicXML support: Michael Good, the creator of MusicXML, is now working for MakeMusic (the creators of Finale), and the way I understood his comments on the MusicXML mailing list he would be very interested in LilyPond having MusicXML export functionality, too. Maybe you can even get him on board. Reinhold On 2013-03-26 18:27, David Kastrup wrote:> We would extend LilyPond to be able to directly export MusicXML and use > MusicXML as an input language. Scores submitted to the "Mutopia 2" in > LilyPond format would be available in newer versions via convert-ly. > Verification of proper convert-ly could be done by comparing the > resulting MusicXML, if the conversion failed, at least delivering the > MusicXML as proper LilyPond files are, due to the continuing evolution > of the language, somewhat precarious as a long-term archival format. > > Defining standard MusicXML readings of LilyPond files and, if necessary, > at a later point of time defining convertible newer format versions that > would be convertable forward (and back?) with a more reliable mechanism > than convert-ly would also be necessary. > > For the whole XML-centric and web-centric workflows we'd have a > significant amount of convertibility from cash into results (those are > mainstream frameworks and as such there are capacities on the free > market). > > Getting LilyPond and MusicXML into a closer relation and providing end > user accessible web entry inputs would be possible by players like > Scorio.com, and Philomelos, and they have quite a bit to gain by getting > a larger corpus of LilyPond-friendly MusicXML into their grasp. If we > can get something like Steinberg into the same boat (without sinking it) > for playing a more generally useful MusicXML game, this could also be > interesting. > > This could move to a very big framework of a reliably archivable > MusicXML version and surrounding free toolchains, with other notesetting > programs being able to compete on their own merits on the same publicly > accessible MusicXML database. > > One would need to flesh out work flows and dependencies of particular > milestones and targets in order to arrive at a good distribution of > tasks and competency. > -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: For those who need new features and bug fixes...
On 2012-12-21 13:33, David Kastrup wrote: In contrast, grace notes in typesetting are usually _not_ aligned. Grace notes in one voice may even overlap previous moments of other instruments (See Gould, first image p.128): "This facilitates score-reading, as it prevents distorted note-spacing of a single beat"(Gould). An appoggiatura comes _on_ the beat, with the main note following it without additional spacing, acciaccature come _before_ the beat. We should really only have one NoteColumn per _main_ time (and not on grace times), and in the case of appoggiature, it should align on the appoggiatura itself, whereas for normal grace notes and acciaccature, it should align on the main note. Gould: "Grace notes are placed before the position of the beat regardless of whether they are prerformed on or before the beat." In either case, grace notes and main notes should be next to each other without doing _any_ NoteColumn kind of alignment for vertically aligning material within the grace timing. > Visual grace alignment is really a thing that should be per-voice. It > may be nice to have a "Grace_alignment_engraver" which you can call in > at higher level such as Staff optionally (to synchronize graces for > potentially multi-voice instruments). But by default I don't think they > should be aligned. Gould: "When there are two parts on one stave, align the grace notes of the two parts. [image] When two parts with grace notes are on separate staves, it may be more helpful visually to close up grace notes to the following measured value, regardless of vertical alignment)." Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python hacker emergency on git-cl
On 2012-12-02 12:50, Thomas Morley wrote: Trying to upload a new patch set for issue 2966, I ran into said git-cl-issue. Using LilyDev, I tried to apply Reinholds patch (after storing it in git-cl.diff), but the terminal returns: harm@harm-laptop ~/lilypond-git (dev/local_working)$ git apply git-cl.diff error: git-cl: No such file or directory error: upload.py: No such file or directory What's wrong and how to proceed? Are you trying to apply it to the lilypond source code? It should be applied to your git-cl checkout... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python hacker emergency on git-cl
On 2012-12-01 17:12, David Kastrup wrote:> My interpretation is that Google has set codereview.appspot.com so that > any http request will automatically get redirected to https, and git-cl > is unable to deal with that. Well, git-cl (I would prefer git-cly to indicate this is not the standard git-cl, but a modified version for use with lilypond!) uses Google's upload.py script, which is able to handle https properly. > It is unlikely that this is going to change on Google's side, so until > somebody gets git-cl able to deal with that, our workflow is hosed. It's actually quite simple: https://codereview.appspot.com/6864043/ All I did was download the latest upload.py from the rietveld help page and adjust the changed command line arguments... > Any Python hackers willing or able to take this on? Absolutely no python needed... Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow music of nominally zero duration to be typeset. (issue 6810087)
On 2012-11-16 23:57, d...@gnu.org wrote:
I have not actually tried to understand the code. I just added checks
for existing array elements before access until I could no longer make
LilyPond segfault or produce programming errors.
So this is, indeed, strictly a patch on the "won't make things worse"
basis, except for the one, initial removal of a zero-duration check,
necessary for sane behavior in things like incipits without notes.
But that check was added for exactly that reason: To warn the user that
no output was produced (apparently, no regtest was added back then).
With this patch, even for an empty music, lilypond tries to do the
pagebreaking (and reports 0 pages):
-) With this patch applied
reinhold@zweistein:~$ lilypond empty.ly
GNU LilyPond 2.17.7
»empty.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Warnung: keine Musik in der Partitur gefunden
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf 0 Seiten angepasst...
Systeme erstellen...
Kompilation erfolgreich beendet
-) Without that patch:
reinhold@zweistein:~$ lilypond empty.ly
GNU LilyPond 2.17.7
»empty.ly« wird verarbeitet
Analysieren...
Warnung: keine Musik in der Partitur gefunden
Kompilation erfolgreich beendet
So there is a difference (to me, pagebreaking does not make much sense
if we already know there will be not output). But that doesn't mean that
I'll veto that patch.
The downside are problems with material that indeed produces no
output. The basic change is simple and just in
lily/global-context-scheme.cc. All the rest is attempting to remove
programming errors and warnings occuring for basically empty systems.
The current state is that
\new Staff { }
will segfault,
Really? With lilypond 2.17.7 it didn't crash here...
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: possibility of merging \override and \set (was: Naming _another_ lacking puzzle piece)
On 14/10/2012 17:46, Janek Warchoł wrote:
> As for (2), i see that there are three operations that can be
> performed on stack: push, pop and clear.
Please, can we get away from thinking in terms of implementation details
and instead think of the use cases:
1) Just set a property (grob or context property) to a certain value,
don't worry about previous values
2) Set a property to the defaults
3) Temporarily set a property to a new value, being able to switch back
after a while
4) Switch back to a previous value
To implement those, only 3) and 4) need a stack or some other form of
storing previous values, but even that is not important to the user
(lilypond users as well as developers simply using the provided API to
modify grob properties).
\set and \unset (for context props) currently do 1) and 2), \override
currently more or less does 1), \revert does 4), and only the scheme
function make-grob-property-override does 3)
The name "override" to me implies that there a value in force, but one
temporarily overrides its effect with something else, so this would
suggest it for use case 3). Also see the documentation string of
make-grob-property-set (which is called by \override):
"Make a @code{Music} expression that sets @var{gprop} to @var{val} in
@var{grob}. Does a pop first, i.e., this is not an override."
So even the documentation for \override says that it is NOT an override...
My suggestion for the functions performing those four basic operations are:
1) \set(most current uses of \override by users are really meant as
\set)
2) \clear (replaces current \unset, some of the \revert calls)
3) \override (only needed when you need to switch back to previous value)
4) \restore
Of course, context properties currently don't have any history (i.e. no
stack), except for handling \once\set in the iterator, so this would
need to be implemented.
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On 2012-10-14 01:07, Joseph Rushton Wakeling wrote:
On 10/13/2012 11:44 PM, David Kastrup wrote:
\once creates a one-time-step temporary change, \temporary an
unterminated temporary change which can be terminated element-wise with
\revert or, again using a converter, en bloc from the original overrides
with \undo.
Forgive me for coming into this without the background, but what's the
difference between \temporary and the existing \override?
\temporary\override would work the way you probably expect \override to
work now:
It sets the grob property to a new value and keeps the old value stored
so that after \revert the property takes the old value it had before the
\temporary\override.
The actual problem is that \override currently CLEARS (i.e. reverts) the
current value before setting the new one, so that the old value is not
stored anywhere any more, and a \revert thus reverts to the default value.
As an example, let's look at the following code. What color would you
expect the final "b" to have? red? (because the \revert clears the
previous override to blue, right?)
\version "2.16.0"
\relative c' {
c4
\override NoteHead #'color = #red
f
\override NoteHead #'color = #blue
g
\revert NoteHead #'color
b
}
In reality, the \revert does not revert the override, but completely
clear the value to the black default. Currently, there is no way to
temporarily change a property and then change it back to its previous
value (except for \once\override, which only works for one timestep).
In fact, \override and \revert are currently misnamed, they work more
like \set and \unset.
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On 2012-10-13 23:44, David Kastrup wrote: \once creates a one-time-step temporary change, \temporary an unterminated temporary change which can be terminated element-wise with \revert +1 That's a consistent naming scheme, and \temporary is a perfect match with \once, so I'm all for that name. \once changes the value for one step, \temporary until it is explicitly \revert'ed (und unfortunately \override alone permanantly overwrites rather than overrides). or, again using a converter, en bloc from the original overrides with \undo. Temporary changes are important enough that we have had \once for a long time already. Fully agree, \temporary was really missing. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 22:48, Joe Neeman wrote: If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names "push" and "pop" as being opaque to non-programmers, Exactly. The names push/pop are stack concepts that require thinking like a programmer (and to be honest, I'm still confused: Does "pop" popsomething into the stack or pop something out of the stack The only way for me is to think that it's the opposite of "push"). I completely agree that we need a function that changes a property in a non-destructive way. It is an implementation detail that this internally means a pure push on the grob properties' stacks, but I don't think that the interface we provide to the users/high-level developers should have the API of a stack, as that would require that we describe it to users (many of whom have no programming experience, and don't want to) in terms of stacks. The internal handling of property values is via stacks, but for the user it is not about a stack, but about changing the value of a property, and later reverting it to a previous value (at least, I would expect that; currently we always revert to the default), or restoring the default. That was my main objection to using "push" and "pop" as names: They reveal the implementation details (using a stack for the property value handling) rather than providing a high-level API that is centered on the purpose of the calls rather than the internals. If we were to completely re-design the lilypond language, I would suggest \override, \revert and \clear (as push, pop and clear stack), but they currently have a slightly different meaning. The real problems we currently have are that, 1) We don't have a function that sets a grob proparty non-destructively via a simple push, 2) although the name suggests otherwise, \override is a not really a temporary override, but a permantent, destructive value setter function. 3) \revert does not revert the effect of an override, but rather reverts to the default value... 4) Grop properties and context properties have different setter functions and concepts (\override vs. \set), which is not intitive to me, and hard to explain to a newcomer. 5) Any change will likely break backward-compatibility and introduce subtle problems (like things looking/behaving different without any warning). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 23:29, David Kastrup wrote: >If you are referring to Werner's and Reinhold's comments, I think you >may not be reading them as the authors intended. In particular, I >believe that Reinhold was merely objecting to the names "push" and >"pop" as being opaque to non-programmers, To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^ into a programming language and away from being a description of ^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. Sorry, maybe I wasn't clear enough in that last sentence. It would have been clearer if I wrote ... but using the names "push" and "pop" ... The thing about programming languages was intended to give a larger picture why I don't like pure programming concepts introduced to lilypond users, and using the names "push" and "pop" introduces stack concepts to the users, rather than providing a user-friendly (i.e. musician-friendly, not programmer-friendly) high-level API to the users. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 09:32, Werner LEMBERG wrote:>> Maybe \push\override ... but this has the disadvantage that you >> never actively see a \pop. Hm. Maybe we should rename \undo to >> \pop then? > > I think that we either need a consistent use if \push and \pop, or we > should refrain using it. Given that the Scheme functions handling the > stack are not mapped one-to-one to user commands, as you've shown in a > previous mail, I think we should avoid \push and \pop. To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more into a programming language and away from being a description of music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 2012-10-13 07:30, Keith OHara wrote: Can anyone reading here (other than David who implemented it) give an example where he has used the grob-augmented \tweak syntax ? I had to use it to change the parentheses of \parenthesize, e.g. to use square brackets or to use only a left or right parenthesis (to indicate longer parenthesized parts, like multiple staccatos). See: http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00707.html Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 2012-10-12 00:25, David Kastrup wrote:> \tweak gets one symbol list, \override gets two symbol lists. The > symbol list for \tweak may optionally start with a grob name, the first > symbol list for \override may optionally start with a context name. I > can offer \tweak color.Accidental #red cis as the optional form for > \tweak, but that seem bonkers. Is there really no way to determine whether a symbol describes a context, a grob or a grob property? We don't neccessarily need this at the parsing stage. We might change the internal functions to use a list to describe the full path for grob properties, and the functions that handle them could then check whether the first entry is a context, a grob or a property. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 2012-10-09 11:14, Francisco Vila wrote:> 2012/10/9 Benkő Pál
:
>> 2012/10/9 Francisco Vila :
>>> When I learned how to read music, triplets were taught to me as
>>> "always shrinking" groups and you see a "3" but there is an implicit
>>> "2" so we have 3:2. Only the numerator is printed by convention.
>>>
>>> Thus, if you write
>>>
>>>\times 2/3 { b16 b b b b b }
>>>
>>> or
>>>
>>>\times 4/6 { b8 b b }
>>>
>>> this is mathematically perfect but the number you are asking to be
>>> printed is a confusing "3" and a confusing "6" respectively.
>>
>> the first is not confusing:
I think the point here was not that the tuplet notation on paper is
confusing per se. Actually, both are VERY common (the 6:4 tuplets appear
e.g. in Schubert's Stabat Mater, in several pieces by Preindl or Eybler,
etc.)
What is confusing is that "3" is printed, when you actually write 2/3.
Also, Gould explains tuplets m:n as "m in the time of n" and calls m:n
(i.e. 3:2) the tuplet ratio...
>> it makes sure to read
>> b16[ b] b[ b] b[ b]
>
> Yes, but I think it is more common to print a "6" here with the same
> meaning.
Not that I know.
A triplet (i.e. 3:2) means that there are three beats in the tuplet, the
first might get a slight accent, while a sextuplet means there are two
groups of three notes.
Also compare Gould, p. 213, regarding the subdivision of beams:
"A triplet is always a tripartite division, whereas a sextuplet is two
groups each of three notes, a bipartite division."
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 2012-10-08 00:21, Joseph Rushton Wakeling wrote:
On 10/07/2012 11:52 PM, Reinhold Kainhofer wrote:
There is, however, no check whether the fraction with the durations makes
sense and matches the real tuplet (in most cases, itwill not).
Yes, that's what I mean. I'd like to see something where the fractions
and durations are all derived from the tuplet syntax.
Actually, thinking of it, it would actually be quite simple to calculate
the displayed fraction with durations from the given durations and the
tuplet fraction (except that there is no way to distinguish 3:2 and 4:6).
(m*dur1):(n*dur2) = tuplet fraction
can be easily solved as
m/n = (tuplet fraction)*dur2/dur1
and then reduced to minimal m and n. This could then be displayed as
m{dur1}:n{dur2}
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 2012-10-07 23:38, Joseph Rushton Wakeling wrote:
On 10/07/2012 11:29 PM, Reinhold Kainhofer wrote:
http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817
I implemented those functions for MusicXML import. Note, however, that
lilypond
does not automatically use those, you have to manually set them as
shown in the
snippets.
Do I understand right that these functions are entirely manual overrides
-- that they specify what to print (either a note-value, or the entire
ratio) without reference to the actual tuplet underneath?
No, the formatter functions that I wrote use the tuplet fraction. The
override does not contain the values of the tuplet fraction, just the
note types. E.g.
\once \override TupletNumber #'text =
#(tuplet-number::append-note-wrapper
tuplet-number::calc-denominator-text "4")
\times 2/3 { c8 c8 c8 c8 c8 c8 }
This will print 3{4}, where the 3 comes from the tuplet fraction and
only the base note duration is set in the override.
Or the more general case:
\once \override TupletNumber #'text =
#(tuplet-number::fraction-with-notes "4." "8")
\times 2/3 { c4. c4. c4. c4. }
This will print a tuplet number
3{4.}:2{8}
where the 3 and the 2 comes from the \times command and only the note
durations are specified in the override. There is, however, no check
whether the fraction with the durations makes sense and matches the real
tuplet (in most cases, it will not).
There are, however, also formatter functions that override also the
tuplet fraction.
This is what I'm getting at, you see -- I'd like to see a \tuplet
command that takes the information I've given about the tuplet ratio and
units and translates that _automatically_ into the correct notation.
I don't think that fully automatic tuplet notation will work in all cases.
However, there is certainly enough to think about a more general tuplet
command in lilypond. The formatting functions are already there, what's
missing is the input syntax.
I'm not trying to dismiss your work, it's just that I'm leery of purely
manual notational overrides because there's always a risk of screwing
things up if you later revise the piece and forget to also revise the
override (there's a similar problem IIRC with the current solution to
customized subsidiary beam-breaking).
It's not purely manual overrides... (But still enough rope to hang
yourself in the way you describe).
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 2012-10-07 23:14, Joseph Rushton Wakeling wrote:
Apologies for coming late with these next remarks, but it's perhaps
worth thinking about quite how flexible a \tuplet command could be, in
respect of some of the various modern notations out there.
Just to give a flavour, besides the standard
|-- n --|
(i.e. bracket with number), and the almost-as-standard
|- n : m -|
(i.e. ratio), you also might encounter something like,
|- 3 : 2 {2} -|
or
|- 3 {2} : 2 -|
where {2}, {4}, {8} etc. represents a written half, quarter, eighth
note, etc.
http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817
I implemented those functions for MusicXML import. Note, however, that
lilypond does not automatically use those, you have to manually set them
as shown in the snippets.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)
On 2012-10-06 06:33, lemzw...@googlemail.com wrote:
http://codereview.appspot.com/6584073/diff/1/python/book_latex.py
File python/book_latex.py (right):
http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
On 2012/10/06 02:12:41, Julien Rioux wrote:
.* should be replaced by the non-greedy .*?
Yes :-)
Absolutely, was my mistake.
http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
As David has commented on the list, I would prefer if you replaced the
\iffalse ... \fi with a higher-level command, namely \begin{comment} ...
\end{comment} (from the `comment' package).
So, your opinion is that lilypond-book SHOULD process the \lilypond{...}
code inside the \iffalse section and spectacularly fail. If users are
using \iffalse -- I am for example one of those who use \iffalse to
quickly comment out some parts temporarily -- then lilypond-book would
still require everything between \iffalse and \fi to be in correct
lilypond syntax and will create snippet images for all those snippets:
\documentclass[a4paper, 12pt]{article}
\begin{document}
TODO
\iffalse
This is a template for my future snippets:
\lilypond{Code comes here}
\fi
\end{document}
Shall lilypond-book really fail for (and process) snippets that will NOT
be included by latex???
First of all, this syntax
suits LaTeX better since it resembles normal environments. Second, it
is a bad idea in general to expose \ifXXX to the top level; in other
words, users should never do that.
But fact is, people ARE using \iffalse to temporarily comment out larger
parts of latex files. With my colleagues, I have never seen
\begin{comment} for comments, all the researchers I have worked with so
far were using \iffalse.
Also, this is not about advocating what latex users should use, but
handling whare users are using currently. So, I will add \begin{comment}
to the pattern, too, but I still think that lilypond-book SHOULD ignore
everything inside \iffalse.
Reason is that \ifXXX is handled
very special in TeX since you can define, say, \ifFoo which also pairs
with the next \fi, making correct balancing of nested \ifXXX commands
quite delicate and very hard to debug.
Sure, it's not the perfect way, but it's the quick-and-dirty way.
I'm also aware that lilypond-book will not be able to handle nested
\ifXXX correctly. However, in the worst case, it will process some code
after the first \fi and before the final \fi of the \iffalse. But that's
still better than the current situation, where it processes everything
between \iffalse and \fi.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets
On 2012-10-05 09:10, James wrote:
Hello,
On 5 October 2012 00:19, Ian Hulin wrote:
This is a proposal to move the triplet/tuplet discussion forward.
There will be new commands to supplement (or eventually replace) the
current \times command.
1. \tuplet n/m {}
% does what \times does, but not so easily confused with \time
% command.
2. \triplet {} % shorthand for current
% \times 2/3 command
3. \duplet {
+1
Do we need all these commands?
They are helpful utility functions. We don't need them, but it would be
nice to have them.
Can't we just have \tupelet and then a qualifier (or whatever it is
called) that then determines if it is 3/2. 2/3, 6/4 etc.
I may be the only one but no one that I play with makes any
distinction from a musical point of view between a 'tupelet' that is
2/3 and one that is, say, 5/3 or 6/4.
A tuplet with 2/3 and one with 4/6 have a different inherent meter (i.e.
a different accentuation), even though it's notes have the same length
(just like \time 3/4 and \time 6/8 have a completely different
accentuation).
They are all 'tupelets.
http://en.wikipedia.org/wiki/Tuplet
In German, they are
2/3: Triole
3/2: Duole
4/5: Quintole
4/6: Sextole
etc.
So in German, each of them has its own name, which would coincide with
the music function's name...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
On 2012-09-26 15:32, d...@gnu.org wrote: Reinhold Kainhofer writes: On 26/09/2012 11:26, d...@gnu.org wrote: \once does something entirely different. It does not turn an override into a tweak but rather marks it at being active only at the current timestep. \once applies at a single time, \single applies on a single item. To me as a user, \once\override is used to change the next note (or items attached to it) and \single\tweak is used to change the next item. Both are only roughly equivalent when there is only one item per timestep. \once\override affects _everything_ happening at the same time. Ah, thanks for the explanation. I didn't understand that \single is meant to fix the case where \once applies to multiple items at the same timestep! Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events "z" "y"
On 26/09/2012 14:34, David Kastrup wrote:
> David Kastrup writes:
>
>> Werner LEMBERG writes:
>>
>>>>> It would be tremendously helpful if you can show possible syntax
>>>>> *alternatives* instead of just pretending to be a naysayer.
>>>> I've posted actual working definitions for that purpose.
>>> It seems I've missed that, lost in the many examples you've given to
>>> demonstrate what doesn't work.
>>>> They would definitely simplify the kind of entry you are asking for.
>>> Please repeat.
>> Sigh.
>>
>> at =
>> #(define-music-function (parser location time event music)
>> (ly:duration? ly:music? ly:music?)
>> "Place @var{event} at a relative duration @var{time} in relation
>> to @var{music}."
>> #{ << { \skip $time <>$event } $music >> #})
>>
>> {
>> \at 4 \<
>> \at 1*2/3 \!
>> c'1\p
>> }
> [12 days later, and no followup again]
>
> Let's just continue pretending me to be a naysayer then.
You demonstrated that a solution is possible, but quite inconsistent with
the lilypond language: You have to write the dynamic BEFORE the note,
although it should be printed AFTER the note...
In your example, what you want is note with "p", hairpin start, hairpin
end. But what you have to write is hairpin start, hairpin end, note with
"p".
So, yes, such hacks as workarounds are certainly possible, but IMO they
currently don't really fit well with the general concepts of the lilypond
language (i.e. all dynamics are written using postfix notation)...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
On 26/09/2012 11:26, d...@gnu.org wrote: > \once does something entirely different. It does not turn an override > into a tweak but rather marks it at being active only at the current > timestep. \once applies at a single time, \single applies on a single > item. To me as a user, \once\override is used to change the next note (or items attached to it) and \single\tweak is used to change the next item. That \once\override applies to the next timestep, and the following note incidentally happens at that timestep is an internal detail when I'm writing a score. >From a developer's POV there is a different concept involved, but I doubt that a normal user really cares about this. To me it's basically the same as the \set / \override distinction. It might be a different concept to anyone who knows the internals, but to a user both are used to change the default. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
is there any particular reason why you created a new command (\single) and didn't reuse \once. IMO, using \once as an indicator that the next command applies only to the next item would make it more consistent. http://codereview.appspot.com/6495135/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] turn xxx.yyy into ("xxx" "yyy")
On 2012-09-12 10:38, David Kastrup wrote:
if we write xxx in LilyPond, this is considered to be a string. I want
xxx.yyy.zzz to be a list of strings ("xxx" "yyy" "zzz"). The main
incentive is to be able to have music functions be able to accept both
Stem as well as Staff.TimeSignature as a function argument.
How would this work with lyrics or with markups?
\version "2.17.0"
\markup \line { This is some text. And another sentence. }
\relative c'' <<
\new Voice = "a" { c1 c1 }
\new Lyrics \lyricsto "a" { text. text. }
>>
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: irc and hangouts
On 2012-09-09 16:50, Graham Percival wrote: Janek and I had a brief chat on Tuesday night on the irc channel. Yesterday, we had a voice chat with google hangout about various recent happenings on -devel. I think that both options can be very helpful for understanding each other better. Is anybody else interested in chatting, with either text or voice? I'm not available next Tuesday at 20:00 UTC, but we can easily pick a different time. Or, if other people are available, they could have a chat without me. The previous "scheduled chat" only had 2 participants from -devel (plus two people already in the irc channel), so it's certainly worth rescheduling the time if we could get 3 participants. I have my IRC app running on my office machine 24/7, so I can always read up what was discussed if I missed any discussion. Scheduled chats in the (early) evening are a problem with me, because I have rehearsals with the Arnold Schoenberg Choir (a professional choir in Vienna, see http://en.wikipedia.org/wiki/Arnold_Schoenberg_Chor ) basically every night, and I also have several performances at the Vienna Volksoper. If someone wants to chat with me, it's best to ping me in the irc channel, and I'll try to respond when I notice it. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
On 2012-09-08 08:11, Werner LEMBERG wrote: 1. reject any offers of help from contributors who do not follow the existing formatting. 2. educate each contributor individually, go through multiple rounds of each patch to adjust the formatting, etc. 3. use an automatic formatting tool. 4. combine 2 and 3: use an automatic formatting tool for most of the code style, but still require some additional manual formatting (and go through a few rounds of reviews if necessary). I favor either 3 or 4; we are not in a position to be gratuitously rejecting patches, and having "finicky" manual formatting will discourage some contributors. I fully agree. Since we have no support for (3) yet, I will do a bit of (2), and I really hope that Phil can bear with me :-) Is it really such a big deal if the code formatting is not perfectly consistent in every little detail? In particular, I would favor option 5. (relax 2 a bit) educate each contributor individually when giving feedback about the patch. Don't insist on a new patch for formatting alone, but tell the submitter that (s)he should (i.e. following the RFC terminology strongly recommended, but not absolutely required) fix the indentation before applying. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
On 06/09/2012 10:05, David Kastrup wrote:
> Janek Warchoł writes:
>> That's more like it, but i'm not totally sure.
>> What i think of is a general way of attaching objects to another
>> objects. For example '&' would attach objects:
>> \arpeggio&\< meaning a hairpin attached to arpeggio
>> g\fermata&\markup \italic {10 seconds} meaning a "10 seconds" markup
>> attached to the fermata.
> You are thinking in ways of PDF. LilyPond is meant for expressing
> music. If we build in syntax like that, it should carry musical
> meaning, not just create pretty images. How do you "attach" things like
> that to MIDI or MusicXML?
That argument also holds for \markup, yet we have the \markup command as
an integral part of lilypond. Just because one concept does not have any
correspondence e.g. in MIDI, this doesn't mean that we should not
provide a way to use it in output formats where it makes sense...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
On 2012-09-03 22:43, Werner LEMBERG wrote: From a user's point of view who has to write a lot of piano music, `q' is *really* valuable. In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi. Nobody says that you should not be able to make use of shortcuts, but that does not mean that the LilyPond language is the right place for providing them. No, no, and again no! I want *readable* lilypond input. Compare this: 8\f \p \f \p | with this: 8\f q q q\p q \f \p q | In the first version, have you immediately seen the note change from `c' to `b' in the fifth chord? Only in the second version it's clear that it is not a typo. Chord repetition is a *central* part of piano music (and not only there). It really deserves a proper syntax, and I'm glad that we have it now. I can completely second this as a music publisher. I made an edition of Schubert's Nachthelle, where the right hand consists entirely of (mostly repeated, but also often slightly changed) 16th chords. From this experience, I really would not want to miss q as part of the lilypond syntax. The existence of q not only made writing much easier (which could admittedly also be achieved by editor shortcuts), but the main advantage was that it made proofreading and later editing MUCH easier. For one, as Werner already noticed, it is immediately obvious where a chord changes. And the other reason is that the repeated chords written out fully hide the rhythm, while with the 'q' notation you can see the rhythm as easily as with single notes. I had that experience with another score. q is one of those features that make LilyPond unfeasible as a storage format for music. What makes lilypond unfeasiable as a storage format is that its internals change so often. In particular, we currently have the viewpoint that changes to \overrides are internals, so we don't have to care about compatibility. In other words: We care only about trivial scores, where absolutely no overrides are required. In reality, however, I have not encountered a single score without any overrides for layout purposes. Since we don't guarantee anything about \override, one can never be sure that a huge score you are writing today will still work in a few months. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
On 2012-08-24 02:25, Han-Wen Nienhuys wrote: Hey Jan, could you put the following agenda item up for discussion? Change font license from GPL to dual licensed OFL / GPL (see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL_web) I'm fine with any relicensing of my lilypond contributions. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 2732: Extract the full page geometry in lilypond-book (issue 6454139)
Reviewers: dak,
http://codereview.appspot.com/6454139/diff/1/python/book_latex.py
File python/book_latex.py (right):
http://codereview.appspot.com/6454139/diff/1/python/book_latex.py#newcode262
python/book_latex.py:262: textwidth = (textwidth + columnsep) / columns
- columnsep
On 2012/08/12 13:24:37, dak wrote:
Why not use the value of \columnwidth in the first place here?
Good idea, I wasn't aware that this length existed. You are right, this
is much better.
Note that this
does not help with full-width figures:
\begin{figure*}
...
\end{figure*}
For those you'll have to specify an explicit line-width parameter to the
snippet anyway.
http://codereview.appspot.com/6454139/diff/1/python/book_snippets.py
File python/book_snippets.py (right):
http://codereview.appspot.com/6454139/diff/1/python/book_snippets.py#newcode128
python/book_snippets.py:128: MARGIN_LEFT: r'''left-margin =
%(left-margin)s''',
On 2012/08/12 13:24:37, dak wrote:
I have a hard time imagining the margins to make any sense since TeX
applies
them to the included material anyway.
Neither do I. I just figured it might not be wrong if the lilypond
snippet uses the exact same position on the paper as the latex document
(i.e. don't center the line-width on the paper, but use the latex
left-/right margins). But then, I can't think of a situation where
lilypond would give a different cropped result for different margins,
but same line-width...
The top-/bottom-margins might have an influence for vertical
stretching/compressing of multi-staff systems in a snippet. If the latex
margins are quite large, without top-/bottom margins lilypond would
create a snippet image that is too high for the latex textheight.
However, I don't think that these margin settings should be documented.
They are not meant to be used as snippet options manually, only for the
auto-extracted page geometry.
Description:
Fix 2732: Extract the full page geometry in lilypond-book
So far, lilypond-book tried to extract the line-width from the latex
settings,
but not the full page geometry (height, width, margins). Instead, it
simply used
the extracted line-with with the default paper size.
If the latex paper size is larger than the lilypond default paper size,
then the
line-width will be larger than the page. Lilypond detects this and
ignores the
wrong line-width.
The proper solution is to extract the full page geometry from the latex
document
and use that for the lilypond snippet, too (unless an explicit papersize
or
line-width was given, of course...)
As a side-effect, we now have some more snippet options:
-) paper-width
-) left-margin
-) paper-height
-) top-margin
-) bottom-margin
The latter options only have an effect on vertical stretching of
multi-staff groups.
This patch also fixes a small mis-calculation of the text-width for
multi-column
texts (the columnsep was subtracted only once rather than once per
separation...)
Please review this at http://codereview.appspot.com/6454139/
Affected files:
A input/regression/lilypond-book/tex-papersize-detection.lytex
M python/book_base.py
M python/book_latex.py
M python/book_snippets.py
M python/book_texinfo.py
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Interoperability with pdf viewers
On 2012-08-23 11:56, Colin Hall wrote: I presume that our GNU project membership dictates what pdf viewers we can recommend. Not really. Any free software (I hate that term, it sounds so much like Freeware, which has a VERY negative connotation to me) pdf viewer is acceptable. http://blog.kowalczyk.info/software/sumatrapdf/ http://projects.gnome.org/evince/ So would the correct policy be to recommend Evince and SumatraPDF, and perhaps work out interop problems with them? I'm using Okular, which is KDE's pdf viewer, and I have never had any problems with lilypond scores... http://okular.kde.org/ Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes popen3 deprecated warning (issue 6471043)
IIRC, the problem was not the Popen wouldn't be working on Windows. Rather, our GUB installer somehow does not include the msvcrt python module in its python build, which is needed on Windows to provide the Popen call. So, running lilypond-book fromself-compiled binaries has always been working, only the downloads from lilypond.org didn't... http://codereview.appspot.com/6471043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Time to fork a guile-2 branch?
On 13/08/2012 15:54, David Kastrup wrote: > Reinhold Kainhofer writes: >> I haven't checked, > That's the rub. See below... > This only works for existing branches/tags. Otherwise, git will not > know how to disambiguate the reference. It seems to work here: reinhold@curie:~/lilypond/lilypond$ git checkout -b dev/kainhofer-test Switched to a new branch 'dev/kainhofer-test' reinhold@curie:~/lilypond/lilypond$ git push origin dev/kainhofer-test Total 0 (delta 0), reused 0 (delta 0) To git+ssh://kainho...@git.savannah.gnu.org/srv/git/lilypond * [new branch] dev/kainhofer-test -> dev/kainhofer-test Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Time to fork a guile-2 branch?
On 2012-08-13 02:44, Ian Hulin wrote: Given that these patches will be quite extensive, is now a good time to set up a guile-2 branch in git, forking off from the start of the V2.17.0 development? Setting up a dev/guile-2 branch on our git server is a good idea any time you want your changes to be tested by others... You can also rebase your branch later on to the latest master at any time. Git is a distributed system, which means you can simply upload your local branch (you are working in a temporary development branch, right?) to the server, no need for an admin to create a branch. If you look at the repository with a view like qgit, you'll see that there are currently 19 dev/* branches on the server, which are temporary development branches from some developer (janek has 6 at the moment) Branches in git are very simple and very useful. E.g. I have 12 local development branches for various bugfixes (most are only unsuccessfull attempts) on my laptop and 8 devel branches on my office machine. I regularly pull branches off the other machine, just like I would do from the server ( If the answer is yes, I may need some hand-holding/support to make sure I don't do any damage to the main git repository. Mike already told you the commands: > To fork a branch, assuming that your git branch is called "guile-2" > and forked off current master, you can do: > > git checkout guile-2 > git push origin HEAD:refs/heads/dev/guile-2 > > This will create a remote branch called guile-2 w/o touching master > or staging. I haven't checked, but I think the push command could also simply be: git push origin dev/guile-2 (i.e. simply push the currently checked out branch to the server(=origin) as branch dev/guile-2) Also, don't worry about messing up: The server repository is nothing special, every developer has a full copy (from the time he last pulled/fetched) on his harddrive. If you mess something up, any developer can push his repo to the server again and nothing is lost. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow all papersizes to be specified with a trailing "papersize" or "landscape" string. (issue 6461071)
Not tested, either, but LGTM from reading the patch. http://codereview.appspot.com/6461071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: landscape mode in lilypond-book doesn't calculate line length correctly
On 2012-08-11 21:57, David Kastrup wrote:
Laura Conrad writes:
"Laura" == Laura Conrad writes:
Laura> When run on the attached file, lilypond-book sets the line
Laura> length of the music to be much less than the actual width of
Laura> the page that latex is using (which you can see by where it
Laura> puts the footers.)
I think I have a clue as to the source of this problem. I did
some investigation, since this is a blocking bug for a project with a
tight deadline in early September.
I looked at the lilypond-book python code, and it does indeed seem to be
setting the width wider for a landscape page than for a portrait page.
However, at some point when lilypond-book is running lilypond, I get the
following warning:
warning: systems run off the page due to improper paper settings,
setting default values
It looks like whatever code writes this warning thinks that no page
should ever be more than about 9 inches wide. This might be good enough
for my purposes, although I was thinking about using smaller than 1 inch
margins, and certainly there are some purposes for which you would
definitely want minimal margins.
So can someone who understands where that message comes from check
whether there's some inappropriate hard coding of the maximum width of a
page which is too small for a letter paper in landscape?
No such luck, it is in LilyPond itself that you have
if (to_boolean (c_variable ("check-consistency")))
{
// Consistency checks. If values don't match, set defaults.
if (abs (paper_width - line_width - left_margin - right_margin) > 1e-6)
{
line_width = line_width_default;
left_margin = left_margin_default;
right_margin = right_margin_default;
warning (_ ("margins do not fit with line-width, setting default
values"));
}
else if ((left_margin < 0) || (right_margin < 0))
{
line_width = line_width_default;
left_margin = left_margin_default;
right_margin = right_margin_default;
warning (_ ("systems run off the page due to improper paper settings,
setting default values"));
}
}
Have you tried setting the paper type in your lilypond-book snippets?
LilyPond-book only siphons off
# Retrieve dimensions from LaTeX
LATEX_INSPECTION_DOCUMENT = r'''
\nonstopmode
%(preamble)s
\begin{document}
\typeout{textwidth=\the\textwidth}
\typeout{columnsep=\the\columnsep}
\makeatletter\if@twocolumn\typeout{columns=2}\fi\makeatother
\end{document}
so it does not bother getting/setting paper info.
Ah, good point. It actually took me a while to see what you mean: This
snippet correctly extracts the actual line width for the snippet, but
the snippet uses the default lilypond paper size rather than the paper
size implied by the latex document... Nice Catch!
When I worked on these parts of lilypond-book, I tested with various
page settings, but apparently forgot to check with larger page sizes
than A4 portrait...
The apparent solution is to also print out the paper page width/height
and all the margins (to avoid e.g. too much vertical stretching of staff
groups)...
I'll try to come up with a patch.
Cheers,
Reinhold
Fragments may use the
`papersize=STRING'
Where STRING is a paper size defined in `scm/paper.scm' i.e.
`a5', `quarto', `11x17' etc.
Values not defined in `scm/paper.scm' will be ignored, a warning
will be posted and the snippet will be printed using the default
`a4' size.
option. Embarrassingly, there is no way to get a4 landscape in
LilyPond-book right now, but a3 should do the trick I guess, at some
loss of performance.
Inside of LilyPond, #(set-default-paper-size "a4" 'landscape) would
work.
Hmm, to make life for .ly file generators easier, maybe it would be a
good idea to additionally define paper sizes a4landscape and the like...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 01/08/2012 00:29, Joseph Rushton Wakeling wrote:
> You get a similar error with the following:
>
> \compoundMeter #'((4 2/3 4))
>
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
>
> That is,
>
> Parsing...ERROR: In procedure ly:make-moment:
> ERROR: Wrong type argument in position 1 (expecting integer): 14/3
>
> ... which can again be avoided by using the equivalent time signature
> of 7/6.
>
> This is probably actually quite easy to fix, but _as things stand_ it
> seems to me that compound time signatures probably need some careful
> consideration with respect to the styles and use-cases out there.
>
> Based on the above it's _probably_ just an internals issue and not a
> syntax problem (I can make bug reports accordingly), but it's another
> contemporary music issue to throw into the mix regarding syntax.
When I implemented \compoundMeter, I only had the classical meters in
mind (i.e. denominators are powers of 2, all enumerators are (possibly
sums of) integers, and there are no double fractions).
I haven't looked at the code, but I don't see a reason why it wouldn't
be possible to extend that to non-power-of-2 denominators.
Double fractions and real numbers in the enumerator pose more problems,
because in these cases I have no idea how to determine the beat
structure... (e.g. in #'(1 4 3 8), eights are automatically beamed as c8
c[ c c c] c[ c c]. How would you beam #'(3.2 8)? )
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy's built docs on the web
On 31/07/2012 17:18, John Mandereau wrote: > When lilypond-patchy-staging.py a.k.a. Patchy succesfully builds on MSH > Paris Nord server, it now puts the docs on > > http://194.254.171.80/lilypond-web/master/ > > This is intended for use by all developers and contributors; I'm not > sure whether it duplicates docs on kainhofer.com/~lilypond/, it depends > on how Reinhold builds them. I let a cronjob build origin/master from scratch every night at 01:30 am CEST (UTC+2) and upload the docs to my server. The main difference to all the other documentation copies on various servers is that I enable the AJAX quick search box in the manuals (which basically just greps through the index and displays the hits from the index). To be honest, I couldn't work with the docs any more without that search box. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: abc2ly Patch
Arne has sent me a patch for abc2ly, which improves e.g. the handling of
chords (previously converted as annotation, now as chordmode)...
I haven't looked at or tested this patch.
Cheers,
Reinhold
Original Message
Subject: abc2ly Patch
Date: Thu, 09 Aug 2012 16:47:52 +0200
From: Arne Rempke
To: Reinhold Kainhofer
Hallo,
ich schlage mich grade mit der Konvertierung von abc-Daten nach lilypond
herum und habe dazu das Skript abc2ly von lilypond etwas erweitert.
Wesentlichste Änderung dürfte die Behandlung von Akkorden sein, die nun
als \chordmode und nicht mehr als hochgestellte Anmerkung verarbeitet
werden. Außerdem wird die Taktzählung wieder lilypond überlassen und
Auftakte versucht zu erkennen. Tatsächlich sind auch ein paar Änderungen
drin, die zumindest diskussionwürdig sind (z.B. Silbenmatching
Lyrics/Melodie bei Slur/Tie-Konstruktionen), aber die bei meinen Daten
so die besseren Ergebnisse erzielt haben.
Ich dachte mir, bevor die Änderungen nur auf meiner Platte verkümmern
versuch ich sie doch noch zu teilen -- hab aber zugegeben grad nicht den
Nerv mich mit dem Repository/Ticketsystem zu beschäftigen und schick
daher einfach mal nen Patch an einen mir geeignet erscheinenden
Entwickler. Evtl. kann man das (oder Teile) ja verwenden, ansonsten bin
ich da auch nicht bös drum. Der Patch ist gegen das Skript einer
Lilypond 2.14.2-Installation erstellt worden.
Danke und viele Grüße aus dem Harz,
Arne
--- /usr/bin/abc2ly 2011-10-22 15:48:20.0 +0200
+++ abc2ly2 2012-08-09 15:50:38.138219097 +0200
@@ -91,6 +91,8 @@
import sys
import re
import os
+from fractions import Fraction
+import math
program_name = sys.argv[0]
@@ -132,11 +134,15 @@
header['footnotes'] = ''
lyrics = []
slyrics = []
+slyrics_num_syl = []
voices = []
+chords = ['']
state_list = []
repeat_state = [0] * 8
current_voice_idx = -1
current_lyric_idx = -1
+chord_length = 0
+chord_name = ''
lyric_idx = -1
part_names = 0
default_len = 8
@@ -148,7 +154,6 @@
HSPACE=' \t'
midi_specs = ''
-
def error (msg):
sys.stderr.write (msg)
if global_options.strict:
@@ -205,6 +210,7 @@
state_list.append(Parser_state())
voices.append ('')
slyrics.append ([])
+slyrics_num_syl.append([])
voice_idx_dict[name] = len (voices) -1
__main__.current_voice_idx = voice_idx_dict[name]
__main__.state = state_list[current_voice_idx]
@@ -241,18 +247,18 @@
def dump_lyrics (outf):
if (len(lyrics)):
-outf.write("\n\\score\n{\n \\lyrics\n <<\n")
+outf.write("\n\\markup { \\column {\n")
for i in range (len (lyrics)):
-outf.write ( lyrics [i])
-outf.write ("\n")
-outf.write(">>\n\\layout{}\n}\n")
+l = re.sub('^[ \t]*\}\}', '', lyrics [i])
+outf.write ( l + "}}\n")
+outf.write ( "} }\n")
def dump_default_bar (outf):
"""
Nowadays abc2ly outputs explicits barlines (?)
"""
## < 2.2
-outf.write ("\n\\set Score.defaultBarType = \"empty\"\n")
+#outf.write ("\n\\set Score.defaultBarType = \"empty\"\n")
def dump_slyrics (outf):
@@ -280,9 +286,11 @@
m = k
outf.write ("\nvoice%s = {" % m)
dump_default_bar(outf)
+if state_list[voice_idx_dict[k]].partial:
+outf.write("\n \\partial %s" % state_list[voice_idx_dict[k]].partial)
if repeat_state[voice_idx_dict[k]]:
outf.write("\n\\repeat volta 2 {")
-outf.write ("\n" + voices [voice_idx_dict[k]])
+outf.write (voices [voice_idx_dict[k]])
if not using_old:
if doing_alternative[voice_idx_dict[k]]:
outf.write("}")
@@ -290,6 +298,14 @@
outf.write("}")
outf.write ("\n}")
+def dump_chords (outf):
+chord_flush()
+if (len(chords[0])):
+outf.write ("\nharmonies = \\chordmode {")
+outf.write ("\n" + chords[0])
+outf.write ("\n}")
+
+
def try_parse_q(a):
#assume that Q takes the form "Q:'opt. description' 1/4=120"
#There are other possibilities, but they are deprecated
@@ -314,6 +330,7 @@
ks = voice_idx_dict.keys ();
ks.sort ()
+outf.write ("\n\t\\context ChordNames\n\t{\n\t\t\\set chordChanges = ##t\n\t\t\\germanChords \\harmonies\n\t}\n" )
for k in ks:
if re.match('[1-9]', k):
m = alphabet (int (k))
@@ -596,6 +613,8 @@
if not stuff:
stuff.append (a)
else:
+if (a == '\n' and stuff[idx] and stuff[idx][-2] == a):
+return
Re: Properly implement fromproperty markup handing in the pdftitle header field (issue 6447052)
On 2012-08-06 00:44, d...@gnu.org wrote: http://codereview.appspot.com/6447052/diff/4001/scm/markup.scm File scm/markup.scm (right): http://codereview.appspot.com/6447052/diff/4001/scm/markup.scm#newcode109 scm/markup.scm:109: (define (markup-cons->string-cons c props) "props" seems like a total misnomer: that is usually used for a list of alists, while it here is a list of modules/scopes. Do you have any better suggestion? Thanks, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1650: merge multiple header specifications. (issue 6445053)
LGTM, seems to work correctly on all my (reg)tests. I actually like David's idea of changing the header field values to include correctness information. Still I like comments inside sample code to make the reasons for a particular block clearer. http://codereview.appspot.com/6445053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Using MSH Paris Nord server
On 30/07/2012 16:21, Graham Percival wrote: > oh, logins just occurred to me. Can gerrit let people log in with > their google accounts (IIRC there's an api for that), or would we > all need to make new accounts on the gerrit server? IIRC, gerrit works with any openID service... A while ago I set up gerrit on my server to evaluate it (I even posted it here), but I have meanwhile removed the installation again, as it seemed no one was really interested. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
On 28/07/2012 07:32, David Kastrup wrote: > Reinhold Kainhofer writes: > >> The text spanner implemented in scheme (which is also used as a basis >> for David's measure counter engraver) seems to work fine in the regtest, >> but apparently it is not quote-proof. >> >> In particular, if you try call \addQuote on some music that contains >> \schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the >> following warnings and the text spanner is not quoted: > Well, scheme-text-spanner changes the \Global context, and quote > environments uses the layout definition partCombineListener in > ly/declarations-init.ly with an unchanged Global context. > > Change its Global context similarly, and you should be set. How can a user, who wants to use e.g. the measure counter engraver, change the partCombineListener' s Global context without messing with the original lilypond sources? Am I missing something? The whole point of scheme engravers and scheme text spanners is that users can now also implement things in scheme without messing with the lilypond sources... If I understand you right, then the user cannot add new grobs in an include file without messing with the lilypond sources. Would a proper solution be to change the partCombineListener to a context mod and construct the real listener when we need it (i.e. replace the current (ly:parser-lookup parser 'partCombineListener) by the actual creation of the listener from the context in effect when add-quotable or recording-group-emulate is called? However, I don't really have enough knowledge about how to create the actual listener in scheme and insert a given context mod in scheme... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1650: Multiple header blocks shall be merged rather than replace a previous one (issue 6441058)
Reviewers: dak,
Message:
On 2012/07/27 05:10:50, dak wrote:
> I think this is the wrong way to do things since you can't refer to
old header
> values when defining the new one. Instead, you should start with
the
definition
> you are adding things to, like LAYOUT and similar do. So that
likely means
that
> you need to change the definition of lilypond_header (or create
several
versions
> of it) to make it not start from an empty slate.
Actually, it looks like it just doing that: taking the old value and
adding to
it.
Apparently, it doesn't do it properly:
\book {
\header { title = "Title" }
\header { composer = "Composer" }
\score { \new Staff { c'4 } }
}
or
\version "2.15.42"
\score {
\new Staff { c'4 }
\header { piece = "Piece" opus = "Opus" }
% This should NOT clear the piece from above:
\header { opus = "New Opus" }
}
In both cases the assignments of the first header block are lost,
because when parsing the second header block, it starts from an empty
block and replaces the whole header block rather than adding to the
existing assignments...
The hierarchy works correctly (i.e. top-level header blocks are used as
base for book-level blocks, which are used as base for bookpart-level
blocks, which are used as base for score-level blocks), mainly because
in score.cc and book.cc the parent's header block is copied when
inserting a book or score into its parent.
Description:
Issue 1650: Multiple header blocks shall be merged rather than replace a
previous one
If there are two or more header blocks at top-, book-, bookpart- or
score-level,
the settings of all header blocks are merged. If a value appears in
multiple
blocks, the last assigment wins.
Please review this at http://codereview.appspot.com/6441058/
Affected files:
A input/regression/header-book-multiple.ly
A input/regression/header-book-multiplescores.ly
A input/regression/header-bookpart-multiple.ly
A input/regression/header-score-multiple.ly
A input/regression/header-toplevel-multiple.ly
M lily/parser.yy
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
The text spanner implemented in scheme (which is also used as a basis
for David's measure counter engraver) seems to work fine in the regtest,
but apparently it is not quote-proof.
In particular, if you try call \addQuote on some music that contains
\schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the
following warnings and the text spanner is not quoted:
scheme-text-spanner.ly:210:5: warning: Event class should be a list
a4
b\schemeTextSpannerStart c d |
scheme-text-spanner.ly:212:7: warning: Event class should be a list
a4 b
c\schemeTextSpannerEnd d |
So apparently the scheme way to add new event classes is not entirely
correct...
Sample file (regtest adapted to quote the music) is attached.
Any idea about the correct fix to this?
Thanks,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version "2.15.31"
\header {
texidoc = "Use @code{define-event-class}, scheme engraver methods,
and grob creation methods to create a fully functional text spanner
in scheme."
}
#(define my-grob-descriptions '())
#(define my-event-classes (ly:make-context-mod))
defineEventClass =
#(define-void-function (parser location class parent)
(symbol? symbol?)
(ly:add-context-mod
my-event-classes
`(apply
,(lambda (context class parent)
(ly:context-set-property!
context
'EventClasses
(event-class-cons
class
parent
(ly:context-property context 'EventClasses '()
,class ,parent)))
\defineEventClass #'scheme-text-span-event #'span-event
#(define (add-grob-definition grob-name grob-entry)
(let* ((meta-entry (assoc-get 'meta grob-entry))
(class(assoc-get 'class meta-entry))
(ifaces-entry (assoc-get 'interfaces meta-entry)))
(set-object-property! grob-name 'translation-type? list?)
(set-object-property! grob-name 'is-grob? #t)
(set! ifaces-entry (append (case class
((Item) '(item-interface))
((Spanner) '(spanner-interface))
((Paper_column) '((item-interface
paper-column-interface)))
((System) '((system-interface
spanner-interface)))
(else '(unknown-interface)))
ifaces-entry))
(set! ifaces-entry (uniq-list (sort ifaces-entry symbol>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On 2012-06-20 05:51, Graham Percival wrote: > "do not recommend any non-Free programs" > > We have a list of non-free ones on the easier editing page - e.g. > Noteworthy and my converter. However, it seems daft to me to remove > these. I would think for the long list we could disclaim with > "we're not recommending these, but noting that they exist". Thanks, that seems reasonable. Actually, to me there is a big difference between "recommending" a program for use and listing alternatives that are compatible (which is the case for the applications in question). I actually don't like the phrasing, because I understand "we're not recommending these" as a nice formulation of "We strongly discourage you from using these". Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6294047)
The partcombiner does not really bother about keeping the number of generated start and end slur events matched, so this attempts to cope by implementing the following behavior: a) multiple slur starts on the same moment are not an error but the same as one. I actually did NOT implement it like this on purpose: If you start a slur and a phrasing slur and forget the backslash in the phrasing slur start (which happened to me quite frequently!), you'll have to manually find out where the phrasing slur should start (which is typically several lines before), while on the other hand two concurrent slurs are not supported, anyway. So to me it seemed reasonable to warn the user about the double slur start, which typically indicates a missing backslash for a phrasing slur. http://codereview.appspot.com/6294047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LoMuS
On 27/04/2012 07:09, m...@apollinemike.com wrote: > Hey all, > > I've received a couple e-mails from colleagues and one nudge from > Valentin about: > > http://concours.afim-asso.org/ > > I've been reticent about applying because the development community is > rather diffuse and there isn't any good way to accept the prize money > if we win. However, after having received now two e-mails from people > who I respect a lot in the French computer music community, I think > it'd be a good idea and that we should let institutional barriers stop > us from applying. I strongly support applying. > 1) Use it internally on projects (i.e. we'd all agree that person X > would get paid Z euros to do thing Y) in which case there'd have to be > a money shepherd. I'd rather not do this, but I can if no one else > wants to. YES! I would suggest that if you do all the application bureaucracy, then you should also be the one to distribute the possible prize money. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly
On 2012-04-08 20:15, pls wrote: yes, we are currently working on the musicxml2ly scripts and we have solved e.g. the issue concerning the chord symbols you mentioned. I haven't had time to work on the patch James pointed to but it works as it is. We use it on www.philomelos.net <http://www.philomelos.net>. Philomelos is a new community site for free and editable sheet music. The private beta version includes the ability to read and share MusicXML files that are displayed online using LilyPond technology. If someone wants to be invited: drop me a line offlist. We will share all improvements on musicxml2ly but we could also need some help! We are planning to add a blog/wiki to our website so that philomelos can be used to test MusicXML files and to share music sheets and knowledge concerning MusicXML, conversions between musical notation codes... I was the last one to extensively work on musicxml2ly, so if you have any questions, drop me a mail. I must add, though, that I have beeen really busy the last few weeks and I'm not sure if this will change in the near future, so expect some days of response time. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new lilypond-auto mailing list
On 2012-03-20 00:28, Graham Percival wrote: On Tue, Mar 20, 2012 at 12:11:46AM +0100, David Kastrup wrote: So instead of surprising volunteers by giving them more information than expected we give them less information than expected? Bug squad members shouldn't be reading tracker messages anyway. It's not about bug squad, but about all developers. The comment of the lilypond users to the bug reports are *extremely* important for development. On the other hand, all those hundreds of automated comments to the bug reports are totally unnecessary. To me the main problem is that we have so many automated comments to a bug report that the bug-lilypond list is swamped with those notifications and the relevant human responses are hard to detect (I now typically ignore all bug mails, since it simply takes to long to find out which of the ~50-70 mails per day are automated and which are relevant). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sets lilypond-id message to type progress (issue 5848056)
LGTM http://codereview.appspot.com/5848056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: My own Figured Bass number set, where do I start?
On 20/02/2012 14:44, Reinhold Kainhofer wrote:
> On 20/02/2012 14:18, Nils wrote:
>> my pusblisher wants baroque figured bass gylphs. They have the strokes in
>> different places than the Lilypond versions.
>> I guess nobobdy did this so far, so I have to do it myself.
> Yes, we have a feature request
> (http://code.google.com/p/lilypond/issues/detail?id=2042 ), but no one
> has done any work on it.
>
>> Where is the point in the code where I have to start? I want to do it right
>> and use the same lilypond syntax like 4\+ or 6\\.
> I suppose that the proper way would be to create new glyphs in our fonts
> (using metafont, source file mf/feta-numbers.mf) and then adjust the
> format-bass-figure function (in scm/translation-functions.scm) to use
> those glyphs for the slashed figures.
Despite my lack of metafont knowledge, I have started tweaking some of
the glyphs:
http://codereview.appspot.com/5683051
That patch simply takes the digits 2, 4 and 5 of the feta font,
stretches the one line that will be slashed, and adds a vertical box as
a slash through it. These glyphs are not yet used by the figured bass
formatting functions, but you can already use them via the musicglyph
markup function. Attached is a simple test file showing the glyphs.
Some issues:
-) I have no idea how to properly implement the 6+ (the upper arc should
have much less curvature and the slash is drawn through it. I would like
the flare to have less turning angle, but with beta != +-90 it is no
circle any more).
-) Currently I place the slashes at more or less hardcoded positions and
they are straight vertical. In particular for the 2 it might make sense
to calculate the real intersection of the slash with the lower wavy
line, so the slash is vertically centered. It might also be slanted to
be perpendicular to the line it slashes through. Similarly, I'm not sure
if the 5 should get a slightly slanted slash...
-) I have no idea whether I should adjust the height of the boxes to
include the slash.
-) etc.
It would be great if someone with more metafont knowledge could improve
those issues.
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
figured-bass-slashed-figures-test.preview.pdf
Description: Adobe PDF document
\version "2.15.31"
\header {
texidoc = "Examples of dedicated slashed bass figure glyphs."
}
\paper { ragged-right = ##t }
<<
\context Voice {
c'4 c' c' c'
}
\figures {
\bassFigureExtendersOn
<2\+ \markup { \fontsize #-2 \musicglyph #"twoplus" } 2 >
<4\+ \markup { \fontsize #-2 \musicglyph #"fourplus" } 4 >
<5\+ \markup { \fontsize #-2 \musicglyph #"fiveplus" } 5 >
% <6\+ 6\\ 6/ \markup { \fontsize #-2 \musicglyph #"sixplus" 6} >
}
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Fr., 17. Feb. 2012 08:47:19 CET, m...@apollinemike.com wrote: > Note that this whole "slow down" thing is much less relevant now that it > was before. My current benchmarks show a 0.2-2 second per minute > slowdown depending on the file. Most important: is the slow down linear in the score length, polynomial or exponential? I particular, is there any danger of making really huge sores impossible to run through lilypond? Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Allow multiple identical slurs (issue 1967). (issue 5671053)
LGTM http://codereview.appspot.com/5671053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
On 15/02/2012 15:30, David Kastrup wrote:
> Reinhold Kainhofer writes:
>
>> Actually, LilyPond's parser decides which chars are part of the scheme
>> expression and which are part of lilypond's syntax.
> No, it doesn't. It fires up the Scheme reader at the current position
> in the input, and picks up again wherever the Scheme reader leaves the
> input position.
Yes, but it's our parsers decision to give the scheme reader everything
it might want, even if that means chunking away from the lilypond code...
A scheme expression is embedded into lilypond syntax, so why can the
embedded expression decide where it ends, rather than the surrounding
LilyPond syntax?
This leads to situations like:
relative c'' {
{\override NoteHead #'X-offset = #(+ 1 2)} c % works
{\override NoteHead #'X-offset = #3} c % doesn't work
}
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: google summer of code
On 11/02/2012 14:00, Graham Percival wrote: > I believe that one of the major things that GSoC looks are is "how > good is the list of tasks suggested by that project". Yes, most applicants (who are not yet involved with a project) will simply look at the list and select one of the suggested projects. Students, who are already developers for a project, tend to have their own suggestions. At least that's my experience a while ago as a SoC mentor for KDE. > Except that the mentor needs to (IIRC) sign an agreement > specifying that they *will* continue to do that. And it needs to > be a single mentor. I can't remember any formal agreement. But anyway, Google was not that strict, and my students didn't need any help (I was co-mentoring with someone else, but I can't remember any time-consuming problems with the students) > It's sounding as though lilypond is a bad fit for GSoC, so perhaps > we should just drop it. Don't worry. The lilypond developer community consists of many brilliant heads, who can and probably will help out, if a mentor is tied up with something else. No one says that a student must only communicate with the mentor. My feeling was also that Google gave the project a loot of freedom to decide on the accepted projects, how to administer them and how to decide on the success of the students. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code - Ideas List, please discuss
On 12/02/2012 12:51, m...@apollinemike.com wrote: >> 2) Adding comprehensive MusicXML import and export features, together >> > with test suites for it. Requirements: ? (no idea in which language >> > this would be written), MusicXML, basic LilyPond and music notation >> > knowledge; familiarity with other scorewriters would be a nice bonus >> > (for cross-testing). The goal would be considered achieved when a >> > (previously chosen) not-so-complicated score could be imported from >> > MusicXML and exported back with no (unintentional) loss of data. >> > > I worked on this a little bit - it is totally possible and would likely weigh > in @ 500-1000 lines of Scheme. I'd recommend not worrying about placement > data and stopping at the engraver level. This is more or less the same thing > as a MIDI plus stuff like articulations, slurs, etc.. Placement data would > be doable but hard: it'd be better to just get the info from engravers first. It is much easier to export just the music contents (in scheme, just using the output of the iterators), but that solves only part of the problem. To be able to provide solutions for composers in the professional music publishing world, layout information is essential in the MusicXML export. Currently, if you are using LilyPond, you are locked in to LilyPond. If any composer writes a piece in lilypond, it's practically impossible to find a publisher. The publishers usually only accept finished (i.e. layout done!) Finale/Sibelius/SCORE files, and probably MusicXML. But if the LilyPond users sends them the MusicXML of the finished LilyPond file, the publisher will have just the raw data and needs to do all the layout themselves again (and proably reject the files)... So, just a basic MusicMXL export functionality is not able to fulfill all the needs of the users. To be able to compete in the professional market, LilyPond also needs to export the positioning (and MusicXML is moving more and more into that direction, now also including full audio support). MusicXML 1.0 was just about the musical contents, MusicXML 2.0 added mainly layout information, and MusicXML 3.0 adds lots of audio information. Also notice that many MusicXML viewer are not able to lay out the musical contents themselves, but depend on the positioning information in the MusicXML file. My suggestion would be to implement MusicXML export with the following steps: -) Handle basic musical content export like the MIDI export (i.e. using dedicated exporter classes, derived from the translator class) -) Build the XML tree of the basic musical content, add a connection from music event to XML tag -) Let all engravers do their jost -) add ability to link each output object (basically each stencil / group of stencils) to the music cause (and thus to the XML tag in the XML tree) -) Add a XML output backend, which can then add the layout information for each output object to the XML tags This would probably be the most generic and extensible solution (although it is definitely not the easiest road). Basic export could already be implemented using some translator-derived classes collecting all interesting events. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code - Ideas List, please discuss
On 12/02/2012 15:13, Graham Percival wrote:
> On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
>> 2) Adding comprehensive MusicXML import and export features, together
>> with test suites for it. Requirements: ? (no idea in which language
>> this would be written), MusicXML, basic LilyPond and music notation
>> knowledge; familiarity with other scorewriters would be a nice bonus
>> (for cross-testing). The goal would be considered achieved when a
>> (previously chosen) not-so-complicated score could be imported from
>> MusicXML and exported back with no (unintentional) loss of data.
> umm, you know that we already have musicxml2ly import, right?
>
> I agree with having this on the ideas list, but it should
> definitely mention musicxml2ly.py and basic familiarity with
> python. The export would most likely be in scheme, although it's
> not impossible to imagine that somebody might write a relatively
> simple scheme exporter to an intermediate format (or just use
> \displaymusic{} ), then use python to construct the actual
> musicxml file.
That's bound to fail. LilyPond has so much processing going on in the
engravers, that the MusicXML exporter would have to duplicate most of
that. To me it makes much more sense to build on the result of the
iterators and engravers, rather than having to duplicate most of them in
custom code.
Cheers,
Reinhold
--
------
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: GDP Docs compilation FAILED (2012.02.14-01:39)
On 14/02/2012 15:48, Julien Rioux wrote: > Reinhold Kainhofer kainhofer.com> writes: >>> Dissecting... >>> Converting MusicXML file `./out-www/suffix-lyxml.xml'... >>> >>> lilypond-book.py: error: `musicxml2ly --out=- - ' failed (0) >>> lilypond-book.py: error: The error log is as follows: >>> musicxml2ly: Reading MusicXML from Standard input ... > I've pushed a potential fix to staging. The cronjob successfully finished last night. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: GDP Docs compilation FAILED (2012.02.14-01:39)
On 14/02/2012 08:01, David Kastrup wrote: > Reinhold Kainhofer writes: > > [...] > > It is not clear where this mail hails from, which commands were used to > get this error under which circumstances. > Nightly cron job building lilypond and the documentation (http://kainhofer.com/~lilypond/ ) from scratch. Graham said some months ago, that I should forward those error mails to the mailing list rather than waiting for someone else to spot a problem building master. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code - Ideas List, please discuss
On 12/02/2012 15:43, Janek Warchoł wrote: > W dniu 12 lutego 2012 15:13 użytkownik Graham Percival > napisał: >> umm, you know that we already have musicxml2ly import, right? > Yes. I had some issues with it - dynamics got attached to wrong > notes. The problem is that in LilyPond, each dynamic is attached to a note, while in MusicXML it is attached to a staff and placed via x-offsets. It's mostly not so trivial to find the proper note to attach the dynamics to (and even if you do, you'll need to obtain a proper x-offset to override LilyPond's default placement). Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Summer of Code - Ideas List, please discuss
On 12/02/2012 12:03, Janek Warchoł wrote: > Hi all, > > SUMMARY: in order to participate in Google Summer of Code ($$$), we > need an Ideas List. > > (to learn more about GSoC, go here > http://www.google-melange.com/gsoc/homepage/google/gsoc2012) > > An Ideas List should be a list of suggested student projects. This > list is meant to introduce contributors to the project's needs and to > provide inspiration to would-be student applicants. > > For an example, go here: > http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_observation_planner_and_logging_feature > > Below are my suggestions for our Ideas List. Please comment on them > and give your suggested projects. > > > > General student prerequisites: (basic?) git knowledge > > 1) Fixing problems with synchronization of grace notes, together with > all underlying architecture (issue 34). Requirements: C++, MIDI; > familiarity with basic music notation recommended I think for this problem, a basic understanding of the lilypond code is really necessary. It goes straight into the timing code. Also, it's hard to judge the real effort required to solve it, so I don't think this is a very good candidate for a project. > 2) Adding comprehensive MusicXML import and export features, together > with test suites for it. Requirements: ? (no idea in which language > this would be written), MusicXML, basic LilyPond and music notation > knowledge; familiarity with other scorewriters would be a nice bonus > (for cross-testing). The goal would be considered achieved when a > (previously chosen) not-so-complicated score could be imported from > MusicXML and exported back with no (unintentional) loss of data. That is definitely a good project. It is self-contained, and there is not a success-or-fail outcome, but the possible outcomes vary from "basic support" to "full support" in a continuous range. > 5) Build System Improvement: if we want to ever move away from make, > this would be a good opportunity. Issues like thousands of errors and > warnings during compilation should be removed, all dependancies fixed > (so that one doesn't need to remove fonts folder to have fonts > rebuilt). Requirements: Python, Make and (optionally) another build > system. Janitor work sounds very boring to me for a summer job... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Thinking about putting together a grant to support development on LilyPond
On 09/02/2012 12:08, Han-Wen Nienhuys wrote: > I have tried getting grants from different EU and national bodies with > various partner institutions (including the one where Graham now > works, IIRC). My impression is that you need people (preferably many) > with lots of academic clout that can sign off on the proposal, since > LilyPond itself has little formal recognition. Also, for EU research > grants specifically, they were focused a lot on partnerships with and > things that helped small and medium enterprises, and we couldn't > invent a story around that. Just in case it helps proposals: I have a small music publishing company (http://www.edition-kainhofer.com/ ), and I exclusively use LilyPond, so you don't have to invent a story about that. > A) Development of ly2xml Reviewers would probably argue that this is not really scientific research and should be funded by an industry partner instead. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On 06/02/2012 18:50, m...@apollinemike.com wrote: >>> I'm fixing all of the regtest issues, but what I need most from other >>> people who have a few minutes are benchmarks. >> L'Isle joyeuse: >> [...] > Thanks! > In my opinion, these times are too high to justify the gain that one gets > from using fine-tuned vertical skylines. Agreed. > In the final version of the patch, I'll limit them to slurs, ties, > tuplet-brackets, volta repeats, and treble clefs. What about hairpins? They are one of the main problem areas in my scores (and they are even worse in a piano staff). Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
On 05/02/2012 08:30, David Kastrup wrote: > The variable is not } but 0.9} instead. Anything that can't be parsed > as a constant in Scheme is a variable. > > This has nothing to do with Lilypond: > > dak@lola:/usr/local/tmp/lilypond$ guile > guile> 0.9} > ERROR: Unbound variable: 0.9} > ABORT: (unbound-variable) > guile> dak@lola:/usr/local/tmp/lilypond$ > > > You could likely say > > #(define 0.9} 0.9) > > and have the above work except for the missing closing brace. There is > absolutely nothing that LilyPond could, or even _should_ be trying to > fix here. Scheme is Scheme and outside of LilyPond's responsibility > regarding syntax and semantics. Actually, LilyPond's parser decides which chars are part of the scheme expression and which are part of lilypond's syntax. The lilypond parser decides that the scheme expression includes the }, which from a user's POV doesn't make sense, as the } is LilyPond's delimiter and should thus definitely end the scheme expression (even though 0.9} would be a valid guile variable). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: GDP Docs compilation FAILED (2012.02.14-01:39)
- Ursprüngliche Mitteilung - Von: LilyPond Development Gesendet : Di., 14. Feb. 2012 01:39:05 CET An: reinh...@fam.tuwien.ac.at Betreff: GDP Docs compilation FAILED (2012.02.14-01:39) > Preprocessing graphical objects... > Calculating line breaks... > Drawing systems... > Writing header field `texidoc' to > `/home/lilypond/build/out/lybook-db/25/lily-87ced4d9.texidoc'... Writing > /home/lilypond/build/out/lybook-db/25/lily-87ced4d9-1.signature Layout output > to > `/home/lilypond/build/out/lybook-db/25/lily-87ced4d9.eps'... Converting to > `/home/lilypond/build/out/lybook-db/25/lily-87ced4d9.pdf'... Converting to > PNG... > Layout output to > `/home/lilypond/build/out/lybook-db/25/lily-87ced4d9-1.eps'... > Converting to `/home/lilypond/build/out/lybook-db/25/lily-87ced4d9-1.pdf'... > Writing /home/lilypond/build/out/lybook-db/25/lily-87ced4d9-systems.texi... > Writing /home/lilypond/build/out/lybook-db/25/lily-87ced4d9-systems.tex... > Writing /home/lilypond/build/out/lybook-db/25/lily-87ced4d9-systems.count... > Success: compilation successfully completed > Compiling > /home/lilypond/build/input/regression/lilypond-book/out-www/tex-musicxml-file.tex... > Writing > `/home/lilypond/build/input/regression/lilypond-book/out-www/tex-musicxml-file.tex'... > lilypond-book.py (GNU LilyPond) 2.15.30 LILYPOND_VERSION=2.15.30 > /usr/bin/python > /home/lilypond/lilypond/scripts/lilypond-book.py -I > /home/lilypond/lilypond/input/regression/lilypond-book/ -I ./out-www -I > /home/lilypond/lilypond/input -I /home/lilypond/lilypond/Documentation -I > /home/lilypond/lilypond/Documentation/snippets -I > /home/lilypond/lilypond/input/regression/ -I > /home/lilypond/lilypond/Documentation/included/ -I > /home/lilypond/build/mf/out/ > -I /home/lilypond/build/mf/out/ -I > /home/lilypond/lilypond/Documentation/pictures -I > /home/lilypond/build/Documentation/pictures/./out-www > --process='/home/lilypond/build/out/bin/lilypond -dbackend=eps > --formats=ps,png,pdf -djob-count=4 -dinclude-eps-fonts -dgs-load-fonts > --header=doctitle --header=doctitlecs --header=doctitlede --header=doctitlees > --header=doctitlefr --header=doctitlehu --header=doctitleit > --header=doctitleja > --header=doctitlenl --header=doctitlezh --header=texidoc --header=texidoccs > --header=texidocde --header=texidoces --header=texidocfr --header=tex idochu > --header=texidocit --header=texidocja --header=texidocnl --header=texidoczh > -dcheck-internal-types -ddump-signatures -danti-alias-factor=2' > --output=./out-www --loglevel=NONE --lily-output-dir > /home/lilypond/build/out/lybook-db --pdf -o ./out-www > /home/lilypond/lilypond/input/regression/lilypond-book/tex-paragraphs.lytex > langdefs.py: warning: lilypond-doc gettext domain not found. lilypond-book.py: > error: Unknown or invalid loglevel 'NONE' Reading > /home/lilypond/lilypond/input/regression/lilypond-book/tex-paragraphs.lytex... > Running `pdflatex' on file `/tmp/tmprdFEfM.tex' to detect default page > settings. > > Dissecting... > Writing snippets... > Processing... > Running lilypond... > Processing > `/home/lilypond/build/out/lybook-db/snippet-map--8367446982699564671.ly' > Parsing... Processing `/home/lilypond/build/out/lybook-db/67/lily-ff28cae4.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects... > Calculating line breaks... > Drawing systems... > Writing /home/lilypond/build/out/lybook-db/67/lily-ff28cae4-1.signature > Layout output to `/home/lilypond/build/out/lybook-db/67/lily-ff28cae4.eps'... > Converting to `/home/lilypond/build/out/lybook-db/67/lily-ff28cae4.pdf'... > Converting to PNG... > Layout output to > `/home/lilypond/build/out/lybook-db/67/lily-ff28cae4-1.eps'... > Converting to `/home/lilypond/build/out/lybook-db/67/lily-ff28cae4-1.pdf'... > Writing /home/lilypond/build/out/lybook-db/67/lily-ff28cae4-systems.texi... > Writing /home/lilypond/build/out/lybook-db/67/lily-ff28cae4-systems.tex... > Writing /home/lilypond/build/out/lybook-db/67/lily-ff28cae4-systems.count... > Success: compilation successfully completed > Compiling > /home/lilypond/build/input/regression/lilypond-book/out-www/tex-paragraphs.tex... > Writing > `/home/lilypond/build/input/regression/lilypond-book/out-www/tex-paragraphs.tex'... > lilypond-book.py (GNU LilyPond) 2.15.30 LILYPOND_VERSION=2.15.30 > /usr/bin/python > /home/lilypond/lilypond/scripts/lilypond-book.py -I > /home/lilypond/lilypond/input/regression/lilypond-book/ -I ./out-www -I > /home/lilypond/lilypond/input -I /home/lilypond/lilypond/Documentation -I > /home/lilypond/lilypond/Documentation/snippets -I > /home/lilypond/lilypond/input/regression/ -I > /home/lilypond/lilypond/Documentation/included/ -I > /home/lilypond/build/mf/out/ > -I /home/lilypond/build/mf/out/ -I > /home/lilypond/lilypond/Documentation/pictures -I > /home/lilypond/build/Documentation/pictures/./out-www > --process='/home/lilypond/build/out/bin/lilypond -dbackend=eps > --formats=ps,png,pdf -djob-count=4 -dinclude-eps
Re: Cheat sheet
On 07/02/2012 10:02, Francisco Vila wrote: > Hello Reinhold, > > Here is my work in progress with a Spanish version of the Cheat sheet > you posted some time ago. > > http://paconet.org/lilypond/lilypond-cheat-sheet-es.pdf (source attached) > > If you don't want to give away your source code, which I understand, I > would like nevertheless to ask you a few questions or clues about the > implementation. Some tricks look very clever from your PDF. The complete code is available at: https://gitorious.org/lilypond-cheatsheet/ Please use the new-baposter branch, which builds on a customized version of the baposter package (included in the git repo). I haven't yet tried it with the latest official baposter release, which includes all my changes (but might add some other things that break the cheatsheet). > If you decide to send me even fractional, incomplete chunks of the > source file, you'd be credited in the sheet as the author and myself > as translator with the same license you used and in the same way you > did. I do not plan to sell it. No problem, I realized that you cannot make money off lilypond, so I'm putting also the source code under the creative commons license. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging->Master
On 2012-02-02 18:11, Phil Holmes wrote: - Original Message - From: "David Kastrup" To: "Phil Holmes" I believe James indicated his big machine was on 24x7 - hence my instructions if he has some time to look at this. I think that this would be the preferable solution. Even though patchy is quite less painful on my current machine than on the one I had been using a few days ago, it takes its time. My box runs it quite quickly and is not used for anything else. It has to be turned on to run patchy though. Suggest you leave it to me for now unless you're experimenting. My new office machine (on 24/7) is quite a powerful beast, and I usually don't to any expensive calculations. So, I can certainly set up a cronjob to run patchy regularly. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On 2012-01-30 12:59, David Kastrup wrote: Graham Percival writes: On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. I am not sure what the problem is with anybody else running it. You call it, and it complains about LILYPOND_GIT not being set. Then you call LILYPOND_GIT=/usr/local/tmp/lilypond /usr/local/tmp/lilypond-extra/patches/lilypond-patchy-staging.py (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. I can run it regularly (i.e. a cron job) on my office machine (recently got a really fast quad-core system), which is up 24/7 and doesn't have too much load otherwise. I don't know how much time I'll have to set it up, though. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 2012-01-27 00:00, Julien Rioux wrote: On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? Please check the -devel mailing list (e.g. thread "Memleaks or not" last August/September), where I already observed this. I fully agree that after one file is processed, lilypond should reset to its initial state and not need more memory than before. I have no idea why the memory is going up like it does. To me it doesn't look like a classical memleak, but rather somthing with the Guile garbage collection... Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 20:58, Julien Rioux wrote: > Thanks, you're quite right CPU is not the limiting factor for the > build. Disk access and usage of swap when compiling > input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806 python/book_snippets.py:806: self.ext = os.path.splitext (os.path.basename (self.filename))[1] On 2012/01/22 00:08:45, Julien Rioux wrote: The '.ly' is hardcoded elsewhere already, so that when you include a .ily, lilypond-book actually writes a lily-.ly file for it, and this is what we link to. On the other hand leaving the current code in leads to broken links to a lily-.ily file. What about --use-source-file-names? http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode124 python/book_snippets.py:124: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''', On 2012/01/22 00:08:45, Julien Rioux wrote: On 2012/01/21 23:54:36, Reinhold wrote: > Aren't there cases when neither LINE_WIDTH nor QUOTE is used? Yes, that's the case for html-inline-no-option.html I was rather talking about e.g. when the papersize=... snippet option is used in a texi file... (I think that doesn't work currently, either, though). > In that case we don't subtract the padding... Why would a padding be relevant when there is no specified line width? The line width is implicitly specified by the paper size. http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
LGTM in general. Some comments though. Plus: The example in the comment above will now compile, but it will be missing the additional padding... Another thing about the hard-coded .ly extension: I would leave the extension extraction in the file snippet class, so that the base class sets a default of .ly, but for file snippets the extension will be extracted from the file name. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184 python/book_snippets.py:184: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1)) On 2012/01/21 21:18:00, janek wrote: Ah, so the problem was that sometimes line-width wasn't defined and thus trying to adjust it failed? Yes, the problem is that I don't know of any way to get the default line-width, because there are cases where line-width is not explicitly defined in the snippets. In those cases we also need to subtract the padding... http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806 python/book_snippets.py:806: self.ext = os.path.splitext (os.path.basename (self.filename))[1] Why are you removing a generic statement and hardcoding .ly above? This will break e.g. if you try to include a .ily file as a snippet! http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode890 python/book_snippets.py:890: return result On 2012/01/21 19:14:15, Julien Rioux wrote: ...this part. Yeah, appending the original extension makes more sense (and also works when you have a compressed .xml file where you explicitly specify --compress). http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode124 python/book_snippets.py:124: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''', On 2012/01/21 19:14:15, Julien Rioux wrote: This fixes the first problem by adjusting line-width directly where it is defined. Aren't there cases when neither LINE_WIDTH nor QUOTE is used? In that case we don't subtract the padding... http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add a node prefix to snippets, preventing duplicate node errors (issue 2221). (issue 5541050)
I had tried this very approach a while ago, but there were some problems. Unfortunately, I can't remember which problems I encountered. One issue might be that all links to one particular snippet will be broken with that patch. If you don't encounter any problems with broken links etc., then I'm fine with the patch. http://codereview.appspot.com/5541050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book on windows
On 12/01/2012 09:06, David Kastrup wrote: > "Trevor Daniels" writes: > >> Trevor Daniels wrote Wednesday, January 11, 2012 6:49 PM >> >>> To carry things to their logical conclusion I'm installing MikTeX to >>> see if it is possible to make Reinhold's code work as intended on >>> Windows. Even if it does, I could not recommend downloading >>> 167Mbytes of MikTeX just to pick up these values automatically. >> Well, MikTex contains texi2dvi.exe, so I renamed this to texi2pdf.exe >> and added its directory to the MinGW path. > You need a TeX distribution anyway to create PDF from lytex files. And > if you are not creating print copy there is no point in figuring out a > line width as it would deliver a result without any meaning (except if > for some reason you want notes in HTML use the same line breaks as in > print). So if lilypond-book fails when creating HTML documentation > without a TeX distribution, this is a deficiency not just in Windows. Exactly, and as I said, it is supposed to work without texi2pdf (and/or a working TeX installation) available. However, even for HTML we need some kind of line width so that we can line-break all lilypond snippets. The default fallback value (which roughly corresponds to A4 with some margins) is an acceptable default value, so things should look okay in any case. The problem is just that the subprocess module needs msvcrt on Windows, but that python as provided by lilypond does not ship that module. I would rather see this as a packaging problem, or am I seeing something wrong? Cheers, REinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book on windows
On 2012-01-11 15:12, Julien Rioux wrote: One problem that exists here for sure for windows is the definition of cmd which include "LC_ALL=C texi2pdf ...". LC_ALL is an environment variable that sets the locale. I think this is here to ensure that the output from texi2pdf is in English and can be parsed easily. No, texi2dvi has a nasty bug that will show in certain locales (e.g. in German), where any call to texi2dvi will fail, because one regexp is incorrect in that case. For that reason, we need to forc texi2dvi to use C locale. Search the mailing list a few months back for a short discussion. Setting environment variables in this way does not work on windows. Instead one might add env=something as an argument to the subprocess.Popen call. Okay, if you find a way that works in Linux, too, feel free to fix it. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
LGTM. From a lazy user's POV, I don't like that I now have to use \default for auto-numbering (which is th typical case)... But then, one can always define one's own music function that takes care of that. So no objection from my side. http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.itely#newcode1141 Documentation/notation/input.itely:1141: @funindex \footnote Remove duplicate... http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: VirtualBox help
On 2012-01-04 12:05, m...@apollinemike.com wrote: Alternatively, if that doesn't work, does anyone know how to recover files from a virtual hard drive? I think you simply want to enlarge the file system to the full virtual harddisk size, right? There's that nice gparted live ISO image, from which you can boot your virtual machine (download the iso (~100MB), set it as the virtual box's CD drive, change boot order to boot from CD and run your virtualbox) and then resize the file system to the full available space. Opens up like a charm, but it seems that my drive is blocked @ 19.42 gigs (see screen shot) and that I can only fiddle with the swap space. Is this the right thing to do? You'll have to move (remove) the swap space so that you can enlarge your real data partition... Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: VirtualBox help
On 2012-01-04 09:11, m...@apollinemike.com wrote: In my GUB installation, my VirtualBox ran out of space and peetered out. So, I closed my VirtualBox down, resized the hard drive, and tried to boot again. You know, resizing the harddrive (i.e. partition) does not resize the filesystem itself. So your filesystem is still just as full as it was before. However, it cannot restart (some message about GNOME power something something) and I think it's because the disk space is full. It's not even recognizing my root password :-/ Yes, that's a typical sign... Does anyone know how to do delete files on a VBox from the outside so that I can free up space? I know this question is more appropriate for a VirtualBox forum, but I figured that one of you may know... There is a virtualbox-fuse file system, so you can mount a virtual harddrive and then delete files there Alternatively, if that doesn't work, does anyone know how to recover files from a virtual hard drive? I think you simply want to enlarge the file system to the full virtual harddisk size, right? There's that nice gparted live ISO image, from which you can boot your virtual machine (download the iso (~100MB), set it as the virtual box's CD drive, change boot order to boot from CD and run your virtualbox) and then resize the file system to the full available space. I did exactly that with my WinXP virtual machine and it worked just fine. Cheers, Reinhold -- ------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)
On 28/12/2011 11:40, m...@apollinemike.com wrote:
> On Dec 25, 2011, at 10:50 PM, Janek Warchoł wrote:
> Vertical skylines are useful for any object whose height changes appreciably
> over its horizontal span. Slurs (sometimes) fall into this category.
> Accidentals fall into this category as well and have been dealt with
> similarly (I don't know who wrote the code, but there is code in
> accidental.cc to get a boxed approximation of an accidental's form).
>
> I am not sure that dynamics and lyrics have subtleties in their shape that
> could be better approximated by the use of boxes (perhaps dynamics more than
> lyrics as they are slanted, but I'm dubious of this).
>
> To fix the problem, it'll be necessary to cook up a few minimal examples
> showing each problem (ideally with lines that can be commented out to trigger
> the problem). Once you have this, we'll be able to find the cause rather
> quickly. I suspect that the issue arises from too-generous pure height
> approximations and/or oddities in inter-staff vertical spacing, so boxes are
> likely not the solution.
Another situation is that center-aligned barnumbers (right-aligned
barnumers simply look ugly for >100 bars) are shifted upwards by the
rectangular box of the treble clef, even though no collision would occur
at all. Simple example is attached.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version "2.15.24"
\relative c'' {
\override Score.BarNumber #'self-alignment-X = #CENTER
\repeat unfold 5 { c1 c1 c1 | \break }
}
treble_clef_barnumber.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tie LilyPond, lexer and parser together more type-safely. (issue 5501056)
LGTM (looks very much like a code simplification) http://codereview.appspot.com/5501056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)
Is anyone here using a 64-bit OS? There are ~150 compiler warnings when compiling lilypond currently (see bug 1890), so -Werror can't be enabled on 64-bit systems. http://codereview.appspot.com/5489092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't blindly issue the warning (issue 5477087)
LGTM. In particular, it's a good idea to call communicate() before checking the returncode, because communicate ensures that the returncode is set... http://codereview.appspot.com/5477087/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to add measure counters?
On Sa., 10. Dez. 2011 00:32:48 CET, Xavier Scheuer wrote: > On 12 September 2011 21:03, Reinhold Kainhofer > wrote: > > I'm currently investigating how to implement measure counters (Bug > > 146): http://code.google.com/p/lilypond/issues/detail?id=146 > > Plop, I need a measure counter for the score I'm currently typesetting > and found this thread again. > > I am just wondering: Reinhold, are you still working on this? No, I'm currently so short on time that I don't have any time for lilypond. Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds parenthesized measure numbers at mid-bar breaks. (issue 5452057)
http://codereview.appspot.com/5452057/diff/1/lily/bar-number-engraver.cc File lily/bar-number-engraver.cc (right): http://codereview.appspot.com/5452057/diff/1/lily/bar-number-engraver.cc#newcode107 lily/bar-number-engraver.cc:107: if (mp.main_part_ != Rational (0)) So, we now always print out the barnumber in parenthesis for mid-measure breaks. The user has no chance to turn that off? http://codereview.appspot.com/5452057/diff/1/lily/bar-number-engraver.cc#newcode110 lily/bar-number-engraver.cc:110: maybe_close_paren = ")"; Don't hardcode formatting settings, use a property instead. http://codereview.appspot.com/5452057/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On 2011-11-30 23:27, olafbuddenha...@gmx.net wrote: Having participated in or followed a number of free software projects (both GNU and other) over the years, I don't know of *any* besides LilyPond that uses a dedicated patch review tool. (Including the very largest ones, such as Linux or GCC.) Reviews are done almost exclusively by email -- and quite frankly, I don't see why anything else would be preferred for the actual review. The only problem is tracking the status of patches *afterwards*... KDE uses reviewboard... Until a few years ago, patch reviews were only done for patches by newcomers, and that went over the mailing lists. But now more and more features are reviewed on reviewboard. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Thinking about another disruptive change
Am 2011-11-15 10:49, schrieb David Kastrup: > The "principle of lazy complication" would keep material as simple as > feasible until a more complicated version is asked for. > > That is, when a music function asks for a "scheme?" argument and the > input is just c', it gets a pitch. If it asks for a "ly:music?" event, > it gets a NoteEvent (not an EventChord). If it asks for an EventChord, > it gets one. > [...] > > All in all, such a change should make programming and inspecting data > structures much more straightforward, and particularly save the > programmer from the "let's see what complex structures Lilypond creates > from simple input and devise a scheme how to get at the simple things we > actually wanted" phenomenon. > > But it is definitely not going to be an upwards-compatible change. What will be different for a normal user? I.e. What basic lilypond notation will change? And what advanced notation will break with that change? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes footnote automatic numbering. (issue 4877041)
On 2011-11-14 14:24, m...@apollinemike.com wrote: Reinhold - how did you do the memory profiling on all of the regtests? I can figure out how to do it for a single file, but not the regtests in succession. This'd help me figure out where/why lilypond is fizzling out. cd input/regression/ lilypond *.ly (and then get the values in a separate shell by "ps aux|grep lilypond|grep -v grep") Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nonfastforwarding push to staging
On 2011-11-13 20:10, David Kastrup wrote: It would look somewhat like the following (untested) #!/bin/sh case "$1" in refs/heads/dev/*) exit 0;; refs/heads/staging) if [ $3 == "" ] then echo "Deleting $1 not permitted.";exit 1 fi exit 0;; *) if [ $3 == "" ] then echo "Deleting $1 not permitted.";exit 1 elif [ $2 == "" ] then echo "Creating $1 not permitted.";exit 1 elif [ "`git rev-list --count $3..$2`" -ne 0 ] then echo "Only fast forwards allowed on $1";exit 1 fi exit 0;; esac AFAIK, Graham needs to create branches origin/stable/2.xx for each release. I also don't know whether origin/release/unstable will be deleted/recreated by Graham's scripts. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.18 regtests
On So., 13. Nov. 2011 14:43:28 CET, Peekay Ex wrote: > > I seem to recall Reinhold saying something about one of the reg test > > results I posted in the last two or three days for one of David's more > > complex checkins about this (I think - I cannot find that post). > > > http://code.google.com/p/lilypond/issues/detail?id=2024#c11 > > Found it. Is this the same thing Reinhold as what was supposed to be > fixed in http://code.google.com/p/lilypond/issues/detail?id=1529 Yes, issue 1529 was this very issue. Apparently something doesn't work in this case. I'll have to investigate a bit more. But I moved into a new appartement last week, so (1) I don't have internet at home yet and (2) I have so many more important things to do right now, like unpacking, cleaning etc... Maybe we should reopen 1529 (assign to me) and link to that discussion. Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Keep yaffut from attempting to demangle. (issue 5375051)
On 2011-11-11 09:31, d...@gnu.org wrote: Remember that yaffut is a cross platform test suite, are things like c++filt available for MSVC, for example? Huh? What concern are the platforms yaffut runs on? Don't tell me that Lilypond is one of its main distribution points. If it is, so much the better that I added a notice about the change. The point of importance are the platforms _Lilypond_ runs on. And it is not like the test suite will fail without demangling: it just has less readable output. If it tries to call an external binary that fails, that's a problem, because then make check will fail... Now, I haven't looked at the patch, so I don't know if the test suite will still work if c++filt is not available... In the worst case, we need to add a configure check for it.a) don't use demangle but a neutral name like "typeformat". Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch series (available at branch dev/syntax) for more argument list power. (issue 5333051)
On 2011/11/03 22:59:52, J_lowe wrote: Passes make and make check, No reg test diffs. Is Patch Set 3 the final version, or are the three patch sets independent patches that need to be applied one after the other??? It seems that the patch set 3 does not contain many changes from the first two patch sets. http://codereview.appspot.com/5333051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement \once as music function able to operate on complex stuff. (issue 5322065)
http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly
File input/regression/complex-once.ly (right):
http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly#newcode11
input/regression/complex-once.ly:11: \unHideNotes g a \once\hideNotes
b c |
While this is the easy approach, it builds on the fact that hideNotes is
internally implemented as a music expression with several \override
commands. If that internal representation ever changes, we won't have a
proper regtest any more...
I would prefer to define the multiple property operations command
explicitly in the regtest, so we have complete control and no risk that
a totally unrelated change might break a regtest (without us even
noticing).
I.e. I would explicitly do
multipleOperations = {
\override #'NoteHead #'color = #red
\override #'Stem #'color = #blue
}
and then \once\multipleOperations.
http://codereview.appspot.com/5322065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement \once as music function able to operate on complex stuff. (issue 5322065)
LGTM, although regtests are missing (for \once applied to multiple settings at one, stored in a variable). http://codereview.appspot.com/5322065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lybook-db etc etc.
Am 2011-10-26 17:13, schrieb David Kastrup: Well, I am currently in the process of running make info (similar to make doc), and this is totally silly. In my opinion, the whole lybook-db stuff needs to go. Instead, Lilypond is run _once_ for all snippets of a lybook source, Lilypond is currently run _once_ for all snippets. In particular, it is called by lilypond-book with snippet-names.* as input file, listing all files to process. generating _one_ PostScript file. Then GhostScript is run _once_ to generate a bunch of eps files, or a multi-page PDF file with all graphics in them which get referenced as needed. This is a fundamental deviation from how lilypond works currently, and it's probably hard to get it right. Currently, lilypond processes one file after the other in a loop, properly cleaning up after each file, and the corresponding backend does its job one file at a time. You are proposing that all backends should be split into two stages, one to create the ps files (for the (|e)ps backend at least) and one to convert them to pdf/pngs. This does not affect only lilypond-book, but lilypond being run on multiple files in general. What if one file fails to compile? Imagine you are running multiple files at once, i.e. lilypond file1.ly file2.ly file3.ly file4.ly and file4.ly contains a syntax error. So far, file1, file2 and file3 will have been properly processed and finished (i.e. their *.pdf/svg/eps/ps/scm output files have been created), only file4 failed. With your proposal, all already compiles files will have only half of the work done, but no PDF created. So basically you will have NO pdf output at all for any of the files. Bleedover of variables/fonts/whatever is not all that crucial since we are talking about a single document source rather than an immaculate database. How does your proposal work with files that e.g. change the scheme options, like resolution? (Well, I think this case doesn't work properly right now, either, because the option might not be reset after the file that sets it, but at least each file can be compiled with different settings). And would definitely simplify the build system. Actually, it will not simplify the build system that much. All the work you are describing is done by lilypond-book, and the build system only calls lilypond-book on the list of snippets (with some copying of output files, of course, which complicates things; that will be simplified). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicexp.py: Fix for issue 1985 (issue 5303063)
LGTM. http://codereview.appspot.com/5303063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
