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
