lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vertical shift of trill


From: Valentin Petzel
Subject: Re: vertical shift of trill
Date: Sat, 06 Aug 2022 18:27:52 +0200

The way I see it *internal* means that this property is used, but there are no 
guarantees on a certain behaviour. Thus using an internal property is fine, but 
there will be no promise that this works in all circumstances and that it will 
keep working unless we break API.

This is different than for example relying on UB, but it is still a case where 
if you use this property you might need to maintain it to keep working. Thus 
doing this too extensively this poses a risk of creating dead snippets.

In this one example this is of course to be expected, as you are effectively 
extending the API. But still it is something that of course *should* be 
documented in a perfect world (even very technical, internal details should be 
documented), but it should not be recommended too much.

Regarding Werner’s point about automatic behaviour: Adding the encompassed 
note columns to the side support should not really affect the placement as 
outside-staff object. So it might be viable to have this simply on by default. 
But staff-padding does create issues. It is of course questionable if staff-
padding should have a meaning for an non outside-staff object.

But you could without any problems replace replace the default values of staff-
padding and meta.object-callbacks.side-support-elements with callbacks that 
check for the value of outside-staff-priority and act accordingly.

Cheers,
Valentin

Am Samstag, 6. August 2022, 17:15:13 CEST schrieb Jean Abou Samra:
> Le 06/08/2022 à 16:45, Werner LEMBERG a écrit :
> >> That said, there's a much simpler way.  [...]
> > 
> > Your solution is ingenious.  However, how on earth are we mere mortals
> > able to find that?
> 
> Read the source, Luke :-)
> 
> Seriously, there is no way around that in this case -- as in many cases
> when it comes to Scheme coding, because the task is essentially to meddle
> with LilyPond internals.
> 
> Obviously, I don't claim that this is something every user is supposed to
> be able to do.
> 
> > Both `note-columns` and `side-support-elements`
> > are tagged as internal properties, which essentially means "don't
> > touch".
> 
> _All_ "object" properties* are documented as internal, so as soon
> as you're writing an engraver that sets up a grob that interacts
> with other grobs, you start touching those.
> 
> In my book, a property being tagged as "internal" means "this is an
> advanced parameter, be aware that touching it might be more difficult
> than using \override and you likely need to know a bit about internals
> if you want to tinker with it", but doesn't advise against using it
> in Scheme when you know what you're doing. (If setting internal properties
> in Scheme were forbidden, the range of things you could do with Scheme
> in LilyPond would be much more limited.)
> 
> > Additionally, the documentation is ... scarce, to be polite
> > 
> > I wonder whether it makes sense to encapsulate this functionality into
> > a LilyPond macro, to be provided by default.  Or maybe even better:
> > Could this functionality be activated automatically as soon as there
> > is `\override TrillSpanner.outside-staff-priority = ##f`?
> 
> Well, it wouldn't hurt to have it by default even with
> outside-staff-priority. I'm currently preparing other things
> though, maybe later, or maybe you'll beat me at it :-)
> It's not more difficult than defining the callback in output-lib.scm,
> using it in define-grobs.scm, and adding a regtest too.
> I've actually long been wanting to refactor outside-staff placement
> so this sort of issue would not appear in the first place
> (see also
> https://lists.gnu.org/archive/html/lilypond-user/2022-06/msg00232.html)
> but it's pretty complicated ...
> 
> Best,
> Jean
> 
> 
> 
> * I mean the grobs & grob arrays, accessed with ly:grob-object, and
>    subject to break substitution. I never know how to call them,
>    "object properties" sounds similar to "[regular] properties of
>    [graphical] objects" which is not the same, and Guile also has
>    "object properties" that are a different thing entirely ...

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]