Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[Andrew Bernard]

It's the most controversial topic I know!

Andrew


On Fri, 25 Oct 2019 at 14:08,  wrote:

> On Fri, 25 Oct 2019, Andrew Bernard wrote:
> > complex part of this, along with SPF and DKIM. The change that is being
> made
> > here is clearly necessary to me, and explains some of the list issues
> people
> > were having lately. Sadly, it's probably unintelligible to non-experts.
>
> I run a mail server too, and I think From: munging is a better solution.
>
>

Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[mskala]

On Fri, 25 Oct 2019, Andrew Bernard wrote:
> complex part of this, along with SPF and DKIM. The change that is being made
> here is clearly necessary to me, and explains some of the list issues people
> were having lately. Sadly, it's probably unintelligible to non-experts.

I run a mail server too, and I think From: munging is a better solution.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[Andrew Bernard]

I have been setting up a server for a mailing list I created for
harpsichord discussion. It took three months full time work by me to set up
all the open source software. So I have deep knowledge of this area
currently. A large part of the technical difficulty is actually getting
mails out through the complex world of spam blacklists, and DMARC is a huge
and very difficult and complex part of this, along with SPF and DKIM. The
change that is being made here is clearly necessary to me, and explains
some of the list issues people were having lately. Sadly, it's probably
unintelligible to non-experts.

But classifying mail into folders for this list is trivial - just make a
filter rule on the To: header. I have used that just fine for years. Any
mailer can do that nowadays.

Andrew

Re: Fyi: this list, lilypond-user, just had its subject [tag] and footer removed

[Brian Barker]

At 21:38 24/10/2019 -0400, Matthew Skala wrote:

On Thu, 24 Oct 2019, sysad...@gnu.org wrote:
Any list administrator for this list is free to change these 
settings back, instructions are below.


I hope that it will be changed back. The subject tag is useful for 
automatic categorization of incoming messages.


But surely this list currently had no subject *tag*?

Brian Barker  

Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[mskala]

On Thu, 24 Oct 2019, sysad...@gnu.org wrote:
> Any list administrator for this list is free to change these settings
> back, instructions are below.

I hope that it will be changed back.  The subject tag is useful for
automatic categorization of incoming messages.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[sysadmin]

The Free Software Foundation has changed the GNU Mailman settings on
this list. The short version is that any subject prefix or message
footer has been removed, allowing us to turn off DMARC from munging.
Any list administrator for this list is free to change these settings
back, instructions are below.

The change is to better deal with increased adoption of the DMARC email
standard. The default Mailman settings were causing messages sent from
users with strict DMARC policy domains like yahoo.com to be rejected
when sent to list subscribers by Mailman. See the end of this email for
a technical overview of DMARC and DKIM. There are two main ways to fix
the issue by changing Mailman list settings.

The first option, and the preferable way for discussion lists, is what
we call the "unmodified message fix." There are Mailman list settings
which modify the messages by adding a subject prefix (e.g. [list-name])
or a footer. Modifying the message breaks DKIM message signatures and
thus DMARC, so we just turn those off. Many lists are already this way
and there is no change for them. Instead of using the subject prefix to
identify a list, subscribers should use the List-Id, To, and Cc headers.
List footer information can also be be put in the welcome email to
subscribers and the list information page by list administrators.

We changed the default for new lists to send unmodified messages, and
are now updating existing discussion lists to the new default. We
emailed all list administrators and moderators and Savannah group admins
to allow them to opt in to the alternate fix before we made this
change. However, not all lists had a valid administrator contact.

The second option is for lists which want or need to continue to modify
the message, for example with subject prefix or footer settings. In this
case we turn on a Mailman list setting called dmarc_moderation_action:
"Munge From". With this, if a strict DMARC sender sends to the list, we
alter the headers of that message like so:

A message sent to the list:

From: Anne Example Person 

Is modified by Mailman and sent to subscribers as:

From: Anne Example Person via Alist 
Reply-To: Anne Example Person 

Without going into all of the details, here's a few points about why we
concluded the unmodified message fix is better for discussion
lists. Email clients don't all treat munged messages the same way as
unmunged, and humans read these headers so it can confuse people,
causing messages not to be sent to the expected recipients. GNU Mailman
has an option to do "Munge From" always, but does not recommend using
it[1]. While we're not bound by what others do, it's worth noting that
other very large free software communities like Debian GNU/Linux have
adopted the unmodified message fix[2]. The unmodified messages fix
avoids breaking DKIM cryptographic signatures, which show the message
was authorized by the signing domain and seems like a generally good
security practice. Tools to manage patches, for example patchew, use the
from field and are tripped up by from munging.

For any Mailman list administrator who wants to change or look over the
relevant settings: The dmarc_moderation_action setting is under "Privacy
Options" subsection "Sender Filters". The only options that should be
selected are "Accept" or "Munge From", along with corresponding changes
to the subject_prefix option under "General Options", and msg_footer is
under "Non-digest options".

If no list administrators or moderators are around for this list, anyone
should feel free to try to track them down or figure out who should
become one and explain in detail by replying to sysad...@gnu.org. Please
be patient, this process may take several weeks.

Please send any questions that should be public to mail...@gnu.org. For
private ones, just reply to sysad...@gnu.org.

For the general announcement of these changes, please read
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
and
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html


A short DMARC technical overview:

DMARC policy is a DNS txt record at a _dmarc subdomain. For example:

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100;
rua=mailto:address@hidden;;;

The only important thing there for our purpose is p=reject. p=reject
means that conforming mail servers that receive mail with a from header
of *@yahoo.com will reject that email unless it was either 1. sent from
Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM
signature[5] is a public key cryptographic signature of the email body
and some headers included in the message header "DKIM-Signature". A
verified DKIM signature means that email body and signed headers have
not been modified.

Comprehensive resources about DMARC tend to downplay or ignore its
problems, but some that have helped me are Wikipedia[6], the Mailman
wiki[1], dmarc.org wiki[7], and the DMARC rfc[8].

Re: Hairpin whiteout problem

[Simon Albrecht]

On 24.10.19 23:51, David Kastrup wrote:

\version "2.19.83"

placeAbsolute = #(define-event-function (xy ev) (pair? ly:music?)
    #{
  \tweak whiteout ##t
  \tweak outside-staff-priority ##f
  \tweak Y-offset 0
  \tweak extra-offset $xy
  $ev
    #})

Worth mentioning that if you have 2.19.83, the above can be written as

placeAbsolute = -\tweak whiteout ##t
 -\tweak outside-staff-priority ##f
 -\tweak Y-offset 0
 -\tweak extra-offset
 \etc


Oh cool, I didn’t know that it worked for more than one argument. Thanks!

Best, Simon

Re: Hairpin whiteout problem

[Ben]

On 10/24/2019 5:39 PM, Simon Albrecht wrote:

On 24.10.19 23:30, Ben wrote:
Is there any way to adjust that so it always takes up a full chunk of 
the hairpin regardless of the true size of the markup?


Of course. Try using markup with \with-dimensions or 
\with-dimensions-from; maybe also override whiteout-style.


HTH, Simon


Simon,

You're right! I forgot about with-dimensions. Sorry. :)

Check this out! (.png)

\relative c'
{
  c2 d e\< f g-\placeAbsolute #'(0 . -3.85)  _\markup \with-dimensions 
#'(-.5 . 1.25) #'(-.5 . 1) { "c" } f\! e d c

}

Re: Hairpin whiteout problem

[David Kastrup]

Simon Albrecht  writes:

> On 24.10.19 18:33, Ben wrote:
>> Is it possible to whiteout hairpins?
>
> Of course—the real problem here is that you have to make the hairpin
> ignore the markup for its placement. Here’s a fidgety solution:
>
> %%
> \version "2.19.83"
>
> placeAbsolute = #(define-event-function (xy ev) (pair? ly:music?)
>    #{
>  \tweak whiteout ##t
>  \tweak outside-staff-priority ##f
>  \tweak Y-offset 0
>  \tweak extra-offset $xy
>  $ev
>    #})

Worth mentioning that if you have 2.19.83, the above can be written as

placeAbsolute = -\tweak whiteout ##t
-\tweak outside-staff-priority ##f
-\tweak Y-offset 0
-\tweak extra-offset
\etc

-- 
David Kastrup

Re: Hairpin whiteout problem

[Simon Albrecht]

On 24.10.19 23:30, Ben wrote:
Is there any way to adjust that so it always takes up a full chunk of 
the hairpin regardless of the true size of the markup?


Of course. Try using markup with \with-dimensions or 
\with-dimensions-from; maybe also override whiteout-style.


HTH, Simon

Re: Hairpin whiteout problem

[Ben]

On 10/24/2019 5:14 PM, Simon Albrecht wrote:

On 24.10.19 18:33, Ben wrote:

Is it possible to whiteout hairpins?


Of course—the real problem here is that you have to make the hairpin 
ignore the markup for its placement. Here’s a fidgety solution:


%%
\version "2.19.83"

placeAbsolute = #(define-event-function (xy ev) (pair? ly:music?)
   #{
 \tweak whiteout ##t
 \tweak outside-staff-priority ##f
 \tweak Y-offset 0
 \tweak extra-offset $xy
 $ev
   #})

\relative c'
{
  c2 d e\< f g-\placeAbsolute #'(0 . -4)  _"C" f\! e d c
}
%%%

HTH, Simon


Hi Simon,

This is very helpful yes thank you! It gives me a different way to 
approach this.


I did notice one thing however, using your code. It seems like if I 
don't use capital letters (or "anything" that is big enough to cover the 
entire hairpin, it doesn't whiteout fully. Is this correct?


Is there any way to adjust that so it always takes up a full chunk of 
the hairpin regardless of the true size of the markup?


Sorry if this is a silly question.



c2 d e\< f g-\placeAbsolute #'(0 . -3.75)  _"c" f\! e d c

Re: Hairpin whiteout problem

[Simon Albrecht]

On 24.10.19 18:33, Ben wrote:

Is it possible to whiteout hairpins?


Of course—the real problem here is that you have to make the hairpin 
ignore the markup for its placement. Here’s a fidgety solution:


%%
\version "2.19.83"

placeAbsolute = #(define-event-function (xy ev) (pair? ly:music?)
   #{
 \tweak whiteout ##t
 \tweak outside-staff-priority ##f
 \tweak Y-offset 0
 \tweak extra-offset $xy
 $ev
   #})

\relative c'
{
  c2 d e\< f g-\placeAbsolute #'(0 . -4)  _"C" f\! e d c
}
%%%

HTH, Simon

Re: All grobs at a given time/in a note column in all or certain contexts

[Klaus Blum]

Hi Urs, 

Urs Liska-3 wrote
> is it possible from either a music function or a callback or an engraver
> to get to all the grobs in a certain note column, either across the whole
> score or within specific contexts?

a few years ago, David Nalesnik wrote an interesting engraver: 
http://lilypond.1069038.n5.nabble.com/box-around-notes-td35581.html
  

IIUC, it iterates through all grobs inside a music expression to determine
the dimensions of a box around it. 

I learned a lot from that thread, but most of the magic there is far beyond
anything I can understand.  :(
But maybe it's helpful for you... 

Cheers, 
Klaus




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

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

Re: Puzzled about r1 issue in 3/4 time

[Cynthia Karl via lilypond-user]

> From: Michael Wagner 
> Subject: Puzzled about r1 issue in 3/4 time 
> Date: October 23, 2019 at 2:59:06 PM CDT
> To: lilypond-user@gnu.org
> 
> 
> I am seeing some behavior I don’t understand. I have ended the music for 
> “Silver Bells” into lilypond, and I am seeing a puzzling error.
> 
> The song is in 3/4 time, but the rest in measure 33 seems to betaking 4 beats 
> - I get a bar check failed and there are one two rests in measure 34, and an 
> extra measure is inserted at the end.
> 
> What am I doing wrong? 
> 
The most serious thing you’re doing wrong is not submitting an MWE to 
illustrate your problem, e.g.:

\version “2.18.2”
{ \time 3/4 r1 | r1 }

The next most serious thing you’re doing wrong is not reading the 
documentation, e,g, since you’re having a problem with rests, section 1.2.2 
“Writing Rests” of the Notation RM has a subsection called “Full Measure 
Rests”.  So the way to fix your problem is to write:

\version “2.18.2”
{ \time 3/4 R2. | R2. }

(You might also upgrade to version 2.19.83, which is very stable and fixes a 
lot of problem that existed in version 2.18.2)___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Hairpin whiteout problem

[Ben]

Hello!

Is it possible to whiteout hairpins? I can't figure it out.

Code example:

%

\relative c'
{
  c2 d e\< f g_"C" f\! e d c
}

%

I'd like for the "C" in this example to be inside / on top of the 
hairpin. Is there a way to have *any* type of object whiteout a hairpin, 
whether it's a multiphonics diagram, or markup, or anything?


I've tried other solutions from the mailing list but they don't work here.

\override Hairpin.whiteout = ##t
\override Hairpin.layer = #2
\override TextScript.staff-padding
etc.

(please see attached)

Thanks so much!

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