Re: [GLISS] non-timed or non-musical events z y
On Wed, Sep 26, 2012 at 03:44:27PM +0200, David Kastrup wrote: Reinhold Kainhofer reinh...@kainhofer.com writes: { \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... It is conceivable to cook up stuff that would allow to write something like c'1\p-\at 4 \ -\at 1*2/3 \! Really? Wow, I wish you had replied with this when I wrote Now, if a music function can apply to the current note, i.e. c1-\at{ s4 s s\f s } then I'd be much happier. on 2012 Sep 13: http://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg00597.html If you don't even bother to reply, how am I supposed to guess what your problem with my approach is? Evidently Reinhold isn't the only person who doesn't even bother to reply. In my opinion, dynamics are one case where using postfix syntax was a mistake, exactly because they are not inherently associated with a particular note but rather a moment of time. Are you speaking of the implementation or the music? I consider dynamics to be associated with moments of time within a voice. It is _that_ choice which does not really fit well with the general concepts of the LilyPond language, and in consequence dynamics are the _dominant_ example for use of and/or s1*0. So my preferred path to a remedy would rather be to un-postevent stuff that does not really fit the postevent category rather than to mess with the timing relations of postevents. Hmm. Something like this: \p \accent( c4\legato fis8. \f )d16 ? (additional spaces added to demonstrate which commands go with which notes) - Graham ___ 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
David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org 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. -- David Kastrup ___ 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 d...@gnu.org writes: Werner LEMBERG w...@gnu.org 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: [GLISS] non-timed or non-musical events z y
Reinhold Kainhofer reinh...@kainhofer.com writes: On 26/09/2012 14:34, David Kastrup wrote: David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org 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... It is conceivable to cook up stuff that would allow to write something like c'1\p-\at 4 \ -\at 1*2/3 \! here. 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)... If you don't even bother to reply, how am I supposed to guess what your problem with my approach is? In my opinion, dynamics are one case where using postfix syntax was a mistake, exactly because they are not inherently associated with a particular note but rather a moment of time. It is _that_ choice which does not really fit well with the general concepts of the LilyPond language, and in consequence dynamics are the _dominant_ example for use of and/or s1*0. So my preferred path to a remedy would rather be to un-postevent stuff that does not really fit the postevent category rather than to mess with the timing relations of postevents. -- David Kastrup ___ 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
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. Hehe. Sorry for not answering (I was busy, and then I forgot), and thanks for resending the example. While I can see that this works, I'm not getting comfortable with the notation. I still favor something like c'1-{...} regardless of its impossibility :-) Maybe things change in the future, and we can reconsider the whole issue then. Werner ___ 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
Reinhold Kainhofer reinh...@kainhofer.com writes: On 26/09/2012 14:34, David Kastrup wrote: David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org 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... One can, of course, exchange the order of arguments. However, then adding several arguments becomes more awkward: at = #(define-music-function (parser location music event time) (ly:music? ly:music? ly:duration?) Place @var{event} at a relative duration @var{time} in relation to @var{music}. #{ \context Voice { \skip $time $event } $music #}) { \at { \at { c'1\p } \ 4 } \! 1*2/3 } In this case, we might get the same result, however, by specifying the second duration not in relation to the main event but to the already delayed event: after = #(define-music-function (parser location music time event) (ly:music? ly:duration? ly:music?) Place @var{event} at a relative duration @var{time} in relation to @var{music}. #{ \context Voice { \skip $time $event } $music #}) { \after { c'1\p } 4 \after \ 1*1/6 \! } This is now in time order but I am not really convinced that it is less confusing. -- David Kastrup ___ 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
\after { c'1\p } 4 \after \ 1*1/6 \! This is now in time order but I am not really convinced that it is less confusing. You are right, it's worse. Your first solution is fine except that it doesn't follow lilypond's suffix notation. Werner ___ 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
2012/9/24 Keith OHara k-ohara5...@oco.net: Graham Percival graham at percival-music.ca writes: Although mathematicians and programmers are quite comfortable with contains with 0 items inside them, this is not a particularly intuitive concept (just look at the concept of zero in the history of mathematics!) as a mathematician and programmer I find it natural that a chord may be empty, but I'm confused by it having zero duration - I'd have thought that duration is the property of the chord, not of its elements. This would allow people to write either: { c'1\ \! } { c'1\ z\! } The non-timed null event z would be inserted after the previous note (the c'1) is finished. I avoided s1*0 (maybe I subconsciously felt it was cheating) but find extremely useful +1 and use it a lot. \pp^pizz. \repeat unfold 3 c'4 great to know! so long I used only at the end of an expression, and just recently I've struggled with such repeats. does anybody has a similar way (not a function) of marking just the first note with a cautionary accidental? p ___ 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
Benkő Pál benko@gmail.com writes: 2012/9/24 Keith OHara k-ohara5...@oco.net: Graham Percival graham at percival-music.ca writes: Although mathematicians and programmers are quite comfortable with contains with 0 items inside them, this is not a particularly intuitive concept (just look at the concept of zero in the history of mathematics!) as a mathematician and programmer I find it natural that a chord may be empty, but I'm confused by it having zero duration - I'd have thought that duration is the property of the chord, not of its elements. This would allow people to write either: { c'1\ \! } { c'1\ z\! } The non-timed null event z would be inserted after the previous note (the c'1) is finished. I avoided s1*0 (maybe I subconsciously felt it was cheating) but find extremely useful +1 and use it a lot. \pp^pizz. \repeat unfold 3 c'4 great to know! so long I used only at the end of an expression, and just recently I've struggled with such repeats. does anybody has a similar way (not a function) of marking just the first note with a cautionary accidental? This is probably somewhat tongue-in-cheek, but try { \key fis\major dis4 \once\accidentalStyle teaching \repeat unfold 7 cis } But maybe it would make sense checking the available accidental styles anyway: perhaps you actually want a different one throughout. -- David Kastrup ___ 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
2012/9/24 David Kastrup d...@gnu.org: Benkő Pál benko@gmail.com writes: does anybody has a similar way (not a function) of marking just the first note with a cautionary accidental? This is probably somewhat tongue-in-cheek, but try { \key fis\major dis4 \once\accidentalStyle teaching \repeat unfold 7 cis } But maybe it would make sense checking the available accidental styles anyway: perhaps you actually want a different one throughout. indeed; what I actually want is a blend of default and neo-modern: { \repeat unfold 4 fisis8 \repeat unfold 4 fis8 | \repeat unfold 4 f8 } I'd like to get the sharp as in default, i.e. with a prepended natural, and have a natural before the first f as in neo-moder. I'm happy to write it manually, but \repeat unfold 4 f!8 puts a natural before all notes, so currently I have { \repeat unfold 4 fisis8 \repeat unfold 4 fis8 | f!8 \repeat unfold 3 f8 } p ___ 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 23/09/12 15:58, David Kastrup wrote: With the separately discussed isolated durations are pitch-less NoteEvent in noteentry, you could use arguments like { 8 ~ 8. } = { 4 } and such music arguments would get passed through a \score markup using a specific TempoStaff without stafflines and with nice dimensions, also allowing for specs like \tempo \times 2/3 { 4 8 } = 64 Just to be clear I understand, this last example means triplet quarter + eighth = 64, and would be equivalent to regular quarter = 64, correct? It looks quite an elegant formulation as (again, if I understand correctly) it allows an arbitrary combination of durations (tied and non-tied) to be used as the beat length. I can also see other applications in other contexts for a pitchless NoteEvent. Basically, I think with this single post you've removed all my concerns about the \tempo command and its future. :-) ___ 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
2012/9/23 David Kastrup d...@gnu.org: As I said: I have not yet tackled this actively since at least the equals sign may still become part of the universe supported by music functions. If \tempo had mandatory curly braces, that would simplify things. \tempo already accepts \markup. All features of \tempo could be done inseide of ad-hoc \markup commands. Maybe entering directly in markup mode, and improving the available markup commands to adapt to tempo marks, is a solution. \tempo { Allegro \bpm{ 4 80 } } %no paren \tempo { Allegro (\bpm{ 4 80 }) } %paren \tempo { \bpm{ 4 \ca{ 80 100 } } } %circa It looks very long and cluttered, though. Asi it currently is, \tempo is very sweet in terms of sugar for the user. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.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 23/09/12 00:07, Graham Percival wrote: I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the text parts of the existing \tempo command (if they don't already exist, which they probably do). That seems potentially quite ouch -- too much chance of the user tweaking the visual mark but not the actual bpm, or vice versa. OK, perhaps you could make it so any metronome mark in the \tempoMark is derived from the \tempo_bpm setting, but it still seems problematic. Step back for a second and consider the variants you might want in a tempo change: (1) specified beat unit has a particular number of bpm. Your beat unit may not be limited to a typical unit like a quarter- or eighth-note, but might be a 5th, 6th, 10th or 12th note (i.e. quintuplet or triplet quarter or eighth), or it might be a combination of note values (e.g. two note values tied together, say 8 ~ 8. or 4 ~ 10). (2) Beat unit unchanged, but bpm changed to a multiple of previous value (e.g. tempo doppio, etc.). (3) New beat unit tempo equal to a multiple of a beat unit in previous music. Simple case here is e.g. half-note tempo = previous quarter-note tempo, i.e. 4 = 2 or 2 = 4 depending on what way you want to write it), but it could also involve much more complicated beat units as already described in (1); e.g. 8 ~ 8. = 4, or 10 = 12, or, ... ... each with corresponding metronome mark indicators. Ideally the Lilypond tempo syntax would allow for all of the above kinds of tempo change. Does it currently? And is it possible to imagine a practical syntax that allows for this? ___ 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
Hello, On 23 September 2012 04:29, David Kastrup d...@gnu.org wrote: Jay Anderson horndud...@gmail.com writes: On Sat, Sep 22, 2012 at 3:07 PM, Graham Percival gra...@percival-music.ca wrote: I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the text parts of the existing \tempo command (if they don't already exist, which they probably do). Please keep \mark and \tempo separate. They serve different purposes, Only to some degree. align differently with the music, and it's a pain to put multiple marks in one place. I doubt that the ultimate solution to the problem \mark is far too limited and restricted is let's add another far too limited and restricted command. - \tempoText Allegro - \tempoBpm 4=100 - \tempoTextBpm Allegro 4=100 - \tempoEquation 4=2 %%% print quarter note = half note - \tempoTextEquation Lo stesso tempo 4=2 Even easier: \tempoBpm can take a string instead (e.g. \tempoBpm 4=100) which it internally parses and throws an error if it doesn't like what it sees. At that point it could be 100% scheme instead of at the parser level. The possible downside is we'd have a mini language for this function, but I don't think that's too bad. I don't really like the artificiality of additional string parsers. It divides LilyPond into areas with supported and those with unsupported syntax. For me, it makes far more sense to only work with consistent supported syntax, and make sure that this is expressive enough not to be an onerous restriction. Coming at this from a different angle, for \header blocks I often use multiple 'variables' to get my fonts and sizes just right title = \markup { \override #'(font-name . Palatino) \abs-fontsize #24 This is My Tune } couldn't we do something similar with \tempo in that we simply ('simply'!) have a 'top level' \tempo command and then whatever we need to specify if it needs a markup and/or a timing? \tempo { \markup { some value } \bpm {another value} \metronome_mark {yet another value} } or something like that ... Sorry if I have missed a point. james ___ 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
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: Step back for a second and consider the variants you might want in a tempo change: (1) specified beat unit has a particular number of bpm. Your beat unit may not be limited to a typical unit like a quarter- or eighth-note, but might be a 5th, 6th, 10th or 12th note (i.e. quintuplet or triplet quarter or eighth), or it might be a combination of note values (e.g. two note values tied together, say 8 ~ 8. or 4 ~ 10). (2) Beat unit unchanged, but bpm changed to a multiple of previous value (e.g. tempo doppio, etc.). (3) New beat unit tempo equal to a multiple of a beat unit in previous music. Simple case here is e.g. half-note tempo = previous quarter-note tempo, i.e. 4 = 2 or 2 = 4 depending on what way you want to write it), but it could also involve much more complicated beat units as already described in (1); e.g. 8 ~ 8. = 4, or 10 = 12, or, ... With the separately discussed isolated durations are pitch-less NoteEvent in noteentry, you could use arguments like { 8 ~ 8. } = { 4 } and such music arguments would get passed through a \score markup using a specific TempoStaff without stafflines and with nice dimensions, also allowing for specs like \tempo \times 2/3 { 4 8 } = 64 Basically, one would have to vary the typesetting depending on whether the right side contains a number or music, assuming music on the left side, and measuring out the lengths of the music. Ideally the Lilypond tempo syntax would allow for all of the above kinds of tempo change. Does it currently? And is it possible to imagine a practical syntax that allows for this? The equals sign might come into play at some later point of time, and tempo _ranges_ are not really something I see fitting well. -- David Kastrup ___ 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
Graham Percival graham at percival-music.ca writes: Although mathematicians and programmers are quite comfortable with contains with 0 items inside them, this is not a particularly intuitive concept (just look at the concept of zero in the history of mathematics!) Well, the concept and language for an empty basket was used in place of a basket with zero apples. It seems that positional numbering systems first required placeholders, in order to write 302 as 3_2, and then people eventually started thinking of empty as just another number. That history would seem to favor the empty chord, , over a name for the abstract concept of zero notes, z. But if anyone is willing to do the programming we can have both. This would allow people to write either: { c'1\ \! } { c'1\ z\! } The non-timed null event z would be inserted after the previous note (the c'1) is finished. I avoided s1*0 (maybe I subconsciously felt it was cheating) but find extremely useful and use it a lot. \pp^pizz. \repeat unfold 3 c'4 A vaguely-related idea [...] \new Voice { { c'1 } { s4\ s s\ s\! } } \new Voice { c'1 y4\ y y\ y\! } I've been thinking about this and trying it out (just pretending LilyPond would accept what I typed) and don't recommend it. The refined version c'1 -{y2\ y\ \!} is easier to read within a string of music, but not any better than c'1 {s2\ s\ \!} so I don't think it worth learning the extra concept, if we did take the time to implement it. ___ 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 Fri, Sep 14, 2012 at 12:00:49AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: How about considering how they are supposed to translate to and from Scheme? Woah. Is the syntax supposed to support translating from scheme to .ly ?! Reality check. Everything you do needs a representation in Scheme. Of course. I'm questioning your to and **from** sentence (emphasis added). Basically, if we have A:= c4-\something{ s4\ s s\!\ s\! } B:= c4 {s4\ s s\!\ s\!} C:= some scheme we already have an unambiguous translation from B-C. If we have an unambiguous translation from A-B (by assumption), then we have an unambiguous translation from A-C. This part works (again, with the assumption of A-B). However, we clearly do not have a translation C-A vs. C-B. Is this a problem? Do we need to transate **from** scheme to a *particular* bit of ly language? I'm not fond of prefix functions; that's why I didn't care for your \at function. LilyPond does not have anything but prefix functions. Event functions don't get to see the preceding expression as an argument: they just get attached to them when LilyPond sweeps up the whole kaboodle, but they don't get to operate on them. It is rather the job of the preceding expression itself to collect them usefully, so that is again a prefix operation. So the fact that in c4\p d4 the \p applies to the c4 is due to the design of the c4 expression? Take a look at the \tempo command. Everybody and their dog tells me that this is just what a musician wants in syntax. Whenever I do significant work on the parser, \tempo pitches in with a few dozen reduce/reduce errors and takes an hour of extra time. I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the text parts of the existing \tempo command (if they don't already exist, which they probably do). - Graham ___ 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 Sat, Sep 22, 2012 at 3:07 PM, Graham Percival gra...@percival-music.ca wrote: I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the text parts of the existing \tempo command (if they don't already exist, which they probably do). Please keep \mark and \tempo separate. They serve different purposes, align differently with the music, and it's a pain to put multiple marks in one place. I think having multiple tempo commands would be fine if it simplified the parser (with whatever capitalization you like): - \tempoText Allegro - \tempoBpm 4=100 - \tempoTextBpm Allegro 4=100 - \tempoEquation 4=2 %%% print quarter note = half note - \tempoTextEquation Lo stesso tempo 4=2 Even easier: \tempoBpm can take a string instead (e.g. \tempoBpm 4=100) which it internally parses and throws an error if it doesn't like what it sees. At that point it could be 100% scheme instead of at the parser level. The possible downside is we'd have a mini language for this function, but I don't think that's too bad. tempoBpm = #(define-music-function (parser location text) (string?) (let* ((eq-index (string-contains text =)) (parsed (log2 (string-number (string-trim (substring text 0 eq-index) (base (make-note-by-number-markup parsed 0 1)) (bpm (string-trim (substring text (+ 1 eq-index (markup #{ \markup { \normal-text { \smaller $base = $bpm } } #})) #{ \tempo $markup #})) Obviously this would need to be expanded to handle errors, parse what we currently support, and generate the midi tempo change. Would this help clean things up with the tempo command? -Jay ___ 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
Jay Anderson horndud...@gmail.com writes: On Sat, Sep 22, 2012 at 3:07 PM, Graham Percival gra...@percival-music.ca wrote: I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the text parts of the existing \tempo command (if they don't already exist, which they probably do). Please keep \mark and \tempo separate. They serve different purposes, Only to some degree. align differently with the music, and it's a pain to put multiple marks in one place. I doubt that the ultimate solution to the problem \mark is far too limited and restricted is let's add another far too limited and restricted command. - \tempoText Allegro - \tempoBpm 4=100 - \tempoTextBpm Allegro 4=100 - \tempoEquation 4=2 %%% print quarter note = half note - \tempoTextEquation Lo stesso tempo 4=2 Even easier: \tempoBpm can take a string instead (e.g. \tempoBpm 4=100) which it internally parses and throws an error if it doesn't like what it sees. At that point it could be 100% scheme instead of at the parser level. The possible downside is we'd have a mini language for this function, but I don't think that's too bad. I don't really like the artificiality of additional string parsers. It divides LilyPond into areas with supported and those with unsupported syntax. For me, it makes far more sense to only work with consistent supported syntax, and make sure that this is expressive enough not to be an onerous restriction. As I said: I have not yet tackled this actively since at least the equals sign may still become part of the universe supported by music functions. -- David Kastrup ___ 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 13/09/12 08:11, David Kastrup wrote: If it does, so does c'1 { s4 s\ s2 s\! } Stepping back from syntax for a second, the problem with the above (as currently implemented) is that the spacing will not produce correct output from a visual engraving point of view. This applies also to articulations, ornamentations, etc. which do not fall exactly on the note. Consider e.g. c'4 c'4\turn { c'2 } { s4 s4^\turn } Now, what you _want_ here is that the spacing for the final c'2 to be such that it's clear that the \turn falls on the second quarter. That means that the spacing of the c'2 probably needs to be larger than it would be otherwise, and the \turn needs to fall halfway through that space. What you actually _get_ is that the spacing of c'2 is entirely unaffected, and the \turn falls in a location just to the right of the note-stem which makes it look as if it's been accidentally placed a bit off. AFAICS this happens because Lilypond considers skip elements s to be irrelevant for spacing purposes. The same applies to your example with the crescendo starting on the 2nd beat of the c'1. You don't get sufficient horizontal spacing following the note to be able to appreciate the nuances of the hairpin's placement: in practice, it would most likely be read as starting on the note itself. Further, the quarter-beat positions do not fall evenly in that horizontal space, so if you have e.g. a \ \ on the same note, it may look like one is longer than the other. Try e.g.: { c'1 } { s4 s\ s\ s\ s\! } ... where each of the hairpins should last one quarter-beat, but actually they are all of different horizontal widths, and the \ could easily be mistaken for an accent. So to me, the problem is not with the existing syntax per se, but the fact that the existing syntax _doesn't produce the desired output_ and needs lots of complicated tweaks to get right. ___ 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
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 13/09/12 08:11, David Kastrup wrote: If it does, so does c'1 { s4 s\ s2 s\! } Stepping back from syntax for a second, Let's keep that in mind. the problem with the above (as currently implemented) is that the spacing will not produce correct output from a visual engraving point of view. This applies also to articulations, ornamentations, etc. which do not fall exactly on the note. Consider e.g. c'4 c'4\turn { c'2 } { s4 s4^\turn } Now, what you _want_ here is that the spacing for the final c'2 to be such that it's clear that the \turn falls on the second quarter. That means that the spacing of the c'2 probably needs to be larger than it would be otherwise, and the \turn needs to fall halfway through that space. What you actually _get_ is that the spacing of c'2 is entirely unaffected, and the \turn falls in a location just to the right of the note-stem which makes it look as if it's been accidentally placed a bit off. So what would be required here seemingly would be linearization of the spacing in absence of note columns which convey proper timing through their note values, however non-linearly spaced. AFAICS this happens because Lilypond considers skip elements s to be irrelevant for spacing purposes. The same applies to your example with the crescendo starting on the 2nd beat of the c'1. You don't get sufficient horizontal spacing following the note to be able to appreciate the nuances of the hairpin's placement: in practice, it would most likely be read as starting on the note itself. Further, the quarter-beat positions do not fall evenly in that horizontal space, so if you have e.g. a \ \ on the same note, it may look like one is longer than the other. Try e.g.: { c'1 } { s4 s\ s\ s\ s\! } ... where each of the hairpins should last one quarter-beat, but actually they are all of different horizontal widths, and the \ could easily be mistaken for an accent. So to me, the problem is not with the existing syntax per se, but the fact that the existing syntax _doesn't produce the desired output_ and needs lots of complicated tweaks to get right. I would not say the problem is not with the existing syntax since that is what people were concerned with. However, I don't see that a different syntax would warrant different resulting music expressions here, so regardless of how the input looks, it would seem that our backend does not cope well in the resulting spacing currently. Bug squad, do we have an issue with that already? -- David Kastrup ___ 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 17/09/12 13:38, David Kastrup wrote: So what would be required here seemingly would be linearization of the spacing in absence of note columns which convey proper timing through their note values, however non-linearly spaced. Actually, this is an interesting question for people to examine in scores -- when you have cresc/decresc etc. like this in one part, is it more normal to synch the horizontal placing of the hairpins with rhythms in other parts, or to just have even horizontal spacing? Doesn't seem a trivial question, as what may seem theoretically logical (space with surrounding musical material) may not actually work in practice for a conductor. (Obviously without other musical events taking place in parallel, the spacing needs to be even, or proportional to whatever lengths are involved.) It might also be worth reconsidering minimum lengths of hairpins. This is tricky anyway particularly as minimum length can include preceding dynamic marks -- really, there needs to be a minimum length for the hairpin itself regardless of any other dynamical elements. I would not say the problem is not with the existing syntax since that is what people were concerned with. However, I don't see that a different syntax would warrant different resulting music expressions here, so regardless of how the input looks, it would seem that our backend does not cope well in the resulting spacing currently. Well, I suppose there could be an issue in that by writing this kind of stuff with parallel musical events, {} {} , you miss an indication that certain events are associated with certain notes, and that might affect the ability of the backend to infer spacing. But while I think it's always good to have playful and creative discussions around any aspect of Lilypond, to me this seems a pretty good example of how syntax discussions need to be tempered by first defining the scope of musical notation that Lilypond is trying to address, and then detailing how well Lilypond addresses that notation, and _then_ identifying what syntax changes are necessary to correct problems. Here we have something where the existing syntax really isn't bad, but even better syntax won't address the really extant problem. ___ 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
Werner LEMBERG w...@gnu.org writes: \tempo does not have optional arguments but rather several quite different forms of argument lists, and then some rather weird form of numeric range echoed nowhere else in the syntax. BTW, could you suggest a better syntax for \tempo which looks similar to the current definition, but avoiding the problems? The markup-only variant could just be \tempoMarkup markup The Midi variant could likely be \tempo [optional markup] duration number-or-number-pair This is a syntax that should work fine currently. A number-pair can be entered as #'(50 . 56) or 50/56 currently. I don't fancy 50~56 just for the sake of \tempo. I am not proposing a current change since supporting functions that can be used to the left of an equals sign is a change that I have scheduled for implementation, and it _might_ offer itself for \tempo [optional markup] duration = number-or-number-pair syntax. This would, however, not relieve the necessity for a separate markup-only function, and it would be a somewhat awkward use for the feature since a standalone \tempo [optional markup] duration would not make independent sense. -- David Kastrup ___ 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
\tempo does not have optional arguments but rather several quite different forms of argument lists, and then some rather weird form of numeric range echoed nowhere else in the syntax. BTW, could you suggest a better syntax for \tempo which looks similar to the current definition, but avoiding the problems? Using \tempo as an excuse to make syntax everywhere else more cumbersome is letting it doing even more unwarranted damage. I fully agree. Werner ___ 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 Thu, Sep 13, 2012 at 11:39:52PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I think we need to decide what direction we want the syntax to move in (or indeed, decide not to change the syntax at all!). I don't see the point in the repeated threats of locking me out from what I am working on. You have a fundamental misunderstanding of these discussions. The intent is to share ideas, not to bring forward formal proposals for language modifications. Yes, of course a shared project would be much easier with a benevolent dictator. The only alternative I see so far is a benevolent slave. Nobody is working on syntax right now except me. And nobody is interested in working on it except me. Instead people are interested in telling me what I should be doing. You are not a slave. Nobody is telling you what you should be doing. Nobody is demanding that you take these discussions seriously -- in fact, I have repeatedly told you *not* to take them seriously! However, other than a few specific instances (such as the stable/2.16 branch), I don't think that we *want* benevolent dictators. A number of people want to discuss syntax possibilities. Where is the point in blind people voting on the color of the sky? We're not voting. We *won't* be voting. Besides, we haven't even seen a single serious proposal yet! (other than ideas from you and Han-Wen, maybe. Although I seriously think that ligature should be placed the same way as slurs and beams, I have not yet submitted a formal proposal to this effect.) Most of those other ideas are unworkable, but until we examine each idea, we won't know if it is actually workable or not. Wrong. Until _I_ examine each idea, you won't know if it is actually workable or not. Most of the ideas are unworkable from the standpoint of unambiguous notation of music. If a human can't understand what the syntax means, then of course a computer can't understand it! - Graham ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 11:39:52PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I think we need to decide what direction we want the syntax to move in (or indeed, decide not to change the syntax at all!). I don't see the point in the repeated threats of locking me out from what I am working on. You have a fundamental misunderstanding of these discussions. The intent is to share ideas, not to bring forward formal proposals for language modifications. decide not to change the syntax at all means stopping me from working on the parser. I am doing my best within the existing possibilities of staying upwards compatible, but no change at all means just that, unwanted side effects and all. Yes, of course a shared project would be much easier with a benevolent dictator. The only alternative I see so far is a benevolent slave. Nobody is working on syntax right now except me. And nobody is interested in working on it except me. Instead people are interested in telling me what I should be doing. You are not a slave. Nobody is telling you what you should be doing. Nobody is demanding that you take these discussions seriously -- in fact, I have repeatedly told you *not* to take them seriously! If you state that one possible goal is to decide no further changes will be allowed, and if statements like I think we need to decide are coming from the project leader, it is pretty strange to say I should not be taking them seriously. Most of the ideas are unworkable from the standpoint of unambiguous notation of music. If a human can't understand what the syntax means, then of course a computer can't understand it! But if a human can't understand that he can't understand what the syntax means, he will try to persuade the computer otherwise, and at some point of time, people will have a heap of workarounds to maintain that do not make for a consistent whole. The usual approach in the backend is to heap exceptions upon exceptions until the result is more often than not aesthetically pleasing. And given the problem space, that approach is not, in itself, wrong as long as the infrastructure supports this approach since the overall goal is a complex aesthetic one that is fuzzily defined. This approach does not work with input syntax. Not if we want to give users the tools required for extending LilyPond for their own purposes, and we want to give them the tools since it means that we also get a workforce of people helping with extending and maintaining the version of LilyPond we distribute. The extend in arbitrary ways to the point of breakage approach works with a fixed, closed, hard-wired syntax, making LilyPond fixed, closed, and hard-wired. And that is short-selling its capabilities. -- David Kastrup ___ 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
Werner LEMBERG w...@gnu.org 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 } -- David Kastrup ___ 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
c'1-{ s4 s\ s2 z\! } This looks nice. No idea whether it works, but something into this directions looks right. Werner ___ 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
c'1-{ s4 s\ s2 z\! } c-d-. Which one gets the accent? What should `c-d' mean? AFAIK, there is only one `anchor', namely the note pitch (which would be `c' in your example). A pitch attached to a pitch doesn't make sense to me. If you provide counterexamples, which is good, please illustrate them a bit more for us mere mortals not acquainted with the intricacies of the parser and lexer. I rather suggest to handle the -{ ... } construct specially, for example, to allow only `s' and Graham's proposed `z', together with constructions which work like articulations. Werner ___ 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
I rather suggest to handle the -{ ... } construct specially, for example, to allow only `s' and Graham's proposed `z', together with constructions which work like articulations. Actually, if we have -{ ... }, we don't need `z' at all: c'1-{ s4 s\ s2 s\! } fully does the job, by registering the fact that a final `s' comes at a moment which is equal the anchor's duration (sloppily formulated). Werner ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 07:18:50AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Here's a few imaginary ways of writing the same music: \at 4 \ \at 1 \! c'1 c'1 y4 y\ y z\! c'1- y4 y\ y z\! c'1-{ s4 s\ s2 z\! } Out of these, I'm most comfortable with the last one. c-d-. Which one gets the accent? Neither; lilypond exits with an error because there's no explicit -{} and because there's a pitch within the extra timed events portion. Why do we need an explicit -{}? What with c-{ d e }-. How long is this construct in music? Which one gets the accent? How is this clearer than c-. { d e } ? Can I write { d e }-c ? If not, why not? Why is this not symmetric? Can I write { d e }-c-. ? The idea is to line up cresc/dynamics/etc that occur within a note (or chord), not to replace the current method of writing multiple voices. You are confusing multiple voices with parallel music.does not (without \\) introduce parallel voices. It is just a reasonably transparent way of arranging time within a voice. You want to replace this reasonably transparent way with something messing around with post-event syntax which is bad enough on its own. That's awful since it a) obfuscates the fact that parallel music has the same level of priority b) does not at all correspond to the logical structure of music and thus can't be reasonably translated into MusicXML or even LilyPond's own Music expressions. -- David Kastrup ___ 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
Werner LEMBERG w...@gnu.org writes: I rather suggest to handle the -{ ... } construct specially, for example, to allow only `s' and Graham's proposed `z', together with constructions which work like articulations. Actually, if we have -{ ... }, we don't need `z' at all: c'1-{ s4 s\ s2 s\! } fully does the job, by registering the fact that a final `s' comes at a moment which is equal the anchor's duration (sloppily formulated). If it does, so does c'1 { s4 s\ s2 s\! } Or are you planning to limit the total visible duration of the construct (in your case 3/2) to the base? So what happens with c'1-{ s4 s\ s1 s\! } c4 c4 ? Does the crescendo end far after the following quarter notes? -- David Kastrup ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 07:29:35AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: With that view (which is evidently not universal), it seems natural to me to write the pitch and duration first, and then all the other special bits that occur on or around that note. Like c\clef treble\time 3/2 ? No, because the clef and time signature comes before the first note. How about \tempo? That comes _at_ the first note. All other things equal, horizontally left notation in a score should be horizontally left in a .ly file. You mean, when collision avoidance shifts fingerings left, those should be written before the note? Above, I'm talking about reading a series of events which are aligned vertically at the same horizontal position. So what's with \tempo? -- David Kastrup ___ 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
Actually, if we have -{ ... }, we don't need `z' at all: c'1-{ s4 s\ s2 s\! } fully does the job, by registering the fact that a final `s' comes at a moment which is equal the anchor's duration (sloppily formulated). If it does, so does c'1 { s4 s\ s2 s\! } Yes. Or are you planning to limit the total visible duration of the construct to the base? Yes. (in your case 3/2) No. The `base' note has a length of 1/1. So what happens with c'1-{ s4 s\ s1 s\! } c4 c4 ? Does the crescendo end far after the following quarter notes? No, my idea is that everything `longer' than the base not gets ignored (causing a warning). I know that we are talking about syntactical sugar. What Graham suggests can be always written with ... constructs. However, I share his feeling that many people (including me) are quite uncomfortable with using parallel music for attaching a crescendo to a note. Actually, for complicated situations, ... is certainly more appropriate, but for simple cases I want a simpler notation. Werner ___ 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
Werner LEMBERG w...@gnu.org writes: Actually, if we have -{ ... }, we don't need `z' at all: c'1-{ s4 s\ s2 s\! } fully does the job, by registering the fact that a final `s' comes at a moment which is equal the anchor's duration (sloppily formulated). If it does, so does c'1 { s4 s\ s2 s\! } Yes. Or are you planning to limit the total visible duration of the construct to the base? Yes. (in your case 3/2) No. The `base' note has a length of 1/1. s4 + s4 + s2 + s2 is 3/2. You are asking for the last 1/2 to be silently ignored, as opposed to what you want below: So what happens with c'1-{ s4 s\ s1 s\! } c4 c4 ? Does the crescendo end far after the following quarter notes? No, my idea is that everything `longer' than the base not gets ignored (causing a warning). Except when you think they should not cause a warning. I know that we are talking about syntactical sugar. The association to cavities is hard to avoid... What Graham suggests can be always written with ... constructs. However, I share his feeling that many people (including me) are quite uncomfortable with using parallel music for attaching a crescendo to a note. Actually, for complicated situations, ... is certainly more appropriate, but for simple cases I want a simpler notation. But the notation is not actually simpler at all, and it abuses existing constructs. It is exactly the sort of thing that makes LilyPond unsuitable as a reusable representation for music rather than a write-only format that only humans and LilyPond itself can hope to understand, if they are lucky. It would not have a reasonable Scheme representation as Music expressions. I am working hard to get expressions like { s4 s\ s1 s\! } parseable and recognizable without context, and obliterate the need to write - for anything except accent shorthands. This is pretty much unavoidable if you want to get music functions and other expressions to behave consistently and independently from how the results of calling them are going to be used. One intermediate result is that our Scheme tutorial these days says something like 2.8 Inline Scheme code == TODO: the example for this section is ill-chosen since F = -\tweak #'font-size #-3 -\flageolet (note the `-' marking it as a post event) will actually work fine for the stated purpose. Until this section gets a rewrite, let's pretend we don't know. The main disadvantage of `\tweak' is its syntactical inflexibility. For example, the following produces a syntax error. F = \tweak #'font-size #-3 -\flageolet \relative c'' { c4^\F c4_\F } Using Scheme, this problem can be avoided. And the initial TODO stating that the example is ill-chosen is _doubly_ inaccurate since indeed, not even For example, the following produces a syntax error is true any more. It just works as expected. And I am getting the code where even writing c4\tweak #'font-size #-3 \flageolet without any spurious - signs will work since the post-event property of \flageolet will transparently pass through. But to make things work in that natural manner, I need a consistency between how expressions are written and what they mean. This sort of let's throw a few existing elements into the blender and let them mean something almost, but not quite, entirely different, when combined in a particular manner approach is absolute poison for being able to create syntactic elements that can be reliably interpreted, translated and combined with a straightforward relation between input, meaningful content (which is required for MusicXML export, for example), and output. It will still take some time until I have the parser where it provides the consistency and power I am striving for with all of the ultimately unnecessary complexity driven out, and then it will be quite more infeasible on a technical level to sabotage the existing framework because it would be much more obvious what sort of things are a bad match to then existing facilities and a cause for major usability regressions. And it will be much less stressful for me to be able to state you can't have that because it would break what we have, just try for yourselves rather than having to state it is a bad idea to do that since it would stop me from getting us where I see us wanting to go. Yes, locking others away in a fuzzy discussion list and hoping that they won't manage work out the details of something which they then will want to see implemented might take away some of that stress. And then saying something like uh, that is hard, I don't think it could be done. Which probably would be a lie since if you disregard priorities and sanity, most things can be done. The problem is that there is always a price to pay, and in some cases the price is on the ability to do work that is ultimately quite more important, and on the complexity and maintainability of the results.
Re: [GLISS] non-timed or non-musical events z y
On Thu, Sep 13, 2012 at 12:37:00PM +0200, David Kastrup wrote: Werner LEMBERG w...@gnu.org writes: Actually, if we have -{ ... }, we don't need `z' at all: c'1-{ s4 s\ s2 s\! } This is a little bit unclear, since the final s\! would have the same duration as the previous s2, and thus would go over the duration limit of 1. I think there's still a need for a event after the previous duration, i.e. c'1-{ s4 s\ s2 \! } c'1-{ s4 s\ s2 z\! } (in your case 3/2) No. The `base' note has a length of 1/1. s4 + s4 + s2 + s2 is 3/2. You are asking for the last 1/2 to be silently ignored, as opposed to what you want below: Not silently; if the duration exceeds the base note, there should be an error (or possibly merely a warning, like a barcheck warning). No, my idea is that everything `longer' than the base not gets ignored (causing a warning). Except when you think they should not cause a warning. This was due to the how do we anchor an event after a duration problem. I know that we are talking about syntactical sugar. The association to cavities is hard to avoid... Please avoid snarky comments in this discussion. Avoiding all sugar would have us writing music directly in scheme; the amount of sugar used is a matter of degree, not an absolute yes/no. What Graham suggests can be always written with ... constructs. However, I share his feeling that many people (including me) are quite uncomfortable with using parallel music for attaching a crescendo to a note. Actually, for complicated situations, ... is certainly more appropriate, but for simple cases I want a simpler notation. But the notation is not actually simpler at all, and it abuses existing constructs. ok, it could be something else instead, c'1- s4 s\ s2 z\! c'1- s4 s\ s2 z\! c'1-{{ s4 s\ s2 z\! }} c'1\at{ s4 s\ s2 z\! } c'1\extra{ s4 s\ s2 z\! } It is exactly the sort of thing that makes LilyPond unsuitable as a reusable representation for music rather than a write-only format that only humans and LilyPond itself can hope to understand, if they are lucky. It would not have a reasonable Scheme representation as Music expressions. I don't follow this. If we can produce an unambiguous expansion of c'1- s4 s\ s2 z\! into { c'1 } { s4 s\ s2 z\! } then surely it can be expressed as music functions. (NB: before the expansion, we give an error if there's any pitch-notes within the condensed version, so by assumption the expansion will only have s or z/ constructs) I know that you are not convinced that this can be done unambiguously, but that's what we're talking about. - Graham ___ 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
Graham Percival gra...@percival-music.ca writes: I don't follow this. If we can produce an unambiguous expansion of c'1- s4 s\ s2 z\! into { c'1 } { s4 s\ s2 z\! } then surely it can be expressed as music functions. \displayLilyMusic would have no chance reconstructing the input. The meaning of - here is quite different to normal usage, there is no really meaningful interpretation to things like c'1- s4 s\ s2 z\! -. as opposed to the normal alliterative meaning of accents, there is no sensible interpretation to x = - s4 s\ s2 z\! in an assignment, or in a use as a music argument. This is a quantum leap backwards in making LilyPond and Scheme expressions and variables and functions and arguments in the parser work and combine in a predictable manner. I am working hard on stopping the Scheme layer from being something entirely different and interacting in unpredictable ways with LilyPond depending on where variables and function arguments start and end. I really don't get why people are keen on destroying all progress we have made regarding a straightforward relation between Scheme and LilyPond. I know that you are not convinced that this can be done unambiguously, but that's what we're talking about. Given the respective levels of work, expertise and planning invested in the parser, I would wish for a modicum more of listening accompanying the talking. -- David Kastrup ___ 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
I think there's still a need for a event after the previous duration, i.e. c'1-{ s4 s\ s2 \! } c'1-{ s4 s\ s2 z\! } Mhmm. If we have anchor-{ skip1 skip2 ... skipn skipx } with duration(skip1) + duration(skip2) + ... duration(skipn) = duration(anchor) then skipx can have an arbitrary duration, which is ignored, and only its post-event is taken into account. I really don't see an immediate need for `z'. It would only make sense to introduce `z' if there are other situations to use it. c'1\at{ s4 s\ s2 z\! } This looks like being possible to realize with a music function... Actually, this would satisfy my syntax sugar needs. Werner ___ 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
[...] This is a quantum leap backwards in making LilyPond and Scheme expressions and variables and functions and arguments in the parser work and combine in a predictable manner. I am working hard on stopping the Scheme layer from being something entirely different and interacting in unpredictable ways with LilyPond depending on where variables and function arguments start and end. I really don't get why people are keen on destroying all progress we have made regarding a straightforward relation between Scheme and LilyPond. David, please relax. I've typeset hundreds of pages with lilypond, including complicated piano and organ music; I don't lightly suggest syntactic stuff just to annoy you. Graham's and my suggestions are very restrictive, and we are just playing around with possible syntax forms. It would be tremendously helpful if you can show possible syntax *alternatives* instead of just pretending to be a naysayer. Werner ___ 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
Werner LEMBERG w...@gnu.org writes: [...] This is a quantum leap backwards in making LilyPond and Scheme expressions and variables and functions and arguments in the parser work and combine in a predictable manner. I am working hard on stopping the Scheme layer from being something entirely different and interacting in unpredictable ways with LilyPond depending on where variables and function arguments start and end. I really don't get why people are keen on destroying all progress we have made regarding a straightforward relation between Scheme and LilyPond. David, please relax. I've typeset hundreds of pages with lilypond, including complicated piano and organ music; I don't lightly suggest syntactic stuff just to annoy you. We are getting most certainly nowhere if people don't even bother understanding the technical points of my replies. They get no followup, and the next proposal coming up is not any more suitable for pretty much the same reasons. Graham's and my suggestions are very restrictive, and we are just playing around with possible syntax forms. How about considering how they are supposed to translate to and from Scheme? 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. They would definitely simplify the kind of entry you are asking for. However, nobody can be interested in them since they don't necessitate parser changes. -- David Kastrup ___ 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 Thu, Sep 13, 2012 at 12:37:00PM +0200, David Kastrup wrote: I am working hard to get expressions like { s4 s\ s1 s\! } parseable and recognizable without context, and obliterate the need to write - for anything except accent shorthands. This is pretty much unavoidable if you want to get music functions and other expressions to behave consistently and independently from how the results of calling them are going to be used. I'm afraid that I don't follow this paragraph. Other than simplifying the parser/lexer code (which is of course a good goal unto itself), why do we want to avoid writing - for anything except accent shorthands, and why do we want music functions to behave independently from how the results of calling them are going to be used? (other than the below example) One intermediate result is that our Scheme tutorial these days says something like 2.8 Inline Scheme code == TODO: the example for this section is ill-chosen since F = -\tweak #'font-size #-3 -\flageolet (note the `-' marking it as a post event) will actually work fine for the stated purpose. Until this section gets a rewrite, let's pretend we don't know. The main disadvantage of `\tweak' is its syntactical inflexibility. For example, the following produces a syntax error. F = \tweak #'font-size #-3 -\flageolet \relative c'' { c4^\F c4_\F } Using Scheme, this problem can be avoided. And the initial TODO stating that the example is ill-chosen is _doubly_ inaccurate since indeed, not even For example, the following produces a syntax error is true any more. It just works as expected. And I am getting the code where even writing c4\tweak #'font-size #-3 \flageolet without any spurious - signs will work since the post-event property of \flageolet will transparently pass through. But to make things work in that natural manner, I need a consistency between how expressions are written and what they mean. I don't see the big deal here. As you know, I would like to let people distinguish whether commands affect the previous or subsequent note without having to memorize all the commands. So I would actually *prefer* to see c4-\flageolet c4\tweak #'font-size #-3 -\flageolet instead of c4\flageolet c4\tweak #'font-size #-3 \flageolet I think we need to decide what direction we want the syntax to move in (or indeed, decide not to change the syntax at all!). It will still take some time until I have the parser where it provides the consistency and power I am striving for with all of the ultimately unnecessary complexity driven out, and then it will be quite more infeasible on a technical level to sabotage the existing framework because it would be much more obvious what sort of things are a bad match to then existing facilities and a cause for major usability regressions. That's actually why I think we need to discuss these things now. As far as I understand it, you are moving in the direction of using \commands for almost everything. Some of those \commands affect the previous note; others affect the next note. That lack of consistency makes it harder for users to learn and use lilypond. Is this the direction we want to move in? Maybe yes, maybe no. I think we need to discuss the possible alternatives, weigh the advantages and disadvantages of them, and *then* decide whether we want to move to everything being \commands. And it will be much less stressful for me to be able to state you can't have that because it would break what we have, just try for yourselves rather than having to state it is a bad idea to do that since it would stop me from getting us where I see us wanting to go. Yes, of course a shared project would be much easier with a benevolent dictator. However, other than a few specific instances (such as the stable/2.16 branch), I don't think that we *want* benevolent dictators. A number of people want to discuss syntax possibilities. I am not at all certain that I agree with where you see us wanting to go. I *am* certain that I, and many others, have ideas which do not agree with where you see us wanting to go. Most of those other ideas are unworkable, but until we examine each idea, we won't know if it is actually workable or not. - Graham ___ 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 Thu, Sep 13, 2012 at 08:56:26PM +0200, David Kastrup wrote: Graham's and my suggestions are very restrictive, and we are just playing around with possible syntax forms. How about considering how they are supposed to translate to and from Scheme? Woah. Is the syntax supposed to support translating from scheme to .ly ?! I honestly had no idea that this was an overall goal. I'm not being snarky; I really had no clue. That would, of course, change things drastically. In particular, it would sink the easy implementation[1] of the -{ s4 ... } idea. [1] basically, do the translation -{ ...} as a one-directional pre-processor step; I could write a python program that would do the replacement before passing the .ly file to the main lilypond binary. If that's intended, then I should add it here: http://lilypond.org/~graham/gliss/gliss_1.html 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. They would definitely simplify the kind of entry you are asking for. However, nobody can be interested in them since they don't necessitate parser changes. I'm not fond of prefix functions; that's why I didn't care for your \at function. Now, if a music function can apply to the current note, i.e. c1-\at{ s4 s s\f s } then I'd be much happier. However, perhaps there's a larger issue here. Maybe it's time to follow the example of TeX and LaTeX -- we could create a pared-down, easily scheme-ly representation format (e.g., following David's plan (almost?) exactly). Then a separate group of people (me, Janek, etc) could define an additional format as a pre-processor step. That other format (ly2 ?) would have an unambiguous representation in ly, but we would not be concerned about going from ly to ly2. In terms of code sanity, the ly2ly (ok, it would need a better name than ly2 !) translator could be done in a completely separate language (python, scheme, whatever) and would create a .ly file in /tmp/, which is then processed by the usual lilypond parser. - Graham ___ 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
David, please relax. I've typeset hundreds of pages with lilypond, including complicated piano and organ music; I don't lightly suggest syntactic stuff just to annoy you. We are getting most certainly nowhere if people don't even bother understanding the technical points of my replies. I try. They get no followup, Because I don't know what to answer. It's beyond my knowledge. and the next proposal coming up is not any more suitable for pretty much the same reasons. This can happen, yes. Graham's and my suggestions are very restrictive, and we are just playing around with possible syntax forms. How about considering how they are supposed to translate to and from Scheme? This is the next step IMHO. Additionally, you are the doorman we have to pass :-) 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. Werner ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 08:56:26PM +0200, David Kastrup wrote: Graham's and my suggestions are very restrictive, and we are just playing around with possible syntax forms. How about considering how they are supposed to translate to and from Scheme? Woah. Is the syntax supposed to support translating from scheme to .ly ?! Reality check. Everything you do needs a representation in Scheme. I honestly had no idea that this was an overall goal. It is not a goal but a necessity. I'm not being snarky; I really had no clue. That would, of course, change things drastically. In particular, it would sink the easy implementation[1] of the -{ s4 ... } idea. [1] basically, do the translation -{ ...} as a one-directional pre-processor step; I could write a python program that would do the replacement before passing the .ly file to the main lilypond binary. Well, music functions are also basically preprocessing. However, preprocessing that mixes up the order of elements has quite funny consequences regarding the continuity of \relative, of chord repeats, of autochanging, of voice creation, part combining and so on, because that happens to a good degree at subsequent layers. Music functions are a reasonably transparent and predictable transformation. I'm not fond of prefix functions; that's why I didn't care for your \at function. LilyPond does not have anything but prefix functions. Event functions don't get to see the preceding expression as an argument: they just get attached to them when LilyPond sweeps up the whole kaboodle, but they don't get to operate on them. It is rather the job of the preceding expression itself to collect them usefully, so that is again a prefix operation. Now, if a music function can apply to the current note, i.e. c1-\at{ s4 s s\f s } then I'd be much happier. If functions look back and forth, and manipulate forwards and backwards, the resulting parser complexity, both programming it as well as understanding the results, will be horrendous. In terms of code sanity, the ly2ly (ok, it would need a better name than ly2 !) translator could be done in a completely separate language (python, scheme, whatever) and would create a .ly file in /tmp/, which is then processed by the usual lilypond parser. The difference is that LilyPond is a live, extensible and well-defined system. You don't need to mess with the language in order to create good shorthands for any given task. That does not mean that messing with the language is inappropriate for some things. Or impossible to do. Take a look at the \tempo command. Everybody and their dog tells me that this is just what a musician wants in syntax. Whenever I do significant work on the parser, \tempo pitches in with a few dozen reduce/reduce errors and takes an hour of extra time. Add a few dozen things musicians think the greatest thing since sliced bread, in the usual poke things with a stick until the regtests pass programming style popular among LilyPond programmers, and you may as well declare the syntax fixed. You won't be able to make progress without breaking more things than you can improve. I don't want to go there. But every single step down the slippery slope may seem doable if you don't think too hard about it. -- David Kastrup ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 12:37:00PM +0200, David Kastrup wrote: I am working hard to get expressions like { s4 s\ s1 s\! } parseable and recognizable without context, and obliterate the need to write - for anything except accent shorthands. This is pretty much unavoidable if you want to get music functions and other expressions to behave consistently and independently from how the results of calling them are going to be used. I'm afraid that I don't follow this paragraph. Other than simplifying the parser/lexer code (which is of course a good goal unto itself), why do we want to avoid writing - for anything except accent shorthands, and why do we want music functions to behave independently from how the results of calling them are going to be used? Because music functions are used to transform expressions. Functions like \tweak operate on their arguments, and the arguments don't change their character. So it does not make sense to have to remember to redeclare the type of the expression again and again syntactically just because a music function has been used to operate on it or generate it. Everybody gives me hell when I write documentation passages like Remember when using xxx, you will have to place @code{-} explicitly before it when it is used as a post-event, just like you have to do with @code{\tweak}. I get shit for all that technobabble and nonsensical restrictions, yet when I work on making that kind of awkwardness go away, people tell me that it is not a big deal and they would rather throw everything accomplished so far away in order to let some random juxtaposition of existing syntax elements mean something that they could consider their personal handwriting in the parser. (other than the below example) Because when I bring up actual examples, they don't count. Or what? And the initial TODO stating that the example is ill-chosen is _doubly_ inaccurate since indeed, not even For example, the following produces a syntax error is true any more. It just works as expected. And I am getting the code where even writing c4\tweak #'font-size #-3 \flageolet without any spurious - signs will work since the post-event property of \flageolet will transparently pass through. But to make things work in that natural manner, I need a consistency between how expressions are written and what they mean. I don't see the big deal here. Sure. Making problems go away that previously required using Scheme, to a degree that nobody can even think of a good tutorial-level problem that would still require actually meddling with Scheme: no big deal. Who is interested in that sort of stuff anyway? As you know, I would like to let people distinguish whether commands affect the previous or subsequent note without having to memorize all the commands. So I would actually *prefer* to see c4-\flageolet c4\tweak #'font-size #-3 -\flageolet instead of c4\flageolet c4\tweak #'font-size #-3 \flageolet But c4\tweak #'font-size #-3 -\flageolet does not work (yet), and you want to require - signs where the version without - sign does not even have any useful different interpretation. Where is the point? If you pass expressions through music functions or variables, they won't remember the way they came about. They will just remember their value. And Scheme expressions also don't remember anything but their value, so the value must include the type. LilyPond is based on a dynamically typed language, and on dynamically typed expressions, and if we are going to pass information in and out of Scheme, everything not tied into the expressions but rather to the way of using them is going to cause inconsistencies and hard to remember artifacts. You don't see the big deal here. Which is why I am working on that kind of stuff. I'm not blind to it. I think we need to decide what direction we want the syntax to move in (or indeed, decide not to change the syntax at all!). I don't see the point in the repeated threats of locking me out from what I am working on. The current state is inconsistent in so many regards that there is no point in declaring it canonical. It will still take some time until I have the parser where it provides the consistency and power I am striving for with all of the ultimately unnecessary complexity driven out, and then it will be quite more infeasible on a technical level to sabotage the existing framework because it would be much more obvious what sort of things are a bad match to then existing facilities and a cause for major usability regressions. That's actually why I think we need to discuss these things now. As far as I understand it, you are moving in the direction of using \commands for almost everything. Music functions. Or rather, functions. I already have a branch where event functions, music functions and Scheme functions are no longer syntactically different. Some of
Re: [GLISS] non-timed or non-musical events z y
On Thu, Sep 13, 2012 at 7:00 PM, David Kastrup d...@gnu.org wrote: Take a look at the \tempo command. Everybody and their dog tells me that this is just what a musician wants in syntax. Whenever I do significant work on the parser, \tempo pitches in with a few dozen reduce/reduce errors and takes an hour of extra time. I would argue that this is an indication that the \tempo syntax is a mistake. If making backward incompatible changes is allowed, I would suggest to reconsider and scrap the onerous parts of its syntax. -- 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: [GLISS] non-timed or non-musical events z y
On Thu, Sep 13, 2012 at 11:23:43PM -0300, Han-Wen Nienhuys wrote: On Thu, Sep 13, 2012 at 7:00 PM, David Kastrup d...@gnu.org wrote: Take a look at the \tempo command. Everybody and their dog tells me that this is just what a musician wants in syntax. Whenever I do significant work on the parser, \tempo pitches in with a few dozen reduce/reduce errors and takes an hour of extra time. I would argue that this is an indication that the \tempo syntax is a mistake. If making backward incompatible changes is allowed, I would suggest to reconsider and scrap the onerous parts of its syntax. Of course backwards incompatible changes are allowed until GLISS has stabilized a particular bit of language. But in the case of \tempo, I would hope that adding explicit delimiters to the parameters could clear it up. I think we should require explicit delimiters around the argument list for any function which has an optional arguments. - Graham ___ 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
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 13, 2012 at 11:23:43PM -0300, Han-Wen Nienhuys wrote: On Thu, Sep 13, 2012 at 7:00 PM, David Kastrup d...@gnu.org wrote: Take a look at the \tempo command. Everybody and their dog tells me that this is just what a musician wants in syntax. Whenever I do significant work on the parser, \tempo pitches in with a few dozen reduce/reduce errors and takes an hour of extra time. I would argue that this is an indication that the \tempo syntax is a mistake. If making backward incompatible changes is allowed, I would suggest to reconsider and scrap the onerous parts of its syntax. Of course backwards incompatible changes are allowed until GLISS has stabilized a particular bit of language. But in the case of \tempo, I would hope that adding explicit delimiters to the parameters could clear it up. I think we should require explicit delimiters around the argument list for any function which has an optional arguments. \tempo does not have optional arguments but rather several quite different forms of argument lists, and then some rather weird form of numeric range echoed nowhere else in the syntax. Using \tempo as an excuse to make syntax everywhere else more cumbersome is letting it doing even more unwarranted damage. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GLISS] non-timed or non-musical events z y
I'd like to float two ideas about events. The first is to define a null event which functions like the empty chord . Although mathematicians and programmers are quite comfortable with contains with 0 items inside them, this is not a particularly intuitive concept (just look at the concept of zero in the history of mathematics!) This would allow people to write either: { c'1\ \! } { c'1\ z\! } The non-timed null event z would be inserted after the previous note (the c'1) is finished. A vaguely-related idea is to allow easy positioning of musical events within a note. Instead of having a non-timed null event which begins *after* the previous note, we have a timed null event which begins at the same time as the previous note. An example might make that much more clear: \new Voice { { c'1 } { s4\ s s\ s\! } } \new Voice { c'1 y4\ y y\ y\! } Of course in complicated piano it would still be necessary to have explicit voices, but this could simplify such constructs for string, voice, and wind instruments. - Graham ___ 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
Graham Percival gra...@percival-music.ca writes: I'd like to float two ideas about events. The first is to define a null event which functions like the empty chord . Although mathematicians and programmers are quite comfortable with contains with 0 items inside them, this is not a particularly intuitive concept (just look at the concept of zero in the history of mathematics!) But does not solely rely on the concept of 0 items to be a recognizable unit. If it did, \p \p %{ empty %} \p \p would all look the same to the user. The 0 item property is a useful mnemonic that helps you remembering what means without looking in the manual. Which reminds me: we should likely put in the index since it looks so much like something with a meaning of its own that people might well look it up as a unit. This would allow people to write either: { c'1\ \! } { c'1\ z\! } The non-timed null event z would be inserted after the previous note (the c'1) is finished. Hardly surprising given the past discussions, I don't fancy introducing something that needs a new music name as well as likely a new music type (so far, only event-chord and rhythmic-event types can take a post-event, and a rhythmic-event _always_ has a duration which will also get printed when using \displayLilyMusic, and lots of code uses the music type event-chord interchangeably with the music name EventChord). A vaguely-related idea is to allow easy positioning of musical events within a note. Instead of having a non-timed null event which begins *after* the previous note, we have a timed null event which begins at the same time as the previous note. An example might make that much more clear: \new Voice { { c'1 } { s4\ s s\ s\! } } \new Voice { c'1 y4\ y y\ y\! } If this is supposed to be equivalent, note that there is no difference between c'1\ and c'1 y4\ when viewed alone, yet in context they are supposed to generate different output. I suspect that you were rather thinking about the first line being { c'1 } { s4 s\ s s\ \! } I don't really think that this (assuming that this is what you wanted to write) is clearer than \at 4 \ \at 1 \! c'1 and at any rate, it looks that this is to a good degree a self-made problem by virtue of us turning dynamics into post-events, something which does not really fit their nature well. Of course in complicated piano it would still be necessary to have explicit voices, but this could simplify such constructs for string, voice, and wind instruments. For some definition of simplify. -- David Kastrup ___ 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
The first is to define a null event which functions like the empty chord . While this is perhaps a nice syntax sugar idea... \new Voice { c'1 y4\ y y\ y\! } ... I think that this is a nightmare both on the user and the parser/lexer side. Your proposed `y' essentially means to go backwards in time which is against all principles of LilyPond, as far as I know. Werner ___ 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 Thu, Sep 13, 2012 at 01:56:35AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: A vaguely-related idea is to allow easy positioning of musical events within a note. Instead of having a non-timed null event which begins *after* the previous note, we have a timed null event which begins at the same time as the previous note. An example might make that much more clear: \new Voice { { c'1 } { s4\ s s\ s\! } } \new Voice { c'1 y4\ y y\ y\! } If this is supposed to be equivalent, note that there is no difference between c'1\ and c'1 y4\ when viewed alone, yet in context they are supposed to generate different output. I'm confused. The intent is indeed that these two lines produce identical behaviour: | c'1\ | c'1 y4\ namely, the music time advances by a whole note 1, while the extra event time advances by a quarter note 4 . The crescendo operates as a postfix on the y4, which begins at the same time as the c'1. The initial example could also be written as: \new Voice { c'1\ y2 y4\ y\! } I suspect that you were rather thinking about the first line being { c'1 } { s4 s\ s s\ \! } I don't really think that this (assuming that this is what you wanted to write) is clearer than \at 4 \ \at 1 \! c'1 You will be entirely unsurprised to hear that I shudder to see that prefix. :) and at any rate, it looks that this is to a good degree a self-made problem by virtue of us turning dynamics into post-events, something which does not really fit their nature well. I think of music as being a series of pitches+rhythms+modifications. I mean, when I skim music, my eyes notice the staff position, notehead, and beam before really taking in dynamic signs, articulations, etc. With that view (which is evidently not universal), it seems natural to me to write the pitch and duration first, and then all the other special bits that occur on or around that note. Here's a few imaginary ways of writing the same music: \at 4 \ \at 1 \! c'1 c'1 y4 y\ y z\! c'1- y4 y\ y z\! c'1-{ s4 s\ s2 z\! } Out of these, I'm most comfortable with the last one. I can immediately see the pitch and duration. Once I've noticed those, I can look at the extra bits inside the -{}. Even better, those extra bits can be easily (for some definitions of easily) be given a different color with syntax highlighting. - Graham ___ 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
Graham Percival gra...@percival-music.ca writes: Here's a few imaginary ways of writing the same music: \at 4 \ \at 1 \! c'1 c'1 y4 y\ y z\! c'1- y4 y\ y z\! c'1-{ s4 s\ s2 z\! } Out of these, I'm most comfortable with the last one. c-d-. Which one gets the accent? -- David Kastrup ___ 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
Graham Percival gra...@percival-music.ca writes: I think of music as being a series of pitches+rhythms+modifications. I mean, when I skim music, my eyes notice the staff position, notehead, and beam before really taking in dynamic signs, articulations, etc. You'll be really popular with conductors if you read that c''' before you read \pp. With that view (which is evidently not universal), it seems natural to me to write the pitch and duration first, and then all the other special bits that occur on or around that note. Like c\clef treble\time 3/2 ? -- David Kastrup ___ 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 Thu, Sep 13, 2012 at 07:18:50AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Here's a few imaginary ways of writing the same music: \at 4 \ \at 1 \! c'1 c'1 y4 y\ y z\! c'1- y4 y\ y z\! c'1-{ s4 s\ s2 z\! } Out of these, I'm most comfortable with the last one. c-d-. Which one gets the accent? Neither; lilypond exits with an error because there's no explicit -{} and because there's a pitch within the extra timed events portion. The idea is to line up cresc/dynamics/etc that occur within a note (or chord), not to replace the current method of writing multiple voices. - Graham ___ 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 Thu, Sep 13, 2012 at 07:29:35AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: With that view (which is evidently not universal), it seems natural to me to write the pitch and duration first, and then all the other special bits that occur on or around that note. Like c\clef treble\time 3/2 ? No, because the clef and time signature comes before the first note. All other things equal, horizontally left notation in a score should be horizontally left in a .ly file. Above, I'm talking about reading a series of events which are aligned vertically at the same horizontal position. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel