TestLily / Backup-2016-12-10 / #2717 Implement \single for converting overrides to tweaks

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

Or \sneaky.

Owner: dak@gnu.org
Status: Started

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

Implement \hide as a shorthand for \tweak #'\stencil #f

Other possible names would be \stealthy or \hidden.

http://codereview.appspot.com/6443087

Labels: -Patch-review Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

(No comment was entered for this change.)

Summary: Patch: Implement \hide as a shorthand for \tweak #'stencil #f

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

(No comment was entered for this change.)

Summary: Patch: Implement \hide as a shorthand for \tweak #'stencil ##f

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-06

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-09

Originally posted by: dak@gnu.org

Without a clear usage case (like getting some problematic Midi volume changes done in examples or docs), it does not seem like putting this into 2.16 makes sense. Not put on countdown for now.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-08-12

Originally posted by: dak@gnu.org

I don't see an immediate use case yet, and \hide is a rather generic macro name. There also has been no discussion, so I am putting this on hold.

Labels: -Patch-review Patch-waiting

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-09

Originally posted by: dak@gnu.org

Putting this back to review. Most commands like \hideNotes or so are overrides, and there would be some incentive to have \hide be consistent with _that_, namely use
\new Voice \with { \hide StringNumber } { c\3 }
and instead use the macro name \hidden for this patch's functionality, one-time stencil settings, like
\hidden Accidental cis-\hidden\3

There is some slight grammatical advantage to using \hide for the override as well: \once\hide makes grammatical sense, \once\hidden not so much. On the other hand, the tweaks will likely occur more often, and \hidden is more work to type.

Discuss.

Labels: -Patch-waiting Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-09

Originally posted by: m...@hohlart.de

What about using it the other way round?

\new Voice \with { \hidden StringNumber } { c\3 }
\hide Accidental cis-\hide\3

looks quite convincing for me, but I am a non-native speaker.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-09

Originally posted by: dak@gnu.org

Well, I have to agree that the combination with \with is almost too good to be true, but it basically works best when there is nothing else in the context mod. \once\hidden has the disadvantage of the connotation "but now revealed". Also we have \hideNotes, \hideKeySignature, hideSplitTiedTabNotes, \hideStaffSwutch, and all of those are overrides/sets. That's likely the strongest reason for not using \hide for a tweak.

Telling those apart is likely not going to be fun for the average user, but I think that the hide/hidden combo for override/tweak is likely a bit more consistent. I don't think it makes sense to pick more different words for pretty much the same concept applied in a different way.

A probably more accurate term would be "invisible", but I can't think of a good pairing for it, and we already have "hide" in use for other overrides.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-11

Originally posted by: ColinPKC... (code.google.com)@gmail.com

(No comment was entered for this change.)

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-12

Originally posted by: dak@gnu.org

I decided, after discussions in the mailing list, to go with \hidden for tweaks and overrides since that is consistent with \hide... functions in property-init.ly.

Actually, it isn't quite consistent since the \hide ... functions work via setting the grobs to transparent rather than nuking their stencil. So it might be more accurate to use \erase or \wipe here. Sigh. Do we need separate convenience shortcuts for making transparentizing und unstencilling?

Summary: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-12

Originally posted by: dak@gnu.org

Implement \hidden/\hide as a shorthands for \tweak/override #'\stencil = ##f

http://codereview.appspot.com/6443087

Labels: -Patch-countdown Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-12

Originally posted by: pkx1... (code.google.com)@gmail.com

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-13

Originally posted by: ColinPKC... (code.google.com)@gmail.com

(No comment was entered for this change.)

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-15

Originally posted by: dak@gnu.org

I am grateful for the trust in my technical judgment expressed by placing the patch on countdown, but think that the ongoing discussion on the Rietveld review warrants further opportunity for reaching a broader consent, so putting this back to Patch-review for now. I'll likely try submitting a different proposed patch in the next day and see where this takes the discussion.

Labels: -Patch-countdown Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-16

Originally posted by: dak@gnu.org

Issue 2717: Implement \single, \erase and \hide

\erase StringNumber would be equivalent to
\override StringNumber #'stencil = ##f,

\hide StringNumber would be equivalent to
\override StringNumber #'transparent = ##t

and something like \single\erase StringNumber \3 would be equivalent to
\tweak StringNumber #'stencil ##f \3

\single can, like \once, translate larger override sets like \voiceOne
into a tweak, so you can use things like \single\voiceOne c4 .

The disadvantage of this particular approach is that with
\single\erase StringNumber \3 you still need to be specific about the
grob you want to see erased, even though \3 would sufficiently provide
that information. It would be conceivable to allow
\single\erase \default \3
for that, by letting \erase \default create something that does not
actually work in music but is understood by \single, but that does not
seem all too satisfactory either.

The advantage is that this makes most overrides in ly/property-init.ly
available as tweaks.

http://codereview.appspot.com/6495135

Labels: -Patch-review Patch-new

Related

Issues: ~~#2717~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-17

Originally posted by: pkx1... (code.google.com)@gmail.com

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: ianhuli... (code.google.com)@gmail.com

Hi David,
How will we document \once and \single so they don't get confused?
Am I correct in these assumptions re \once and \single?

\once = "do the following commands and only apply them to a single time-step (moment in LilyPondish) in the score"

\single = "apply this modification to a one unique property or sub-property relevant particular graphic object (grob) within some LilyPond context or other"

Could you ever get user code specifying \once and \single together?

In everyday usage "once" and "single" are sort-of synonymous, if there isn't a more specific name for \single that isn't too long, ugly or both, let's make it clear in big, friendly letters how different they are in the docs.

(When you frame your reply for me - imagine you're explaining it to Winni and Fridolin - and then make a few more allowances because they've got horse-sense!)

Cheers,
Ian

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: dak@gnu.org

Regarding comment #20:

\single = "do the following commands and only apply them to the single item following them, as a \tweak"

\single\once ... is the same as \single ..., and \once\single is nonsense since \single first converts overrides to a tweak, and you can't apply \once on a tweak.

"once" and "single" are not synonymous. "once" is the same as "a single time", but the point is that "\single" applies an override just to a single item.

Or in other words: \single converts overrides into one or more \tweaks. This means that you can write something like <\single\hideNotes c e g> and, in contrast to
\once\hideNotes <c e g>, just the c will get hidden (I can't vouch for what will happen to the Stem: this will depend on whether LilyPond considers the NoteHead for c as the cause of the Stem, or rather that of some other note).

I would not care explaining this distinction to Fridolin: he tends to ignore distinctions such as the distinction between inside and outside of a fence.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: m...@hohlart.de

I find the term "\single" a bit confusing;
< \only\hideNotes c e g > or < \just\hideNotes c e g >
are possible alternatives, but I am not convinced of
either one.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: dak@gnu.org

My original thought was "\tweakish\hideNotes" but that does not help making the connection that it applies to the following expression. Other things would be \this\hideNotes or \next\hideNotes or \one\hideNotes. None of those convinced me really over \single.

At least it does not seem like people have significant complaints about the \hide/\erase pairing for the transparent/stencil override.

I do like \new Voice with { \erase StringNumber } { ... }

There would also be other options like \expunge or \remove (though that one is taken already) or \wipe or \kill or \delete or \omit.

Oh. \omit is actually even better, isn't it?

I'll likely change that, short of protests. Still, something more convincing for \single would be nice.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: dak@gnu.org

(No comment was entered for this change.)

Summary: Implement \single, \omit and \hide

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-20

Originally posted by: dak@gnu.org

Issue 2717: Implement \single, \omit and \hide

\omit StringNumber would be equivalent to
\override StringNumber #'stencil = ##f,

\hide StringNumber would be equivalent to
\override StringNumber #'transparent = ##t

and something like \single\omit StringNumber \3 would be equivalent to
\tweak StringNumber #'stencil ##f \3

\single can, like \once, translate larger override sets like \voiceOne
into a tweak, so you can use things like \single\voiceOne c4 .

The disadvantage of this particular approach is that with
\single\omit StringNumber \3 you still need to be specific about the
grob you want to see erased, even though \3 would sufficiently provide
that information. It would be conceivable to allow
\single\omit \default \3
for that, by letting \erase \default create something that does not
actually work in music but is understood by \single, but that does not
seem all too satisfactory either.

The advantage is that this makes most overrides in ly/property-init.ly
available as tweaks.

http://codereview.appspot.com/6495135

Labels: -Patch-review Patch-new

Related

Issues: ~~#2717~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Implement \single for converting overrides to tweaks

Test issue tracker

Searches

Help

#2717 Implement \single for converting overrides to tweaks

Discussion

Related

Related