Re: \override multiple properties?

[Aaron Hill]

On 2020-02-01 6:46 pm, Bric wrote:

In my case i am needing to override a series of notes and then revert.
 (So, don't want to use "\once"). I have already used your construct,
coupling it with reverting directives grouped the same way (with a
named group):

emphasizeStem = {
   \override Stem.thickness = #3.0
   \override Stem.color = #'(0.5 0.3 0.2)
}

revertStem = {
  \revert Stem.thickness
  \revert Stem.color
}


The \undo command can be useful to avoid needing to individually 
\revert:



{ d'8 \emphasizeStem d' e' f' \undo \emphasizeStem g'4 d' }




What would be nice is be able to parametrize those blocks somehow

But, i guess, that can only be done with a Scheme function? I'm shaky 
on scheme.


Music functions certainly give you the most flexibility, although there 
are simple cases where you can use 2.19's \etc keyword as a shorthand to 
defining the function yourself:



\version "2.19"

stemColor = \override Stem.color = \etc

{ d'8 \stemColor #red e' f' \undo \stemColor ##f g' }


Note the \undo command above is less ideal as one needs to provide a 
dummy argument to the function.


Here would be one way to parameterize \emphasizeStem:


\version "2.19"

emphasizeStem = #(define-music-function
  (thickness color)
  ((number? 3) color?)
  #{ \override Stem.thickness = #thickness
 \override Stem.color = #color #})

{ \emphasizeStem #red d'8 e'4
  \emphasizeStem 6 #blue f'2 }


The above demonstrates how the first argument could be made optional.


-- Aaron Hill

Re: \override multiple properties?

[Bric]

> On February 1, 2020 at 7:06 PM Aaron Hill  wrote:

> related \overrides into their own music variable or function, if there 
> needs to be some parameterization:
> 
> 
> \version "2.18"
> 
> emphasizeStem = {
>\override Stem.thickness = #3.0
>\override Stem.color = #'(0.5 0.3 0.2)
> }
> 
> % . . .
> \new Voice \with { \emphasizeStem } { b'4 c''2. }
> % . . .
> \new Voice { e'8 g' \once \emphasizeStem f'4 a'2 }
> % . . .
> 
> 
> Grouping related \overrides together in a well-named variable promotes 
> readability, reusability and maintainability.  As an added bonus, \once 
> can be used with the variable without needing to apply it to every 
> \override.

In my case i am needing to override a series of notes and then revert.  (So, 
don't want to use "\once"). I have already used your construct, coupling it 
with reverting directives grouped the same way (with a named group):

emphasizeStem = {
   \override Stem.thickness = #3.0
   \override Stem.color = #'(0.5 0.3 0.2)
}

revertStem = {
  \revert Stem.thickness
  \revert Stem.color
}

Then i mark up a set of notes with the above two, as start and end markers, 
like so:

e'8  \emphasizeStem  gis'' cis''  e'' dis'' \revertStem fis''

What would be nice is be able to parametrize those blocks somehow

But, i guess, that can only be done with a Scheme function? I'm shaky on scheme.

Re: \override multiple properties?

[Aaron Hill]

On 2020-02-01 7:54 am, David Kastrup wrote:

Bric  writes:
Is it possible to override multiple with just one "\override" 
directive?


something like this (wrong syntax):

\override { Voice.Stem.thickness = #3.0
Voice.Stem.color = #(rgb-color 0.3 0.1 0.1)
  }

to reduce redundant syntax, if one had to override many at once.


No.  It's not like the savings in this case would be overwhelming.


To that point, the better and already existing solution is to move these 
related \overrides into their own music variable or function, if there 
needs to be some parameterization:



\version "2.18"

emphasizeStem = {
  \override Stem.thickness = #3.0
  \override Stem.color = #'(0.5 0.3 0.2)
}

% . . .
\new Voice \with { \emphasizeStem } { b'4 c''2. }
% . . .
\new Voice { e'8 g' \once \emphasizeStem f'4 a'2 }
% . . .


Grouping related \overrides together in a well-named variable promotes 
readability, reusability and maintainability.  As an added bonus, \once 
can be used with the variable without needing to apply it to every 
\override.



-- Aaron Hill

Re: Clef change placement

[Kieren MacMillan]

Hi Daniel,

> From Elaine Gould's "Behind Bars" (p. 9):
> 
>> Where an instrument rests for more than a system, it is usual to return it 
>> to its commonest clef... Place
>> the clef change at the end of the system after the player has finished: this 
>> is the least disruptive position
>> as regards spacing. It is better than an immediate clef change before rests, 
>> which draws unwanted
>> attention to the new clef at an arbitrary point.
> 
> Is there a way to achieve this placement automatically, other than by 
> specifying explicit system breaks?

Did you ever get an answer to this?
Seems like a perfect job for a [Scheme] engraver…

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: \override multiple properties?

[David Kastrup]

Bric  writes:

> The documentation examples are showing single property overrides, like so:
>
> \override Voice.Stem.thickness = #3.0
>
> Is it possible to override multiple with just one "\override" directive?
>
> something like this (wrong syntax):
>
> \override { Voice.Stem.thickness = #3.0
> Voice.Stem.color = #(rgb-color 0.3 0.1 0.1)
>   }
>
>
> to reduce redundant syntax, if one had to override many at once.

No.  It's not like the savings in this case would be overwhelming.

-- 
David Kastrup

\override multiple properties?

[Bric]

The documentation examples are showing single property overrides, like so:

\override Voice.Stem.thickness = #3.0

Is it possible to override multiple with just one "\override" directive?

something like this (wrong syntax):

\override { Voice.Stem.thickness = #3.0
Voice.Stem.color = #(rgb-color 0.3 0.1 0.1)
  }


to reduce redundant syntax, if one had to override many at once.

Re: passing file to LilyBin

[David Nalesnik]

Hi Kieren!

On Sat, Feb 1, 2020 at 8:15 AM Kieren MacMillan
 wrote:
>
> Hi David,
>
> Does  help?
>
> Cheers,
> Kieren.

It's very informative, though I was hoping that there is a LilyBin
API.  If not, that would be a killer addition.

Best,
David

\partCombine \pitchedTrill

[Pierre-Luc Gauthier]

Hi there,

In this MWE the trill pitch des''' is not displayed for some reason.

When \partCombineChords is forced, why doesn't both trill note get displayed ?

Side question :
Why isn't the second bar merged "chorded" by default?
Both parts seems \partCombineApart by default.

Thanks for your help
-- 
Pierre-Luc Gauthier
\version "2.21.0"

\partCombine
{
  c'1 |
  \partCombineChords
  \pitchedTrill
  a''2
  \startTrillSpan bes''
  a''2\stopTrillSpan |
  \partCombineAutomatic
  c'1 |
}
{
  c'1 |
  \pitchedTrill
  c'''2
  \startTrillSpan des'''
  c'''2\stopTrillSpan |
  c'1 |
}

Re: Newbie Question

[Mark Gould]

Hi,

A reboot seemed to fix my issue... I have a working LilyPond now - so time to 
do some reading of the manuals!

Mark

Re: passing file to LilyBin

[Kieren MacMillan]

Hi David,

Does  help?

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: passing file to LilyBin

[David Nalesnik]

On Sat, Feb 1, 2020 at 7:39 AM David Nalesnik  wrote:
>
> Hi all,
>
> If a website writes an LY file, is it then possible to call
> lilybin.org directly with the file from the website?  I suppose you
> could write it to the clipboard, but a more direct route would be
> nice.
>
And, that would be lilybin.com, of course.

passing file to LilyBin

[David Nalesnik]

Hi all,

If a website writes an LY file, is it then possible to call
lilybin.org directly with the file from the website?  I suppose you
could write it to the clipboard, but a more direct route would be
nice.

Thanks,
David

Re: Scheme Book

[Freeman Gilmore]

Thanks, Urs:

I have read “Extending LilyPond”, it did give me some idea of some of what
I need to know.   But the need was still there.   I find your “Scheme Book”
answers this need.   Thank you for all your effort.Wish I was smart
enough to help.

Thank You, ƒg


On Sat, Feb 1, 2020 at 3:47 AM Urs Liska  wrote:

> Am Freitag, den 31.01.2020, 16:53 -0800 schrieb Aaron Hill:
> > On 2020-01-31 11:57 am, Urs Liska wrote:
> > > https://scheme-book.ursliska.de
> >
> > My apologies for hijacking this thread.
>
> Don't worry, seems like a useful thing.
>
> >
> > Two things:
> >
> > 1)  Is it possible to auto-generate (ideal) or manually maintain
> > (not
> > ideal) a page linked from the contributing section regarding the
> > sections of the book that are incomplete?
> > For instance, "list
> > recursion" has no content currently.  But you would not know that
> > unless
> > you drill down into that section, which in this new styling requires
> > a
> > fair number of mouse clicks.  I sometimes have spare cycles where I
> > could help flesh out this book, but at the face of it, I would not
> > immediately know where to look.  A one-page index listing where work
> > is
> > needed would be great.
>
> The previous system, GitBook, treated missing files in a way similar to
> a Wiki, by creating non-clickable entries in the TOC. MkDocs doesn't
> seem to have this, missing input files will cause 404 errors. As a
> lesser evil I decided to put in empty files - which will at least auto-
> generate the heading for the page, and an edit link so someone could
> directly jump to Github to enter something.
>
> Of course that's suboptimal, for the reasons you describe.
> I think a good solution would be a dedicated TOC page serving two
> purposes at once: giving the overview and direct navigation asked for
> by Freeman in the first place, and adding state information to each
> page's entry.
>
> First I thought doing so automatically would be deficient because that
> could only catch missing or actually empty files (which would miss a
> file with a short description of the missing/intended content).
> However, I *think* it is possible to use metadata for that. MkDocs has
> some functionality to process metadata in itself, which could be used
> by a plugin, which is something I haven't investigated yet. But since
> the book has to be built by a build script anyway it would be easy to
> hook in a step of generating the TOC/state page using content from the
> metadata. So not only empty files could be properly flagged but also
> files that have a state flag in the metadata.
>
> This will need some time, which could drastically be reduced by someone
> stepping in and helping me with the investigation.
>
> >
> >
> > 2)  Since some pages are entirely blank, it can be difficult to
> > contribute as title alone may not fully indicate the intended purpose
> > of
> > a section.  Using the example above, should "list recursion" be
> > talking
> > about nesting lists within lists and common strategies for this
> > structure (c.f. member vs member*) or is there something else to
> > discuss?  Including a short one-liner description of what to expect
> > would be helpful.
>
> This can certainly be integrated in the above appraoch. A plugin can
> surely extract such a comment from the metadata and write it on the
> page, and a TOC generator can also add this as a comment to a TOC
> entry.
>
> However, one thing to note is that "what is missing" is not necessarily
> equivalent to "what Urs at one point added as a TOC entry". The
> structure I outlined at some point is a draft, and looking at the
> contents again after a few years tells me there's a lot that could be
> improved.
>
> That wants to say: If someone finds the time and energy to add to that
> book it's not relevant if that addition fits to the existing empty
> pages, it can be something totally different.
>
> The aim of this book has always been an introduction, giving interested
> users the chance to get over the initial threshold of perceiving Scheme
> as black magic. And while I think the level of detail and the pace of
> explanation is generally quite successful in this regard, I now think
> the overall structure, i.e. the order of topics the reader is exposed
> to, could be improved.
>
> I hope I'll find the time to do that, page by page, and while reviewing
> I will purge the "I" perspective to make it more suitable as a
> community-driven resource.
>
> The "task" of potential contributors is not to fill in the blanks I
> have created in the outline but to add or improve arbitrary topics, and
> suggestions regarding the improvement of the outline are equally
> welcome.
>
> Best
> Urs
>
> >
> >
> > -- Aaron Hill
> >
>
>
>

Re: clusters (accordion)

[Gianmaria Lari]

>
> I would like to engrave the cluster symbol in the attached image.
>

I have been able to do something that is similar. Here it is:

\version "2.19.83"
{
  \hide Rest
  \makeClusters { 8 8} r8
  \makeClusters { 8 8} r8
  \makeClusters { 8 8} r8
  \makeClusters { 8 8} r8
  \undo \hide Rest
}

But I'm sorry I didn't understand how it really works makeClusters and they
go out the first measure.
Any help would be appreciated.

Thanks, g.

Re: Scheme Book

[Urs Liska]

Am Freitag, den 31.01.2020, 16:53 -0800 schrieb Aaron Hill:
> On 2020-01-31 11:57 am, Urs Liska wrote:
> > https://scheme-book.ursliska.de
> 
> My apologies for hijacking this thread.

Don't worry, seems like a useful thing.

> 
> Two things:
> 
> 1)  Is it possible to auto-generate (ideal) or manually maintain
> (not 
> ideal) a page linked from the contributing section regarding the 
> sections of the book that are incomplete?  
> For instance, "list 
> recursion" has no content currently.  But you would not know that
> unless 
> you drill down into that section, which in this new styling requires
> a 
> fair number of mouse clicks.  I sometimes have spare cycles where I 
> could help flesh out this book, but at the face of it, I would not 
> immediately know where to look.  A one-page index listing where work
> is 
> needed would be great.

The previous system, GitBook, treated missing files in a way similar to
a Wiki, by creating non-clickable entries in the TOC. MkDocs doesn't
seem to have this, missing input files will cause 404 errors. As a
lesser evil I decided to put in empty files - which will at least auto-
generate the heading for the page, and an edit link so someone could
directly jump to Github to enter something.

Of course that's suboptimal, for the reasons you describe.
I think a good solution would be a dedicated TOC page serving two
purposes at once: giving the overview and direct navigation asked for
by Freeman in the first place, and adding state information to each
page's entry.

First I thought doing so automatically would be deficient because that
could only catch missing or actually empty files (which would miss a
file with a short description of the missing/intended content).
However, I *think* it is possible to use metadata for that. MkDocs has
some functionality to process metadata in itself, which could be used
by a plugin, which is something I haven't investigated yet. But since
the book has to be built by a build script anyway it would be easy to
hook in a step of generating the TOC/state page using content from the
metadata. So not only empty files could be properly flagged but also
files that have a state flag in the metadata.

This will need some time, which could drastically be reduced by someone
stepping in and helping me with the investigation.

> 
> 
> 2)  Since some pages are entirely blank, it can be difficult to 
> contribute as title alone may not fully indicate the intended purpose
> of 
> a section.  Using the example above, should "list recursion" be
> talking 
> about nesting lists within lists and common strategies for this 
> structure (c.f. member vs member*) or is there something else to 
> discuss?  Including a short one-liner description of what to expect 
> would be helpful.

This can certainly be integrated in the above appraoch. A plugin can
surely extract such a comment from the metadata and write it on the
page, and a TOC generator can also add this as a comment to a TOC
entry.

However, one thing to note is that "what is missing" is not necessarily
equivalent to "what Urs at one point added as a TOC entry". The
structure I outlined at some point is a draft, and looking at the
contents again after a few years tells me there's a lot that could be
improved.

That wants to say: If someone finds the time and energy to add to that
book it's not relevant if that addition fits to the existing empty
pages, it can be something totally different.

The aim of this book has always been an introduction, giving interested
users the chance to get over the initial threshold of perceiving Scheme
as black magic. And while I think the level of detail and the pace of
explanation is generally quite successful in this regard, I now think
the overall structure, i.e. the order of topics the reader is exposed
to, could be improved.

I hope I'll find the time to do that, page by page, and while reviewing
I will purge the "I" perspective to make it more suitable as a
community-driven resource.

The "task" of potential contributors is not to fill in the blanks I
have created in the outline but to add or improve arbitrary topics, and
suggestions regarding the improvement of the outline are equally
welcome.

Best
Urs

> 
> 
> -- Aaron Hill
>