Re: openLilyLib website

[David Kastrup]

Urs Liska  writes:

> Hi David,
>
> Am Sonntag, den 23.02.2020, 22:12 +0100 schrieb David Kastrup:
>> Urs Liska  writes:
>> 
>> > Hi all,
>> > 
>> > as a starting point for a - hopefully - comprehensive documentation
>> > effort I have finally updated https://openlilylib.org with a
>> > completely
>> > new website, which I'd like to have some feedback about and
>> > contributions for.
>> > 
>> > There are several parts to that effort, most of which are
>> > essentially
>> > not started yet.
>> > 
>> >  * A general introduction website. This is basically complete and
>> >should finally give a proper introduction about what OLL "is"
>> > and
>> >how it can be made to work
>> >  * Independent sub-sites for each OLL package. These have not been
>> >written at all, only the links to empty starting pages work
>> > without
>> >404 errors.
>> >  * I've settled with MkDocs (https://www.mkdocs.org), which seems
>> > to
>> >provide what I need, especially a suitable way to hook into and
>> >extend to our needs.
>> >  * Each sub-site is maintained in a separate Git repository and
>> >included as a Git submodule, so it should be straightforward to
>> >manage independent authoring of the documentation by the
>> > respective
>> >package maintainers.
>> >  * There's a link to a contributor's guide, which is also
>> > essentially
>> >empty, except for an entry page.
>> > 
>> > What I have so far is an infrastructure for textual, Markdown-
>> > authored
>> > manuals, although I have already created a plugin for LilyPond
>> > syntax
>> > highlighting using python-ly (
>> > https://github.com/uliska/markdown-lilypond/).
>> > 
>> > What I really *want* to have but have no idea so far how to achieve
>> > is
>> > additional code/API documentation retrieved from the actual source
>> > files. There should be a tool to retrieve that from comments (or
>> > actual
>> > signatures?), resulting in either HTML or Markdown documentation
>> > that
>> > can be automatically integrated in the "manual-style"
>> > documentation.
>> 
>
> I must admit I don't fully understand what your comments are actually
> targeted at.
>
>> With regard to the LilyPond-book/Texinfo route, it might be worth
>> considering that Asciidoc (which Git documentation is written in) can
>> be
>> converted via the route (grabbed lines from the git Documentation
>> Makefile):
>> 
>> user-manual.texi: user-manual.xml
>>  $(QUIET_DB2TEXI)$(RM) $@+ $@ && \
>>  $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout
>> >$@++ && \
>>  $(PERL_PATH) fix-texi.perl <$@++ >$@+ && \
>>  rm $@++ && \
>>  mv $@+ $@
>> 
>> user-manual.xml: user-manual.txt user-manual.conf
>>  $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
>>  $(TXT_TO_XML) -d book -o $@+ $< && \
>>  mv $@+ $@
>> 
>> ASCIIDOC = asciidoc
>> ASCIIDOC_EXTRA =
>> ASCIIDOC_HTML = xhtml11
>> ASCIIDOC_DOCBOOK = docbook
>> ASCIIDOC_CONF = -f asciidoc.conf
>> ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \
>>  -agit_version=$(GIT_VERSION)
>> TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML)
>> TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK)
>> 
>> DOCBOOK2X_TEXI = docbook2x-texi
>> 
>> So that's a bunch of stuff that can convert via Docbook XML to
>> Texinfo.
>> And it's likely that some Wiki-acceptable format convertable to
>> Docbook
>> XML exists.
>
> I've had a look at the Asciidoc homepage, and it looks like a tool I
> might like.
>
> But at this point we are talking about HTML targets (possibly PDF too),
> Markdown files and documentation generated from LilyPond/Scheme files.
> Nothing about DocBook, texidoc etc.
>
> What are you actually intending to convey with these Makefile excerpts?
> That I should consider AsciiDoc as a possible platform for the
> documentation? What would be in there that makes it a (better and)
> suitable tool for the task?
> (This is not meant as an objection [somewhat hard to express], rather a
> request for clarification. I need more a more concrete idea what you
> want me to consider.)

Basically this boils down to pointing out that Texinfo, which has some
prominence in the LilyPond core, has conversion paths via docbook2x-texi
from formats that are more akin to what one would use automated
documentation extraction on.

That's all.  I have not enough clue about openLilyLib to figure out
whether that information might be useful for you.  I just threw that out
and it would seem like I made it sound like more (or something
different) than it actually is.  Just some keyword-triggered info that
may or may not be interesting for whatever this conversation I barreled
in was about.

Sorry if it's just nonsense and occupied too much of your time trying to
make sense of.

David

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive"

Re: markup(List) text color

[Pierre Perol-Schneider]

Hi Bric,
Try \with-color =>
http://lilypond.org/doc/v2.19/Documentation/notation/other#index-_005cwith_002dcolor-2
HTH
Cheers,
Pierre

Le dim. 23 févr. 2020 à 23:09, Bric  a écrit :

> Greetings.  For my life I can't (find|figure out) the code for changing
> text color in \markupList.  The "font-size" line does work - the font size
> change is applied to the entire paragraph.
>
> The "\override #'(font-color . red)" line does not cause an error, but has
> no effect on the color. Using version 2.19.83. Please help. Thanks.
>
>
> #(define-markup-list-command (paragraph layout props args) (markup-list?)
>
>#:properties ((par-indent 3))
>
>(interpret-markup-list layout props
>
> #{\markuplist \justified-lines { \hspace #par-indent #args } #}))
>
>
> \markuplist {
>
>   \override #'(font-size . -2)
>   \override #'(font-color . red)
>
>   \paragraph {
>
>  Monsieur le baron était un des \bold plus puissants seigneurs de la
> Westphalie, car son château avait une porte et des fenêtres.  Sa  grande
> salle même était ornée d'une tapisserie.  Tous les chiens de ses
> basses-cours composaient une meute dans le besoin ; ses. Etc...
>
> }
> }
>
>

Re: openLilyLib website

[Urs Liska]

Hi David,

Am Sonntag, den 23.02.2020, 22:12 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Hi all,
> > 
> > as a starting point for a - hopefully - comprehensive documentation
> > effort I have finally updated https://openlilylib.org with a
> > completely
> > new website, which I'd like to have some feedback about and
> > contributions for.
> > 
> > There are several parts to that effort, most of which are
> > essentially
> > not started yet.
> > 
> >  * A general introduction website. This is basically complete and
> >should finally give a proper introduction about what OLL "is"
> > and
> >how it can be made to work
> >  * Independent sub-sites for each OLL package. These have not been
> >written at all, only the links to empty starting pages work
> > without
> >404 errors.
> >  * I've settled with MkDocs (https://www.mkdocs.org), which seems
> > to
> >provide what I need, especially a suitable way to hook into and
> >extend to our needs.
> >  * Each sub-site is maintained in a separate Git repository and
> >included as a Git submodule, so it should be straightforward to
> >manage independent authoring of the documentation by the
> > respective
> >package maintainers.
> >  * There's a link to a contributor's guide, which is also
> > essentially
> >empty, except for an entry page.
> > 
> > What I have so far is an infrastructure for textual, Markdown-
> > authored
> > manuals, although I have already created a plugin for LilyPond
> > syntax
> > highlighting using python-ly (
> > https://github.com/uliska/markdown-lilypond/).
> > 
> > What I really *want* to have but have no idea so far how to achieve
> > is
> > additional code/API documentation retrieved from the actual source
> > files. There should be a tool to retrieve that from comments (or
> > actual
> > signatures?), resulting in either HTML or Markdown documentation
> > that
> > can be automatically integrated in the "manual-style"
> > documentation.
> 

I must admit I don't fully understand what your comments are actually
targeted at.

> With regard to the LilyPond-book/Texinfo route, it might be worth
> considering that Asciidoc (which Git documentation is written in) can
> be
> converted via the route (grabbed lines from the git Documentation
> Makefile):
> 
> user-manual.texi: user-manual.xml
>   $(QUIET_DB2TEXI)$(RM) $@+ $@ && \
>   $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout
> >$@++ && \
>   $(PERL_PATH) fix-texi.perl <$@++ >$@+ && \
>   rm $@++ && \
>   mv $@+ $@
> 
> user-manual.xml: user-manual.txt user-manual.conf
>   $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
>   $(TXT_TO_XML) -d book -o $@+ $< && \
>   mv $@+ $@
> 
> ASCIIDOC = asciidoc
> ASCIIDOC_EXTRA =
> ASCIIDOC_HTML = xhtml11
> ASCIIDOC_DOCBOOK = docbook
> ASCIIDOC_CONF = -f asciidoc.conf
> ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \
>   -agit_version=$(GIT_VERSION)
> TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML)
> TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK)
> 
> DOCBOOK2X_TEXI = docbook2x-texi
> 
> So that's a bunch of stuff that can convert via Docbook XML to
> Texinfo.
> And it's likely that some Wiki-acceptable format convertable to
> Docbook
> XML exists.

I've had a look at the Asciidoc homepage, and it looks like a tool I
might like.

But at this point we are talking about HTML targets (possibly PDF too),
Markdown files and documentation generated from LilyPond/Scheme files.
Nothing about DocBook, texidoc etc.

What are you actually intending to convey with these Makefile excerpts?
That I should consider AsciiDoc as a possible platform for the
documentation? What would be in there that makes it a (better and)
suitable tool for the task?
(This is not meant as an objection [somewhat hard to express], rather a
request for clarification. I need more a more concrete idea what you
want me to consider.)

Urs

> 

Re: openLilyLib website

[Urs Liska]

Hi Simon,

Am Sonntag, den 23.02.2020, 18:42 +0100 schrieb Simon Albrecht:
> Hi Urs,
> 
> this looks great! As often, I can’t offer much more than applause
> and 
> some nitpicking…

Well, that's useful too.

> 
> On the ‘About LilyPond’ I’d rather write “GNU LilyPond is a music 
> notation program /strongly inspired by/ traditional craftsmanship”. 
> After all, the process of working with LilyPond doesn’t resemble 
> traditional craftsmanship at all…

Good point.

> 
> The use of the word ‘domain’ in the About/LilyPond and /openLilyLib 
> seems quite technical considering IIUC the site is supposed to be
> read 
> also by people without a background in software development…

I must say I'm pretty unhappy with that whole page. I actually replaced
the bullet list with some text just to be able to send that email to
the list.

The introduction on that page should be even shorter, but at the same
time more friendly, casual, positively inspiring than the current text
tending to be too technical and boring.

> 
> ‘Get started/Install openLilyLib’ has an instance of [oll-core} that 
> seems unintentional.

Thanks, had already been spotted and fixed (although not uploaded yet).

> 
> s/documenation/documentation

Thanks.

Best
Urs

> 
> … but generally, the texts seem very appropriate and useful :-)
> 
> Very best regards
> Simon
> 
> On 20.02.20 22:44, Urs Liska wrote:
> > Hi all,
> > 
> > as a starting point for a - hopefully - comprehensive documentation
> > effort I have finally updated https://openlilylib.org with a
> > completely
> > new website, which I'd like to have some feedback about and
> > contributions for.
> > 
> > There are several parts to that effort, most of which are
> > essentially
> > not started yet.
> > 
> >   * A general introduction website. This is basically complete and
> > should finally give a proper introduction about what OLL "is"
> > and
> > how it can be made to work
> >   * Independent sub-sites for each OLL package. These have not been
> > written at all, only the links to empty starting pages work
> > without
> > 404 errors.
> >   * I've settled with MkDocs (https://www.mkdocs.org), which seems
> > to
> > provide what I need, especially a suitable way to hook into and
> > extend to our needs.
> >   * Each sub-site is maintained in a separate Git repository and
> > included as a Git submodule, so it should be straightforward to
> > manage independent authoring of the documentation by the
> > respective
> > package maintainers.
> >   * There's a link to a contributor's guide, which is also
> > essentially
> > empty, except for an entry page.
> > 
> > What I have so far is an infrastructure for textual, Markdown-
> > authored
> > manuals, although I have already created a plugin for LilyPond
> > syntax
> > highlighting using python-ly (
> > https://github.com/uliska/markdown-lilypond/).
> > 
> > What I really *want* to have but have no idea so far how to achieve
> > is
> > additional code/API documentation retrieved from the actual source
> > files. There should be a tool to retrieve that from comments (or
> > actual
> > signatures?), resulting in either HTML or Markdown documentation
> > that
> > can be automatically integrated in the "manual-style"
> > documentation.
> > 
> > Best
> > Urs
> > 
> > 

markup(List) text color

[Bric]

Greetings.  For my life I can't (find|figure out) the code for changing text 
color in \markupList.  The "font-size" line does work - the font size change is 
applied to the entire paragraph.

The "\override #'(font-color . red)" line does not cause an error, but has no 
effect on the color. Using version 2.19.83. Please help. Thanks.


#(define-markup-list-command (paragraph layout props args) (markup-list?)   
  
   #:properties ((par-indent 3))
  
   (interpret-markup-list layout props  
  
#{\markuplist \justified-lines { \hspace #par-indent #args } #}))


\markuplist {

  \override #'(font-size . -2)
  \override #'(font-color . red)

  \paragraph {

 Monsieur le baron était un des \bold plus puissants seigneurs de la 
Westphalie, car son château avait une porte et des fenêtres.  Sa  grande salle 
même était ornée d'une tapisserie.  Tous les chiens de ses basses-cours 
composaient une meute dans le besoin ; ses. Etc...

}
}

Re: openLilyLib website

[David Kastrup]

Urs Liska  writes:

> Hi all,
>
> as a starting point for a - hopefully - comprehensive documentation
> effort I have finally updated https://openlilylib.org with a completely
> new website, which I'd like to have some feedback about and
> contributions for.
>
> There are several parts to that effort, most of which are essentially
> not started yet.
>
>  * A general introduction website. This is basically complete and
>should finally give a proper introduction about what OLL "is" and
>how it can be made to work
>  * Independent sub-sites for each OLL package. These have not been
>written at all, only the links to empty starting pages work without
>404 errors.
>  * I've settled with MkDocs (https://www.mkdocs.org), which seems to
>provide what I need, especially a suitable way to hook into and
>extend to our needs.
>  * Each sub-site is maintained in a separate Git repository and
>included as a Git submodule, so it should be straightforward to
>manage independent authoring of the documentation by the respective
>package maintainers.
>  * There's a link to a contributor's guide, which is also essentially
>empty, except for an entry page.
>
> What I have so far is an infrastructure for textual, Markdown-authored
> manuals, although I have already created a plugin for LilyPond syntax
> highlighting using python-ly (
> https://github.com/uliska/markdown-lilypond/).
>
> What I really *want* to have but have no idea so far how to achieve is
> additional code/API documentation retrieved from the actual source
> files. There should be a tool to retrieve that from comments (or actual
> signatures?), resulting in either HTML or Markdown documentation that
> can be automatically integrated in the "manual-style" documentation.

With regard to the LilyPond-book/Texinfo route, it might be worth
considering that Asciidoc (which Git documentation is written in) can be
converted via the route (grabbed lines from the git Documentation
Makefile):

user-manual.texi: user-manual.xml
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
$(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && 
\
$(PERL_PATH) fix-texi.perl <$@++ >$@+ && \
rm $@++ && \
mv $@+ $@

user-manual.xml: user-manual.txt user-manual.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_XML) -d book -o $@+ $< && \
mv $@+ $@

ASCIIDOC = asciidoc
ASCIIDOC_EXTRA =
ASCIIDOC_HTML = xhtml11
ASCIIDOC_DOCBOOK = docbook
ASCIIDOC_CONF = -f asciidoc.conf
ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \
-agit_version=$(GIT_VERSION)
TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML)
TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK)

DOCBOOK2X_TEXI = docbook2x-texi

So that's a bunch of stuff that can convert via Docbook XML to Texinfo.
And it's likely that some Wiki-acceptable format convertable to Docbook
XML exists.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: openLilyLib website

[mason]

On 02/22, Urs Liska wrote:
> Am Freitag, den 21.02.2020, 18:52 -0800 schrieb ma...@masonhock.com:
> > Do you want something similar [Sphinx][1] or [Doxygen][2]?  
> 
> Yes, something similar, but IISC these tools (which I had of course
> taken notice of earlier) are limited to their set of languages.

Yes, that's right.  I wasn't recommending those tools, just confirming
that you are looking for something similar.

> Craig Dabelstein did some research and suggested NaturalDocs (
> https://www.naturaldocs.org/) which looks nice and suitably
> extensible/configurable for our purpose. I'm a little bit wary about
> the fact that it's a project with a single contributor, and I know what
> I'm talking about ...
> (also I *think* it would be good to have a Python-based tool because it
> might be easier to extend and to integrate with the other stuff.
> 
> > Are the
> > source files in Scheme, Lilypond, or a combination of both?
> 
> Of course both.
> The end-user interface is usually LilyPond, but the functionality is 
> all LilyPond, Scheme-in-LilyPond, and Scheme-in-Scheme-files.

Huh.  I thought it would be easier to find a good documentation
generator for Scheme, but after searching for a while everything I found
appears to have gone unmaintained for at least a few years (which I'm
guessing is what you're afraid could happen with NaturalDocs?), and
other than NaturalDocs I couldn't find anything that supports
configuration for arbitrary languages.


signature.asc
Description: PGP signature

Re: box-stencil (was: Drawing boxes around grobs)

[Torsten Hämmerle]

Hello Paolo,

Yes, indeed, this is the crux with italic fonts… It's hard (to say the
least) to automatically determine whether or not the additional space
inserted after "mf" is needed. Even in hot-metal typesetting the typesetter
has to decide when to insert such an "italic correction".

The only feasible way out I can think of at the moment is creating new
special padded dynamics rather than overwriting the original definitions and
then deliberately choosing one or the other depending on the context, e.g.
\mfbox as a padded version tailored for boxing and standard \mf in
combination with follow-up hairpins.
Or finding a compromise plus applying some box-padding so that one and the
same re-defined \mf will work reasonably well in all circumstances.

Cheers,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: box-stencil (was: Drawing boxes around grobs)

[Thomas Morley]

Am So., 23. Feb. 2020 um 18:13 Uhr schrieb Paolo Prete :
>
>
>
> On Sun, Feb 23, 2020 at 12:54 PM Torsten Hämmerle  
> wrote:
>>
>>
>> A *pragmatic solution* to your problem would be to re-define the dynamics
>> definitions concerned, simply adding a wee bit of space to the left and to
>> the right, as in
>>
>>   mf = #(make-dynamic-script (markup #:line (#:hspace 0.2 "mf" #:hspace
>> 0.5)))
>>
>> This will make your output look like
>>
>> 
>>
>> HTH,
>> Torsten
>
>
> Hello Thorsten,
>
> unfortunately this work-around has the side effect of adding unwanted padding 
> when the dynamic is followed by a hairpin.
>  I wonder if is there, at least, a way to overlay the dynamic *over* the box 
> (and not the box over the dynamic, as it happen by default)
> Thanks for your support,
>
> Best
> P

Well, the default does so:

{
  \override DynamicText.stencil =
#(make-stencil-boxer 0.4 0
  (lambda (grob) (stencil-with-color (ly:text-interface::print grob) red)))

c'_\mf
}

If you use Aaron's redefinition of 'make-stencil-boxer', then, in
'box-stencil', switch the arguments here;
  (ly:stencil-expr (ly:stencil-add stencil box))
->
  (ly:stencil-expr (ly:stencil-add box stencil))

HTH,
  Harm

Re: Arbitrary MIDI

[Cam]

On 2020-02-23 10:17 a.m., David Kastrup wrote:

Cam  writes:


On 2020-02-22 9:22 p.m., David Kastrup wrote:

Cam  writes:


Is there any way to inject arbitrary bytes of data into the stream of
generated MIDI?

No.


There are times this would be convenient.

You'll probably need a Midi sequencer or processor to get this done
with
LilyPond output.






David,

Thanks for the quick reply. At least your answer is clear and unequivocal :)

I will work around.


The Midi backend is pure C++, not accessible to Scheme programming and
not even using Scheme garbage collection.  That would be good to change
some day, but that's a long-term perspective without currently ongoing
or even started work, and without a Scheme way into _any_ Midi,
generating arbitrary Midi bytes just does not appear to make a lot of
sense as they could not be usefully serialised.

One could conceive of a few special-cased "performers" that could pick
up data of certain kinds (generic controllers or stuff?): that kind of
thing might actually work without opening up Midi to Scheme in general.

But at the current point of time, there is nothing implemented, and more
importantly there is absolutely nothing you could do without going to
C++ first.


Thanks for the additional info.

Although it would be slightly more convenient to be able to embed some 
arbitrary MIDI in the Lilypond source, I can work around without great 
difficulty. The point is to control some non-musical gear which responds to 
MIDI messages. I invoke Lilypond, from within a Python program, to compile 
short musical phrases which are then glued together and merged to create a 
single MIDI output file.

Cheers

Cam

Re: openLilyLib website

[Simon Albrecht]

Hi Urs,

this looks great! As often, I can’t offer much more than applause and 
some nitpicking…


On the ‘About LilyPond’ I’d rather write “GNU LilyPond is a music 
notation program /strongly inspired by/ traditional craftsmanship”. 
After all, the process of working with LilyPond doesn’t resemble 
traditional craftsmanship at all…


The use of the word ‘domain’ in the About/LilyPond and /openLilyLib 
seems quite technical considering IIUC the site is supposed to be read 
also by people without a background in software development…


‘Get started/Install openLilyLib’ has an instance of [oll-core} that 
seems unintentional.


s/documenation/documentation

… but generally, the texts seem very appropriate and useful :-)

Very best regards
Simon

On 20.02.20 22:44, Urs Liska wrote:

Hi all,

as a starting point for a - hopefully - comprehensive documentation
effort I have finally updated https://openlilylib.org with a completely
new website, which I'd like to have some feedback about and
contributions for.

There are several parts to that effort, most of which are essentially
not started yet.

  * A general introduction website. This is basically complete and
should finally give a proper introduction about what OLL "is" and
how it can be made to work
  * Independent sub-sites for each OLL package. These have not been
written at all, only the links to empty starting pages work without
404 errors.
  * I've settled with MkDocs (https://www.mkdocs.org), which seems to
provide what I need, especially a suitable way to hook into and
extend to our needs.
  * Each sub-site is maintained in a separate Git repository and
included as a Git submodule, so it should be straightforward to
manage independent authoring of the documentation by the respective
package maintainers.
  * There's a link to a contributor's guide, which is also essentially
empty, except for an entry page.

What I have so far is an infrastructure for textual, Markdown-authored
manuals, although I have already created a plugin for LilyPond syntax
highlighting using python-ly (
https://github.com/uliska/markdown-lilypond/).

What I really *want* to have but have no idea so far how to achieve is
additional code/API documentation retrieved from the actual source
files. There should be a tool to retrieve that from comments (or actual
signatures?), resulting in either HTML or Markdown documentation that
can be automatically integrated in the "manual-style" documentation.

Best
Urs

Re: box-stencil (was: Drawing boxes around grobs)

[Paolo Prete]

On Sun, Feb 23, 2020 at 12:54 PM Torsten Hämmerle 
wrote:

>
> A *pragmatic solution* to your problem would be to re-define the dynamics
> definitions concerned, simply adding a wee bit of space to the left and to
> the right, as in
>
>   mf = #(make-dynamic-script (markup #:line (#:hspace 0.2 "mf" #:hspace
> 0.5)))
>
> This will make your output look like
>
> <
> http://lilypond.1069038.n5.nabble.com/file/t3887/italic-box-overshoot-dynamics.png>
>
>
> HTH,
> Torsten


Hello Thorsten,

unfortunately this work-around has the side effect of adding unwanted
padding when the dynamic is followed by a hairpin.
 I wonder if is there, at least, a way to overlay the dynamic *over* the
box (and not the box over the dynamic, as it happen by default)
Thanks for your support,

Best
P

Re: Arbitrary MIDI

[David Kastrup]

Cam  writes:

>> On 2020-02-22 9:22 p.m., David Kastrup wrote:
>>> Cam  writes:
>>> 
 Is there any way to inject arbitrary bytes of data into the stream of
 generated MIDI?
>>> No.
>>> 
 There are times this would be convenient.
>>> You'll probably need a Midi sequencer or processor to get this done
>>> with
>>> LilyPond output.
>> 
>
>
>
> David,
>
> Thanks for the quick reply. At least your answer is clear and unequivocal :)
>
> I will work around.

The Midi backend is pure C++, not accessible to Scheme programming and
not even using Scheme garbage collection.  That would be good to change
some day, but that's a long-term perspective without currently ongoing
or even started work, and without a Scheme way into _any_ Midi,
generating arbitrary Midi bytes just does not appear to make a lot of
sense as they could not be usefully serialised.

One could conceive of a few special-cased "performers" that could pick
up data of certain kinds (generic controllers or stuff?): that kind of
thing might actually work without opening up Midi to Scheme in general.

But at the current point of time, there is nothing implemented, and more
importantly there is absolutely nothing you could do without going to
C++ first.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: box-stencil (was: Drawing boxes around grobs)

[Torsten Hämmerle]

Paolo Prete-3 wrote
> I just checked that this unwanted behavior happens in the
> default make-stencil-boxer function too.

Ciao Paolo,

Unfortunately, this is a common problem with (mostly) italic fonts:
When looking at the dynamic f in FontForge, you'll see that the glyph is
sticking out of its left and right boundaries.

 

This exaclty matches the physical design of traditional lead type:

 


A *pragmatic solution* to your problem would be to re-define the dynamics
definitions concerned, simply adding a wee bit of space to the left and to
the right, as in

  mf = #(make-dynamic-script (markup #:line (#:hspace 0.2 "mf" #:hspace
0.5)))

This will make your output look like


 

HTH,
Torsten

italic-box-overshoot.png
  
italic-box-overshoot-dynamics.png

  



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: How can I shorten the space for a final single note?

[Pierre Perol-Schneider]

Hi Robert,

Le dim. 23 févr. 2020 à 10:45, Robert Blackstone <
blackstone.rob...@gmail.com> a écrit :
[...]

> Many thanks for your help. Three different solutions for my problem is a
> precious gift.
>
> They all work but I do need some time to understand your codes. They are
> so totally different from mine.
>
[...]

Some direction:

%%
global = {
  \time 4,4,1 2/1 %% <= see:
http://lilypond.org/doc/v2.19/Documentation/changes/index.html
  % Change time signature stencil to 2/2 glyph:
  \override Staff.TimeSignature.stencil = #(lambda (grob)
(grob-interpret-markup grob #{ \markup\musicglyph #"timesig.C22" #}))
}
%%


[...]

> Another habit is to never use “relative”
>
|...]

So do I.

Cheers,
Pierre

How can I shorten the space for a final single note?

[Robert Blackstone]

Hi Pierre. Harm and David, 

Many thanks for your help. Three different solutions for my problem is a 
precious gift. 
They all work but I do need some time to understand your codes. They are so 
totally different from mine.
I use TeXShop as my editor but that should not be a problem. 
I made for myself a set of templates for various types of music. Usually they 
work for me. 
Another habit is to never use “relative” and always add the duration of a note. 
Anyway, I will try to make an MWE with my tools for you to find my errors 
and\or clumsiness. 

Thanks in advance.

Best regards,

Robert