Re: Incipits
2008/2/11, Nicolas Sceaux <[EMAIL PROTECTED]>: > > - If I'm reading this correctly, this is all a grand hack to add a > > little staff to an instrument name. I don't see the essential > > difference between this and > > > > \set instrumentName = \markup { \score { .. } the-real-name } > > > > except that this is longer, more error prone and less flexible. Again, > > what problem are you trying to solve? > > The problem I was trying to solve is to separate the definition > of the instrument name, from the one of the incipit. They are not > the same thing, and should be entered separetely. It's well enough > to explicitely write >\set instrumentName = \markup { \score { .. } the-real-name } > when you have a single piece to typeset. It really sucks when you > have hundreds. (I have more than 600 pieces that would use this > incipit thing.) I though we had mechanisms to create more generic/parametrized markups. > That would address the points you raised in your answer. > Are you ok with this (much less enormous) patch? This looks much better. I would probably just scm-ify Score::add_output_def(), rather than have the optarg, though. Please go ahead. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Le 11 févr. 08 à 02:07, Han-Wen Nienhuys a écrit : [...] - If I'm reading this correctly, this is all a grand hack to add a little staff to an instrument name. I don't see the essential difference between this and \set instrumentName = \markup { \score { .. } the-real-name } except that this is longer, more error prone and less flexible. Again, what problem are you trying to solve? The problem I was trying to solve is to separate the definition of the instrument name, from the one of the incipit. They are not the same thing, and should be entered separetely. It's well enough to explicitely write \set instrumentName = \markup { \score { .. } the-real-name } when you have a single piece to typeset. It really sucks when you have hundreds. (I have more than 600 pieces that would use this incipit thing.) ... Actually, if there were ly:score-add-output-def! (or an optional output-def argument to ly:make-score) and ly:output-def-set-variable! functions, all could be done entirely from the outside. Example: \score { \new Staff { %% All this would be shortcuted by an appropriate music function: \override Staff.InstrumentName #'music = ##{ \clef "petrucci- c1" c'4 d' e' f' #} \override Staff.InstrumentName #'self-alignment-X = #RIGHT \override Staff.InstrumentName #'self-alignment-Y = #UP \override Staff.InstrumentName #'Y-offset = #4 \override Staff.InstrumentName #'padding = #0 \override Staff.InstrumentName #'stencil = #(lambda (grob) (let* ((instrument-name (ly:grob-property grob 'long-text)) (layout (ly:output-def-clone (ly:grob-layout grob))) (music (make-music 'SequentialMusic 'elements (list (make-music 'ContextSpeccedMusic 'context-type 'MensuralStaff ;;'property-operations '((remove "Time_signature_engraver")) 'element (make-music 'PropertySet 'symbol 'instrumentName 'value instrument- name)) (ly:grob-property grob 'music) (ly:output-def-set-variable! layout 'indent 0) (ly:output-def-set-variable! layout 'line-width 20) (ly:output-def-set-variable! layout 'ragged-right #f) (set! (ly:grob-property grob 'long-text) (markup #:score (ly:make-score music layout))) (ly:system-start-text::print grob))) %% the instrument name definition is separated: \set Staff.instrumentName = "Violon" c'4 d' e' f' g'1 } \layout { ragged-right = ##t indent = 5\cm } } ==> <> That would address the points you raised in your answer. Are you ok with this (much less enormous) patch? nicolas incipit-helper-functions.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Till: > Juergen Reuter schrieb: > > as far as I understand, all problems with incipits boil down to the > > following two major issues: > > > > (1) horizontal spacing, and I did not focus on that, it is an ancient notation issue, it is not specific to incipits. > > (2) the system start delimiter. > > > > Karl's solution unfortunately leaves horizontal space between the > > incipit and the actual score; hence it does *not* solve issue (2). > > Rather, the score lines should not stop inbetween. If you don't like the space, then remove the \stopStaff \startStaff thing. But then, whats wrong with the \bar "||" variant as Till suggests below. (cont. below) > Well, I am not so sure about that. I agree, the space is a bit too big > here, but I personally like Nocolas' solution where the space mainly > covers the distance between the choirstaff brace and the beginning of > the staff. I know that much incipits are engraved with the double line > method that is now used in the templates, but it feels logical to me > that the "real" staff with the brace start only after the incipit. I > somehow recall this would be also "hand engraved convention", but I > might be wrong. There is an example pdf on the list sent by Stefan > Slapeta that shows a broad range of incipits which show mainly the staff > lines going through all the way. So it might be my personal opinion only > that it would be nice to have the incipit seperated by a little white space. Getting less space is simple, us less space between \stop-\startStaff. See attached pdf. $ diff -u c.ly.old c.ly --- c.ly.old2008-02-11 19:41:54.923054408 +0100 +++ c.ly2008-02-11 19:42:34.417301808 +0100 @@ -34,8 +34,8 @@ \stopStaff \once \override Score.TimeSignature #'print-function = ##f \nor - \time 3/8 - s4. + \time 1/16 + s16 \revert Score.SpanBar #'print-function \revert Score.BarLine #'print-function \startStaff @@ -74,7 +74,7 @@ \score { \new ChoirStaff \with { % a pain to set? Thats Right!!! -\override SystemStartBracket #'extra-offset = #'( 38.8 . 0 ) +\override SystemStartBracket #'extra-offset = #'( 30.2 . 0 ) } { << \new Staff { > > Till > > > > IMHO, all other features have been quite well demonstrated in template > > A.5.1 for a while now. Hence, you probably should concentrate on > > solving these two remaining issues. > > > > Regarding issue (2), maybe the "right" solution is to extend the > > system start delimiter implementation in such a way, that > > > > (a) automatic printing at the system start may be suppressed for a > > specific range of the score with kind of > > "\turnSystemStartDelimiterOff" and "\turnSystemStartDelimiterOn" > > commands, and > > > > (b) a kind of "\bar #'system-start-delimiter" command prints an > > additional system start delimiter whereever you want. (But if this > > bar should happen to appear at the system start, the delimiter > > should not be printed twice.) That would be nice, but you can use the workaround with the extra-offset as shown above. > > Regarding issue (1), I am not sure what the "right" solution is. > > Please note that the note durations in the incipit are typically much > > larger than in the actually score. Karl and Nicolas, did you check > > what happens with the horizontal spacing in your incipit solutions, if > > you double or quadruple the note durations in the incipit (and only > > there)? In your examples, in the incipts you are unfortunately using > > the same durations as in the actual score. I may be wrong, but I > > suspect that your solutions do *not* solve issue (1). No I did not try. Try this (\men \nor as in previous mail) cold = { \clef "petrucci-c4" } cnew = { \clef "treble_8" } \new Voice \relative c { \men\cold d\breve*1/8 e\longa*1/16 f\maxima*1/32 g\breve*1/8 \nor\cnew | d4 e2 f4~ | f2. g4 | } I tried with B = #(ly:make-duration -1 0 1 8) ... d\B e\L f\M but it didn't work. Maybe someone have know how to write a function \foo: breve -> breve*1/8 ... I tried with % as a first test #(define-public (nop music) (if (ly:duration? music) (let music (ly:make-duration -1 0 1 8 foo = #(define-music-function (parser location music) (ly:music?) (let ((new-music (ly:music-deep-copy music))) (music-map nop new-music) new-music)) but it didn't work. %%% You can use the lsr snippet 305 to scale down the note values (and a modern lilypond version). There is the problem with/without ligatures with solutions like A.5.1 and the one I provided. And it would probably be som problems with incipits in vaticana style. %%% What would be nice is to be able to glue to \scores together, without a newline. Then one could have independent engraving on the historical and the modern part, or to have multiple parts stacked together, continuing on the same line. %%% Also it would be nice to
Re: [patch] X-aligned instrument names
Le 11 févr. 08 à 02:41, Han-Wen Nienhuys a écrit : Sounds like a good idea. You could do the same with the other lines, if you would assume that there was a 'virtual' indent (don't change the line dimensions, but assume there is a global given space to align names with) Ok. Should I define a new layout property for that? Maybe the best would be to have it computed: for the other lines, the virtual indent is the length of the larger short instrument name. (But then I have no idea how that could be done). + Real right_padding = padding * (1.0 - ((align_x + 1.0) / 2.0)); this looks as if you're looking for the linear_combination function ok. + Stencil right_stencil (right_box, ly_string2scm ("")); + right_stencil.translate_axis (p_extent[RIGHT], X_AXIS); why don't you create a stencil with a modified dimesions and the same expression? Adding a bogus ("") seems unnecessary. I thought about that this morning while driving to work. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Juergen Reuter schrieb: Hi all, as far as I understand, all problems with incipits boil down to the following two major issues: (1) horizontal spacing, and (2) the system start delimiter. Karl's solution unfortunately leaves horizontal space between the incipit and the actual score; hence it does *not* solve issue (2). Rather, the score lines should not stop inbetween. Well, I am not so sure about that. I agree, the space is a bit too big here, but I personally like Nocolas' solution where the space mainly covers the distance between the choirstaff brace and the beginning of the staff. I know that much incipits are engraved with the double line method that is now used in the templates, but it feels logical to me that the "real" staff with the brace start only after the incipit. I somehow recall this would be also "hand engraved convention", but I might be wrong. There is an example pdf on the list sent by Stefan Slapeta that shows a broad range of incipits which show mainly the staff lines going through all the way. So it might be my personal opinion only that it would be nice to have the incipit seperated by a little white space. Till IMHO, all other features have been quite well demonstrated in template A.5.1 for a while now. Hence, you probably should concentrate on solving these two remaining issues. Regarding issue (2), maybe the "right" solution is to extend the system start delimiter implementation in such a way, that (a) automatic printing at the system start may be suppressed for a specific range of the score with kind of "\turnSystemStartDelimiterOff" and "\turnSystemStartDelimiterOn" commands, and (b) a kind of "\bar #'system-start-delimiter" command prints an additional system start delimiter whereever you want. (But if this bar should happen to appear at the system start, the delimiter should not be printed twice.) Regarding issue (1), I am not sure what the "right" solution is. Please note that the note durations in the incipit are typically much larger than in the actually score. Karl and Nicolas, did you check what happens with the horizontal spacing in your incipit solutions, if you double or quadruple the note durations in the incipit (and only there)? In your examples, in the incipts you are unfortunately using the same durations as in the actual score. I may be wrong, but I suspect that your solutions do *not* solve issue (1). IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
On Mon, 11 Feb 2008, Robert Memering wrote: Am Montag, 11. Februar 2008 16:36 schrieb Juergen Reuter: IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. IMO, horizontal spacing in incipits should be completely "turned off", i.e. uniform (and rather tight) spacing regardless of note values, as seen in the renaissance manuscripts. Robert Yes, IIRC we once used to have a global boolean variable "compact" for exactly this purpose, but I think it never worked as expected due to the complex resolving of competetive spacing constraints. Remember that you almost always need to stretch something somewhere to get your line of score filled; so you can not achieve solely uniform spacing unless in combination with ragged printing of systems. I guess switching from uniform ragged spacing in the incipit to non-uniform spacing in the remaining score would require a major rewrite of the whole horizontal spacing engine. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Robert Memering schrieb: Am Montag, 11. Februar 2008 16:36 schrieb Juergen Reuter: IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. IMO, horizontal spacing in incipits should be completely "turned off", i.e. uniform (and rather tight) spacing regardless of note values, as seen in the renaissance manuscripts. I would agree with that. I had an idea about a scheme function working in the background that would scale all notes to a single duration (like 1/8 or even 1/16 as Karl has done in some of his scores. It seems now to be the most easiest way to overcome the spacing engine while keeping still all of its advantages if some objects (like text e.g.) are wider than the note itself. Till Robert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Am Montag, 11. Februar 2008 16:36 schrieb Juergen Reuter: > IIRC, the spacing engine maintains a variable that keeps track of shortest > available duration in a peace in computes the ideal distance of larger > note values in a logarithmic scale based on the shortest duration. Maybe > this computation needs to be changed for the incipit (and only there!) to > get tighter spacing in the incipit. IMO, horizontal spacing in incipits should be completely "turned off", i.e. uniform (and rather tight) spacing regardless of note values, as seen in the renaissance manuscripts. Robert -- Robert Memering Arbeitsbereich Linguistik, Universität Münster Hüfferstraße 27, D-48149 Münster, Germany Raum 01.85, Tel. +49-251-83-31958 http://santana.uni-muenster.de ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Hi all, as far as I understand, all problems with incipits boil down to the following two major issues: (1) horizontal spacing, and (2) the system start delimiter. Karl's solution unfortunately leaves horizontal space between the incipit and the actual score; hence it does *not* solve issue (2). Rather, the score lines should not stop inbetween. IMHO, all other features have been quite well demonstrated in template A.5.1 for a while now. Hence, you probably should concentrate on solving these two remaining issues. Regarding issue (2), maybe the "right" solution is to extend the system start delimiter implementation in such a way, that (a) automatic printing at the system start may be suppressed for a specific range of the score with kind of "\turnSystemStartDelimiterOff" and "\turnSystemStartDelimiterOn" commands, and (b) a kind of "\bar #'system-start-delimiter" command prints an additional system start delimiter whereever you want. (But if this bar should happen to appear at the system start, the delimiter should not be printed twice.) Regarding issue (1), I am not sure what the "right" solution is. Please note that the note durations in the incipit are typically much larger than in the actually score. Karl and Nicolas, did you check what happens with the horizontal spacing in your incipit solutions, if you double or quadruple the note durations in the incipit (and only there)? In your examples, in the incipts you are unfortunately using the same durations as in the actual score. I may be wrong, but I suspect that your solutions do *not* solve issue (1). IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Han-Wen: > Sorry for looking at this so late. > > General comments: > > - you're adding an enormous bunch of code to the instrument name > engraver. That's a bad idea. If this idea merits an engraver, it > should be a separate one. ... > - If I'm reading this correctly, this is all a grand hack to add a > little staff to an instrument name. I don't see the essential > difference between this and > > \set instrumentName = \markup { \score { .. } the-real-name } > > except that this is longer, more error prone and less flexible. Again, > what problem are you trying to solve? > > 2008/2/9, Nicolas Sceaux <[EMAIL PROTECTED]>: > > > Here is draft patch: the Instrument_name engraver is used to create an > > > Incipit grob before the first line when an incipit has been specified. > > > There are several problems in it: ... > > Both these problems are solved in the following patch. > > Do core developpers see a problem with it? Inicipits can be done with the code below. Regards, /Karl %--- \version "2.6.4" men = { \override Accidental #'style = #'mensural \override NoteHead #'style = #'petrucci \override Rest #'style = #'neomensural \override Staff.TimeSignature #'style = #'mensural \override Stem #'flag-style = #'mensural \override Stem #'thickness = #0.8 % \set Score.timing = ##f \set Staff.defaultBarType = "" #(set-accidental-style 'forget) } nor = { \override Accidental #'style = #'default \override NoteHead #'style = #'default \override Rest #'style = #'default \override Staff.TimeSignature #'style = #'default \override NoteHead #'font-size = #'0 \override Stem #'flag-style = #'default \override Stem #'thickness = #1.9 \override TimeSignature #'style = #'default #(set-accidental-style 'default) % \set Score.timing = ##t } staa = { \override Score.SpanBar #'print-function = ##f \override Score.BarLine #'print-function = ##f \men } jump = { \stopStaff \once \override Score.TimeSignature #'print-function = ##f \nor \time 3/8 s4. \revert Score.SpanBar #'print-function \revert Score.BarLine #'print-function \startStaff \once \override Score.TimeSignature #'print-function = ##f \time 1/16 s16 \override Score.SpanBar #'print-function = ##f \once \override Staff.Clef #'full-size-change = ##t \set Staff.forceClef = ##t \clef bass \time 4/4 \bar "" } % % Music and lyrics clefic = { \clef "petrucci-c1" } vic = \relative c' { c1 c } lic = \lyricmode { A B } clefmc = { \clef soprano } vmc = \relative c' { \vic d } lmc = \lyricmode { \lic c d e f g } clefib = { \clef "petrucci-f" } vib = \relative c { a1 a } lib = \lyricmode { A B } clefmb = { \clef bass } vmb = \relative c { \vib g } lmb = \lyricmode { \lib c d e f g } % \score { \new ChoirStaff \with { % a pain to set? Thats Right!!! \override SystemStartBracket #'extra-offset = #'( 38.8 . 0 ) } { << \new Staff { \set Staff.instrument = \markup { "Cantus" } \context Voice = vc { \clefic \staa \vic \jump \clefmc \vmc } } \context Lyrics = lc \lyricsto vc { \lic \lmc } \new Staff { \set Staff.instrument = \markup { "Bassus" } \context Voice = vb { \clefib \staa \vib \jump \clefmb \vmb } } \context Lyrics = lb \lyricsto vb { \lib \lmb } >> } \layout { \context { \Score \consists Span_bar_engraver \remove System_start_delimiter_engraver } } } c.pdf Description: c.pdf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Should \relative be the default for musicxml2ly
> "Mats" == Mats Bengtsson <[EMAIL PROTECTED]> writes: Mats> Definitely relative! I don't feel strongly, but the other converters (midi2ly, abc2ly, etf2ly...) all use absolute pitches. And using relative definitely makes it necessary to be careful about taking an exerpt out of context, which is often what you want to do next when you've converted something. As long as both options are available, I suppose it doesn't matter much. I assume most of us who actually type lily are using relative pitches, as they're easier to both read and type. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Should \relative be the default for musicxml2ly
Definitely relative! /Mats Andrew Hawryluk wrote: I, too, am in favour of relative as the default. -AH On Feb 8, 2008 9:40 AM, Reinhold Kainhofer <[EMAIL PROTECTED]> wrote: Hi all, Musicxml2ly supports converting to both relative pitches and absolute pitches. The question I have is, which one should be the default? The other would be available via a command-line option (either -r / --relative or -a / --absolute) to musicxml2ly. I actually prefer relative pitches, so I'm in favor of using -r by default and absolute only when given on the command line. What do you think? Cheers, Reinhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel