Re: \unset with modified default properties

[Saul Tobin]

Interesting. So if the default property is set at the Staff level, for
instance, then changed and \unset at the Voice level, it goes back to the
default for the higher-level context. But if in the example \new Staff
\with... is changed to \new Voice \with... the original problem arises
where \unset reverts to the built-in default.

Didn't realize about the \tuplet syntax. That's quite useful. Thanks for
the tip!

Actually, I just used tupletSpannerDuration because it was convenient to
write a tiny example. My practical use case is changing the default
keepAliveInterfaces for certain staves.

On Sun, Jul 1, 2018 at 1:00 AM David Kastrup  wrote:

> Saul Tobin  writes:
>
> > In both 2.18 and 2.19, \unset appears to set a context property to the
> > built-in default, rather than the default set in the \with {} block:
> >
> > music = \relative c' {
> >   \tuplet 3/2 {
> > c8 c c d d d e e e f f f |
> >   }
> >   \set Staff.tupletSpannerDuration = #(ly:make-moment 1/2)
> >   \tuplet 3/2 {
> > c8 c c d d d e e e f f f |
> >   }
> >   \unset Staff.tupletSpannerDuration
> >   \tuplet 3/2 {
> > c8 c c d d d e e e f f f |
> >   }
> > }
> >
> > \new Staff \with {
> >   tupletSpannerDuration = #(ly:make-moment 1/4)
> > } \music
> >
> > In cases like this, I would find it useful to reset the property to the
> > custom default value without having to explicitly \set it every time. Is
> > there a way to do this? Also, is this the most useful behavior of \unset?
>
> There are several approaches.  The tupletSpannerDuration is actually
> interpreted at Voice level, so if you set/unset the Voice level value,
> it remains dominant while set and can be unset nicely:
>
> music = \relative c' {
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
>   \set tupletSpannerDuration = #(ly:make-moment 1/2)
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
>   \unset tupletSpannerDuration
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
> }
>
> \new Staff \with {
>   tupletSpannerDuration = #(ly:make-moment 1/4)
> } \music
>
> But of course for this functionality in particular, use the optional
> tuplet spanner duration argument to the \tuplet music function:
>
> music = \relative c' {
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
>   \tuplet 3/2 2 {
> c8 c c d d d e e e f f f |
>   }
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
> }
>
> \new Staff \with {
>   tupletSpannerDuration = #(ly:make-moment 1/4)
> } \music
>
> In fact, I'd lean towards using it always and not even bother setting
> tupletSpannerDuration at all.  So basically:
>
> music = \relative c' {
>   \tuplet 3/2 4 {
> c8 c c d d d e e e f f f |
>   }
>   \tuplet 3/2 2 {
> c8 c c d d d e e e f f f |
>   }
>   \tuplet 3/2 4 {
> c8 c c d d d e e e f f f |
>   }
> }
>
> \music
>
> It's minimal writing effort and keeps the information where it belongs.
>
> --
> David Kastrup
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[N. Andrew Walsh]

Hi Urs, List

On Sun, 1 Jul 2018, 00:08 Urs Liska  wrote:

> Hi Simon and Craig,
>
> I think it's a good point. And since maybe I'll have to suffer more than
> anyone else ;-) I shouldn't wring my hands too much and just go for that.
>
I'll consent to slogging through all our Kayser project to update the
annotations if it means getting this very excellent feature implemented.

Cheers,

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

Re: edition-engraver: multiple editions

[Mason Hock]

On 07/01, Jan-Peter Voigt wrote:
> Hi Mason,
> 
> thank you for the hint what has to be explained more concisely in the
> docs that are still waiting for there incarnation.
> 
> In you examples activation of the editions is done with
> `\addEdition first`. To only apply edition `second` you can omit
> `\addEdition first` or comment that out.
> The command `\editionMod first ...` does not need `\addEdition first` to
> compile.

I see. I incorrectly assumed that \addEdition declares a set of edition-mods, 
but it makes much more sense that it applies them. Thanks for clarifying.

> Now the idea of the edition-engraver is to separate layout-mods and
> editorial stuff from the content. So in a real project one or more files
> containing the bare music definitions, e.g. `wind.fluteI = \relative {
> c''8 b a ... }`, are included in a file starting the typesetting for a
> specific edition.
> All editionMods (for all editions) may be placed in another
> include-file. Now in the file to typeset the specific edition either
> `\addEdition first` for each needed collection of mods is added or in
> one command `\setEditions first.second`.
> So any edition receives is typeset from its own source file. Those files
> are quite short containing the paper, layout and edition settings and
> the actual score-creating command.
> 
> IIRC I once created one file to create multiple PDFs with different
> editions activated and different paper sizes, but that is really tricky.

With the piece I'm currently working, on I'm attempting something similar using 
a bash script that iterates through every paper/tablet size, constructs \paper, 
prepends \version, appends \score, and tells lilypond to compile. Now I can 
also have it include a file containing the appropriate \addEdition statements.

Thanks for creating this very valuable tool. Lilypond is already far more 
powerful than any other scorewriter, but edition-engraver takes it to a whole 
other level.

Mason

> And in production I always use different files for separate editions.
> 
> HTH
> Jan-Peter


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

Re: Opinions requested on deprecating "annotation" commands

[Urs Liska]

Am 01.07.2018 um 00:08 schrieb Urs Liska:


Hi Simon and Craig,

I think it's a good point. And since maybe I'll have to suffer more 
than anyone else ;-) I shouldn't wring my hands too much and just go 
for that.


There will be a Git tag referencing the latest state of the "old" 
interface, and it should be possible to use that for existing 
projects. Of course when someone wants to make use of the additional 
functionality they'd have to update their projects but for others this 
should at least work as long as LilyPond progress won't make things 
incompatible.




I've found a better solution: I've moved the code for the 
\criticalRemark functions and friends to a new module 
scholarly.annotate.legacy. So for existing documents just the 
\loadModule command has to be changed and the legacy commands can be 
used. The best part about this is that I didn't even have to duplicate 
any code, just redistribute it over two files and have one include the 
other ...


Best
Urs


Best
Urs


Am 01.07.2018 um 00:04 schrieb Craig Dabelstein:
I'm happy to go with the consensus. Breaking any of my old documents 
won't be an issue for me, and I'm happy to defer to your expertise.


Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht > wrote:


On 30.06.2018 14:14, Urs Liska wrote:
> # Encourage people to use the new system and "deprecate" the
old syntax
> (but leave it alone and working). The downside is that the
*names* of
> the old commands are very much what one would want, so I
wouldn't want
> to discard them completely.
> # Make the old names wrappers around the new technology, so one
can
> still say \criticalRemark.

I’d vote for the latter. Better to make a clean cut, and there’s
so much
potential in this, and the number of users seems to be limited
until now
in my perspective – I may be wrong.

Best, Simon

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



--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/




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


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

Re: \bookparts and scaling (Karlin High)

[David Kastrup]

Torsten Hämmerle  writes:

> This being said, I agree with you that we need something that lets us
> create differently-sized scores within a \bookpart that look as if
> #(set-global-staffsize …) was used. Ideally, layout-set-staff-size
> would be able to accomplish this, which isn't the case yet and
> therefore, to me, the current layout-set-staff-size doesn't make too
> much sense.

I am not sure: it might make sense for score markups inside of a score
since they similarly might have to match the spacing of the surrounding
score.  However, this could now be considered the problem of \staffSize
and it might make more sense to use layout-set-staff-size for the
complete deal.

I don't think that, whatever its original intent was, it is being used
significantly for anything these days.

-- 
David Kastrup

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

Re: Frescobaldi to default window layout

[David Wright]

On Sun 01 Jul 2018 at 09:58:23 (+0200), Urs Liska wrote:
> Hi Andrew,
> 
> I didn't say anything about the value of the choice of the original
> settings. Actually I don't remember them anymore (since there's no
> real way to get back to them short of installing Frescobaldi on a
> fresh computer).
> 
> What I meant is that "revert to default" is clearly a command to
> reset all (layout) settings to their "factory presets". There's not
> much to argue about that, I think.

I think that it would be much simpler to either

. create a nonce user and run Fresco as that new user, or
. move $HOME/.config/frescobaldi/¹ to another location before running Fresco,

and then examine the diffs between the new $HOME/.config/frescobaldi/
tree and the original user's version.

> What you are asking for is saving personal presets, one of them
> maybe being your "personal default". In order to achieve that we'll
> have to determine which settings we want to be included in such a
> preset (Obviously the positions of all windows from the "Tools"
> menu, but would you also want to store colors and fonts, zoom sizes,
> or maybe a copy of *all* Preferencs? This would have to be
> discussed) and then figure out an interface to maintain that. This
> isn't really hard to do, I think, but someone needs to take the time
> to do it. But *if* it is done adding a "factory reset" is trivial,
> and I think it should be added too.

In a similar manner, after setting up Fresco to the user's personal
satisfaction, a snapshot of the configuration tree can be saved for
future use as a "personal default", implemented by substituting it
for the tree that's no longer desired.

> Am 01.07.2018 um 09:50 schrieb Andrew Bernard:
> >Hi Urs,
> >
> >I can't quite say I agree with that. The default when first opened
> >is to not show the Documentation Window. You have to choose it to
> >turn it on. Trivial to do and little effort, yes, but the point is
> >my default is but everyone's default.
> >
> >Andrew
> >
> >On 1 July 2018 at 17:35, Urs Liska  >> wrote:
> >
> >
> >That's easy. The default is how it would be with no user
> >preferences present.

¹ substitute the appropriate location for your platform
  (this being Debian's).

Cheers,
David.

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

Re: \bookparts and scaling (Karlin High)

[Torsten Hämmerle]

Karlin High wrote
> The effect of that \staffSize function looks slightly different than 
> using layout-staff-size. But for me it still shows the same problem: it 
> makes things smaller, but doesn't change the layout like 
> set-global-staff-size does.


Hi Karlin,

The proposed function \staffSize just basically does what the standard
procedure for changing all font sizes (by \set fontSize) changing
staff-space did before \magnifyStaff came up.

The intention behind it was to create differently-sized (usually smaller)
*single* staves within a score, as for example a piano score with a solo
instrument stave in smaller print.
In this case, it's not a bug at all to not alter the overall spacing, since
the smaller-sized notes, clefs, time signatures, key signatures, etc. have
to be horizontally aligned to the rest of the standard-size staves.
The main staves of the score, so to say, will still determine the overall
spacing, and that ist correct and expected behaviour.

Therefore, we need to differentiate between scaling up/down singular staves
in a score and up-/downscaling a complete score with bag and baggage.

This being said, I agree with you that we need something that lets us create
differently-sized scores within a \bookpart that look as if
#(set-global-staffsize …) was used. Ideally, layout-set-staff-size would be
able to accomplish this, which isn't the case yet and therefore, to me, the
current layout-set-staff-size doesn't make too much sense.

All the proposals made so far actually do scale the staves, but don't get
the overall spacing right (both vertically and horizontally).

All the best,
Torsten




--
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: Discern single note-event from one in a chord

[David Kastrup]

Urs Liska  writes:

> Well, the problem at hand is that I want to apply some styles, say a
> color, to the music passed into a music function. And depending on the
> type of music this should be done by wrapping the (sequential) music
> in \temporary \override .. \revert statements, by creating \tweaks or
> by issuing \once \overrides (which is necessary when the music is for
> example "\clef bass").
>
> I can discern between sequential and non-sequential music, and I can
> detect events that are not rhythmic-events. But I would like to be
> able to apply the wrapping to single music events too. For example
> when having a single note I'd like to override a number of grobs'
> color property while within a chord it's only the notehead, so \tweak
> is good.

>>> Is there maybe a way to get to a music's "parent" in order to check
>>> what type that is?
>> No.  A music function is a local transform.  It does not get to see
>> where its result is being used.  You can use its result in a variable
>> which you may use both as a single note and inside of a chord.
>>
>> If you want to work with music in context, you need to analyze stream
>> events in an engraver.
>>
>
> Hm, I don't think that's an option in my case. The problem is that in
> my \tagSpan function I *dispatch* the actual styling to another
> (user-provided) music function. And I think this has to be at the
> music-function stage because this function may not only override grob
> properties but may do anything a music function can do, like adding
> marks before or after the music or even apply some random procedure
> meddling with the content (I can imagine someone doing
>     \tagSpan randomize \with { strength = 0.9 seed = 0.49283567
> algorithm = original } { c c g' g a a g2 }
> )

So do both and use tags in-chord and not-in-chord (in a tag group of
their own) and add a scorification hook that removes all such tagged
music from where it does not belong.

> The problem is that
>     \tagSpan something c'
> often has to be treated differently from
>     
>
> Any ideas toward that use-case, independent from my original problem
> description?

Either do both but tagged, or just tweak the stuff and do a pass through
the finished music (scorification hook or not) that replaces recognized
tweaks outside of chords with corresponding overrides.

This will not work very favorably with people using parallel music
inside of one context for piecing stuff together but if you want to do
that, you really need to iterate.

-- 
David Kastrup

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

Re: Discern single note-event from one in a chord

[Urs Liska]

Am 01.07.2018 um 10:04 schrieb David Kastrup:

Urs Liska  writes:


Hi,

is there a way to discern whether the ly:music? passed into a music
function is a single note-event or a note within a chord?

\version "2.19.80"

testType =
#(define-music-function (music)(ly:music?)
(ly:message "Music type(s): ~a" (ly:music-property music 'types))
music)

{
   \clef bass
   \testType c
   
}

prints `Music type(s): (event note-event rhythmic-event
melodic-event)` in both cases.


Is there anything else besides the 'types music-property I can check
for in this context?

No.


Too bad.




I hope there is because there are many respects in which the two would
have to be treated differently.

Which ones?


Well, the problem at hand is that I want to apply some styles, say a 
color, to the music passed into a music function. And depending on the 
type of music this should be done by wrapping the (sequential) music in 
\temporary \override .. \revert statements, by creating \tweaks or by 
issuing \once \overrides (which is necessary when the music is for 
example "\clef bass").


I can discern between sequential and non-sequential music, and I can 
detect events that are not rhythmic-events. But I would like to be able 
to apply the wrapping to single music events too. For example when 
having a single note I'd like to override a number of grobs' color 
property while within a chord it's only the notehead, so \tweak is good.


So
    \testType c'
should be expanded to
    \temporary \override NoteHead.color = #red c' \revert NoteHead.color
while
    
should result in
    < \tweak color #red e>





Is there maybe a way to get to a music's "parent" in order to check
what type that is?

No.  A music function is a local transform.  It does not get to see
where its result is being used.  You can use its result in a variable
which you may use both as a single note and inside of a chord.

If you want to work with music in context, you need to analyze stream
events in an engraver.



Hm, I don't think that's an option in my case. The problem is that in my 
\tagSpan function I *dispatch* the actual styling to another 
(user-provided) music function. And I think this has to be at the 
music-function stage because this function may not only override grob 
properties but may do anything a music function can do, like adding 
marks before or after the music or even apply some random procedure 
meddling with the content (I can imagine someone doing
    \tagSpan randomize \with { strength = 0.9 seed = 0.49283567 
algorithm = original } { c c g' g a a g2 }

)

The problem is that
    \tagSpan something c'
often has to be treated differently from
    

Any ideas toward that use-case, independent from my original problem 
description?


Thanks
Urs

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

Re: Discern single note-event from one in a chord

[Urs Liska]

Am 01.07.2018 um 10:04 schrieb David Kastrup:

Urs Liska  writes:


Hi,

is there a way to discern whether the ly:music? passed into a music
function is a single note-event or a note within a chord?

\version "2.19.80"

testType =
#(define-music-function (music)(ly:music?)
(ly:message "Music type(s): ~a" (ly:music-property music 'types))
music)

{
   \clef bass
   \testType c
   
}

prints `Music type(s): (event note-event rhythmic-event
melodic-event)` in both cases.


Is there anything else besides the 'types music-property I can check
for in this context?

No.


Too bad.




I hope there is because there are many respects in which the two would
have to be treated differently.

Which ones?


Well, the problem at hand is that I want to apply some styles, say a 
color, to the music passed into a music function. And depending on the 
type of music this should be done by wrapping the (sequential) music in 
\temporary \override .. \revert statements, by creating \tweaks or by 
issuing \once \overrides (which is necessary when the music is for 
example "\clef bass").


I can discern between sequential and non-sequential music, and I can 
detect events that are not rhythmic-events. But I would like to be able 
to apply the wrapping to single music events too. For example when 
having a single note I'd like to override a number of grobs' color 
property while within a chord it's only the notehead, so \tweak is good.


So
    \testType c'
should be expanded to
    \temporary \override NoteHead.color = #red c' \revert NoteHead.color
while
    
should result in
    < \tweak color #red e>





Is there maybe a way to get to a music's "parent" in order to check
what type that is?

No.  A music function is a local transform.  It does not get to see
where its result is being used.  You can use its result in a variable
which you may use both as a single note and inside of a chord.

If you want to work with music in context, you need to analyze stream
events in an engraver.



Hm, I don't think that's an option in my case. The problem is that in my 
\tagSpan function I *dispatch* the actual styling to another music 
function. And I think this has to be at the music-function stage because 
this function may not only override grob properties but may do anything 
a music function can do, like adding marks before or after the music or 
even apply some random procedure meddling with the content (I can 
imagine someone doing
    \tagSpan randomize \with { strength = 0.9 seed = 0.49283567 
algorithm = original } { c c g' g a a g2 }

)

The problem is that
    \tagSpan something c'
often has to be treated differently from
    

Any ideas toward that use-case, independent from my original problem 
description?


Thanks
Urs

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

Re: edition-engraver: multiple editions

[Jan-Peter Voigt]

Hi Mason,

thank you for the hint what has to be explained more concisely in the
docs that are still waiting for there incarnation.

In you examples activation of the editions is done with
`\addEdition first`. To only apply edition `second` you can omit
`\addEdition first` or comment that out.
The command `\editionMod first ...` does not need `\addEdition first` to
compile.
Now the idea of the edition-engraver is to separate layout-mods and
editorial stuff from the content. So in a real project one or more files
containing the bare music definitions, e.g. `wind.fluteI = \relative {
c''8 b a ... }`, are included in a file starting the typesetting for a
specific edition.
All editionMods (for all editions) may be placed in another
include-file. Now in the file to typeset the specific edition either
`\addEdition first` for each needed collection of mods is added or in
one command `\setEditions first.second`.
So any edition receives is typeset from its own source file. Those files
are quite short containing the paper, layout and edition settings and
the actual score-creating command.

IIRC I once created one file to create multiple PDFs with different
editions activated and different paper sizes, but that is really tricky.
And in production I always use different files for separate editions.

HTH
Jan-Peter

Am 30.06.2018 um 18:30 schrieb Mason Hock:
> I'm slowly getting a handle on edition-engraver, largely thanks to this[1] 
> guide, which very clearly explains basic usage for a single edition. However, 
> neither the guide nor the usage examples in the repo demonstrate the use of 
> multiple editions, and I'm confused as to how that would be done in a useful 
> way. For example, these two snippets
> 
> --
> \version "2.19.82"
> 
> \include "oll-core/package.ily"
> \loadPackage edition-engraver
> 
> \addEdition first
> \editionMod first 1 0/4 the-staff.Voice ^\markup { 1 }
> \editionMod first 1 2/4 the-staff.Voice ^\markup { 2 }
> 
> \consistToContexts #edition-engraver Staff.Voice
> 
> \score {
>   \new Staff \with { \editionID the-staff } {
> \relative c' {
>   c d e f
> }
>   }
> }
> --
> 
> --
> \version "2.19.82"
> 
> \include "oll-core/package.ily"
> \loadPackage edition-engraver
> 
> \addEdition first
> \editionMod first 1 0/4 the-staff.Voice ^\markup { 1 }
> 
> \addEdition second
> \editionMod second 1 2/4 the-staff.Voice ^\markup { 2 }
> 
> \consistToContexts #edition-engraver Staff.Voice
> 
> \score {
>   \new Staff \with { \editionID the-staff } {
> \relative c' {
>   c d e f
> }
>   }
> }
> --
> 
> produce identical output, so, in the way I've been using edition-engraver so 
> far, defining multiple editions does not appear to have a different effect 
> from placing all edition-mods in one edition. It is true that I could put the 
> edition-mods for each edition in a separate .ily file and only include the 
> one I want to use when I compile, but even then there is no reason that the 
> edition in each file could be called "first" instead of giving the editions 
> different names.
> 
> My expectation would be that there is a way of specifying which editions(s) 
> should have their edition-mods observed and which should be ignored, but I 
> can't find any information about this. Can anyone provide an example of 
> correct usage of edition-engraver to maintain multiple editions?
> 
> Thanks,
> 
> Mason
> 
> 
> [1] https://lists.gnu.org/archive/html/lilypond-user/2018-01/msg00603.html
> 
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


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

Re: Discern single note-event from one in a chord

[David Kastrup]

Urs Liska  writes:

> Hi,
>
> is there a way to discern whether the ly:music? passed into a music
> function is a single note-event or a note within a chord?
>
> \version "2.19.80"
>
> testType =
> #(define-music-function (music)(ly:music?)
>(ly:message "Music type(s): ~a" (ly:music-property music 'types))
>music)
>
> {
>   \clef bass
>   \testType c
>   
> }
>
> prints `Music type(s): (event note-event rhythmic-event
> melodic-event)` in both cases.
>
>
> Is there anything else besides the 'types music-property I can check
> for in this context?

No.

> I hope there is because there are many respects in which the two would
> have to be treated differently.

Which ones?

> Is there maybe a way to get to a music's "parent" in order to check
> what type that is?

No.  A music function is a local transform.  It does not get to see
where its result is being used.  You can use its result in a variable
which you may use both as a single note and inside of a chord.

If you want to work with music in context, you need to analyze stream
events in an engraver.

-- 
David Kastrup

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

Re: \unset with modified default properties

[David Kastrup]

Saul Tobin  writes:

> In both 2.18 and 2.19, \unset appears to set a context property to the
> built-in default, rather than the default set in the \with {} block:
>
> music = \relative c' {
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
>   \set Staff.tupletSpannerDuration = #(ly:make-moment 1/2)
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
>   \unset Staff.tupletSpannerDuration
>   \tuplet 3/2 {
> c8 c c d d d e e e f f f |
>   }
> }
>
> \new Staff \with {
>   tupletSpannerDuration = #(ly:make-moment 1/4)
> } \music
>
> In cases like this, I would find it useful to reset the property to the
> custom default value without having to explicitly \set it every time. Is
> there a way to do this? Also, is this the most useful behavior of \unset?

There are several approaches.  The tupletSpannerDuration is actually
interpreted at Voice level, so if you set/unset the Voice level value,
it remains dominant while set and can be unset nicely:

music = \relative c' {
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
  \set tupletSpannerDuration = #(ly:make-moment 1/2)
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
  \unset tupletSpannerDuration
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
}

\new Staff \with {
  tupletSpannerDuration = #(ly:make-moment 1/4)
} \music

But of course for this functionality in particular, use the optional
tuplet spanner duration argument to the \tuplet music function:

music = \relative c' {
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
  \tuplet 3/2 2 {
c8 c c d d d e e e f f f |
  }
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
}

\new Staff \with {
  tupletSpannerDuration = #(ly:make-moment 1/4)
} \music

In fact, I'd lean towards using it always and not even bother setting
tupletSpannerDuration at all.  So basically:

music = \relative c' {
  \tuplet 3/2 4 {
c8 c c d d d e e e f f f |
  }
  \tuplet 3/2 2 {
c8 c c d d d e e e f f f |
  }
  \tuplet 3/2 4 {
c8 c c d d d e e e f f f |
  }
}

\music

It's minimal writing effort and keeps the information where it belongs.

-- 
David Kastrup

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

Re: Frescobaldi to default window layout

[Urs Liska]

Hi Andrew,

I didn't say anything about the value of the choice of the original 
settings. Actually I don't remember them anymore (since there's no real 
way to get back to them short of installing Frescobaldi on a fresh 
computer).


What I meant is that "revert to default" is clearly a command to reset 
all (layout) settings to their "factory presets". There's not much to 
argue about that, I think.


What you are asking for is saving personal presets, one of them maybe 
being your "personal default". In order to achieve that we'll have to 
determine which settings we want to be included in such a preset 
(Obviously the positions of all windows from the "Tools" menu, but would 
you also want to store colors and fonts, zoom sizes, or maybe a copy of 
*all* Preferencs? This would have to be discussed) and then figure out 
an interface to maintain that. This isn't really hard to do, I think, 
but someone needs to take the time to do it. But *if* it is done adding 
a "factory reset" is trivial, and I think it should be added too.


Best
Urs


Am 01.07.2018 um 09:50 schrieb Andrew Bernard:

Hi Urs,

I can't quite say I agree with that. The default when first opened is 
to not show the Documentation Window. You have to choose it to turn it 
on. Trivial to do and little effort, yes, but the point is my default 
is but everyone's default.


Andrew

On 1 July 2018 at 17:35, Urs Liska > wrote:



That's easy. The default is how it would be with no user
preferences present.



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


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

Re: Frescobaldi to default window layout

[Andrew Bernard]

Hi Urs,

I can't quite say I agree with that. The default when first opened is to
not show the Documentation Window. You have to choose it to turn it on.
Trivial to do and little effort, yes, but the point is my default is but
everyone's default.

Andrew

On 1 July 2018 at 17:35, Urs Liska  wrote:

>
> That's easy. The default is how it would be with no user preferences
> present.
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Discern single note-event from one in a chord

[Urs Liska]

Hi,

is there a way to discern whether the ly:music? passed into a music 
function is a single note-event or a note within a chord?


\version "2.19.80"

testType =
#(define-music-function (music)(ly:music?)
   (ly:message "Music type(s): ~a" (ly:music-property music 'types))
   music)

{
  \clef bass
  \testType c
  
}

prints `Music type(s): (event note-event rhythmic-event melodic-event)` 
in both cases.



Is there anything else besides the 'types music-property I can check for 
in this context? I hope there is because there are many respects in 
which the two would have to be treated differently. Is there maybe a way 
to get to a music's "parent" in order to check what type that is?



Thanks
Urs

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

Re: Frescobaldi to default window layout

[Urs Liska]

Am 01.07.2018 um 09:18 schrieb Andrew Bernard:


Hi Freeman,

There’s no default layout reset command as far as I know. It’s easy to 
sometimes mess up the window positions. Bu you can just shuffle them 
back with a bit of practice by dragging the title bar tab and 
inserting the window in the place you want. There is a bit of a knack 
to it.


That’s probably a good suggestion, a reset default layout command. But 
it’s a bit problematical, because what it is the default?




That's easy. The default is how it would be with no user preferences 
present.
I'm quite sure when loading the interface every tool loads the settings 
with a given default value which kicks in if no setting is stored. 
Technically it would be very easy to reset all the settings to these 
default values (which must already be there in the code). What I see a 
little bit complicated here is figuring out all places in the code where 
this is relevant, since I assume it is pretty much scattered over all 
the interface components.


It’s different for different users. I use Music View and Documentation 
Browser and the edit window, but others may have different setups. So 
the idea may be to have a save/restore layout function rather than a 
default function.




Well, *if* anyone looks into this I suggest to add *both* these 
functions. Different setups should be good to have for different editing 
stages or project types.


So Freeman, as Aaron suggested it would be good to open a feature 
request on Frescobaldi's issue tracker at 
https://github.com/wbsoft/frescobaldi/issues.


Best
Urs


Andrew

*From:*lilypond-user 
 *On Behalf Of 
*Freeman Gilmore

*Sent:* Sunday, 1 July 2018 12:54 PM
*To:* Lilypond-User Mailing List 
*Subject:* Frescobaldi to default window layout

​How do I restore Frescobaldi to the default window layout?

Thank you, ƒg



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


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

RE: Frescobaldi to default window layout

[Andrew Bernard]

Hi Freeman,

 

There’s no default layout reset command as far as I know. It’s easy to 
sometimes mess up the window positions. Bu you can just shuffle them back with 
a bit of practice by dragging the title bar tab and inserting the window in the 
place you want. There is a bit of a knack to it.

 

That’s probably a good suggestion, a reset default layout command. But it’s a 
bit problematical, because what it is the default? It’s different for different 
users. I use Music View and Documentation Browser and the edit window, but 
others may have different setups. So the idea may be to have a save/restore 
layout function rather than a default function.

 

Andrew

 

 

From: lilypond-user  On 
Behalf Of Freeman Gilmore
Sent: Sunday, 1 July 2018 12:54 PM
To: Lilypond-User Mailing List 
Subject: Frescobaldi to default window layout

 

​How do I restore Frescobaldi to the default window layout?

Thank you, ƒg

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