lilypond-user
[Top][All Lists]
Advanced

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

Re:slur corehack


From: Flaming Hakama by Elaine
Subject: Re:slur corehack
Date: Thu, 26 May 2016 18:34:44 -0700


The main thing that is irritating about this exchange
is that you seem invested in maintaining low-quality documentation.

What is your motivation for that?

I'm trying to help make lilypond more accessible to potential new users, and also to help current users improve their workflows and results.


On that page it says: "In other words, the \shape function can act as
either a \once\override command or a \tweak command depending on
whether the item argument is a grob name, like ?Slur?, or a music
_expression_, like ?(?."

I guess "tweak" is spelled "shape" here.

Unless all your curves require the same deltas, the use of \override is not a practical solution to global adjustments.  So, although this sentence gives you a clue that you can apply \shape globally, that still doesn't make it useful.

The \shape technique is a different technique, that yields different results, than using overrides on the ratio and maximum-height (or any other grob properties). 

(Unless deltas could be specified as percentages, and not absolute offsets.)

 
> What was your point?

It got snipped: "The inefficiency or inconsistency of search engines
is hardly a criticism that can be aimed at LP or its docs."

You can't find something if it doesn't exist.

That is not a search engine problem, it is a lack of documentation problem.

If the document existed, it would turn up in search results.

 
For some reason, your search took you to a different page from mine,
and this page was reportedly unsatisfactory.

Yes, everything I found (and that you found) is unsatisfactory (we found the same pages).

You have yet to present a document that describes the ratio, height-limit and free-head-distance techniques.  Until you do, my observations stands, that this is not yet documented.

Saying "transfer of learning" is just another way of saying it is not documented.

 
I snipped your "The override page doesn't even mention slurs" because
Simon covers that with "transfer of learning". I don't think it would
be possible to cover all the individual functions of \override.

Who suggested that all possible functions of \override be covered?

Slurs and slur issues are not edge cases.  This is common music notation.

I am suggesting that techniques related to modifying slurs in general (as opposed to one-at-a-time) be documented somewhere. If you read my suggested addition, it was not on the override page, but rather on the modify shapes page.

Are you really saying that a modify shapes page is not a relevant place to discuss techniques for modifying slurs?


> The shape of curves affects the overall look of the page.  You would want
> to affect them globally to achieve a "house style".

Yes, once you understand how to affect individual aspects, then you
can design a house style. An apprentice music engraver would learn to
perfect using each punch before getting to design the overall style.

You are again ignoring that the approach of \shape, while it can be applied globally and not just one-at-a-time, is not an appropriate tool for this type of modification, since curves of different dimensions (for example, a slur between two adjacent notes one tone apart, versus a slur across several measures spanning an octave) will not be uniformly improved by specific deltas.

Whereas modifying the default parameters does achieve more scalable results.

Also, we're not in the 18th century any more.  There is no "skill" to executing an engraving, there is only taste in choosing something you like.

Since we're using computers, it is essentially the same amount of work to adjust things globally as it is to adjust a single curve.  Actually, less, since you only have to do the global adjustment once.


More importantly, you cannot evaluate a style by looking at one curve.  That's like trying to pick a document font by looking at how one word looks.  You need to look at the entire document (or at least a page, or relevant flows) in order to evaluate your choice for things like readability and density.

Plus, did I mention that the \shape and overrides of ratio/maximum-height do not perform the same functions?  So, even if you do perfect one slur, there is no way to apply that globally (in a useful way--sure, you can apply the \shape as an override, but it won't give you useful results.)


> Or, simply choose a starting point that fixes most of the issues with the
> curves, before proceeding to the tedious work of one-at-a-time techniques.

My experience of learning is to start with specific examples and then
generalise them, so I remain unconvinced (from a learning angle).

Documentation is not all about you.  It is about many people.

There are different styles of learning.  It seems weird to me to suggest that because you might not benefit from something, that no one else would.


I was troubled because, like others possibly, I wasn't sure of your
distinguishing setting defaults within, say, ily files and setting
them in scm files (a closed book to most LP users, I suspect).

Sure, I was asking about how to more properly use the hacks that I discovered by modifying the scm files.  Because clearly, modifying the scm files is not an approach that plays nice with others.

When the response was, "of course this can be done using code", that led me to wonder, why was I not able to find any mention of this in the documentation.

The answer is that it is because it is not there. 

Sure, it is theoretically possible to figure it out.  But has anyone done this?


On that note, regarding whether this approach of modifying slur ratio, height-limint (and free-head-distance) is being used:

If you search the LSR for "slur ratio", there are zero results.

Searching for "slur head" yeilds one unrelated result.
http://lsr.di.unimi.it/LSR/Item?id=308

Searching for "slur limit" or "slur height" yeilds one result
http://lsr.di.unimi.it/LSR/Item?id=501
Which does use this technique.  But is not the type of example that seems applicable, given that it is non-standard notation.  So while it is technically true that someone has used this, from a documentation standpoint it is not terribly helpful because it isn't obvious what the problem is that is being solved.

 
> > > For now, here are some proof-of concept intermediate versions from the
> > > piece that spurred me to try this approach.
> >
> ...
> > > My final version is not ideal to compare since the line breaking is
> > vastly
> > > different.
...
That's the main problem with my making an A-B comparison between the
examples you gave (apart from having to have two screens to keep track
of corresponding bars). I thought my suggestions were apposite for
making a pair (or triple) of A-B-comparable PDFs.

What part of "My final version is not ideal to compare since the line breaking is vastly different" did you not understand?

Why are you explaining something to me that I pointed out ahead of time?

 
I can see you have avoided one collision in bar 31 (67 is the same,
though (3) lacks it altogether).

The problems I see in my original include bars 7 (too close to tuplet number), bars 31, 40, 66, 67, 68, 75, 76 (crosses accidental), as well as bars 7-8, 43-44, 49 (slurs too far from notes).    That's about 11 out of 32 slurs on the part, or 1/3 of all slurs being problematic.

(This is not even counting the ones that are split across staves, which are too short, and I still don't know how to solve that.)

Every single one of these issues was fixed by the intermediate iteration!  This created other problems (generally, too curvy), but those were fixed by choosing better values.

 
I wondered whether there might be
any mileage in using the penalty mechanism to make avoidances like
this happen.

See, here is something I've just learned.  What is a penalty mechanism?  Why isn't it discussed on the modifying shapes page?

Let me guess--it is a general mechanism that all objects use, and therefore we cannot be expected to document all possible cases of its use.

Well, that may be true, but that doesn't mean that adding useful discussions or examples wouldn't improve the utility of lilypond.


Wouldn't it be great for the docs (about modifying slurs) to to start with a discussion of typical curve issues (collisions, spacing, etc.) and then document various approaches to dealing with them?

I'm not saying that what I stumbled across is the end-all-be-all.  In fact, using Carl's suggestion for free-head-distance will probably cause me to revise the values I use for ratio and height-limit, if I end up using them at all.

My point is that this approach is vastly better than what is presented in the docs, for solving the majority of problems in this area, at least in my scores. 

The alternative was so tedious for me, that for years I just gave up, and accepted mediocre results.

So, that's why I think this may be an improvement worthy of discussion.

 
I don't see where my attitude comes into it. You've made yours clear
in your first and last sentences (and the implication of trolling).

Mostly because of what I said at the top of this post:
Your motivation seems to be in maintaining low-quality documentation.

And your snippy tone ("Oh, and keep the notes the same")


Glad to see that there is some value in this exchange despite all that.



Thanks,

David Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
address@hidden
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


reply via email to

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