Re: LilyPon's feta-braces font license
I've just pushed a change that dual licenses the font files under OFL. On Sun, Apr 29, 2012 at 5:55 PM, Khaled Hosny khaledho...@eglug.org wrote: Hi all, I'm trying to use the nice Feta braces in an OpenType math font I'm working on[1] that is licensed under OFL which is is not compatible with the GPL license of Feta. I'm wondering if it is possible to have permission for using Feta braces under OFL? I'd really appreciate this (I don't mind using GPL myself, but I don't copyright of the majority of that font). I'm using the Type1 output of mf2pt1 (with some modification of the MF source), if it makes any difference. Regards, Khaled PS. I'm not subscribed to the list, please CC me in your replies. [1] https://github.com/khaledhosny/xits-math ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 754: \transpose should not affect \transposition (issue 7304044)
On 2013/02/06 07:11:34, Keith wrote: This works, including midi and cues between transposing instruments. I somewhat recommend doing only patch set 1 and the update to the regtest documentation in set 3. (Or, at least put the change in patchset 2 as a separate commit, with a convert-ly rule to say NOTSMART on any instrumentTransposition in user input.) Well, the current commit structure is commit 055502c402fc90ba208e48c39e6d4f1c50a19fa6 Author: David Kastrup d...@gnu.org Date: Tue Feb 5 14:48:46 2013 +0100 Invert the meaning of instrumentTransposition again. This basically reverts commit 1965ca6b70aaf2c04a25ace9ed3f1fb4e1222f5a and the preceding one. Files affected: lily/note-performer.cc lily/quote-iterator.cc ly/music-functions-init.ly scm/define-context-properties.scm commit 881f2ef1698f1d01276212bb826a31b4e9edd141 Author: David Kastrup d...@gnu.org Date: Tue Feb 5 17:31:48 2013 +0100 Adapt input/regression/quote-transposition.ly to new realities commit f4bc3312b498d9bf304d82b7d56fcd6d872a5dd6 Author: David Kastrup d...@gnu.org Date: Tue Feb 5 12:06:26 2013 +0100 Issue 754: \transpose should not affect \transposition We really need to check out Gerrit at some point of time. I don't see the point in _not_ inverting the instrumentTransposition sign: our documentation gets it wrong, and all regtests are wrong. What is a nuisance is that marking QuoteMusic from \cueDuringWithTranspose (or whatever it is called) as untransposable in order to save quote-transposition from tampering is not feasible as 'element _has_ to be transposed. I am currently rewriting the whole mess of \cueDuringWhatever to give it a sensible interface. LilyPond is sometimes such an arcane heap of junk. https://codereview.appspot.com/7304044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 754: \transpose should not affect \transposition (issue 7304044)
https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly#newcode491 ly/music-functions-init.ly:491: instrumentSwitch = On 2013/02/06 07:11:34, Keith wrote: If and when you revert the negation of instrumentTransposition, you need to get set an untransposable property on the music created here. Well, that makes sense. Except for the If and when part. There is no point in making \instrumentSwitch behave any different from \transposition on its own either case. https://codereview.appspot.com/7304044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 754: \transpose should not affect \transposition (issue 7304044)
This works, including midi and cues between transposing instruments.
I somewhat recommend doing only patch set 1 and the update to the
regtest documentation in set 3.
(Or, at least put the change in patchset 2 as a separate commit, with a
convert-ly rule to say NOTSMART on any instrumentTransposition in user
input.)
Although most people find it confusing (and would not mind changing
their scores) some people might have used the strange but consistent
logic of the behavior in master:
clarinet = { \transposition bes \key d\major
d'4 e' fis' g' }
% the clarinet player is ill; give his part to the flute
flute = \transpose d c { \clarinet }
% ... and for some reason we need midi or cues.
If someone depended on that behavior (maybe in a more elegant or clever
way than we have foreseen) we would want to let that someone use a
version of \transposition that works as it does in current master.
https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly#newcode491
ly/music-functions-init.ly:491: instrumentSwitch =
If and when you revert the negation of instrumentTransposition, you need
to get set an untransposable property on the music created here.
Otherwise, \transpose c d { ... \instrumentSwitch ... } has the
problem originally reported by Werner in 2004.
https://codereview.appspot.com/7304044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove code duplication for cue clefs (issue 7306053)
On 2013/02/06 14:57:05, dak wrote: Fix clueless typo 'clue-clef-map' LGTM https://codereview.appspot.com/7306053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bass figures are not horizontally aligned to whole notes
Hello,
2013/2/2 Xavier Scheuer x.sche...@gmail.com
My guess is that bass figures should indeed be centered on the note
heads (note column), so default behaviour should be changed accordingly.
But only the figures. Accidentals, +, etc. should not be taken into
account in the centering, contrary to Bertrand's first workaround.
If someone possessing a reference book could confirm this, thanks.
Could this be considered as the minimal example and the bad output?:
\new Staff { \clef F c1 c c \bar |.}
\new FiguredBass \figuremode {
51 6 4+ 2\+ 6
}
Marek
bug squad member
attachment: bug.preview.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Did VerticalAxisGroup default-staff-staff-spacing stop respecting padding in 2.17.10?
Hi,
Did VerticalAxisGroup's default-staff-staff-spacing property stop
respecting the 'padding' attribute between 2.17.9 and 2.17.10?
I ask because I use a custom time signature context in my scores.
Short examples using the custom time signature context under 2.17.9 and
2.17.10 are attached. You can see that the time signatures in the 2.17.9
example float in their own context positioned happily above the notes. But
the time signatures in the 2.17.10 example have fallen and intermingle with
the notes.
Here's the code to the complete example.
### BEGIN CUSTOM TIME SIGNATURE CONTEXT EXAMPLE ###
\version 2.17.11
\layout {
ragged-right = ##t
\context {
\type Engraver_group
\name TimeSignatureContext
\consists Axis_group_engraver
\consists Time_signature_engraver
\override TimeSignature #'color = #red
\override TimeSignature #'X-extent = #'(0 . 0)
\override TimeSignature #'X-offset =
#ly:self-alignment-interface::x-aligned-on-self
\override TimeSignature #'Y-extent = #'(0 . 0)
\override TimeSignature #'break-align-symbol = ##f
\override TimeSignature #'break-visibility = #end-of-line-invisible
\override TimeSignature #'font-size = #1
\override TimeSignature #'self-alignment-X = #center
\override VerticalAxisGroup #'default-staff-staff-spacing =
#'((basic_distance . 0) (minimum_distance . 10) *(padding .
6)*(stretchability . 0))
}
\context {
\Score
\remove Bar_number_engraver
\accepts TimeSignatureContext
\override SpacingSpanner #'strict-grace-spacing = ##t
\override SpacingSpanner #'strict-note-spacing = ##t
\override SpacingSpanner #'uniform-stretching = ##t
proportionalNotationDuration = #(ly:make-moment 1 48)
}
\context {
\Staff
\remove Time_signature_engraver
}
\context {
\RhythmicStaff
\remove Time_signature_engraver
}
}
\score {
\context Score = Grouped Rhythmic Staves Score
\context TimeSignatureContext = TimeSignatureContext {
{
\time 1/8
s1 * 1/8
}
{
\time 2/8
s1 * 1/4
}
{
\time 3/8
s1 * 3/8
}
}
\context StaffGroup = Grouped Rhythmic Staves Staff Group
\context RhythmicStaff = Staff 1 {
\context Voice = Voice 1 {
{
c'16 [
c'16
c'16
}
{
c'16
c'16
c'16
}
{
c'16
c'16
c'16
}
{
c'16
c'16
c'16 ]
}
}
}
}
### END EXAMPLE ###
It looks to me like padding is no longer functioning the same way in
VerticalAxisGroup.
Can anyone confirm?
(Testing shows the problem to be present in 2.17.10 and 2.17.11; versions
from 2.17.9 and earlier are fine.)
Trevor.
--
Trevor Bača
trevorb...@gmail.com
attachment: custom-time-signature-context-with-2-17-10.pngattachment: custom-time-signature-staff-with-2-7-9.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 754: \transpose should not affect \transposition (issue 7304044)
On 2013/02/06 11:15:41, dak wrote: I don't see the point in _not_ inverting the instrumentTransposition sign: our documentation gets it wrong, and all regtests are wrong. I cannot follow the multiple negatives, but I can see some point to /either/ convention. 1) Storing the pitch written to sound middle C in instrumentTransposition as in ver2.16 (i.e., the inverse of pitch we use to describe the transposition, d' for clarinet in B-flat ) means that all pitches in the stream are /written/ pitches. The pitch in the event that sets instrumentTranposition would usually be protected from \transpose, but users would retain the capability to \set instrumentTransposition without the protection. Since all \transpose'd pitches are written pitches, the effect is consistent. Some people took advantage of that consistent behavior https://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00074.html 2) Storing the sounding pitch corresponding to written middle C in the instrument part (i.e., storing directly the pitch we use to describe the transposition) is simpler, and most of the documentation thinks LilyPond works this way already. https://codereview.appspot.com/7304044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Did VerticalAxisGroup default-staff-staff-spacing stop respecting padding in 2.17.10?
Trevor Bača trevorb...@gmail.com writes: Hi, Did VerticalAxisGroup's default-staff-staff-spacing property stop respecting the 'padding' attribute between 2.17.9 and 2.17.10? I ask because I use a custom time signature context in my scores. Short examples using the custom time signature context under 2.17.9 and 2.17.10 are attached. You can see that the time signatures in the 2.17.9 example float in their own context positioned happily above the notes. But the time signatures in the 2.17.10 example have fallen and intermingle with the notes. Most likely candidate commit 7d3d28de0ce6e2f018aff599cecd944d1754fe3c Author: Mike Solomon m...@apollinemike.com Date: Thu Jan 10 08:54:12 2013 +0100 Makes all side-positioning based on skylines instead of boxes. The major work is in side-position-interface.cc, with minor modifications at several places in the code-base to adapt to this. This allows for snugger positioning of horizontally-oriented fingerings. A side-effect of this patch is that side-positioning of all cross-staff grobs delves into the element list of axis-groups in order to better guess position, which results in less collisions (for example, dynamics are less likely to collide with cross-staff beams). though there are some others as well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
