Re: C++ question:

[David Kastrup]

Knut Petersen  writes:

> Hi David!
>> Uh what?
>>
>> If you want to change the dimensions of a stencil copy, you can just do
>>
>> Stencil wd0 = orig;
>> wd0.set_empty (false);
>
> I use the following code to emit hyphens (stencil ds) and whiteout boxes 
> (stencil ws)
> in lyric-hyphen.cc:
>
>   Stencil total;
>   for (int i = 0; i < hyphens; i++)
> { // ok
>   Stencil ds = dash_stencil;
>   ds.translate_axis (span_points[LEFT] + start_space +
>  i * (dash_period + dash_length), X_AXIS);
>   total.add_stencil (ds);
>   if (whiteout > 0.0 )
> {
>   Box wb (Interval (0, dash_length + 2 * whiteout * lt),
>   Interval (h - whiteout * lt, h + th + whiteout * lt));
>   Stencil ws (Lookup::round_filled_box (wb, 0.8 * lt));
>   ws = ws.in_color (1.0, 0.0, 0.0);
>   ws.translate_axis (span_points[LEFT] + start_space + i * 
> (dash_period
>  + dash_length) - whiteout * lt, X_AXIS);
>   ws.set_empty(false); // <== Does not help against collision 
> detection
>   total.add_stencil (ws);
> }
> }
>
> As you can see in the attached jpgs, a collision of the whiteout box moves 
> the last lyric line down.
> set_empty(true) nor anything else I tried does change anything.

Uh, you set the dimensions to 0,0 _after_ moving the thing to its place.
That would make the remaining point stick out seriously wide of the
actual glyph.  Maybe move the set_empty before the translate_axis?

> The ugly hack to define a markup property containing a filled box inside a 
> \with-dimensions zero
> for both axes, interpret, scale and move the stencil as required
> works. But there must be a better way ...

Your markup example does _not_ include any shift before zeroing the
bounding boxes of the whiteout rectangle.  So it would appear like you
don't actually do the same thing here.

> WithUglyHack.jpg shows the targeted result ...



-- 
David Kastrup

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

PATCHES - Countdown for January 21st

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on
January 23rd.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/



Push:


5032 Using \with with \chords, \drums and \figures - Trevor Daniels
https://sourceforge.net/p/testlilyissues/issues/5032
http://codereview.appspot.com/313330043


5029 Implement shorten-pair for Hairpin - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5029
http://codereview.appspot.com/315350043


Countdown: No patches in countdown at this time.


Review:


5035 Remove midi.c - Graham Percival
https://sourceforge.net/p/testlilyissues/issues/5035
http://codereview.appspot.com/7016046/\


185 RhythmicStaff squishing chords should produce single notes - Trevor 
Daniels

https://sourceforge.net/p/testlilyissues/issues/185
http://codereview.appspot.com/6495107](


New:


5038 Web: Review GSoC page introduction - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5038
http://codereview.appspot.com/315410043


5037 web: GSoC page: Add SMuFL project - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5037
http://codereview.appspot.com/318330043


5034 Fully document the short forms of the mode-changing commands
https://sourceforge.net/p/testlilyissues/issues/5034
http://codereview.appspot.com/313380043


Waiting:


4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/4600
http://codereview.appspot.com/265160043


Regards

James


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

Re: How to create a Midi File out of Lilypond for Multi-voice Staff

[Mungo1981]

Dear Community,
Im sorry to use the wrong Directory.
But your advise hav help me a lot.
So new Im ready to write Multiple Voice Midi Files in Lilypond.

THanks

Mungo 1981



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-create-a-Midi-File-out-of-Lilypond-for-Multi-voice-Staff-tp199149p199411.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

Re: C++ question:

[Knut Petersen]

Am 20.01.2017 um 13:35 schrieb David Kastrup:

Knut Petersen  writes:


Hi David!

Uh what?

If you want to change the dimensions of a stencil copy, you can just do

Stencil wd0 = orig;
wd0.set_empty (false);

I use the following code to emit hyphens (stencil ds) and whiteout boxes 
(stencil ws)
in lyric-hyphen.cc:

   Stencil total;
   for (int i = 0; i < hyphens; i++)
 { // ok
   Stencil ds = dash_stencil;
   ds.translate_axis (span_points[LEFT] + start_space +
  i * (dash_period + dash_length), X_AXIS);
   total.add_stencil (ds);
   if (whiteout > 0.0 )
 {
   Box wb (Interval (0, dash_length + 2 * whiteout * lt),
   Interval (h - whiteout * lt, h + th + whiteout * lt));
   Stencil ws (Lookup::round_filled_box (wb, 0.8 * lt));
   ws = ws.in_color (1.0, 0.0, 0.0);
   ws.translate_axis (span_points[LEFT] + start_space + i * (dash_period
  + dash_length) - whiteout * lt, X_AXIS);
   ws.set_empty(false); // <== Does not help against collision detection
   total.add_stencil (ws);
 }
 }

As you can see in the attached jpgs, a collision of the whiteout box moves the 
last lyric line down.
set_empty(true) nor anything else I tried does change anything.

Uh, you set the dimensions to 0,0 _after_ moving the thing to its place.
That would make the remaining point stick out seriously wide of the
actual glyph.  Maybe move the set_empty before the translate_axis?


Not even the following code shows any improvement:

  Stencil total;
  for (int i = 0; i < hyphens; i++)
{
  Stencil ds = dash_stencil;
  ds.translate_axis (span_points[LEFT] + start_space +
 i * (dash_period + dash_length), X_AXIS);
  total.add_stencil (ds);
  if (whiteout > 0.0 )
{
  Box wb (Interval (0, dash_length + 2 * whiteout * lt),
  Interval (h - whiteout * lt, h + th + whiteout * lt));
  Stencil ws;
  ws.set_empty(false);
  ws = (Lookup::round_filled_box (wb, 0.8 * lt));
  ws.set_empty(false);
  ws = ws.in_color (1.0, 0.0, 0.0);
  ws.translate_axis (span_points[LEFT] + start_space + i * (dash_period
 + dash_length) - whiteout * lt, X_AXIS);
  ws.set_empty(false);
  total.add_stencil (ws);
  total.set_empty(false);
}
}

  total.translate_axis (-me->relative_coordinate (common, X_AXIS), X_AXIS);
  total.set_empty(false);
  return total.smobbed_copy ();
}

Knut

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

Re: C++ question:

[David Kastrup]

Knut Petersen  writes:

>> Uh, you set the dimensions to 0,0 _after_ moving the thing to its place.
>> That would make the remaining point stick out seriously wide of the
>> actual glyph.  Maybe move the set_empty before the translate_axis?
>
> Not even the following code shows any improvement:
>
>   Stencil total;
>   for (int i = 0; i < hyphens; i++)
> {
>   Stencil ds = dash_stencil;
>   ds.translate_axis (span_points[LEFT] + start_space +
>  i * (dash_period + dash_length), X_AXIS);
>   total.add_stencil (ds);
>   if (whiteout > 0.0 )
> {
>   Box wb (Interval (0, dash_length + 2 * whiteout * lt),
>   Interval (h - whiteout * lt, h + th + whiteout * lt));
>   Stencil ws;
>   ws.set_empty(false);
>   ws = (Lookup::round_filled_box (wb, 0.8 * lt));
>   ws.set_empty(false);
>   ws = ws.in_color (1.0, 0.0, 0.0);
>   ws.translate_axis (span_points[LEFT] + start_space + i * 
> (dash_period
>  + dash_length) - whiteout * lt, X_AXIS);
>   ws.set_empty(false);
>   total.add_stencil (ws);
>   total.set_empty(false);
> }
> }
>
>   total.translate_axis (-me->relative_coordinate (common, X_AXIS), X_AXIS);
>   total.set_empty(false);
>   return total.smobbed_copy ();
> }

Sigh.  Why do you use set_empty _after_ translation?  That makes the
remaining point stick out from the actual glyph.  And of course, it
totally moots any effect of set_empty before translation.

-- 
David Kastrup

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

Re: C++ question:

[Knut Petersen]

Hi David!

Uh what?

If you want to change the dimensions of a stencil copy, you can just do

Stencil wd0 = orig;
wd0.set_empty (false);


I use the following code to emit hyphens (stencil ds) and whiteout boxes 
(stencil ws)
in lyric-hyphen.cc:

  Stencil total;
  for (int i = 0; i < hyphens; i++)
{ // ok
  Stencil ds = dash_stencil;
  ds.translate_axis (span_points[LEFT] + start_space +
 i * (dash_period + dash_length), X_AXIS);
  total.add_stencil (ds);
  if (whiteout > 0.0 )
{
  Box wb (Interval (0, dash_length + 2 * whiteout * lt),
  Interval (h - whiteout * lt, h + th + whiteout * lt));
  Stencil ws (Lookup::round_filled_box (wb, 0.8 * lt));
  ws = ws.in_color (1.0, 0.0, 0.0);
  ws.translate_axis (span_points[LEFT] + start_space + i * (dash_period
 + dash_length) - whiteout * lt, X_AXIS);
  ws.set_empty(false); // <== Does not help against collision detection
  total.add_stencil (ws);
}
}

As you can see in the attached jpgs, a collision of the whiteout box moves the 
last lyric line down.
set_empty(true) nor anything else I tried does change anything.

The ugly hack to define a markup property containing a filled box inside a 
\with-dimensions zero
for both axes, interpret, scale and move the stencil as required works. But 
there must be a better way ...
WithUglyHack.jpg shows the targeted result ...

 Knut

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

Re: Back in the Pond

[David Kastrup]

David Kastrup  writes:

> David Kastrup  writes:
>
>> Alexander Kobel  writes:
>>
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>>
>> Uh, I thought that people replaced extenders right now?
>>
>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
>>
>> The container context issue would want to be tackled by a melisma
>> translator (working both in Midi and PDF since we want the same results
>> there).  That work is unfinished and somewhat pervasive.  So it's a bit
>> unlikely for 2.20.
>
> I have to grudgingly admit though that picking up the pieces of the
> melisma translator would be rather more appropriate for 2.20 (as it
> wraps up half-finished functionality already in LilyPond) than working
> on arbitrary-precision support.
>
> Well, I'll have to take another look to see what got me stuck last time
> around.

Ugh, now I remember.  The Melisma_translator needs to work reliably in
Midi.  For this it needs to know where slurs start and end.  But the
complex logic matching slur starts and ends based on spanner-id actually
is buried in the slur-engraver and works with actual spanners (some kind
of grob).  Which means that its logic is just not accessible to the
Melisma_translator and would need to get duplicated.

That's where I ran into molasses.

Taking this up where I left it with a fresh mind now, I think that the
best course would be having a Spanner_connect_translator not working
with grobs/spanners but rather the originating events and tieing _those_
together based on values of spanner-id.

Great idea.  Which would totally throw at least half a spanner in the
works of the (almost complete?) multiple-spanner GSoC project.  Which
has already triggered (committed) changes in spanner-id user interfaces
and organisation but those would survive.

This sucks.  I'll have to brood somewhat more over it.

-- 
David Kastrup

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

Re: Back in the Pond

[Knut Petersen]

Hi everybody!


+1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
... } has the potential to be a killer feature w.r.t. usability for
choir literature (especially combined with the upcoming automatic
extenders). Unfortunately, assignment of lyrics to *container*
contexts does not work (at least, not reliably), and extender
generation is completely defunct.

Uh, I thought that people replaced extenders right now?

Well, may I cite the notation manual:

"extender lines cannot be drawn when there is no associated voice."

The autoextender patch only adds extenders at places where extenders can be 
added without it.

Prior to Alexanders bugreport I wasn't even aware that something like \lyricsto 
ChoirStaff ... could work.
If we get it to work it might be a good idea to document the feature in the 
notation manual.


I reported that in a thread from 2016-12-26 on bug-lilypond, but could
not motivate any supporters yet.


I verified that the changes made by the autoextender patch are unrelated
but decided that probably the person who added the feature is the most
obvious candidate to fix it ;-)

Currently I work on  LyricHyphen enhancements. After I know if the autoextender
patch will be accepted I'll send a patch that will implement the following 
features:

1: use either a rounded box or an arbitrary markup as a hyphen. Solves issue 
#1255.

2: allow to whiteout every hyphen individually instead of the whole set of 
hyphens
 generated for a HyphenEvent (Yes, I know that some people do not like that)

3: allow minimum distance to be automatically set to the with of the hyphen 
stencil.

4: Improved placement of hyphens:
4a: If the spanner starts at the beginning of a system, place the first hyphen
at the start of the system.
4b: If the spanner ends at the end of the system, place the last hyphen at the 
end of
the system
4c: If neither 4a nor 4b apply: In cases where the old code uses n hyphens  use 
n+1
hyphens if enough place between the first/last syllable and the hyphens remain.
'Enough place' might be changed by a property.

Feature 4 gives much better results if there are multiple stanzas.

I think that these proposed changes could also be a something worth to be
integrated in a lilypond 2.20.

Knut

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

Re: Back in the Pond

[David Kastrup]

David Kastrup  writes:

> Alexander Kobel  writes:
>
>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>> ... } has the potential to be a killer feature w.r.t. usability for
>> choir literature (especially combined with the upcoming automatic
>> extenders). Unfortunately, assignment of lyrics to *container*
>> contexts does not work (at least, not reliably), and extender
>> generation is completely defunct.
>
> Uh, I thought that people replaced extenders right now?
>
>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>> not motivate any supporters yet.
>
> The container context issue would want to be tackled by a melisma
> translator (working both in Midi and PDF since we want the same results
> there).  That work is unfinished and somewhat pervasive.  So it's a bit
> unlikely for 2.20.

I have to grudgingly admit though that picking up the pieces of the
melisma translator would be rather more appropriate for 2.20 (as it
wraps up half-finished functionality already in LilyPond) than working
on arbitrary-precision support.

Well, I'll have to take another look to see what got me stuck last time
around.

-- 
David Kastrup

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

Re: LilyDev 5.0 released

[Federico Bruni]

Il giorno mar 3 gen 2017 alle 21:50, Federico Bruni 
 ha scritto:
To everybody who installed LilyDev 5.0: do you see some icons missing 
in the menu? (e.g. under System Tools> qterminal)


It seems that the icon theme is not set by default. Probably a debian 
bug, but I've not investigated.
You can set it in the menu Preferences>LxQT settings>Appearance>Icons 
Theme and choose one of those listed (e.g. Adwaita).




This is fixed now:
https://github.com/fedelibre/LilyDev/commit/8c321cb1cc2212aaa6528b1784b76f825debebff

I have a new release ready, but I must postpone to Monday, because I'm 
about to leave my office (and uploading the image to github takes a lot 
of time).





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

Re: LilyDev 5.0 released

[Federico Bruni]

Il giorno mar 3 gen 2017 alle 21:22, Federico Bruni 
 ha scritto:
Il giorno mer 28 dic 2016 alle 21:29, Graham Percival 
 ha scritto:

On Wed, Dec 28, 2016 at 06:24:48PM +0100, Federico Bruni wrote:

 The default should be httpredir:
  httpredir.debian.org

 Have you tried again? I hope that it's just a temporary network 
problem.


Yes, seems to have been temporary.  I tried it 3 times yesterday,
but now it's working.


Ok


Well, it never worked for me.
I tried maybe 3 times this week.

I was using virt-manager which allows to easily switch to another 
console in the guest and I saw that the network was not working during 
the installation (cannot ping a domain, cannot run ipconfig). No time 
now to investigate...



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

Re: Back in the Pond

[David Kastrup]

Graham Percival  writes:

> On Thu, Jan 19, 2017 at 02:01:40PM +0100, David Kastrup wrote:
>> "Trevor Daniels"  writes:
>> 
>> > David, you wrote Thursday, January 19, 2017 10:18 AM
>> >
>> >> it would appear that my excursion into a regular workplace ended up
>> >> somewhat shortlived.
>
> Ouch, that sucks.  :(
>
>> Well, the 2.20 release stoppers of course should be tackled.  Step 1
>> IIRC was to contact the persons last having worked on three issues you
>> identified.  Uhm, I'd be glad to leave that in Graham's hand, at least
>> until it's clear that addressing those issues will have to be done by
>> somebody else.
>
> Right, I haven't forgotten, but I likely won't get to this until
> Feb.  I've had a poor (and rare) reaction to some recent
> vaccinations [1], and lost most of 5 days in the past two weeks.

That sucks.  I hope "lost to productive work" rather than "no longer
accessible to my memory": I find the latter ailment more scary though
either is a nuisance.

> I'm not certain how much energy I'll have after catching up on
> work, and getting some work done for a Feb 4 board meeting for an
> (offline) amateur music organization.

Understood.  I'll give it a try then.

-- 
David Kastrup

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

Re: python include path oddity with "make install"

[David Kastrup]

Graham Percival  writes:

> At the moment, doing:
>   mkdir build
>   cd build
>   ../configure --prefix=$HOME/.local/
>   make
>   make install
>
> results in python files which can't find lilylib.  This is
> installed to:
> $(PREFIX)/share/lilypond/$(VERSION)/python/
>
> The relocation is supposed to be handled by:
> python/relocate-preamble.py.in
> but it seems to assume that "current" is a valid $(VERSION).
> I know that GUB does add a symlink for "current", but that doesn't
> appear to happen for "make install".
>
>
> I can see a few different ways forward:
> - figure out why the @lilypond_datadir@ replacement is going to
>   /usr/...  instead of $(PREFIX)
> - add a "current" symlink
> - add some more directories to the system path in
>   relocate-preamble.py.in
>
> Unfortunately, I've lost a lot of steam on this and am not likely
> to return to it until Feb.  I'd rather not hold back the
> pure-python midi2ly change, so it would be awesome if somebody
> else could clarify matters and/or fix it.

Assuming C does not play into it (its own use of lilypond_datadir does
not appear to have any connection to the basic configure/install
process' variants of it: it merely references TOPLEVEL_VERSION as far as
I can see at a glance), I see the following data points here:

dak@lola:/usr/local/tmp/lilypond$ git grep 'lilypond_datadir'|grep -v '^lily/'
Documentation/misc/ChangeLog-1.5:   * make/substitute.make (ATVARIABLES): 
Add local_lilypond_datadir.
Documentation/misc/ChangeLog-2.1:   * make/substitute.make (ATVARIABLES): 
Add lilypond_datadir.
GNUmakefile.in:INSTALLATION_DIR=$(local_lilypond_datadir)
GNUmakefile.in: $(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir)
config.make.in:build_lilypond_datadir = @build_package_datadir@
config.make.in:local_lilypond_datadir = $(local_package_datadir)
config.make.in:lilypond_datadir = $(local_package_datadir)
config.make.in:vimdir = $(lilypond_datadir)/vim
ly/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/ly
make/substitute.make:  lilypond_datadir\
make/substitute.make:  local_lilypond_datadir\
mf/GNUmakefile:INSTALLATION_DIR = $(local_lilypond_datadir)/fonts/source
mf/GNUmakefile:INSTALLATION_OUT_DIR1 = $(local_lilypond_datadir)/fonts/otf
mf/GNUmakefile:INSTALLATION_OUT_DIR2 = $(local_lilypond_datadir)/fonts/svg
mf/GNUmakefile:INSTALLATION_OUT_DIR3 = $(local_lilypond_datadir)/fonts
ps/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/ps
python/GNUmakefile:INSTALLATION_OUT_DIR1=$(local_lilypond_datadir)/python
python/relocate-preamble.py.in:for d in ['@lilypond_datadir@',
scm/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/scm
scripts/build/GNUmakefile:#INSTALLATION_OUT_DIR1=$(local_lilypond_datadir)/scripts
tex/GNUmakefile:INSTALLATION_DIR = $(local_lilypond_datadir)/tex
tex/GNUmakefile:-rmdir $(DESTDIR)$(local_lilypond_datadir)/tex

so we have sort of a parallel diversion of both local_lilypond_datadir
and lilypond_datadir to local_package_datadir .

Judging from the use of $(DESTDIR)$(local_lilypond_datadir), this may be
a relative path.  Could that be part of the problem?

-- 
David Kastrup

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

Re: C++ question:

[David Kastrup]

Knut Petersen  writes:

> Hi everybody!
>
>
> Is there an equivalent of  \with-dimensions #'(0 . 0) #'(0 . 0) that can be 
> used on a stencil within the C++ part of lilypond?
>
> If not: I thought I could work around that problem  by constructing and using 
> a markup:
>
>   SCM properties = Font_interface::text_font_alist_chain (me);
>   SCM ws_mol = Text_interface::interpret_markup (me->layout 
> ()->self_scm (), properties, ly_string2scm ("\\markup {\\bold foo}"));
>   Stencil ws = *unsmob (ws_mol);
>
> That emits "\markup {\bold foo}" instead of the result of the interpreted 
> markup. If I define a property test-markup,
> replace 'ly_string2scm ("\\markup {\\bold foo}")' with something like  
> 'me->get_property ("test-markup")' the code works
> as expected. So ly_string2scm is not enough ... I need a string2markup(). Any 
> idea?

Uh what?

If you want to change the dimensions of a stencil copy, you can just do

Stencil wd0 = orig;
wd0.set_empty (false);

(set_empty (false) sets the bounding dimensions to 0,0 like
point-stencil does, set_empty (true) to nothing like overriding the
stencil with ##f does).

-- 
David Kastrup

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

Re: Back in the Pond

[Knut Petersen]

The autoextender patch only adds extenders at places where extenders
can be added without it.

That does not sound like we should remove __ from lyrics to me.


I don't understand that comment.


With the autoextender patch there will be an extender if a melisma is

detected and there is enough place for an extender.


At places where an extender token "__" is/would be ignored by current master

(that's the problem Alexander describes) the autoextender patch does not

change anything.


Knut




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

Re: Back in the Pond

[David Kastrup]

Knut Petersen  writes:

> Hi everybody!
>
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>> Uh, I thought that people replaced extenders right now?
> Well, may I cite the notation manual:
>
> "extender lines cannot be drawn when there is no associated voice."
>
> The autoextender patch only adds extenders at places where extenders
> can be added without it.

That does not sound like we should remove __ from lyrics to me.

-- 
David Kastrup

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

Re: Back in the Pond

[Alexander Kobel]

Hi (almost) everybory (dropping -user)!

On 2017-01-20 10:20, Knut Petersen wrote:
> Hi everybody!
> 
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>> Uh, I thought that people replaced extenders right now?
> Well, may I cite the notation manual:
> 
> "extender lines cannot be drawn when there is no associated voice."
> 
> The autoextender patch only adds extenders at places where extenders can be 
> added without it.

Good catch. From what I spotted, the missing piece is indeed the association 
between lyrics and voices. Note that it's not just extenders that are broken: 
I'm not entirely confident whether the lyrics placement is what it is supposed 
to be, in case there are different rhythms within a container context and 
outside. At least IIUC the searchForVoice and associatedVoice{,Type,Context} 
properties.

As soon as there is an associated voice (e.g., through the searchForVoice 
algorithm), extenders /are/ drawn. The problem with that approach: AFAICS it is 
not possible to restrict the search to a certain context. E.g., for 
ChoirStaves, you'd only want the search to extend to Voices that are 
(currently) printed on some Staff that is part of the ChoirStaff.
For scores that only consist of one ChoirStaff, the workaround I gave in the 
other thread actually works.

IIUC, the melisma translator you are talking about would ensure that moments 
are skipped where all candidate associated voices have melisma_busy? That's 
another useful feature, obviously, but AFAICS the lyric-voice-correspondence 
should be somewhat independent.
Anyway, I'll stop handwaving and speculating here without a good cause. If you 
want me to proceed, you know where to find me...

> Prior to Alexanders bugreport I wasn't even aware that something like 
> \lyricsto ChoirStaff ... could work.
> If we get it to work it might be a good idea to document the feature in the 
> notation manual.

Yes. In fact, Trevor already mentioned that he will at least modify the SATB 
template to use that feature and document it there. But obviously, once 
everything is reliable, NR 2.1.2 "Polyphony with shared lyrics" could be 
simplified drastically, with the current docs merely an emergency or special 
purpose option...

>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
> 
> I verified that the changes made by the autoextender patch are unrelated
> but decided that probably the person who added the feature is the most
> obvious candidate to fix it ;-)

To make sure: this wasn't a complaint about lack of interest from my side. And 
yes, I also double-checked that the auto extenders aren't the culprit...

> Currently I work on  LyricHyphen enhancements. After I know if the 
> autoextender
> patch will be accepted I'll send a patch that will implement the following 
> features: [...]

Whoo! Nice!


Cheers,
Alexander

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

Re: Back in the Pond

[Alexander Kobel]

On 2017-01-20 10:46, David Kastrup wrote:
> Knut Petersen  writes:
> 
>> Hi everybody!
>>
 +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
 ... } has the potential to be a killer feature w.r.t. usability for
 choir literature (especially combined with the upcoming automatic
 extenders). Unfortunately, assignment of lyrics to *container*
 contexts does not work (at least, not reliably), and extender
 generation is completely defunct.
>>> Uh, I thought that people replaced extenders right now?
>> Well, may I cite the notation manual:
>>
>> "extender lines cannot be drawn when there is no associated voice."
>>
>> The autoextender patch only adds extenders at places where extenders
>> can be added without it.
> 
> That does not sound like we should remove __ from lyrics to me.

That already proved to be a source of endless misinterpretations, so be careful 
to complain... ;-)

Two-line summary:
1. (What used to be) __ is added *everywhere.*
2. *Processing (printing)* of LyricExtenders changed such that only the 
extenders you expect to appear are drawn by default.

Because of 1. it would be rather surprising if the need arises to add it 
manually ever again, and thus it should be safe to deprecate and ignore the 
token.
W.r.t. 2., I think all reasonable use cases are covered. If, however, you have 
any example of lyrics without associated voice, where extenders are required 
and working with the old __, please raise your voice now. I can't imagine that. 
(BTW, this has absolutely nothing to do with the \lyricsto ... = ... { ... } 
issue per se. It's just that both are a tremendous simplification for choral 
scores.)


Cheers,
Alexander

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