subject:"Possible Feature Request\?"

Janek Warchoł janek.lilyp...@gmail.com writes:

 An example which shows that when you have shortcuts you don't even
 need functions for automated manipulation:

 bong = { q16 q q q q16 q8. }
 { c' e' g'2 \bong  c' f' a'2 \bong  d' g' b'2 \bong }

 But bong does not include the original chord of the sequence.

 Is it bad that it doesn't?
 This is actually nice in my opinion.

It means that bong is not rhythmically/thematically complete.  So it is
more like etc than phrase in its meaning.

 I was amazed myself when i wrote this example :)

 It would not have worked before my reimplementation.

 well... doesn't it mean that your reimplementation was good?

More like that the underlying mechanisms chosen in the reimplementation
lead to semantics that make enough sense to people that they _try_
whether they work, even if they are amazed that they do.

 i'd say it's a matter of lookahead.  If i have to write cis instead
 of cis to use the repetition, it means that *every time* i have to
 look ahead to see if it's worth it.  If i don't need , i can just
 use repetition whenever i want, without additional planning.

Guess how much typing you would have been able to save just now when
being able to write q for each to in that paragraph.  Typing is
fast.  I think we need a more compelling reason.

 As for implied pitches (ie.  c2 4 4 = c2 c4 c4) i'm with David: bad
 results far outweigh typing benefits in my opinion.

 Well, it could be made to work by letting spurious durations create
 NoteEvent without a pitch (ergo nothing going wrong with \relative), and
 have a final pass duplicate pitches, like done with repeat chords.  One
 advantage would be that you could specify rhythms as { 4 4 4. 8 }, for
 example.

 so we wouldn't have to use 's' or some placeholder notes to write
 rhythms for http://lsr.dsi.unimi.it/LSR/Item?id=654 and things like
 that?  that would be nice!

It certainly would figure in the category more compelling reason for
me.

 For something like RhythmicStaff where pitches get squashed anyway,
 it might come in handy.  It would _not_, however, repeat chords,
 since you can't magically change a NoteEvent to an EventChord without
 changing the whole structure.

 pity.

We have q to repeat chords, and for matching constructs to rhythms, one
would employ more complex code anyway.  Even while one restricts oneself
to single note with last pitch, one would still have to decide about
last pitch.  Consider chords at all?  If so, pick their first pitch as
reference?

What about lyrics mode?  Is that worth deviating from the only
NoteEvent rule?  How much sense makes repeating a syllable?

 I definitely don't like the ambiguity for function argument parsing
 if 4 can not just signify an unsigned number and a duration, but also
 a music argument on its own.

 The worst consequence most likely would be that if _now_ people
 confuse the order of pitch, duration, and other stuff, they usually
 get a syntax error.  After this change, they would get additional
 notes interspersed instead.  We would be losing a lot of redundancy
 in input, and that would likely cause a _lot_ of surprises.

 good point.  So, i still think that we shouldn't allow c2 4 4
 despite some really nice benefits it could bring us.

Well, it won't affect previously valid programs.  And it would have some
nice side effects, including
c4~ | 1~ | 2.
with or without bar checks or spaces, and reasonably straightforward
underpinnings and semantics.

 As for ties with durations, this seemed interesting initially, but:
 - if i understood David correctly, the type of the tie syntax element
 cannot have durations

 Nope.  The problem with that is that a tie becomes an event that is a
 property of the _previous_ note, and even if we found a way to tell the
 tie a duration, it would have nowhere to go with it.

 Well, that's more or less what i meant :P

See above.  c4~1~2. would work without any special tie or space
semantics, given that particular syntax extension.

The problem is that so would c2 c'~4 and people might be confused that
it will be equivalent to c2 c'2 ~ c'4 (this interjection before the
following period intentionally left blank).

It will be harder to trace to the respective input location than an
error message would.

In short, there are a number of side effects to consider.  There are,
however, also a number of benefits.  A natural manner of expression for
rhythms as such (not just in the syntax of the \tempo command...)
without the need of yet another lexer mode certainly has independent
appeal, whether or not filling in note values with a final pass like q
does.

 - if it would be possible to change tie syntax so that it could have
 a duration, i'd prefer it to mean something different.  See another
 thread.

 I prefer avoiding too many strange and different meanings.

 Sure, as long as there is another concise way of expressing something.

If you want to clobber the meaning of ties, I consider it reasonable to
make them

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-23 Thread Werner LEMBERG


 So, i still think that we shouldn't allow c2 4 4 despite some
 really nice benefits it could bring us.
 
 Well, it won't affect previously valid programs.  And it would have
 some nice side effects, including

   c4~ | 1~ | 2.

 with or without bar checks or spaces, and reasonably straightforward
 underpinnings and semantics.

So let's keep that as one of the first results of our GLISS
discussion, together with your suggestions for improved syntax of
\tempo.


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Werner LEMBERG w...@gnu.org writes:

 So, i still think that we shouldn't allow c2 4 4 despite some
 really nice benefits it could bring us.
 
 Well, it won't affect previously valid programs.  And it would have
 some nice side effects, including

   c4~ | 1~ | 2.

 with or without bar checks or spaces, and reasonably straightforward
 underpinnings and semantics.

 So let's keep that as one of the first results of our GLISS
 discussion, together with your suggestions for improved syntax of
 \tempo.

I think it has a somewhat reasonable chance of being implementable.  It
would certainly take quite a bit of shaking out ambiguities, though.
Particularly in situations lacking context, like in #{ #} and on the
right side of assignments and as function argument it might prove hard
to get really satisfactorily consistent and understandable behavior.

And I don't want to introduce it myself before I get the whole function
call/identifier area to a state I consider a stable basis for further
work.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-23 Thread Marc Hohl


Am 23.09.2012 14:40, schrieb James:

Hello,

[...]

This construct doesn't allow for mixing single notes with
chords.

I see. Hmm...yes that's awkward.



There are instruments and music styles which greatly
benefit from having 'q' available, whereas others don't,
I write a lot of music for guitar (and recently, I had to
typeset music for accordion, too) and there is a
great advantage in both typing *and* readability
between

e,8\5  b,\4 e\3 g\2 b\1  b,,\6  b,\4 e\3 g\2 b\1  e,8\5  b,\4 e\3 g\2
b\1  b,,\6  b,\4 e\3 g\2 b\1 

and

e,8\5  b,\4 e\3 g\2 b\1  b,,\6 q e,\5 q b,,\6 q

(assuming you have switched on \tabChordRepetition).

I'm still not sure I am convinced. Amount of typing? Sure you have to
type less - perhaps (depending on how many 'q' chars you need) but
readability is subjective it seems (i.e. I don't use q, you do I don't
find q that readable at all simply because I read from the left to
right and then see a q and have to jump back left to recall what it is
repeating (just in case I missed something) whereas explicitly writing
out \repeat chord {music expression} is easy - forget about the mixing
notes with chords for now, I _do_ take that point however.



[...](I find reading other's lilypond sources that use 'q'
significantly akin to reading technical documentation where every 4th
word is an acronym or abbreviation).

I'd just say the opposite; in my example above, any change in the
chord is not as easily spotted when you write out everyting:

e,8\5  b,\4 e\3 g\2 b\1  b,,\6  b,\4 e\3 g\2 b\1  e,8\5  b,\4 e\3 g\2
b\1  b,,\6  b,\4 d\3 fis\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1  b,,\6  b,\4 e\3 g\2 b\1  e,8\5  b,\4 e\3 g\2
b\1  b,,\6  b,\4 e\3 g\2 b\1 

as opposed to

e,8\5  b,\4 e\3 g\2 b\1  b,,\6 q e,\5 q b,,\6  b,\4 d\3 fis\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1  b,,\6 q e,\5 q b,,\6 q

In the lower example, you see at first glance that the last chord
in the first measure changes.

That's just how a person writes out his file; I found the example you
gave poor in that I can see the line length doesn't match so I could
see instantly the change.
Well, I try to put at least a full measure in one line, so the example 
was very much

something I use in my pieces.


So to try to take the same examples:

e,8\5  b,\4 e\3 g\2 b\1 
b,,\6 q
e,\5 q
b,,\6  b,\4 d\3 fis\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1 
b,,\6 q
e,\5 q
b,,\6 q

vs

e,8\5  b,\4 e\3 g\2 b\1 
b,,\6  b,\4 e\3 g\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1 
b,,\6  b,\4 d\3 fis\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1 
b,,\6  b,\4 e\3 g\2 b\1 
e,8\5  b,\4 e\3 g\2 b\1 
b,,\6  b,\4 e\3 g\2 b\1 

By the time I get to the last line in the first example, I've
forgotten what q is repeating :) so I have to jump back - what was q
again? etc. The second example here is straightforward, sure it
doesn't tell me what has changed compared to X instance, but neither
does q (at least in long passages).
Ok, it seems that people using 'q' like it and find it easy to type and 
to read,
whereas others don't like it and therefore do not use it – it's a mere 
philosophical

question.



Actually this is probably why I've never bothered to use q for
accordion bass lines on my own compositions, but create variables like
\cmindimsev \cminor \gminorfive etc. in the lilypond file then use
\repeat unfold, so when I have lots of repetitive chords and then
sudden and small passage changes I don't have to care what the
'previous' chord was to make sure I have it right, I already know what
it is now, because what my eye is reading is what the chord really is
- if that makes sense to you?

Ok, that's another possibility – *if* we could use variable names like
em7, c7b5 and store chords in that, this would be even better, but this
yields to yet another big amount of philosophical mails ;-)

To be honest, I use this way of defining chords, too, but with 'q', I like
the possibility of changing the duration easily. If that were possible with
 e8 \eminor e \eminor ~ \eminor \eminor4. , I think I would not miss 'q'
that much if it had to go.



From a novice's point of view q on the face of it is handy, but handy
in the sense that some of the LSR hacks are handy, it just seems so
unlike/inconsistent with any of the other commands we use in LP. I
don't personally have any feelings about whether q is good/bad, I can
see it certainly makes typing quicker, what I was wondering was is the
q 'function' holding back and/or preventing other parts of the .ly
language from being improved/more streamlined in the lexer  parser
work that David is working on.

Good point. And basically, I support the idea of enhancing the
\repeat ... { stuff } construct – I merely wanted to show that
there are situations where the repeat construct would not work.

Regards,

Marc


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Marc Hohl m...@hohlart.de writes:

 Am 23.09.2012 14:40, schrieb James:

 From a novice's point of view q on the face of it is handy, but handy
 in the sense that some of the LSR hacks are handy, it just seems so
 unlike/inconsistent with any of the other commands we use in LP. I
 don't personally have any feelings about whether q is good/bad, I can
 see it certainly makes typing quicker, what I was wondering was is the
 q 'function' holding back and/or preventing other parts of the .ly
 language from being improved/more streamlined in the lexer  parser
 work that David is working on.
 Good point. And basically, I support the idea of enhancing the
 \repeat ... { stuff } construct – I merely wanted to show that
 there are situations where the repeat construct would not work.

Just in case people are worrying about q: I have pretty much expunged
all of its involvement with the parser.  It is not a maintenance burden
either.  The code supporting it is quite separate from the parser itself
and runs either when explicitly called, or when music is placed in a
score.  Regarding future parser work, this is a non-issue.

Making isolated durations carry meaning, in contrast, would consist of
one external component similar to q, but it would also heavily involve
the parser itself.  The challenge would not be in what to create in the
music expression either: like with q, something quite straightforward
would likely work fine.  The challenge would be to deal with all the
resulting ambiguities in a manner that makes sense to parser and humans
alike.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Marc Hohl m...@hohlart.de writes:

 Ok, that's another possibility – *if* we could use variable names like
 em7, c7b5 and store chords in that, this would be even better, but
 this yields to yet another big amount of philosophical mails ;-)

It would make more sense to improve the configurability of chord
notation and integrate it into normal music expressions rather than
requiring \chordmode.

 To be honest, I use this way of defining chords, too, but with 'q', I
 like the possibility of changing the duration easily. If that were
 possible with e8 \eminor e \eminor ~ \eminor \eminor4. , I think I
 would not miss 'q' that much if it had to go.

It would be conceivable to relax the optional arguments at the end of a
function argument list are mandatory condition and allow the default
duration in the parser to pitch in if nothing else matches the
predicate.

I am not promising this as rejecting optional arguments means the
candidate argument needs to go somewhere else, and it is not clear that
this can be made to work in arbitrary contexts.

It would be simple to let a music function access the current default
duration, the tricky stuff is to be able to optionally forego it when an
explicit duration is given.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-21 Thread Francisco Vila

2012/9/21 David Kastrup d...@gnu.org:
 There is no concept of concatenation involved here.  Spaces are not
 significant between separate syntactic elements.  Not even in lyrics.
 If you write
 xxx=text
 then \lyricmode{\xxx\xxx} and \lyricmode { \xxx \xxx } are both
 equivalent to \lyricmode { text text } or \lyricmode{text   text}.

I think not. E.g. is really

  xxx=text
  tenorLyrics = \lyricmode{\xxx}

valid? I can not get it to work.

Or

  \new Lyrics  \lyricmode{text   text}

Which is also not valid because text} is a syllable itself.

  \new Lyrics \lyricmode{text   text} }

is valid input and produces text text}
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-21 Thread Phil Holmes

- Original Message - 
From: Graham Percival gra...@percival-music.ca

To: Nicolas Sceaux nicolas.sce...@free.fr
Cc: David Kastrup d...@gnu.org; lilypond-user@gnu.org
Sent: Thursday, September 20, 2012 7:01 PM
Subject: Re: Possible feature request for 'q' shorthand or tie syntax

On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:

If c'4 was actually a shortcut for c'4, then we could have a
consistent notion that every time unit in every voice is a chord;
that chord may contain 0, 1, or many notes.

- Graham

Actually, if you want c'4 to appear to be c'4, the simplest way is to make 
it so:

\relative c' {
 c4 c c c
 c e4 c e4 c e4 c e4
 c e4 q q q
 c4 c4 c4 c4
 c4 q q q
}

--
Phil Holmes 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Graham Percival gra...@percival-music.ca writes:

 I'm particularly asking about making every note into a chord
 because that would make David's favorite  construct a *lot* more
 consistent.  At the moment, we have
   no note at a time unit: 
   single note at a time unit: c'4
   multiple notes at a time unit: c e g4

 If c'4 was actually a shortcut for c'4, then we could have a
 consistent notion that every time unit in every voice is a chord;
 that chord may contain 0, 1, or many notes.

And \tweak would stop working on c'4 again unless you placed explicit
chord angle brackets around the construct, and lyric syllables would be
chords of their own and they can't be angle-bracket enclosed anyway, so
no tweaking here, and you can't assemble single notes into chords
anymore without unpacking them from their surrounding default chords...

This change was discussed and made a year ago.  It is documented in the
Changes section for 2.16, including rationale and consequences.  It was
extensively discussed on the developer list.  Even if you are not
interested in all the other advantages it brought, it was one of the
requisites to actually make q work according to its original
specification arrived at after extensive (unrelated) discussions.

It just does not make sense to discuss where one wants to be going when
one does not bother checking where one _stands_, and for what reasons
and how and from where one got there.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Francisco Vila paconet@gmail.com writes:

 2012/9/21 David Kastrup d...@gnu.org:
 There is no concept of concatenation involved here.  Spaces are not
 significant between separate syntactic elements.  Not even in lyrics.
 If you write
 xxx=text
 then \lyricmode{\xxx\xxx} and \lyricmode { \xxx \xxx } are both
 equivalent to \lyricmode { text text } or \lyricmode{text   text}.

 I think not. E.g. is really

   xxx=text
   tenorLyrics = \lyricmode{\xxx}

 valid? I can not get it to work.

That is a different bug actually.

xxx=\markup \italic text
tenorLyrics = \lyricmode{\xxx}

works fine.  The spaces have nothing to do with it.


 Or

   \new Lyrics  \lyricmode{text   text}

 Which is also not valid because text} is a syllable itself.

You are correct with that: I was confusing markups with lyrics here.  It
does not make all that much sense to me that these have different
conventions, but you are right that they do.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-21 Thread Gilles




You noticed yourself that this does not work well with chords, but it
also does not play overly well with \relative if you write \av c' for
example.


In the \samePitch function, i try to play with the property
'to-relative-callback. It seems to work also here but of course, it is
heavier -:(  (see below )
For chords, is it conceivable to imagine a ly:pitches? function, (so for
chords), that would be compatible in #{ #}, in the same way ly:pitch? is.
And even, an ly:pitch?-or-ly:pitches? function for notes and chords ?
(well, probably with better names ...)

--
Gilles



%%
#(define (set-rel-callback tied-music)
set all pitches to the pitch of the first note, in relative mode.
(let((not-first? #f))
(map-some-music
  (lambda (x)
(case (ly:music-property x 'name)
  ((or NoteEvent EventChord)
 (if not-first?
   (ly:music-set-property! x 'to-relative-callback
  (lambda (x p) ; set pitch to the prev value
  (ly:prob-set-property! x 'pitch p)
  p)))
   (set! not-first? x)
 x)
  (else #f)))
  tied-music)))


av = #(define-music-function (parser location x) (ly:pitch?)
(set-rel-callback
#{
  $x 8 ~  $x 4
#}))

   \new Staff \relative c' {
  c4. \av c' f4
  fis4. \av fis, g4
   }
%

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Gilles gilles.thiba...@free.fr writes:

 You noticed yourself that this does not work well with chords, but it
 also does not play overly well with \relative if you write \av c' for
 example.

 In the \samePitch function, i try to play with the property
 'to-relative-callback. It seems to work also here but of course, it is
 heavier -:(  (see below )

Yes.  In this kind of situation, it is probably the simplest way out.
If you use \displayLilyMusic _after_ applying \relative to such an
expression, you would not notice the difference...

 For chords, is it conceivable to imagine a ly:pitches? function, (so
 for chords), that would be compatible in #{ #}, in the same way
 ly:pitch? is.  And even, an ly:pitch?-or-ly:pitches? function for
 notes and chords ?  (well, probably with better names ...)

I guess you overestimate the role of ly:pitch? here.  It basically is a
predicate that the parser applies to basic LilyPond syntax entities to
figure out whether to permit them into the function.

Now it is true that there is a bit of disambiguation going on as well,
and it is actually true that in current master, ly:pitch? is indeed
special-cased, meaning you can't mix it with other predicates.  But that
is slated to go.  So if you want to accept note-or-chord, just accept a
ly:music? expression and go from there, looking at its being note or
chord.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-21 Thread Janek Warchoł

Hi all,

there's a lot of emails in this thread so i'll post a general reply.

First, i was puzzled myself that q only repeats chords.  I didn't know
that it was intentional (missed the discussion, sorry) and i was going
to suggest to change this behaviour myself.

I understand Marc's argument about um-pah accompaniment, and i no
longer think that the meaning of q should be changed.

However, the idea of creating another shortcut (p seems to be a good
name) appeals to me.  I would design p to repeat chords as well as
pitches.

As for the pitch names aren't that long argument, i say that:
- for me 3 letters is long enough to warrant a shortcut, especially
because these letters tend to be spread all over the keyboard (e.g.
gis).  Also, full english names are much longer (fsharp)
- it seems to me that a shortcut will allow greater flexibility, both
with manual source manipulation as well as music functions.

An example which shows that when you have shortcuts you don't even
need functions for automated manipulation:

bong = { q16 q q q q16 q8. }
{ c' e' g'2 \bong  c' f' a'2 \bong  d' g' b'2 \bong }

I was amazed myself when i wrote this example :)

As for you can enclose single pitch in  argument, i say that this
is a nice hack, but it still looks like a hack.  From a user
perspective (i'm speaking in my own name here), writing a looks like
huh?.  Also, it's additional 2 characters to type, both with shift!

As for the idea of translating c into c internally (i know that
this description is probably imprecise/wrong), it seemed elegant
initially, but David's reply convinced me immediately.

As for implied pitches (ie.  c2 4 4 = c2 c4 c4) i'm with David: bad
results far outweigh typing benefits in my opinion.  Having no
whitespace between pitch and duration is a nice convention, but
David's music function example immediately convinced me that we want
the flexibility that allowing whitespace gives us.

As for ties with durations, this seemed interesting initially, but:
- if i understood David correctly, the type of the tie syntax element
cannot have durations
- if it would be possible to change tie syntax so that it could have
a duration, i'd prefer it to mean something different.  See another
thread.

cheers,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Janek Warchoł janek.lilyp...@gmail.com writes:

 However, the idea of creating another shortcut (p seems to be a good
 name) appeals to me.  I would design p to repeat chords as well as
 pitches.

When writing c e c q p, what does p repeat and why?  How will it be
represented in music lists so that the usual manipulations of music
lists will not get confused?

We had a few confusions with q (represented as an event-chord with a
duration).  What will p be for pitches?  A NoteEvent without pitch?

 As for the pitch names aren't that long argument, i say that: - for
 me 3 letters is long enough to warrant a shortcut, especially because
 these letters tend to be spread all over the keyboard (e.g.  gis).

That's not even a readability problem (which was argued for chords), it
is an entry problem.  As such it is better solved by the editor than by
anything else.

 Also, full english names are much longer (fsharp) - it seems to me
 that a shortcut will allow greater flexibility, both with manual
 source manipulation as well as music functions.

There is no point in not using the short English names in note entry.
The full names don't make sense for much more than key declarations, if
at all.

 An example which shows that when you have shortcuts you don't even
 need functions for automated manipulation:

 bong = { q16 q q q q16 q8. }
 { c' e' g'2 \bong  c' f' a'2 \bong  d' g' b'2 \bong }

But bong does not include the original chord of the sequence.

 I was amazed myself when i wrote this example :)

It would not have worked before my reimplementation.

 As for you can enclose single pitch in  argument, i say that this
 is a nice hack, but it still looks like a hack.  From a user
 perspective (i'm speaking in my own name here), writing a looks like
 huh?.  Also, it's additional 2 characters to type, both with shift!

But you were out to save _so_ many awful characters in typing, surely
those two characters would pale in comparison?  Are we trying to beat
APL in input compression?

 As for implied pitches (ie.  c2 4 4 = c2 c4 c4) i'm with David: bad
 results far outweigh typing benefits in my opinion.

Well, it could be made to work by letting spurious durations create
NoteEvent without a pitch (ergo nothing going wrong with \relative), and
have a final pass duplicate pitches, like done with repeat chords.  One
advantage would be that you could specify rhythms as { 4 4 4. 8 }, for
example.  For something like RhythmicStaff where pitches get squashed
anyway, it might come in handy.  It would _not_, however, repeat chords,
since you can't magically change a NoteEvent to an EventChord without
changing the whole structure.

I definitely don't like the ambiguity for function argument parsing if 4
can not just signify an unsigned number and a duration, but also a music
argument on its own.

The worst consequence most likely would be that if _now_ people confuse
the order of pitch, duration, and other stuff, they usually get a syntax
error.  After this change, they would get additional notes interspersed
instead.  We would be losing a lot of redundancy in input, and that
would likely cause a _lot_ of surprises.

 As for ties with durations, this seemed interesting initially, but:
 - if i understood David correctly, the type of the tie syntax element
 cannot have durations

Nope.  The problem with that is that a tie becomes an event that is a
property of the _previous_ note, and even if we found a way to tell the
tie a duration, it would have nowhere to go with it.

 - if it would be possible to change tie syntax so that it could have
 a duration, i'd prefer it to mean something different.  See another
 thread.

I prefer avoiding too many strange and different meanings.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Stefan Thomas

Dear Jim,
I don't like writing lots of ties too. And I use the following solution,
which works fine for me.
\include changepitch.ly
   AV = {  c8  c4  }
av = #(define-music-function (parser location x) (ly:music?)
#{
  \context Voice   { \changePitch \AV  { $x $x } } { s8 ~ s8 } 
#})
\new Staff \relative c' {
  c4. \av es f4 fis4 \av fis g4
}
 You can easily define  other commands like this for all combinations of
durations.

A humble suggestion

 Please educate me if there is already a way to do this, but it
 appears that 'q' as a shorthand for the repetition of the
 previous note(s) only works for chords.  It would be handy if it
 worked for single notes also, specifically in ties.

   \time 12/8
   \partial 8
   aes8
   des,4. ~ q4 aes'8  d,4. ~ q4 a'8
   des,4. ~ q4 aes'8  d,4. ~ q4 a'8


 For that matter, it would be nice (though I suspect more
 syntactically problematic) for subsequent notes in ties to only
 require a duration, since by definition the pitch has already
 been specified in the first note of the tie.

 This might be written as:

   \time 12/8
   \partial 8
   aes8
   des,4.~4 aes'8  d,4.~4 a'8
   des,4.~4 aes'8  d,4.~4 a'8

 Flipping that around, it might (or might not, I'm not qualified
 to say) be syntactically convenient to define a 'compound
 duration' as one that includes two or more simple durations
 separated by tildes.  In the above example, the pitch is 'des,'
 and the duration is '4.~4'.  In 4/4 time, 'a2' takes up the same
 time as 'a4~4' but of course in the notation, 'a4~4' is two notes
 tied, and 'a2' is a single note.

 I think this helps the readability to show that it is one pitch
 of a given duration tied to a second duration, and conceivably
 more:

 Here the long C has a duration of '1~1~2~4~8', and the final
 c has an implied duration of 8 since that is the duration of the
 note preceding it in the notation.

   \time 4/4
   \partial 16
   c16
   c1~1~2~4~8 c

 Instead of the current syntax:

   \time 4/4
   \partial 16
   c16
   c1~c1~c2~c4~c8 c



 In chordmode:

   \time 4/4
   bes4~16:m7  ees16~8:7  aes2:maj7


 Perhaps this idea has plenty of holes, but I think I would enjoy
 learning from the discussion.

 Thank you for your time,

 Jim

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Jim Long lilyp...@umpquanet.com writes:

 A humble suggestion

 Please educate me if there is already a way to do this, but it
 appears that 'q' as a shorthand for the repetition of the
 previous note(s) only works for chords.  It would be handy if it
 worked for single notes also, specifically in ties.

   \time 12/8
   \partial 8
   aes8
   des,4. ~ q4 aes'8  d,4. ~ q4 a'8
   des,4. ~ q4 aes'8  d,4. ~ q4 a'8


 For that matter, it would be nice (though I suspect more
 syntactically problematic) for subsequent notes in ties to only
 require a duration, since by definition the pitch has already
 been specified in the first note of the tie.

Yes and no: musically one can tie eis to f or cis to des (not that
LilyPond does a fabulous job with that).

 This might be written as:

   \time 12/8
   \partial 8
   aes8
   des,4.~4 aes'8  d,4.~4 a'8
   des,4.~4 aes'8  d,4.~4 a'8

 Flipping that around, it might (or might not, I'm not qualified
 to say) be syntactically convenient to define a 'compound
 duration' as one that includes two or more simple durations
 separated by tildes.

That would be rather complex concept.  It also does not lend itself
easily to interspersing material like bar lines or bar checks or meter
changes.  At the current point of time, durations are implemented as one
hardwired syntactic element hooking into the duration property of
events while ties are implemented as a post-event that attaches to the
articulations field of the preceding event.

In both cases, the actual attachment is done by the parser, and the
respective element (duration/articulation) is completely formed before
being attached.

Something which LilyPond _does_ support is the so-called
Completion_heads_engraver which has the opposite approach: it takes a
long duration and splits tied notes off according to bar lines getting
in the way.  However, this still requires the original notes to be
specified with a duration corresponding to their full length.  It is
nice for producing canons and/or stretto passages in modern notation
with no untied values crossing barlines, but does not help all that much
when the original is supposed to contain long irregular lengths.

Personally, I rather like the ambiguous nature of shifted Renaissance
mostly rhythms expressed without the use of ties, but of course it is
not really fancied in modern notation.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Graham Percival

On Wed, Sep 19, 2012 at 11:56:02PM +0200, David Kastrup wrote:
 Jim Long lilyp...@umpquanet.com writes:
 
  Please educate me if there is already a way to do this, but it
  appears that 'q' as a shorthand for the repetition of the
  previous note(s) only works for chords.  It would be handy if it
  worked for single notes also, specifically in ties.
 
 A single note name is not that much longer to type than q.  If it is
 really important to you, place the single note in a chord:
 des is perfectly repeatable by q.

What would we lose if every note was automatically a (single-note)
chord?

- Graham

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Nicolas Sceaux


Le 20 sept. 2012 à 19:21, Graham Percival a écrit :

 On Wed, Sep 19, 2012 at 11:56:02PM +0200, David Kastrup wrote:
 Jim Long lilyp...@umpquanet.com writes:
 
 Please educate me if there is already a way to do this, but it
 appears that 'q' as a shorthand for the repetition of the
 previous note(s) only works for chords.  It would be handy if it
 worked for single notes also, specifically in ties.
 
 A single note name is not that much longer to type than q.  If it is
 really important to you, place the single note in a chord:
 des is perfectly repeatable by q.
 
 What would we lose if every note was automatically a (single-note)
 chord?

That behavior is intended, so that you can write:

  c e g c' g q c q g q

And the idea, if you wanted to repeat the previous single note, is
to enclose it between  .
q repeats the last chord, not the last note.  That's why it's named
chord repetition symbol.

Nicolas


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Graham Percival

On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:
 
 Le 20 sept. 2012 à 19:21, Graham Percival a écrit :
 
  A single note name is not that much longer to type than q.  If it is
  really important to you, place the single note in a chord:
  des is perfectly repeatable by q.
  
  What would we lose if every note was automatically a (single-note)
  chord?
 
 That behavior is intended, so that you can write:
 
   c e g c' g q c q g q
 
 And the idea, if you wanted to repeat the previous single note, is
 to enclose it between  .
 q repeats the last chord, not the last note.  That's why it's named
 chord repetition symbol.

I thought the behaviour was intended to simplify things like
  c e g4 q q q

I'm particularly asking about making every note into a chord
because that would make David's favorite  construct a *lot* more
consistent.  At the moment, we have
  no note at a time unit: 
  single note at a time unit: c'4
  multiple notes at a time unit: c e g4

If c'4 was actually a shortcut for c'4, then we could have a
consistent notion that every time unit in every voice is a chord;
that chord may contain 0, 1, or many notes.

- Graham

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Marc Hohl


Am 20.09.2012 20:01, schrieb Graham Percival:

On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:

Le 20 sept. 2012 à 19:21, Graham Percival a écrit :


A single note name is not that much longer to type than q.  If it is
really important to you, place the single note in a chord:
des is perfectly repeatable by q.

What would we lose if every note was automatically a (single-note)
chord?

That behavior is intended, so that you can write:

   c e g c' g q c q g q

And the idea, if you wanted to repeat the previous single note, is
to enclose it between  .
q repeats the last chord, not the last note.  That's why it's named
chord repetition symbol.

I thought the behaviour was intended to simplify things like
   c e g4 q q q

Yes, but if you write some hump-da hump-da guitar or accordion
comping, then

c,  c e d  g, q c, q g, q

is quite fine; if c, is supposed to be  c; , then this becomes

c,  c e g  g,  c e g  c,  c e g  g,  c e g 

so the advantage of q is completely lost in such cases.


I'm particularly asking about making every note into a chord
because that would make David's favorite  construct a *lot* more
consistent.  At the moment, we have
   no note at a time unit: 
   single note at a time unit: c'4
   multiple notes at a time unit: c e g4

from a mathematical/technical point of view, +1
for a musicians point of view rather not.

Regards,

Marc


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

On Thu, Sep 20, 2012 at 01:12:29PM +0200, David Kastrup wrote:
 Jim Long lilyp...@umpquanet.com writes:
 
  A humble suggestion
 
  Please educate me if there is already a way to do this, but it
  appears that 'q' as a shorthand for the repetition of the
  previous note(s) only works for chords.  It would be handy if it
  worked for single notes also, specifically in ties.
 
\time 12/8
\partial 8
aes8
des,4. ~ q4 aes'8  d,4. ~ q4 a'8
des,4. ~ q4 aes'8  d,4. ~ q4 a'8
 
 
  For that matter, it would be nice (though I suspect more
  syntactically problematic) for subsequent notes in ties to only
  require a duration, since by definition the pitch has already
  been specified in the first note of the tie.
 
 Yes and no: musically one can tie eis to f or cis to des (not that
 LilyPond does a fabulous job with that).

My wording was somewhat accidental, but I'll point out 'require'.
Point taken re: your note about bar lines, bar number checks, etc.
And I don't have any resource to fund development, nor is this an
urgent issue.  So unless it's easy to do as a low-priority enhancement 

That said, what about making the pitch *optional* in a tie?

So you could still do enharmonic ties:

c1 ~ | bis4 cis dis cis ~ | des1

But if stand-alone durations (like a '4' standing by itself)
could inherit the previous pitch (somewhat symmetric to how a
stand-alone pitch inherits the previous duration), one could
write:

c1 ~ | 4 cis dis cis ~ | 1

or even:

|c1|~1|~1~|2~4~8 c|



Similarly, if one didn't need bar checks, one *could* write:

c1~4 cis dis cis~1

or

c1~1~1~2~4~8 c

I think this changes my chordmode example somewhat, and makes
the current 'q' shorthand seem pretty adequate in chordmode.

This:
c1:maj7 ~ | 4 cis:maj7 dis:maj7 cis:maj7 ~ | 1

would be the same as:
c1:maj7 ~ | q4 cis:maj7 dis:maj7 cis:maj7 ~ | q1

And:
d4:m7 4 g:7 4 ~ | 4 c:maj7 4 4 |

would be the same as:
d4:m7 q g:7 q ~ | q c:maj7 q q |

I also take your point that the amount of typing saved is small,
but this mostly comes in handy when a (melodic, non-chordal)
rhythmic motif involving ties is repeated around a number of
different pitches, and when cutting and pasting, one has to edit
each pitch in the tied notes.  It's not the amount of typing so
much as the redundant information.  I always feel like whenever
one has to enter information that is already known, it's just
another chance to make a data entry error.  Granted however,
LilyPond gives errors on unterminated ties.

Given that q works so well in chordmode, is it rather non-trivial
to make 'q' work for single notes?  Actually, I just read Marc
Kohl's post about using q in comping notation, and I see his
point.  Perhaps a separate letter could be used to refer to the
previous note, say perhaps p in this example?

c1~|p4 cis dis cis~|p1

This has the advantage that p stands for pitch, just like q
stands for quord. :)  And at some point in the documentation,
users could be admonished to mind their p's and q's.



 Personally, I rather like the ambiguous nature of shifted Renaissance
 mostly rhythms expressed without the use of ties, but of course it is
 not really fancied in modern notation.

Please link to an example, I'd be curious to take a look.

Thanks for taking time to listen.

Jim

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread james


On Sep 20, 2012, at 8:16 PM, Marc Hohl wrote:

 Am 20.09.2012 20:01, schrieb Graham Percival:
 On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:
 Le 20 sept. 2012 à 19:21, Graham Percival a écrit :
 
 A single note name is not that much longer to type than q.  If it is
 really important to you, place the single note in a chord:
 des is perfectly repeatable by q.
 What would we lose if every note was automatically a (single-note)
 chord?
 That behavior is intended, so that you can write:
 
   c e g c' g q c q g q
 
 And the idea, if you wanted to repeat the previous single note, is
 to enclose it between  .
 q repeats the last chord, not the last note.  That's why it's named
 chord repetition symbol.
 I thought the behaviour was intended to simplify things like
   c e g4 q q q
 Yes, but if you write some hump-da hump-da guitar or accordion
 comping, then
 
 c,  c e d  g, q c, q g, q
 
 is quite fine; if c, is supposed to be  c; , then this becomes
 
 c,  c e g  g,  c e g  c,  c e g  g,  c e g 
 
 so the advantage of q is completely lost in such cases.
 
 I'm particularly asking about making every note into a chord
 because that would make David's favorite  construct a *lot* more
 consistent.  At the moment, we have
   no note at a time unit: 
   single note at a time unit: c'4
   multiple notes at a time unit: c e g4
 from a mathematical/technical point of view, +1
 for a musicians point of view rather not.

I agree completely about this. Perhaps a solution would be a different shortcut 
to repeat the previous note, regardless whether chord or single note?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

On Thu, Sep 20, 2012 at 11:01:59AM -0700, Graham Percival wrote:
 
 If c'4 was actually a shortcut for c'4, then we could have a
 consistent notion that every time unit in every voice is a chord;
 that chord may contain 0, 1, or many notes.

I too see the elegance in your idea, but understand Marc Hohl's
concern for protecting the current behaviour of 'q' (apologies
for getting his last name wrong earlier).

But at least for single-note syntax, I'm proposing this kind of
syntactic symmetry:

c4 c4 c4 c4   (pitch and duration specified)

and

c4 c c c   (pitch specified, duration implied)

and

c4 4 4 4   (duration specified, pitch implied)


So then,

c2 c4 c c1

is equivalent to:

c2 4 4 1

If that syntax were possible, then ties between those notes would
accomplish the goal of my original pipedream, to not have to
repeat the pitch on ties.  One could optionally still do so, of
course.

c2~4~4~1 orc2~c4~c~c1

Bar checks could still work:

c2~4~4~|1orc2~4~4|~1


james' suggestion of a shortcut separate from 'q' to repeat the 
previous note or chord (regardless of which it is) then becomes:

A duration specified without a pitch implies that the same
pitch(es) from the previous note or chord are used:

c4 4 4 4

c e g4 4 4 4


etc.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Graham Percival gra...@percival-music.ca writes:

 On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:
 
 Le 20 sept. 2012 à 19:21, Graham Percival a écrit :
 
  A single note name is not that much longer to type than q.  If it is
  really important to you, place the single note in a chord:
  des is perfectly repeatable by q.
  
  What would we lose if every note was automatically a (single-note)
  chord?
 
 That behavior is intended, so that you can write:
 
   c e g c' g q c q g q
 
 And the idea, if you wanted to repeat the previous single note, is
 to enclose it between  .
 q repeats the last chord, not the last note.  That's why it's named
 chord repetition symbol.

 I thought the behaviour was intended to simplify things like
   c e g4 q q q

 I'm particularly asking about making every note into a chord
 because that would make David's favorite  construct a *lot* more
 consistent.

Uh no, it wouldn't.   is not nothing, it is a chord.  It _is_
inconsistent in that it is not included in chord repetitions, but the
reason for that is not to mess up the calculation of durations: q4
counts as a quarter note, and if it were to stand in for , its
duration would change upon expansion.

The most important reason _not_ to make every note into a chord is that
if you make every note into a chord, c e g become c e g.  Now
you can make a special exception that inside of chords, notes are not
made into a chord, but where does that leave you if you use music
functions or variables for generating content _inside_ of chords?  Do
you want to prohibit that?  How would you then use \tweak inside of a
chord?

In 2.14, only the last argument of a function could actually be music:
it was parsed differently than the other arguments.  In a post-event,
the last argument was a post-event.  In a chord, the last element was a
chord constituent (and could not be a variable or anything other than a
directly entered note).  This severely limited the usefulness of music
functions, and music functions behaved differently in different
contexts, and their arguments were provided differently in different
contexts.  Please read the Changes section of 2.16 for more details.

 At the moment, we have no note at a time unit:  single note at a
 time unit: c'4 multiple notes at a time unit: c e g4

 If c'4 was actually a shortcut for c'4, then we could have a
 consistent notion that every time unit in every voice is a chord;
 that chord may contain 0, 1, or many notes.

That was the state before issue 2240.  Check that issue and Changes
for the reasons for _changing_ it.  There was quite the discussion on
the mailing list as well.

One could most certainly make q apply to notes as well as chords, and
indeed that was what the _first_ implementation of q actually did if you
bother to check.  This was changed after quite a bit of discussion,
again because users discussed priorities and agreed on this course of
action.  There was a discussion about _that_ as well, and a consensus,
along with a history of several versions of the original patch.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Jim Long lilyp...@umpquanet.com writes:

On Thu, Sep 20, 2012 at 01:12:29PM +0200, David Kastrup wrote:
Jim Long lilyp...@umpquanet.com writes:

For that matter, it would be nice (though I suspect more
syntactically problematic) for subsequent notes in ties to only
require a duration, since by definition the pitch has already been
specified in the first note of the tie.

Yes and no: musically one can tie eis to f or cis to des (not that
LilyPond does a fabulous job with that).

My wording was somewhat accidental, but I'll point out 'require'.
Point taken re: your note about bar lines, bar number checks, etc.
And I don't have any resource to fund development, nor is this an
urgent issue.

Please don't get me wrong: just because I thankfully accept funds for
keeping me going on LilyPond development does not mean that you can
change my opinion about what is a bad idea in that manner. Politicians
tend to get generous salaries to prevent them being corruptible. That
approach does not work with me even though actually my life depends on
it. So it is really not a question of funding development in such a
case, rather one of convincing me that it is a good idea if I am
supposed to implement it.

That said, what about making the pitch *optional* in a tie?

A tie does not have a pitch. It is just something attaching to the
previous note.

So you could still do enharmonic ties:

c1 ~ | bis4 cis dis cis ~ | des1

But if stand-alone durations (like a '4' standing by itself)
could inherit the previous pitch (somewhat symmetric to how a
stand-alone pitch inherits the previous duration), one could
write:

c1 ~ | 4 cis dis cis ~ | 1

So is c4 c c 2 the same as c4 c4 c2 or as c4 c4 c4 c2 ? We can already
leave _off_ the duration, so if a duration occurs after a pitch, is the
pitch a note without explicit duration followed by a duration without
pitch, or are pitch and duration to be combined?

Given that q works so well in chordmode, is it rather non-trivial to
make 'q' work for single notes? Actually, I just read Marc Kohl's
post about using q in comping notation, and I see his point.

q was _explicitly_ changed to _only_ repeat chords _after_ extensive
discussion. The first approach was repetition of _both_ notes and
chords, and people were not happy with it.

Perhaps a separate letter could be used to refer to the previous note,
say perhaps p in this example?

Note names should be short enough on their own to make this not really
worth the trouble.

Personally, I rather like the ambiguous nature of shifted Renaissance
mostly rhythms expressed without the use of ties, but of course it is
not really fancied in modern notation.

Please link to an example, I'd be curious to take a look.

I find that an embarrassingly large number of scores is mangled with
modern conventions.
URL:http://www.mutopiaproject.org/ftp/JanequinC/Oyseaux-Endfassung/Oyseaux-Endfassung-a4.pdf
has a few minor examples in the tenor. Usually composers like Orlando
di Lasso, John Dowland and Josquin des Prez are chock full of those
non-tied notes crossing bar boundaries, but if they have been pulled
through Finale etc, this does not appear to be the rule.

--
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Gilles

Le Thu, 20 Sep 2012 12:46:14 +0200, Stefan Thomas  
kontrapunktste...@gmail.com a écrit:



\include changepitch.ly
 AV = { c8 c4 }
 av = #(define-music-function (parser location x) (ly:music?)
 #{
 \context Voice  { \changePitch \AV { $x $x } } { s8 ~ s8 } 
 #})
 \new Staff \relative c' {
 c4. \av es f4 fis4 \av fis g4
 }


In changePitch.ly, there is a special function called \samePitch which can  
be used for ties

[ It is shortly described in chapter 6 and 7 of changePitch-doc.pdf at
  http://gillesth.free.fr/Lilypond/changePitch/   ]

%
\include changePitch.ly

av = #(define-music-function (parser location x) (ly:music?)
 #{
  \changePitch \samePitch { c8 ~ c4 } $x
 #})

\new Staff \relative c' {
   c4. \av es f4
   fis4. \av fis g4
}
%
This example should work with any number of ties, but of course, will  
produce music with the rhythm you set as pattern.


--
Gilles

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Gilles




av = #(define-music-function (parser location x) (ly:music?)
  #{
   \changePitch \samePitch { c8 ~ c4 } $x
  #})


But of course, for this example, this will work without any added file :-)

av = #(define-music-function (parser location x) (ly:pitch?)
 #{
   $x 8 ~ $x 4
 #})

\new Staff \relative c' {
   c4. \av es f4
   fis4. \av fis g4
}


--
Gilles

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Gilles




But of course, for this example, this will work without any added file
av = #(define-music-function (parser location x) (ly:pitch?)
  #{
$x 8 ~ $x 4
  #})


... but it will fail with chords
[ ly:pitch? return false of course, for ees g ]

\new Staff \relative c' {
   c4. \av es g f4  % error
   }


Well ... stop of experimentations for me, for this evening.

--
Gilles

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

On Thu, Sep 20, 2012 at 09:55:35PM +0200, David Kastrup wrote:
 
  But if stand-alone durations (like a '4' standing by itself)
  could inherit the previous pitch (somewhat symmetric to how a
  stand-alone pitch inherits the previous duration), one could
  write:
 
  c1 ~ | 4 cis dis cis ~ | 1
 
 So is c4 c c 2 the same as c4 c4 c2 or as c4 c4 c4 c2 ?

Hmmm...  I just ran a test, and I was not previously aware that
'c 2' was valid.  I have been under the incorrect assumption that
whitespace was not allowed between a pitch/chord and its
duration.  In other words, I thought once whitespace has been
found, the previous token was complete.  Not currently the case,
apparently.  As I said earlier, I'm enjoying the learning
process.

Here's the rule I'm envisioning.  I'm going to change the horizontal
string to vertical for illustration:

c4  pitch specified, duration specified
c   pitch specified, duration (4) implied from previous duration
c   pitch specified, duration (4) implied from previous duration
2   duration specified, pitch (c) implied from previous pitch(es)

c4 c c 2 would be the same as c4 c4 c4 c2.

A pitch or chord with an explicit duration would have to have no
whitespace in between, as c2 or f a c1.  Thus, c2 c 2 would be
three notes, all half notes, all on pitch c, and f a c 1 would
be two chords, one with an implied duration not determinable from
this example, and one with a duration of a whole note.

Just a show of hands if anyone is reading this far, is the syntax

'c 4  c4 c  4  c4'

widely used (whitespace exaggerated)?  I'm not a frescobaldi user
nor any of the other lilypond-aware tools, but do they generate
lily-code that puts whitespace between pitches/chords and
durations?  Just wondering whether I'm an eccentric to always
write c4 and bes d2 and never f  1 or c e g16.

 q was _explicitly_ changed to _only_ repeat chords _after_ extensive
 discussion.  The first approach was repetition of _both_ notes and
 chords, and people were not happy with it.

I respect their happiness and propose no changes to q.  Absent my
proposed concept of an implied pitch, if a 'p' shortcut can be
implemented easily, I would find it to be a welcome and useful
addition.  If not, I'm accustomed to its absense, no there's no
harm in discussion.

 Note names should be short enough on their own to make this not really
 worth the trouble.

I don't consider 'character length' a relevant argument either
for or against.  Durations are short enough, too.  Even shorter,
in fact, since almost all durations are 1 or 2 characters, but
two-thirds of pitches (14 out of 21) are three characters (in
lily's default Dutch).  It's about compressing out the redundant
information in the lilypond input notation so that when you take
a motif and change the pitches involved you have fewer moving
parts to worry about.  I may be more alone in facing this problem
than I had thought.

So I'll leave my proposal at this stage.  I was not aware that

f





 4

was the same as

f4

so I can see that my proposal breaks the current syntax, which 
is certainly a drawback.  But I feel like I have at least
sufficiently outlined my idea.

Thanks again for all you do.

Jim



\relative c' {
  \partial 8
  d16 16 |
  8 16 16 8 16 16 g8 a b d,16 16 |
  8 16 16 g8 b a fis d 16 16 |
  8 16 16 8 16 16 g8 a b g16 b |
  d4~16 c b a g8 b g4 |
}

--


\relative c' {
  \partial 2
  r8 f4 8
  4 8 8~8 4 8~| 8 4. r8 f4 8 |
  4 8 8~8 4 8~| 2r8 f4 8 |
  4 8 8~8 4 8~| 8 4. r8 f4 8 |
  4 8 8~8 4 8~| 2r8 bes4 8 |
  4 8 8~8 4 8~| 8 4. r8 bes4 8 |
  4 8 8~8 4 8~| 4. r8 r f4 8 |
  4 8 8~8 4 8~| 8 4 8~8 8 4 |
  4 8 8~8 4 8 |
}


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Gilles gilles.thiba...@free.fr writes:

 av = #(define-music-function (parser location x) (ly:music?)
   #{
\changePitch \samePitch { c8 ~ c4 } $x
   #})

 But of course, for this example, this will work without any added file :-)

 av = #(define-music-function (parser location x) (ly:pitch?)
  #{
$x 8 ~ $x 4
  #})

 \new Staff \relative c' {
c4. \av es f4
fis4. \av fis g4
 }

You noticed yourself that this does not work well with chords, but it
also does not play overly well with \relative if you write \av c' for
example.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Jim Long lilyp...@umpquanet.com writes:

 On Thu, Sep 20, 2012 at 09:55:35PM +0200, David Kastrup wrote:
 
  But if stand-alone durations (like a '4' standing by itself)
  could inherit the previous pitch (somewhat symmetric to how a
  stand-alone pitch inherits the previous duration), one could
  write:
 
  c1 ~ | 4 cis dis cis ~ | 1
 
 So is c4 c c 2 the same as c4 c4 c2 or as c4 c4 c4 c2 ?

 Hmmm...  I just ran a test, and I was not previously aware that
 'c 2' was valid.  I have been under the incorrect assumption that
 whitespace was not allowed between a pitch/chord and its
 duration.  In other words, I thought once whitespace has been
 found, the previous token was complete.  Not currently the case,
 apparently.  As I said earlier, I'm enjoying the learning
 process.

 Here's the rule I'm envisioning.  I'm going to change the horizontal
 string to vertical for illustration:

 c4pitch specified, duration specified
 c pitch specified, duration (4) implied from previous duration
 c pitch specified, duration (4) implied from previous duration
 2 duration specified, pitch (c) implied from previous pitch(es)

 c4 c c 2 would be the same as c4 c4 c4 c2.

And c4 c4 c4 c2 the same as c4 c 4 c 4 c 2, namely as c4 c4 c4 c4 c4 c4 c2?
You say I have been under incorrect assumption that whitespace was not
allowed   But that means you either have to correct your
assumption, or you have make a new proposal including changes that make
your assumptions true.  Making spaces carry meaning between pitch and
duration is a rather large change.

 A pitch or chord with an explicit duration would have to have no
 whitespace in between, as c2 or f a c1.

Pitches can also be put into a variable, like
tonic=f

{ \tonic 2 }

So you want to force writing \tonic2 as well, I assume?  We can also
place them into variables.  Few minutes ago, someone else proposed a
function

av = #(define-music-function (parser location x) (ly:pitch?)
   #{
 $x 8 ~ $x 4
   #})

Now you can't write $x8 here since then Scheme would look for an
identifier x8.  You need the space.  Should then there be a difference
between writing one and writing two spaces?

 Thus, c2 c 2 would be
 three notes, all half notes, all on pitch c, and f a c 1 would
 be two chords, one with an implied duration not determinable from
 this example, and one with a duration of a whole note.

 Just a show of hands if anyone is reading this far, is the syntax

 'c 4  c4 c  4  c4'

 widely used (whitespace exaggerated)?

See the above music function.  It is wide enough use that the latest
posting in an _independent_ news thread actually uses exactly that.

 I'm not a frescobaldi user
 nor any of the other lilypond-aware tools, but do they generate
 lily-code that puts whitespace between pitches/chords and
 durations?

That depends on what the user enters.

 Just wondering whether I'm an eccentric to always write c4 and bes
 d2 and never f 1 or c e g 16.

No, you are not eccentric.  Most people do this by convention, but not
every convention makes sense changing into law.

 q was _explicitly_ changed to _only_ repeat chords _after_ extensive
 discussion.  The first approach was repetition of _both_ notes and
 chords, and people were not happy with it.

 I respect their happiness and propose no changes to q.  Absent my
 proposed concept of an implied pitch, if a 'p' shortcut can be
 implemented easily, I would find it to be a welcome and useful
 addition.

I am not convinced it will be worth the trouble regarding manual note
entry as note names are not hard or long to type.

The one thing that is calling for improvement is repeated use of the
same pitch in music functions that might see use inside of \relative
since getting the equivalent of \relative f { c' c' } is often
undesirable.  I am not sure that p (should or shouldn't it include
chords?) would really help here, one could also use
q =
#(define-music-function (parser location m) (ly:music?)
  (if (music-is-of-type? m 'rhythmic-event) #{ $m #} m))

And then use #{ \q $x q q q #} in a music function that might have
either e' or e' g' as its argument x.

 If not, I'm accustomed to its absense, no there's no harm in
 discussion.

 Note names should be short enough on their own to make this not
 really worth the trouble.

 I don't consider 'character length' a relevant argument either
 for or against.  Durations are short enough, too.

But leaving them off altogether rather than having to write something
else makes more of a difference.

 It's about compressing out the redundant information in the lilypond
 input notation so that when you take a motif and change the pitches
 involved you have fewer moving parts to worry about.  I may be more
 alone in facing this problem than I had thought.

That's more an editing than a representation problem in my opinion.

 So I'll leave my proposal at this stage.  I was not aware that

 f





  4

Re: Possible feature request for 'q' shorthand or tie syntax

On Fri, Sep 21, 2012 at 01:32:57AM +0200, David Kastrup wrote:
 
 Pitches can also be put into a variable, like
 tonic=f
 
 { \tonic 2 }
 
 So you want to force writing \tonic2 as well, I assume?  We can also
 place them into variables.  Few minutes ago, someone else proposed a
 function
 
 av = #(define-music-function (parser location x) (ly:pitch?)
#{
  $x 8 ~ $x 4
#})
 
 Now you can't write $x8 here since then Scheme would look for an
 identifier x8.

As I'm sure you're aware, in bash/sh scripts, many folks write

echo $x

when it is more correct to say

echo ${x}

This eliminates the mistake of $x8 when the programmer really
meant ${x}8

Is there a similar construct in Scheme?  Just guessing, but would

($x)8 ~ ($x)4

be valid (and functionally correct) syntax?  I have no real clue
what to do about your example of

{ \tonic 2 }

Do I understand correctly that these sorts of lilypond-isms
operate as plain text substitution?  Is this a job for a function
akin to \concat, like '\concat { \tonic 2 }'?  Perhaps \concat is
specific to markups, though.

And:

\tonic\tonic 2

yields 'ff 2', yes?  While

\tonic \tonic 2

yields 'f f 2' I presume.  So one has lots of control
concatenating variables, but less with literals?  How does one
concatenate a variable substitution and a literal in such a way
that there is no space between them, such as to get 'f2' or 'ff2'?


  Just wondering whether I'm an eccentric to always write c4 and bes
  d2 and never f 1 or c e g 16.
 
 No, you are not eccentric.  Most people do this by convention, but not
 every convention makes sense changing into law.

As an unconventional person, I am grateful for that -- I'd rather
be seen as unconventional than an outlaw!

 I am not convinced it will be worth the trouble regarding manual note
 entry as note names are not hard or long to type.

I once had a piece in 6 flats, and wondered whether it would look
better in 6 sharps, and search and replace (at least in vi!)
doesn't quite cut it for safely changing all the gis'es to aes'es
and the e's to fes'es, etc.  A melody that had a lot of tied
notes made the work harder than it would have been if I hadn't
had to change each of the multiple notes in the ties.  It would
have been so much nicer to change only the first note in the tie,
and have the remaining consecutively tied notes inherit their
pitch automatically.  Having a p shortcut (where p is the old q)
to repeat tied figures (either notes or chords) would have
sufficed in that instance.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

Jim Long lilyp...@umpquanet.com writes:

 On Fri, Sep 21, 2012 at 01:32:57AM +0200, David Kastrup wrote:
 
 Pitches can also be put into a variable, like
 tonic=f
 
 { \tonic 2 }
 
 So you want to force writing \tonic2 as well, I assume?  We can also
 place them into variables.  Few minutes ago, someone else proposed a
 function
 
 av = #(define-music-function (parser location x) (ly:pitch?)
#{
  $x 8 ~ $x 4
#})
 
 Now you can't write $x8 here since then Scheme would look for an
 identifier x8.

 As I'm sure you're aware, in bash/sh scripts, many folks write

 echo $x

 when it is more correct to say

 echo ${x}

Uh no, it isn't more correct.  It is often more correct to write
echo $x
or actually,
printf '%s\n' $x
since the command line processing of echo might react disfavorable,
depending on the sh version, when $x looks like an option.

 This eliminates the mistake of $x8 when the programmer really
 meant ${x}8

$x and $x8 are different uses.

 Is there a similar construct in Scheme?  Just guessing, but would

 ($x)8 ~ ($x)4

 be valid (and functionally correct) syntax?

It wouldn't, but in any case you surely realize that we have by far left
the region where the proposed cure has worse consequences than the
purported problem it is supposed to address.

 I have no real clue
 what to do about your example of

 { \tonic 2 }

 Do I understand correctly that these sorts of lilypond-isms
 operate as plain text substitution?

No.

 Is this a job for a function
 akin to \concat, like '\concat { \tonic 2 }'?

No.

 And:

 \tonic\tonic 2

 yields 'ff 2', yes?

No.

 While

 \tonic \tonic 2

 yields 'f f 2' I presume.

Like \tonic\tonic2 would.

 So one has lots of control
 concatenating variables, but less with literals?

No.

 How does one concatenate a variable substitution and a literal in such
 a way that there is no space between them, such as to get 'f2' or
 'ff2'?

There is no concept of concatenation involved here.  Spaces are not
significant between separate syntactic elements.  Not even in lyrics.
If you write
xxx=text
then \lyricmode{\xxx\xxx} and \lyricmode { \xxx \xxx } are both
equivalent to \lyricmode { text text } or \lyricmode{text   text}.

 I once had a piece in 6 flats, and wondered whether it would look
 better in 6 sharps, and search and replace (at least in vi!)
 doesn't quite cut it for safely changing all the gis'es to aes'es
 and the e's to fes'es, etc.

Why didn't you put

\transpose ges fis { ... }

around the passage?

 A melody that had a lot of tied notes made the work harder than it
 would have been if I hadn't had to change each of the multiple notes
 in the ties.  It would have been so much nicer to change only the
 first note in the tie, and have the remaining consecutively tied notes
 inherit their pitch automatically.  Having a p shortcut (where p is
 the old q) to repeat tied figures (either notes or chords) would have
 sufficed in that instance.

Wrong tool.  You could have also written

\displayLilyMusic \transpose ges fis { ... }

on the passage, then cut and paste the output back into your file if you
really wanted the _input_ to be changed.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax

2012-09-20 Thread Werner LEMBERG


 You could have also written
 
 \displayLilyMusic \transpose ges fis { ... }
 
 on the passage, then cut and paste the output back into your file if
 you really wanted the _input_ to be changed.

Nice trick!


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Possible feature request for 'q' shorthand or tie syntax