On 2016-12-21 17:05, tisimst wrote:
On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] <
ml-node+s1069038n198284...@n5.nabble.com> wrote:
On 2016-12-20 17:21, Abraham Lee wrote:
Maybe the question I really have is this: what does "given this
length _if possible_" mean and what go
ht? If so, then I think "forced-length" is not the right name for it.
Perhaps just "force" or "force-all"? Or is forced appearance not subject to
"collapse-length"?
Best,
Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/music-function-to-be-included-somewhere-in-scm-tp197960p198288.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2016-12-20 14:16, Knut Petersen wrote:
I still have one problem:
\score {
%\displayMusic
<<
\new Voice = "singleVoice" {
\relative {
a'4 a a a
\repeat volta 3 { b4 b b b }
c4 c c c
}
}
\displayMusic \new Lyrics \lyricsto "singleVo
On 2016-12-20 17:21, Abraham Lee wrote:
Yes, thanks for making this possible! It will be a great addition.
Thanks Abraham.
One question I have about having the two properties is how will the two be
reconciled in actual use? In other words, if collapse-length is larger than
forced-length, will
On Tue, Dec 20, 2016 at 7:41 AM, Paul wrote:
> Hi Knut, Werner, Alexander, and everyone,
>
> On 12/20/2016 08:47 AM, Knut Petersen wrote:
>
>> Hi Werner!
>>
>>> (length-limit-or-forced-length ,ly:dimension? "An automatically
generated lyric extender is suppressed if it would be shorter
Hi Knut, Werner, Alexander, and everyone,
On 12/20/2016 08:47 AM, Knut Petersen wrote:
Hi Werner!
(length-limit-or-forced-length ,ly:dimension? "An automatically
generated lyric extender is suppressed if it would be shorter than
this length. A forced lyric extender is given this length if
On Dec 20, 2016, at 08:23 , Werner LEMBERG wrote:
> Sorry, but I strongly dislike collapsing two properties into one, even
> if the values for the two properties are always the same. So please
> use `collapse-length' (`suppress-threshold', etc.) and
> `forced-length'.
This is wise.
—
Dan
> Nevertheless: two parameters would obfuscate the fact that the
> internal logic would always decide to use only one of those lengths
> and to ignore the other.
You could add something like
This parameter is mutually exclusive with @code{forced-length}.
to make this more visible.
> For the
Hi Werner!
(length-limit-or-forced-length ,ly:dimension? "An automatically
generated lyric extender is suppressed if it would be shorter than
this length. A forced lyric extender is given this length if
possible.")
Sorry, but I strongly dislike collapsing two properties into one, even
if t
>> I second the vote for collapse-length.
>
> Ok, next try:
>
> s/minimum-length/length-limit-or-forced-length/g
>
> (length-limit-or-forced-length ,ly:dimension? "An automatically
> generated lyric extender is suppressed if it would be shorter than
> this length. A forced lyric extender is
I'd advocate to keep minimum-length.
I second the vote for collapse-length.
Ok, next try:
s/minimum-length/length-limit-or-forced-length/g
(length-limit-or-forced-length ,ly:dimension? "An automatically
generated lyric extender is suppressed if it would be shorter than
this length. A
On 2016-12-16 19:13, Knut Petersen wrote:
[...] Have a look at the attached ly and the generated pdf ... and
comment on the chosen names and syntax. It should be
self-explanatory. [...]
One more idea (and I feel a bit bad for asking, since I dump the hard
work on you again - not sure if I'm ab
Hi all,
On 2016-12-16 19:13, Knut Petersen wrote:
Hi Paul, Alexander et. al!
I need to be very short as a rehearsal is waiting.
same here - I was and still am busy with pre-christmas performances.
I'd advocate to keep minimum-length.
I second the vote for collapse-length.
(I agree with y
Hi,
I tested the patch on my scores now (SATB choirs) and it works
perfectly. I applied the 0001-Automated-lyric-extenders.patch and it
adds the extenders where I had put them by hand before and a few other
reasonable places. Before, I made a per-syllable-decision whether I put
it or not. Now, a g
On 17.12.2016 00:23, Trevor Daniels wrote:
How about "collapse-length", which would be analogous to "collapse-height"?
+1
Simon
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> How about "collapse-length", which would be analogous to
> "collapse-height"? This exists already and means "Minimum height of
> system start delimiter. If equal or smaller, the bracket/brace/line
> is removed."
Thanks for finding this property name! I vote for it because of the
striking sim
Noeck wrote Friday, December 16, 2016 9:08 PM
> Am 16.12.2016 um 17:38 schrieb Alexander Kobel:
>> [2] Side Note: other proposed names for minimum-length so far:
>>
>> (1) minimum-space
>> (2) show-length
>> (3) hide-below-length
>> (4) hide-if-shorter-than
>> (5) minimum-visibility
>> (6) visib
>> (1) minimum-space
>> (2) show-length
>> (3) hide-below-length
>> (4) hide-if-shorter-than
>> (5) minimum-visibility
>> (6) visibility-threshold
>> (7) printing-threshold
>> (8) extender-threshold
>
> At a first glance, the property is still the same, just the
> behaviour for shorter extenders c
Am 16.12.2016 um 17:38 schrieb Alexander Kobel:
> [2] Side Note: other proposed names for minimum-length so far:
>
> (1) minimum-space
> (2) show-length
> (3) hide-below-length
> (4) hide-if-shorter-than
> (5) minimum-visibility
> (6) visibility-threshold
> (7) printing-threshold
> (8) extender-
Hi Paul, Alexander et. al!
I need to be very short as a rehearsal is waiting.
I'd advocate to keep minimum-length.
I also need some way to force an extender and to inhibit extender generation.
Forcing an individual extender should overrule a general inhibition of
extenders.
Details can be hidde
Hi Paul.
On 2016-12-16 16:02, Paul wrote:
Hi Knut and everyone,
Great to see your work which seems like a nice improvement. I just have
some thoughts on the implementation / use of properties.
We are just talking about grob properties and not context properties
right? In that case no need to
Hi Knut and everyone,
Great to see your work which seems like a nice improvement. I just have
some thoughts on the implementation / use of properties.
We are just talking about grob properties and not context properties
right? In that case no need to also create context properties as you do
On 2016-12-16 15:20, Urs Liska wrote:
Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik
:
On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen [...]
(define-public (forceExtender)
(once (overrideProperty '(LyricExtender force-extender) #t)))
into scm/music-functions.scm, lilypond does kno
On Fri, Dec 16, 2016 at 8:11 AM, David Nalesnik
wrote:
> On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
> wrote:
>> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>>
>>>
As your knowledge of scheme seems to be well developed, could you give
a scheme equivalent of
forceExtender = {
Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik
:
>On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
> wrote:
>> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>>
>>>
As your knowledge of scheme seems to be well developed, could you
>give
a scheme equivalent of
forceExtend
On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
wrote:
> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>
>>
>>> As your knowledge of scheme seems to be well developed, could you give
>>> a scheme equivalent of
>>>
>>> forceExtender = { \once \override LyricExtender.force-extender = ##t }
>>>
>>> that
Am 16.12.2016 um 14:38 schrieb Urs Liska:
As your knowledge of scheme seems to be well developed, could you give
a scheme equivalent of
forceExtender = { \once \override LyricExtender.force-extender = ##t }
that is acceptable to lilypond?
#(once (overrideProperty '(LyricExtender force-exten
Am 16. Dezember 2016 14:31:43 MEZ, schrieb Knut Petersen
:
>Hi Alexander et. al.!
>
>For me scheme still is the most counterintuitive way to program a
>computer. I believe that I discovered a
>thousand ways to trigger the message "[...] warning: Ignoring
>non-music expression". Could we switch
Hi Alexander et. al.!
For me scheme still is the most counterintuitive way to program a computer. I
believe that I discovered a
thousand ways to trigger the message "[...] warning: Ignoring non-music
expression". Could we switch
to something easy like postscript or x86 assembly? ;-))
As your
On 16.12.2016 08:30, Marc Hohl wrote:
Am 16.12.2016 um 02:09 schrieb Alexander Kobel:
Hi all.
[...]
What about hide-below-length or hide-if-shorter-than?
minimum-visibility?
We’re getting closer… I think ‘threshold’ describes the functionality
well; maybe visibility-threshold? printing-th
Am 16.12.2016 um 02:09 schrieb Alexander Kobel:
Hi all.
[...]
What about hide-below-length or hide-if-shorter-than?
minimum-visibility?
Just my 2ct,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listin
Hi all.
I second Werner's opinion that the goal should not necessarily be an
identical score, but a reasonable one. This time, we could even hope for
improvements: there will be some valid extenders that users simply did
not bother (or did not know how) to add, and I think convert-ly should
n
> What I meant is that I do believe that it is impossible to
> mechanically translate an old score to give exactly the same result
> with the new code.
`Exactly the same' should not be the goal IMHO – we have to freeze the
sources (similar to TeX) to achieve that. The output should rather be
`re
Am 15.12.2016 um 19:29 schrieb Werner LEMBERG:
We have convert-ly exactly for such changes.
I doubt that all corner cases like the Issue 1006 update given in
lyrextest.ly can be handled automatically ...
???
s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/
Yes, that would be e
On December 15, 2016 8:41:14 PM GMT+01:00, Simon Albrecht
wrote:
>On 15.12.2016 17:45, Alexander Kobel wrote:
>> (1) You can put the lyrics to all voices, as extenders are only
>> printed on melismata (unless explicitly enforced).
>> (2) You don't have to add __ in your lyrics anymore - it's don
Knut Petersen wrote Thursday, December 15, 2016 6:08 PM
>> Another common use case occurs when the lyrics in several verses have
>> melismata in different places. This is usually indicated with dashed slurs,
>> occasionally even with two such slurs starting on the same note. When
>> there are m
On 15.12.2016 17:45, Alexander Kobel wrote:
(1) You can put the lyrics to all voices, as extenders are only
printed on melismata (unless explicitly enforced).
(2) You don't have to add __ in your lyrics anymore - it's done
automagically (unless explicitly disabled).
(3) minimum-length (or some o
>> We have convert-ly exactly for such changes.
>
> I doubt that all corner cases like the Issue 1006 update given in
> lyrextest.ly can be handled automatically ...
???
s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/
Werner
___
Am 15.12.2016 um 16:46 schrieb Werner LEMBERG:
We have convert-ly exactly for such changes.
I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly
can be handled automatically ...
cu,
Knut
___
lilypond-devel mailing list
Hi Urs!
I'd suppose that within words hyphens are implicitly created like before?
Yes. Nothing in this patch touches the hyphen engraver ...
cu,
Knut
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lily
Hi Trevor,
Another common use case occurs when the lyrics in several verses have
melismata in different places. This is usually indicated with dashed slurs,
occasionally even with two such slurs starting on the same note. When
there are many of these the easiest way is simply to turn off auto-
Am 15. Dezember 2016 18:58:13 MEZ, schrieb Knut Petersen
:
>Am 15.12.2016 um 17:17 schrieb Francisco Vila:
>>
>> Excuse my brevity for now, but I think lyrics extenders are meant
>only for the last syllable of a word. What does Gould say, for example?
>I can check later, @home.
>>
>I don't know
Am 15.12.2016 um 17:17 schrieb Francisco Vila:
Excuse my brevity for now, but I think lyrics extenders are meant only for the
last syllable of a word. What does Gould say, for example? I can check later,
@home.
I don't know what Gould says, but you are right. Nothing else is proposed.
Knut
Alexander Kobel and Knut Petersen wrote Thursday, December 15, 2016 4:45 PM
OK, thanks for your explanations. Clearly the patch is an improvement for this
use case:
> On 2016-12-15 17:19, Trevor Daniels wrote:
>
> Currently, I set minimum-length = 0 in all Lyric contexts so that I
> can place i
On 2016-12-15 17:19, Trevor Daniels wrote:
Knut Petersen wrote Thursday, December 15, 2016 1:55 PM
minimum-length in my patch means:
- Don't generated automatic extenders if it's impossible to give them
minimum-length.
- Use minimum-length for forced extenders at unusual places (single note) i
Am 15.12.2016 um 17:19 schrieb Trevor Daniels:
Currently, I set minimum-length = 0 in all Lyric contexts so that I
can place identical lyrics in several voices, all with extenders, but
the extenders appear in the score only when they correspond to melismata.
In other words the extender is permit
Excuse my brevity for now, but I think lyrics extenders are meant only for
the last syllable of a word. What does Gould say, for example? I can check
later, @home.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listin
Knut Petersen wrote Thursday, December 15, 2016 1:55 PM
> minimum-length in my patch means:
> - Don't generated automatic extenders if it's impossible to give them
> minimum-length.
> - Use minimum-length for forced extenders at unusual places (single note) if
> possible.
>
> I think the most
On 15.12.2016 17:17, Francisco Vila wrote:
I think lyrics extenders are meant only for
the last syllable of a word.
Of course they are. That’s why the proposed code checks for any hyphens
before adding an extender. Any syllable which is not the last of a word
must have a hyphen.
Best, Simon
>> What about `minimum-space' or `show-length'?
>
> minimum-length has been a property of the engraver for a long
> time. It never implemented the functionality you would expect from
> a minimum-length property at other places of lilypond. Removing it
> would break older scores more than ne
Hi Knut, hi everybody.
On 2016-12-15 13:34, Knut Petersen wrote:
Hi Alexander, hi everybody!
And we might need to offer a way to remove a LyricExtender event.
Unless we go the radical route and ...
After a bit of thinking I'd say: go the radical route.
Attached is a patch against current ma
On 15.12.2016 01:34, Alexander Kobel wrote:
any use case for hyphen + extender?
No.
Best, Simon
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 15.12.2016 13:34, Knut Petersen wrote:
After a bit of thinking I'd say: go the radical route.
Attached is a patch against current master that implements it that way.
I like it, and I’d say: go ahead.
Best, Simon
___
lilypond-devel mailing list
l
Hi Werner!
Nice! However, I'm not happy with the name `minimum-length': It
implies that this value sets the minimum length of extender lines,
which is not true.
What about `minimum-space' or `show-length'?
minimum-length has been a property of the engraver for a long time.
It never implem
> Attached is a patch against current master that implements it that
> way. An additional no-extender property is added that can only be
> overridden by the force-extender property.
Nice! However, I'm not happy with the name `minimum-length': It
implies that this value sets the minimum length of
Hi Alexander, hi everybody!
And we might need to offer a way to remove a LyricExtender event. Unless we go
the radical route and ...
After a bit of thinking I'd say: go the radical route.
Attached is a patch against current master that implements it that way. An
additional no-extender prope
On 2016-12-14 19:46, Knut Petersen wrote:
Am 14.12.2016 um 18:03 schrieb Simon Albrecht:
On 14.12.2016 14:54, Knut Petersen wrote:
With a music function \autoextenders that adds extender events to
every syllable you
- can be sure never to forget extenders,
- can be sure never to generate too sh
On 2016-12-14 21:36, Noeck wrote:
Hi Alexander,
in your example, the last line is just a mockup, isn't it? It is not
done by the proposed function? The extender after "We" in the last line
is unexpected for me.
Hi,
not a mockup, but not the real thing either. I sent this from a PC with
the "
Hi Alexander,
in your example, the last line is just a mockup, isn't it? It is not
done by the proposed function? The extender after "We" in the last line
is unexpected for me.
Cheers,
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https:
Am 14. Dezember 2016 18:03:09 MEZ, schrieb Simon Albrecht
:
>On 14.12.2016 14:54, Knut Petersen wrote:
>> With a music function \autoextenders that adds extender events to
>> every syllable you
>> - can be sure never to forget extenders,
>> - can be sure never to generate too short extenders
>>
Am 14.12.2016 um 18:03 schrieb Simon Albrecht:
On 14.12.2016 14:54, Knut Petersen wrote:
With a music function \autoextenders that adds extender events to every
syllable you
- can be sure never to forget extenders,
- can be sure never to generate too short extenders
- can use the same lyrics de
On 14.12.2016 14:54, Knut Petersen wrote:
With a music function \autoextenders that adds extender events to
every syllable you
- can be sure never to forget extenders,
- can be sure never to generate too short extenders
- can use the same lyrics definition for voices that require extenders
at d
Hi Knut,
On Wed, Dec 14, 2016 at 3:16 AM, Knut Petersen
wrote:
> Hi everybody!
>
> There is a discussion on lilypond-user with the target to allow automated
> lyric extenders
> to lilypond. One part of that is a patch to clean and extend
> lyric_extender.cc.
>
> To allow automated creation of lyr
Hi Urs!
My gut feeling says: Yes, this is an improvement and should be there by
default. IIUC the reason why this has to be discussed is because that
could change/break existing scores, right?
If so, could you please think about an example where the patch would
have a negative impact that can't
Hi Urs, hi all.
On 2016-12-14 11:18, Urs Liska wrote:
Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
To allow automated creation of lyric extenders a helper function is
needed
... that does exactly this, adding extenders everywhere.
IMHO, the actual question to decide upon is: Do we want th
Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
>> To allow automated creation of lyric extenders a helper function is
>> needed
>
> ... that does exactly this, adding extenders everywhere.
>
> IMHO, the actual question to decide upon is: Do we want this to be
> enabled by default? IIUC, the fact
Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
>> Q2: Obviously the definition of \autoextenders does not match the coding
>> style used in scm/*. It does not even
>> work if it is added to music-functions.scm. Some advice is needed ...
>> the extending-manual is not a real help in
>> this case.
Hi Knut, hi all.
On 2016-12-14 10:16, Knut Petersen wrote:
Hi everybody!
There is a discussion on lilypond-user with the target to allow
automated lyric extenders to lilypond. One part of that is a patch
to clean and extend lyric_extender.cc.
Knut is playing down his work here. The crucial po
Hi everybody!
There is a discussion on lilypond-user with the target to allow automated lyric
extenders
to lilypond. One part of that is a patch to clean and extend lyric_extender.cc.
To allow automated creation of lyric extenders a helper function is needed.
Putting the
following code into a
69 matches
Mail list logo
